- This topic has 6 replies, 3 voices, and was last updated 4 years, 8 months ago by
.
-
Posts
-
Hello all,
I made two sample applications starting from LEDBlink (HAL) examples from Visual Studio. The first app is the bootloader and the second app is the application. I am using a STM32H743II processor.
Bootloader: starts at 0x08000000. Blinks an LED a few times and then jumps to application (0x08008000).
Application: starts at 0x08008000. Blinks a different LED.
So far so good. I can program both .bin files at their specified memory address using STM32-ST-Link Utility and everything works fine. The bootloader blicks its LED and then jumps to application which blicks a different LED.
To achive this I modified the .lds files as shown below:
Bootloader:
MEMORY
{
FLASH (RX) : ORIGIN = 0x08000000, LENGTH = 0x8000
DTCMRAM (RWX) : ORIGIN = 0x20000000, LENGTH = 128K
SRAM (RWX) : ORIGIN = 0x24000000, LENGTH = 512K
RAM_D2 (RWX) : ORIGIN = 0x30000000, LENGTH = 288K
RAM_D3 (RWX) : ORIGIN = 0x38000000, LENGTH = 64K
ITCMRAM (RWX) : ORIGIN = 0x00000000, LENGTH = 64K
}_estack = 0x20020000;
_app_start = 0x08000000 + 0x8000;Application:
MEMORY
{
FLASH (RX) : ORIGIN = 0x08008000, LENGTH = 0x8000
DTCMRAM (RWX) : ORIGIN = 0x20000000, LENGTH = 128K
SRAM (RWX) : ORIGIN = 0x24000000, LENGTH = 512K
RAM_D2 (RWX) : ORIGIN = 0x30000000, LENGTH = 288K
RAM_D3 (RWX) : ORIGIN = 0x38000000, LENGTH = 64K
ITCMRAM (RWX) : ORIGIN = 0x00000000, LENGTH = 64K
}_estack = 0x20020000;The problem is that every time I program the application using Visual Studio, the entire memory is erased, including the bootloader. Same for the bootloader – it erases the application as well.
Is there an option to setup VisualGDB to only erase the memory declared in the .lds of the application (from 0x08008000 to 0x08008000 + 0x8000) and not affect anything else?
Here is what I use:
- Visual Studio 2019
- VisualGDB 5.4R12 Build 3309
- I tried Segger J-Link and ST-Link/V2
Any help is welcome.
Thanks,
Eduard
Hi,
Normally, the Segger J-Link software should only erase the affected FLASH pages, so please double-check your ELF file layout via View->Embedded Memory Explorer.
If it doesn’t help, please follow the steps below to diagnose the issue:
- Disable the FLASH memory programming via VisualGDB Project Properties -> Debug Settings.
- Program the memory via an external tool and verify that both parts have been programmed.
- Start a debug session with VisualGDB (it should not re-program the FLASH memory).
- Verify that both bootloader and main application’s areas have not been erased by running “x/10x 0x<ADDRESS>” in the GDB Session window.
- Run the “load” command in the GDB Session window and check its output. Once the loading completes, check whether the entire FLASH memory has been erased again.
If you can confirm that the “load” command erases the entire FLASH memory, please check your FLASH protection bits, and also check with Segger support (there might be a J-Link setting controlling the FLASH erasing logic). If running the “load” program does not erase the entire memory, please create a full gdb session log and we can help you find commands that could be erasing the FLASH memory.
I wonder why do you need the bootloader while you debug your application.
I usually have a link file for debug, which starts at 0x8000000, and release link file which starts address is after the bootloader.
Bootloader is (and should be) a stable and not changed during application development, TMHO.
Johanan
Thank you for your help.
I followed your instructions and found that the “load” command erases the entire memory. I used the “x/10x 0x<ADDRESS>” command before and after the “load” command. After the “load” command, the bootloader address is erased. I am going to check with Segger support to see if they can help me.
Also, what do you mean by checking the FLASH protection bits? Can you give me some more details please?
Hi Johanan,
We are not using two different linker scripts because very often we have to interrupt a tool, program a development version for testing and then program the old stable version back and continue the operation. We want to minimize the interruption time so programming the bootloader would be an additional step that we want to avoid if possible.
Hi,
If the load command erases the bootloader, the file you are programming might contain some data in the bootloader regions. You can double-check it via the Embedded Memory Explorer, and also by looking at the output from the “load” command.
If you can confirm that the ELF file does not have any data there, but the ‘load’ command still erases it, please indeed check with Segger, as their gdb stub is handling the low-level FLASH programming behavior.
The FLASH protection bits are specific to each device family and are usually described in your device’s datasheet. Please refer to the device documentation/datasheets for more details on them.
If nothing helps, please check if you can program just the correct part of the memory using some command-line tools (e.g. Segger or ST-Link). If this is the case, you can disable the memory programming via VisualGDB Project Properties -> Debug Settings and then run the custom command-line tool before debugging via VisualGDB Project Properties -> Custom Debug Steps.
Thank you for your help!
I also asked for support from Segger and they noticed right away that I was using two different addresses from the same memory sector. For STM32H743II processor the first memory sector is from 0x08000000 to 0x08020000 which means that my bootloader (0x08000000) and application (0x08008000) were both in the same memory sector. For erase, the smallest unit is always one sector, so when erasing the first sector to program my application the bootloader was erased as well.
I modified my application to start at 0x08020000 and everything seems to be working perfectly.
Thanks again for your support!
- You must be logged in to reply to this topic.