• State Accepted Answer
  • Locked Locked
  • Replies 16 replies
  • Answers 1 answer
  • Subscribers 24 subscribers
  • Views 19291 views
  • Users 0 members are here
2025 survey

We are running a survey to help us improve the experience for all of our members. If you see the survey appear, please take the time to tell us about your experience if you can.

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