Meeting new people and progress on the atmega loader

On Wednesday evening, I decided to venture into Birmingham to visit a hackspace I'd found online, fizzpop which coincidentally has just moved to the Black Country Atelier premises. Even though I'd printed out a map and had a rough idea of where I was going, I foolishly trusted the satnav which twice took me into the very middle of city centre from different directions, getting me lost each time before I eventually decided to just ignore it, checking the printed map at every red light instead.

Anyway, there were about 10 other people there, and there seemed to be a healthy interest in a bunch of areas. I started off looking at one guy's MakerBot 3D printer which was pretty interesting, but soon realised that almost everybody had wandered off for instruction on how to use the laser cutter. I caught the last half of the safety briefing and watched a couple of pieces of acrylic get cut up at different laser strengths and speeds as a demo. Later on, a couple of the guys etched a QR barcode into some transparent acrylic and burnt the same barcode onto some wood. Both turned out really well.

I'd take along my fpga board, as I wasn't really sure what to expect of the evening but figured I could always hack some more on the AVR code I'd given up on when it seemed to stop working. I didn't actually spend much time at all coding during the evening, but I did notice that the debug data did actually seem to suggest the JTAG chain was working, even though the code didn't work. I kind of knew that as it was previously working and then stopped, but it piqued my interest a bit more. After running some test patterns, I noticed that they were more often than not getting corrupted.

For some reason I woke up really early this morning, and decided to take another look. There were two problems, all within about 3 lines of each other... and in the most fundamental function in my code - the one that clocks in and out a bit of JTAG data! I was reading the TDO before pulsing the clock high and low, as per the spec, and pausing for a few cycles to bring my JTAG clock speed down to about 1MHz. However, because this function was inlined, in a lot of cases where multiple bits are written to change state, there wasn't sufficient delay in the TCK low state before the next bit was written out. So, what worked fine when only the PROM was in the chain (which supports a 33MHz JTAG clock) failed completely when the FPGA itself (which only supports a 25MHz JTAG clock).

Unfortunately, now most of my good JTAG test code, including all the boundary scan test suite is written for the Raspberry Pi GPIO pins, but I think I'll add another command to the AVR code to allow JTAG over serial so I can run my boundary scan code on the PC via the AVR.

I've also opened up the source for the schematic and all JTAG code to date, so this is now available on github.

SCART socket attached, test of video and RAM

Found a couple of problems, but nothing that wasn't easily fixable. Here's a quick program that's scrolling through RAM, advancing half a pixel horizontally and one vertically every frame. The left of the triangle is bits 5-7, the right is bits 2-4 and bits 0-1 (with no blue component):

$TIME_OF_LAST_POST + 30 minutes

Heh. So, after I wrote the last post, I used the braiding wick to remove all the excess solder around the data out pin of the PROM. It looks a lot tidier, but my multimeter was still showing a short to VCC. Turns out, under the PROM there are 2 vias very close together (and pretty close to the pins) for data in and VCC. Fortunately, braiding wick on the pins managed to suck up all the excess solder here and solve the problem. Interestingly, those pins looked fine in the photo I'd used to check the soldering there...

Hopefully later today, I'll try to drive pins via the boundary scan to see if I can detect any other shorts, but in the meantime this is worthy of a new post!

Very slow month

So, this has been a really slow month, mostly spent fighting with the Atmel chip rather than doing FPGA stuff... :(

After the initial problems with the chip that didn't have a bootloader on it, prompting the creation my impromptu Z80 based Atmel programmer, I managed to get things working. Wrote some nice code that'd allow you to send commands like "j" for JTAG scan, "e" for erase, "r" for read and "p" for program to the USB serial port and it programmed the PROM quite successfully. You could program the PROM from a .mcs file with just

echo p >/dev/cpc2012
cat testfpga.mcs >/dev/cpc2012

So, it seemed I was ready to solder on the FPGA chip. So I did. Joy of joys, I did a JTAG scan and it detected the FPGA. \o/

And then I modified my FPGA test code to copy the joystick pins to the GPIO pins so I could test it. Nothing happened. I then encountered my first "issue". I decided to watch the data line between the PROM and FPGA with my scope. So, I attached the ground probe to the PCB ground and straight away, something odd happened... the USB connection dropped. Every time. Repeatably. So, I investigated a bit. It turns out that neither the power brick I was using OR the laptop power adaptor are earthed properly. The scope is. And just attaching the scope signal probe to PCB ground showed my ground was following the mains AC curve at 230V peak. Presumably, the PCB ground was floating, because it happily carried on working rather than frying, but clearly just attaching the probe causes a momentary high voltage potential sufficient to reset the AVR. Great.

So, undaunted I carried on... (well actually, I was pretty daunted really, and spent a couple of hours measuring ground potential on a whole bunch of things thinking it must the the scope ground that was faulty because it was new and there were a couple of scare stories with the DS1052E on the internet, but I eventually concluded that the scope ground was DEFINITELY mains ground and so it was the other non-grounded kit that was the problem).

So, I carried on testing a few things in my code thinking maybe the data was sent to the PROM in the wrong bit endian because the datasheet doesn't mention anything about endianness. And that's when the real weirdness started...

Suddenly, my JTAG scanning code stopped working, even though I hadn't changed any of it. I soon realised that I'd run out of RAM (the AVR has a tiny 1KB) because it was copying all my strings from flash into RAM to pass to sprintf. Not great. More research, and I discovered sprintf_P and moved all my strings out of RAM. Suddenly, I got down to about 40 bytes used plus stack. And then things stopped working again. This time my entire JTAG scan stopped working. Thinking I must have a dry joint, I removed and swapped every chip on the board. Still nothing. Even when I reverted my code back to what was in the repository back when I knew it worked. I then hit some weird issues with the USB. For some reason, every time I flashed my chip, it wouldn't be detected by USB. The bootloader worked, but each time I ran my code, it never worked on the USB. I pulled out my Z80 programmer again and investigated. Turns out the flash was clearly faulty (remember this is the one that didn't have a working bootloader from new). Doing a chip erase and reading back the contents returned a few bytes of error. Repeating this over and over kept returning a few of these faulty bytes over and a few others that seemed more random. But essentially, not erased. Re-erasing moved the faults somewhere else. After that, I never managed to get a working bootloader on it again. So, I replaced the chip, and whilst I was at it, moved to a 8MHz crystal as I realised that 16MHz required a 5V supply and I was trying to use 16MHz with 3.3v.

Code working and USB detected fine on the new chip, but JTAG had stopped working again. Kept trying more things, and this seemed to cause the code to stop working. Now simple commands like "-" which just echoed back 79 "-" characters and a new line started producing 4 lines of output when seemingly every other command executed fine. Looking at the disassembly, the code looked fine, but still the problem persisted. And also when I tried on another board.

By this point, I was almost ready to give up. I've spent quite a lot on all these parts, and I now have 3 boards that pretty much don't do anything. However, my Raspberry Pi just arrived and I thought I'd play with that. Just out of interest, I decided to knock up a quick JTAG interface using the GPIO pins, figuring I could power it from my board and so that'd cut out the laptop power supply out of the equation. Imagine my shock when the very first time I ran this, I could see all the correct bits coming back from the JTAG scan. So, the last couple of days, I've ported all my AVR code to the Raspberry Pi, which to be honest is a much easier development environment too - it's just make and run, rather than make, flash, reset, cat and echo.

So, my JTAG stuff is now currently fully working on the Raspberry Pi. I can erase, flash and dump the PROM and even do a boundary scan read of both devices and that's pretty cool seeing that my joystick ports and clock all appear to be working.

However, the FPGA is still resolutely unable to boot from the PROM. Possibly it's a short on the data out pin as it seems to still be stuck high (see photo below in hi-res).