With the tool chain sorted out I'm clear to start designing configurations for my new Waxwing Spartan 6 FPGA development board. I think that it may be a good idea to start with something simple, and possibly useful, before jumping into some of the more complex peripherals. So first up is the on-board LCD. This way, in later projects, we can give ourselves a fighting chance at debugging our designs, when things don't go to plan.
With almost zero thought I decide to use one of the off-the-shelf 'cores' that will bit-bang the initialisation and display data for us. I'm a big believer of reusing code, and seriously what's the point in writing this when there is almost zero scope to change what other people have done before. So, a tiny amount of searching leads me to stachelsau's LCD controller core, a nicely isolated routine that will take a simple signal containing the data we want to display, and just do everything for us.
'Trying is the first step towards failure'
OK, this is no problem, obviously I've:
- Specified the wrong output or clock constraints; no, they look fine.
- Is the LCD contrast turned all the way down; no, tweaking it makes no difference.
- Does the unit have power; yup, the LCD backlight is working fine.
- Is the configuration actually running (did I program correctly); a quick update to also flash a LED on the board works as expected.
- Maybe the LCD is duff
- Maybe the FPGA pins or traces (that lead to the LCD) are busted
- Maybe the design and/or core is not doing what I expected it to.
This really is the fun bit, but is slightly earlier than I was expecting. So, what can we do here? Well, some people like to use simulation (I'd prefer to leave that to the testing, rather than use it as a debugging tool). Some people use a series of flashing LEDs. I find that works well when you have a slow and isolated area that you want feedback on, but not so great for seeing what's happening at a system level. I think what we need hear is a logic analyser. With a growing nest of wires on the bench, things take an awkward turn. The waveforms look exactly how I would expect!
Well, this could mean only one thing - that the LCD on the board is bust and I've not connected power to the off board LCD correctly. I break out the multimeter and check the break-out 5v power pins.... 3.5v! What? A check of the main board 5v rail also shows 3.5v. It's 3.5v everywhere. The board is powered by USB which I'm sure is 5v so, what gives. Tracing things round it looks like the guys at Numato directed both the USB power in, and the 7-15v power jack in, into the same 5v regulator, meaning that if you power the board using USB, the 5v will always be low because of the regulator drop-out. What the ****?
With the 5v line being low, it was enough to power the FPGA and LCD backlight, but not enough for the LCD controller. Switching over to power the board from an external 9v supply and..... presto, everything works as I'd expect.
And, here we have our golden rule : To quote a great man, Dave Jones of the EEVBlog, "When debugging hardware, thou shalt always check voltages".
The astute of you will notice that I had and passed right by the solution very early on. Point 3 of the original checklist "Does the unit have power; yup, the LCD backlight is working fine.". Note to self, a LED on does not mean we have the right voltage. D'oh!