Software testing for a bare-metal system

Question

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.

Answer 1

I think you're best bet is to work with the vendor of your compiler to get a device simulator.

Tessy supposedly works with that chip. Check out: http://www.hitex.us/products.html?con_186.html~content

Answer 2

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.

Answer 3

When timing is important I like to use a free I/O pin or two and a scope together to instrument the code. I'm also a fan of the JTAG port for source-level debugging. You can also have the microprocessor store a vector of data and send it back over a second uart (if you have one) to the PC for analysis.

Answer 4

Something that I've seen done in this sort of area is unit testing.

No, I'm not joking.

Unit tests run on the device, under the control of the host PC.

You write a wrapper to ley load programs into SRAM under unit test control.

Then your PC can send a program, run it and check the output.

If you need to exercise your board , get a labjack or similar USB interface card.

Now that's the hardware in a test jig, all run from yours host PC.