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).