Tuesday, 23 August 2016

First Project On The Waxwing Spartan 6 FPGA Dev Board

This is a story about doing the obvious things first, and in the process defining a 'golden rule' of debugging hardware.

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.

The on-board LCD is a standard 16x2 HD44780 setup, in a 4 bit configuration, which has a pretty simple protocol. The only slight concern of this is the 4 bit interface, where we have to write the high nibble first, followed by the lower nibble. 

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'
An update of the clock period and the constraints file to direct signals to the on-baord LCD, and everything feels like childs play. Synthesising the design and programming the FPGA and ...... ohhhh ..... nothing,  a blank LCD. 

OK, this is no problem, obviously I've:
  1. Specified the wrong output or clock constraints; no, they look fine.
  2. Is the LCD contrast turned all the way down; no, tweaking it makes no difference.
  3. Does the unit have power; yup, the LCD backlight is working fine.
  4. Is the configuration actually running (did I program correctly); a quick update to also flash a LED on the board works as expected.
So, not so simple after all. My list of 'traps for young-players' exhausted, it's time to break out some more serious assumptions, and test them.
  1. Maybe the LCD is duff
  2. Maybe the FPGA pins or traces (that lead to the LCD) are busted
  3. Maybe the design and/or core is not doing what I expected it to.
So, to discount #1, the on-board LCD is broken, we can re-direct the LCD control pins out to external headers and plug in an off-board LCD module. A few mins later and a nest of wires on the bench I have a similarly non working LCD. checking the possible problems we see that 1 and 2 have been (most likely) discounted. So sigh, its probably something to do with the core or design. 

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!

No comments:

Post a Comment