• State Accepted Answer
  • Locked Locked
  • Replies 16 replies
  • Answers 1 answer
  • Subscribers 25 subscribers
  • Views 19621 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

How to (easily) flash a custom .hex file with debugger?

Aina R

Hello,

I am developping on a firmware using a bootloader which verifies main application's CRC prior to let it start. To do this, I am generating an extra .hex file with data for bootloader added to the .hex file created by Keil. 

I thought I just had to rename my .hex file with data to the name of the one generated by keil... But Keil's debugger is loading the .axf file, not the .hex one :-(

The only workaround I found was to load my .hex with data with another flash programmer, and then start debugging with Keil to have debug symbols. 

Does anyone know how I could do this directly with Keil ?

Thanks a lot in advance!

Parents
  • 0 in reply to Robert McNamara
    Robert McNamara said:

    If your bootloader was a totally separate project, you would never need to combine it with your application. 

    You would build the bootloader and load your bootloader.  

    This is what I am doing, but as bootloader is executing before the application, and is testing application's CRC, every time I change application's binary, I need to update its CRC, otherwise my bootloader would refuse to start the application. 

    Robert McNamara said:
    The application being totally separate would mean that you build the application, add the CRC and create hex file.  load the application hex file. Then Debug the Application using the *.axf debug symbols. (without loading code when  you start the debugger since  you already have the code you want loaded, you just need to symbols)

     

    This is what I am doing, but as I already explained twice in this thread, loading of my first .hex file (the one containing application's CRC) fails with keil's debugger, although I have no problem while loading it with STM32CubeProgrammer.

    I am getting the error "target memory verification failure", followed by "error 57: illegal address (0x800C000). (Note: 0x800C000 is my application's starting point)

    Other strange thing: if I first load my .hex with STM32CubeProgrammer, and then start a debug session with Keil, I get no error.

Reply
  • 0 in reply to Robert McNamara
    Robert McNamara said:

    If your bootloader was a totally separate project, you would never need to combine it with your application. 

    You would build the bootloader and load your bootloader.  

    This is what I am doing, but as bootloader is executing before the application, and is testing application's CRC, every time I change application's binary, I need to update its CRC, otherwise my bootloader would refuse to start the application. 

    Robert McNamara said:
    The application being totally separate would mean that you build the application, add the CRC and create hex file.  load the application hex file. Then Debug the Application using the *.axf debug symbols. (without loading code when  you start the debugger since  you already have the code you want loaded, you just need to symbols)

     

    This is what I am doing, but as I already explained twice in this thread, loading of my first .hex file (the one containing application's CRC) fails with keil's debugger, although I have no problem while loading it with STM32CubeProgrammer.

    I am getting the error "target memory verification failure", followed by "error 57: illegal address (0x800C000). (Note: 0x800C000 is my application's starting point)

    Other strange thing: if I first load my .hex with STM32CubeProgrammer, and then start a debug session with Keil, I get no error.

Children