Debuging code create by IAP

[Barbie]

Posted on April 03, 2013 at 08:34

When I write a code with the BootLoader as IAP there is a question how i can debug it. I wander why it nit arise before.

I put the BootLoader code on the debuger and run with it all the way till it finish to write the main code start on the offset address . But when it done it jump to the new location (offset address )and start to do the main program. But the debugger doesn't have the code in C. so how can I trace it?

I think mybe after debug the boot and write the new code at the offset point upload the main prgram to the IDE (IAR) and then go on Debbug without downloading. Does the IDE can connect between the HEX file it see and my C written code? Can it work?

Bar.

[Tesla DeLorean]

Posted on April 03, 2013 at 10:05

The term you're looking for is wonder, to speculate curiously

, rather than walking aimlessly, or with distraction.

I think most debuggers are capable of stepping into code that is alien to them, and while in many cases the disassembly might be a tad distracting it should be quite sufficient to isolate hand over issues which occur between the jump, and the start of main() of the primary application. Walk along with a .LST file if required, most of the time the code in startup.s should be familiar. Debugging code without a symbolic debugger or source view, is a practical reality many of us grew up with. When it takes 15-30 minutes to erase and program a new set of EPROMs, or if you destroy a $25-50 worth of OTPs, each time you crash-n-burn you learn to be pretty resourceful.

I can't speak to IAR, but in Keil it's reasonably straight forward to walk through the boot loader portion of an IAP with the source loaded, and then navigate into the startup code of the application. Start with the premise that you should be able to test each portion independently, and then bring them together later. The biggest problem for the application is assuming initial conditions of the core/peripherals incorrectly, or without sufficient care.

Conversely if you load up the application code, a ''Run to main'' check box should clear you of the boot loader and into familiar territory. Break pointing should also be viable.

Outputing via a serial port, and using suitable check points, you should be able to ascertain where you are, and conditions on the ground. Such messages should permit you to bisect any problems you have, and focus on where they are.