SUCCESS!
Yes, you read that correctly. I managed to get the board working from my last post. Lucky post 13! I removed the SDRAM chip and the short between GND and the 3.3v line disappeared. Perplexed, I re-checked the data sheet and yes, I’d made a mistake. There are three VCC and three VSS pins. I’d transposed the last two of these. Ah well. This board was never going be the final build anyway, so I just removed the SDRAM chip with my hot air hand tools.
The regulators and inductors were still running hot, so I suspected there was a further issue, but the LED was alight now, which was a good sign. The voltages out of the regulators were a bit low, so I checked some key components, such as the clocks and lo-and-behold, I’d placed the 50MHz oscillator at 90 degrees out. These chips are 2mmx3mm, so excuse this minor fault. I removed the oscillator and the line voltages returned to tolerance and the heat in the regs and inductors went away. Woohoo!
I soldered on the JTAG port for my Atmel-ICE programmer and programmed an initial hello world program. I upped the PLL so that the ARM core ran at 120MHz and it was quite stable. If you switch from low speed to maximum clock it sucks a huge gulp of power from the supply lines, so if the regs, inductors and noise suppression capacitors are not sufficient the core self-resets. I didn’t see any behaviour like that, so I’m confident the Atmel SAM core is good.
I also found a few other stupid mistakes, like I’d provided a jumper to erase the ARM microcontroller, but jumpered it to ground and it needs +3.3v to erase. I also managed to set the security bit while fiddling with the programmer, so I was locked out of the chip. Luckily, the Atmel-ICE cable has two connectors, both a 0.05″ and a 0.1″ pitch connector. So I took 3.3v from this ribbon connector and zapped the erase pin during power up and wiped the security bit, allowing me back into the chip programming mode.
I wrote a quick program to toggle the FPGA configuration lines and managed to get an acknowledgement level-shift on the status line, so all good so far! I tried to get a fault condition, by sending zeros and all-ones to the FPGA, but couldn’t elicit a fault response, so I suspect it’s waiting for specific value before it starts it’s configuration process.
As I write this, I’m installing Altera Quartus on my new HP all-in-one, so that I can create a bitstream simply to turn off the LED (it defaults to on) and see the CONF_DONE line go high. That’s probably some way away, but I thought it worthwhile to report this success after another apparent failure.
I’ll be able to test the other components on this build, so it’s not a waste and I’ll perfect the supervisor programming software and test the remaining components before the next build.
Stay tuned for my next post!