• State Not Answered
  • Locked Locked
  • Replies 4 replies
  • Subscribers 22 subscribers
  • Views 4668 views
  • Users 0 members are here
Options
Related
How was your experience today?
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

debugging a bootloader and Application

Dan Curran

Folks
looking into debugging a curious issue and I was wondering how others have gone about this process before I jump in trying to get something working

I have a bootloader that occupies the bottom 48K of STM32F2xx micro
the next 16K is used for system parameter ( eeprom type storage)
then from the 64K upwards I run an application

Currently the Bootlaoder and Application are seperate projects and I have been developing and bugging each part seperately

Now I want to be able to debug both parts at the same time
e.g the application FTPs a firmware update via GSM to a SD card and then sets a non volatile byte that is used to indicate to the bootloader there is an action required after startup the application then uses a cmsis call to reset the micro and therefore run the bootloader.

Currently there is a problem e.g.

The bootloader part of the code works fine when I use a USB MSD to load up a firmware update to the SD card and then reset the micro. But when I have a GSM provided update the bootloader apprears to ignoring the new firmware file but clears the non volatile byte indicating that new firmware is available.

Is there a way of combining two projects each with different start vectors and ISR vectors
while being able to step through the code and go from the the bootloader to the application.

Parents
  • 0

    The ini file for the debugger can be used to download extra hex data before you start debugging.

    But I don't know of any way where the debugger will know about debug information for both boot loader and application.

    Personally, I would probably settle for a couple of well placed print statements to tell what one side thinks it is handing off, and what the other side thinks it is finding.

    The download code should be able to hand off a binary complete with valid CRC-32 or whatever you use to validate your firmware download. And it should then set that magic flag and request a reboot.

    The boot loader should be able to see the flag, and it should be able to verify that there is an image with correct CRC-32 (or whatever you were using) before i decides what to do.

    If this isn't fulfilled, then the printouts should be able to tell where the failure was seen. After all, the boot loader is expected to be KISS, so a limited number of logic blocks to make the decisions.

Reply
  • 0

    The ini file for the debugger can be used to download extra hex data before you start debugging.

    But I don't know of any way where the debugger will know about debug information for both boot loader and application.

    Personally, I would probably settle for a couple of well placed print statements to tell what one side thinks it is handing off, and what the other side thinks it is finding.

    The download code should be able to hand off a binary complete with valid CRC-32 or whatever you use to validate your firmware download. And it should then set that magic flag and request a reboot.

    The boot loader should be able to see the flag, and it should be able to verify that there is an image with correct CRC-32 (or whatever you were using) before i decides what to do.

    If this isn't fulfilled, then the printouts should be able to tell where the failure was seen. After all, the boot loader is expected to be KISS, so a limited number of logic blocks to make the decisions.

Children