Software testing for a bare-metal system [closed]

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

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 2

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 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.

Answer 5

One thing I've done with some success was to design a PC environment where code can be compiled with C++ for the PC and tested, and then later compiled with "straight" C to run on the embedded system. I/O port references are #defined to be property accesses for an I/O object, which are then sent via socket to a "hardware emulation" program. Parts of the system ended up being clunkier than I would have liked, but I expect succeeding versions will be less clunky.