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!
I am generating a .bin file with fromELF after my build process (I need it to load my application with the bootloader), then I compute its CRC and write it to the data zone with a "home made" script.
I am going to go backwards (i.e. Start from a boards that has your bootloader and hex file already loaded)
1) To start debugging this, you need to be in your Kiel project with the associated axf file. Edit your debug options and make sure that Download to flash is not checked. When you select Debug, your symbols in the axf file will be loaded and you will connect to the board, but nothing will be over written on the board.
2) Select LOAD to load your hex File.
2) I would create a utility that will burn the hex file to your board. you will add this to the Configure Flash Menu command. You want to "Use External Tool for Flash Programming.
3) I would create 2nd project that the name of the executable something like "burnhex.hex" from the command line you can do something like C:\Keil_V5\UV4\Uv4.exe -f burnhex.uprojx. When you execute this .bat file, it will burn your hex file to the board. This is the Command you want to add to the Use External Tool for Flash Programming option.
4) Add User after build run option that will likely create a Bin file, add a CRC and then create a hex file (i.e. run your "home made" script.)
So here is what it looks like in practice
1) Compile your program as you do any Keil Project. (This will create a hex file combining bootloader with Application with CRC)
2) Load your program to flash (Click load, it will load the Hex file using your "external programming tool" - which is just Keil to load the hex file)
3) Select Debug. This will connect to the board and load your symbols from the AXF file, but since you have turned off Loading the flash, it will still have the Hex file you just loaded. Debugging of the App works fine. Note: doing this you will not have access to debug symbols for the Bootloader. If you want to debug the bootloader you will need to load the Hex file as you do, but use the Bootloader axf file and debug without loading to the flash and you can debug it.
You may want to consider making the bootloader a totally separate project that you even load totally separately.
Hi Robert,
Thank you for your reply.
Just a question:
Robert McNamara said:3) I would create 2nd project that the name of the executable something like "burnhex.hex" from the command line you can do something like C:\Keil_V5\UV4\Uv4.exe -f burnhex.uprojx. When you execute this .bat file, it will burn your hex file to the board. This is the Command you want to add to the Use External Tool for Flash Programming option.
But every time my application is modified, I will need to re-build the second project to flash the right CRC on the board. Right?
Robert McNamara said:You may want to consider making the bootloader a totally separate project that you even load totally separately.
This is what I am doing
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.
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)
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.
I asked to Arm's support and got the reply: the .ini file shall be called through the "Utilities" tab (which is called at flashing time), not from "Debug" as I did. Using Utilities tab solved my trouble.