March 13, 2018 at 15:24 #20382
I am using the latest version of VisualGDB Embedded with a STM32F476. I am using various sectors of the STM32F746 internal flash for my program, including a bootloader, 2 sectors for EEPROM emulation, some unused sectors, and finally the local of the program code.
When running debug on the STM32F746 from VisualGDB, I would like to configure it so that it does not erase the sectors used for EEPROM emulation. Is there something I can add to the LDS file to achieve this? If not, is there another way of preventing VisualGDB from erasing particular sectors on flashing/debug?
Thanks in advance guys.March 13, 2018 at 19:39 #20386
Normally OpenOCD should be able to figure out the correct sectors to erase automatically. So our first advice would be to double-check what addresses are actually used by various sections of your program. Please try running arm-eabi-objdump -h <ELF file> and check what section covers the address that is erased and what attributes are set to it. If it has the LOAD attribute, you would need to mark it with the noload attribute in the linker script file.March 14, 2018 at 18:35 #20398
I have modified my linker script and used arm-eabi-objdump -h <ELF file> to inspect the sections used.
It lists the following LMA addresses
- bootloader at 0x08000000
- .isr_vector, .text and other program sections at 0x08040000 +
- RAM objects to be loaded at boot at 0x08040d4b0 +
There is nothing in between the end of the bootloader code in the first sector (0x08000000), and the beginning of the program code (the ISR vector table) at 0x08040000.
Still, when I right click on the Visual Studio project and choose Program and Start Without Debugging I always see the following messages in the openocd output:C++123Info: Erasing FLASH: 0x08000000-0x08080000......Info: Erasing FLASH: 0x08040000-0x08080000...
The project has got an embedded binary for its bootloader, which I created using the guide on this website. It is like openocd is treating the bootloader (0x08000000) plus the application (0x08040000) as one large blob that it needs to program, even though there is nothing in between the bootloader and the application.
Is there a way to configure this so that it doesn’t erase the sectors in between the bootloader and the application? That is where my EEPROM is located…
Thanks again for your help.
March 19, 2018 at 00:50 #20463
- This reply was modified 1 week, 3 days ago by chris250.
This looks like something specific to the OpenOCD FLASH erasing logic. Although this is normally not covered by our support (please consider using Segger J-Link if you are looking for a debug probe that just works out-of-the-box and comes with its own support), we have published a detailed tutorial showing how to build our OpenOCD fork from scratch and debug it with VisualGDB: https://visualgdb.com/tutorials/arm/openocd/build/
Please ensure you use the following VisualGDB build: http://sysprogs.com/files/tmp/VisualGDB-22.214.171.1244.msi
This should help understand why OpenOCD decides to merge the 2 erase regions and tweak it if necessary.
You must be logged in to reply to this topic.