You’ve finally got prototype PCBs back from the manufacturer. All you need to do now is tweak the code you’ve been writing on dev boards to use the right GPIOs and you can compile and go, right?
Well no, not really.
There is an order to the things you should do to safely bring up a new board, and it mostly doesn’t concern your prototype application. The very first thing you should do if you are a software engineer like me is to get out of the way and let the hardware engineers do their thing. They first need to inspect that the boards are correctly assembled; no missing components that aren’t supposed to be missing, or components grossly out of alignment with where they are supposed to be, or unexpected short circuits. Components may even need to be fitted if they weren’t fitted during manufacture, which can happen for a whole variety of legitimate reasons. This can be very important feedback for full-scale manufacturing, so no sensible developer should skimp on it.
Once all that is done to the hardware engineers’ satisfaction, their next job is to bring up the power and make sure that no magic smoke escapes. Power supplies can be contrary beasts, and it may take a while for your colleagues to be happy that all the power rails come up to the right voltages in the right order, and that they aren’t generating excessive ripple or noise.
Finally it’s your turn. The processor has power, so all you have to do is port your nascent application over and try it out, yes?
Don’t be silly. You should run the simplest possible code you can get away with, just to prove that your processor is actually running at all. Usually this means setting up the clocks (which will be different for every processor and board), configuring a single GPIO and turning it on. I always ask for some general purpose LEDs on prototype boards to make this easier, but if you haven’t got any then attaching a logic analyser or oscilloscope to a convenient test point will do. It is very much worth writing this code to poke the necessary registers directly yourself, not using any sort of chip support library. You want to know exactly what is going on, and to make it as simple as possible. Having anything in the way may introduce a source of misconfiguration, and that’s the last thing you need when you aren’t even certain your processor is running properly.
Once that works, rewrite the code to turn the GPIO off just to make sure you didn’t get a false positive.
I’m belabouring the point a bit here, but it’s worth saying repeatedly: Keep It Simple, Stupid. We all have that enthusiastic impulse to leap straight in because it’s going to work, right? That’s almost never true, unfortunately, and the more complicated the thing you try the harder it is to find the specific thing that is going wrong. And something will go wrong, that’s a given of prototyping. I generally end up with a lot of different tiny applications to validate different parts of the hardware, even when my final application will be a Linux installation, just to be sure that the relevant lines are waggling up and down when they should be. It’s not that I don’t trust the support libraries (the Internet would be full of howls of complaint if they didn’t work), it’s that I don’t want them in between me and the operation of the hardware blocks.
Occasionally you discover things about your processor this way. On one otherwise excellent processor that the manufacturer tries really quite hard to force you to use the support library for, I wondered why the library didn’t offer an I²C write-then-read operation, the sort of thing that you want if you are reading registers from a peripheral chip. It was only while writing my bare-metal validation code for the I²C hardware that I discovered the processor’s onboard I²C can’t do a restart, almost uniquely amongst processors I am familiar with. That in turn changed my I²C driver design. It couldn’t allow the write that selects a register to get separated from the read of the register without risking some other register selection intervening, which would have been a disaster.
Only once you have proved to everyone’s satisfaction that the hardware works as expected should you actually try your prototype firmware out. Even then, if you are using an RTOS or a fully fledged embedded OS you should start with a trivial demo rather than your full prototype; waggle an LED or write “Hello, world!” to the serial console, whatever seems simplest. You want to have confidence that your operating system came up correctly when inevitably something goes wrong with your actual application.
Think of it like building a house. If you don’t make sure that your foundations are secure, your building may remain standing but it‘s much more likely that it will collapse unexpectedly. Fix your foundations, your lowest level connections to the hardware, and you are much more likely to build the ground floor of your house successfully, and that in turn will hold up the next floor.
In an ideal world, bringing up new hardware shouldn’t be a huge part of a project in software terms. I hope this article has given you some ideas for how to make sure that’s true for your project.