Re: [avr-chat] boundschecking & instrumentation

[Benjamin Titzer]

> > > If you are interested in some interesting tools that are designed  
> > > for
> > > the AVR then I suggest that you look into Avrora:
> > > <http://compilers.cs.ucla.edu/avrora/>
> > > Among basic simulation it also has: profiling utilities,  
> > > instrumentation
> > > capabilities, control flow graph tool, and a stack checker. Note,
> > > however, that I have not tried Avrora so I cannot comment on its  
> > > efficacy.
> > That I will check out.
>
> Avrora would be much better because of the static checking that it  
> can do. Rather than implement the SD card interface.

Avrora can also do dynamic checking on your code too, with its  
instrumentation capabilities. There is a description of its  
capabilities in "Nonintrusive Precision Instrumentation of  
Microcontroller Software" in LCTES 2005 (linked on the webpage).

We originally wanted to do a lot of static analysis on AVR code, and  
there are still people in our group working on the project, but the  
static checking capabilities of Avrora are superseded by its dynamic  
capabilities.

> > > Could you be a bit more specific with what you would like to see?
> > Well, medical, automotive, and aeronautical systems usually require a
> > higher standard of testing.  Often it's done with the .elf file on a
> > simulator, but given a filesystem, it can be done on the target.  As
> > far as boundschecking, I find most bugs in embedded systems are
> > pointer/array bounds accidents.  Instrumented code could give line
> > numbers over the uart when detecting bounds overflows.
>
> - If you're talking about simple instrumented code with a UART  
> interface, then that is easier than implmenting the full SD Card  
> interface. And it would probably be faster than trying to use these  
> other projects.

You can also have your instrumented code output to the UART, just as  
you would with a hardware device, in Avrora. You can then have the  
UART interface connected to a socket so that the program running in  
simulation outputs to the simulated UART, which in turn outputs to a  
socket that you can dump or debug on.

There is a monitor for doing serial connections that a number of  
people at UCLA have been using to debug their code in both simulation  
in hardware, so if you want a solution that works in both situations,  
then it is possible.

Hope this helps,
-B