Search code examples
embeddedbare-metaltightly-coupled-code

Software testing for a bare-metal system


I am writing a project in C++ for an embedded system with no OS support; almost no library support. Very bare-metal. Hence, a fair amount of my code is tightly coupled(e.g., software triggered interrupts and the layer directly above them).

Part of what I am doing involves changing the serial port configuration, thus driving concurrent change on the PC end (the UI end) and the microprocessor(the activity end). I'm doing okay so far in a super-careful incremental type development(piece by piece fitting it in). However, I'd like to be more confident about my code working in an engineering sense.

What kind of methodologies/frameworks would you recommend for this kind of situation?

Edit:

I use the AMD186 ES on an ACore86 board made by Tern, Inc. Compiler: Paradigm, free edition(ships with the board). I don't have an option to change what I'm working on, unfortunately.


Solution

  • The lack of infrastructure in a bare metal environment is pretty challenging. I'd recommend you focus on debugging tools. Even with great care and excellent methodology, you'll need the ability to debug things.

    It would behoove you to get gdbagent working. You'll need to implement this yourself, but it is a simple text-based protocol. You run gdb on an external machine and communicate with the gdbagent on your target. You certainly could run the gdbagent protocol over the serial port, but this rapidly becomes tedious when large amounts of data need to be examined. If you have a faster interface available, take advantage of it.

    I don't know what your budget is, but you should also plan for a JTAG debugger. gdbagent is great so long as your gdbagent on the target is able to run. If everything crashes hard, you're toast. JTAG debuggers are enormously expensive, but can be rented. I've used Corelis products in the past, and I've heard good things about Abatron.