Debug bootloader and application

Go To Last Post
6 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I know this question has probably been asked a dozen times, and I'm sorry, but I have never actually found a satisfactory answer, so I figured I'd ask it myself to get clarification.

Is there a way to debug a bootloader and application combo at the same time if they are built as separate projects? I'm currently using AVR Studio, but I could get a different tool if need be.

I have combined the two hex files as described elsewhere on the forum and flashed the chip with that, but I'd really like to get in there with my JTAG and make sure everything is working. Can it be done Freaks?

Thanks

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Huh?
Bootloader normally written and used independent of application. Or use one that's bug free and off the shelf. Then installed in Flash and used and forgotten.

Flashing the app does not erase the bootloader if you are using the bootloader to, er, boot the app.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

There are still people who write their own code (bootloaders included). As such, a need exists for debugging.

Unless the AVR tools (AVR Studio, JTAG ICE MKII, or Dragon) has changed in the last year or so, then the answer to your original question is no. You cannot debug the bootloader and app code together if they were built as seperate projects.

You cannot upload seperate hex files (for example a hex file for bootloader and another hex file for application) simultaneously into a device, then perform symbolic debugging.

Here is the problem.
Everytime that you upload a new hex file into the chip using the MKII, it performs a chip erase. Forget about the MKII options checkbox that leads you to believe that a chip erase can be avoided before code upload - it doesn't work. You can build seperately, then merge the hex files together, but you will only get debugging information for the last build. Either the bootloader or app code debugging information is going to be left out.

If you are writing your own bootloader, and need to debug both bootloader and app code simultaneously, your best option is to write your bootloader as a seperate C or asm file, and always compile and link this module with your app code. Doing this will allow symbolic debugging of both bootloader and app code. The debugging information file (COFF, ELF/DWARF, etc) will have all of the symbol information for both. In addition, one hex file will be created for both.

As Stevech has suggested, it is a good idea to keep the bootloader as independant from the app code as possible. But this doesn't mean they have to be built as seperate projects, just written as seperate modules.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

jgiers wrote:
Is there a way to debug a bootloader and application combo at the same time if they are built as separate projects?

Why anybody should do so?

At first write the bootloader and debug.

Then write the application and debug.
No need at this time to debug the bootloader too, since it was already proved as working.

Since a bootloader should never influence the application, you can also debug the application without the bootloader installed.
E.g. if you debug over JTAG and JTAG erase always the whole flash.

Peter

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

Here is the problem.
Everytime that you upload a new hex file into the chip using the MKII, it performs a chip erase.

Well not that it helps much but that particular problem is easy to fix - you just join the two .hex files and then program one composite, whole flash .hex file. The problem you have though is that the symbolic info for debugging the app is in app.elf and the symbolic info for the boot is in boot.elf and there's no easy way to join those two and persuade the debugger to use composite debugging of both.

But as others have said why would you want to do this? You write and debug the bootloader and once that's working you set it to one side as a "black box" and then you work on the app code and debug that completely separately.

The one exception is that you may have shared some of the functions of the bootloader (probably by a jump-table) for use by the app (maybe the serial comms. routines for example?) but in this case just continue to treat the bootloader functions as a "black box". You already tested and proved those when you debugged the bootloader so now - just like libc functions like memcpy(), strlen(), printf(), etc. - just take it as read that they work and there's no need to step into them as you debug the app (just use "step over" when they are called from the app code).

Cliff

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Thanks guys. A solid no it is then.

My reason for wanting to do both is that my bootloader relies on some other hardware that isn't operational yet, so I can't debug it on it's own, but I wanted to simulate the case where the application is already flashed just to verify that. I guess I'll just have to wait.