System Workbench for STM32

Hi

Has anybpdy found a solution for the OP's problem?

My current workflow is:

1 Code and debug the application
2. Relocate the application 16 pages higher in flash by editing STM32F103C8Tx_FLASH.ld and Drivers/CMSIS/Device/ST/STM32F1xx/Source/Templates/system_stm32f1xx.c
to get space for the bootloader and then build again
3. Erase the flash with external tool (qstlink)
4. Apply the bootloader (another project) by means of the debugger
5. Load the application.bin by meams of the bootloader via DFU

It should be possible to load the application with ac6 -> openocd to the production offset address while keeping the bootloader starting at 0x8000000.

I even tried to use a modified copy of target/stm32f1x.cfg in my USER-OPENOCD.cfg file. But openocd ignores the modified base address (0x8004000) given to the "flash bank" command and uses default 0x8000000.
The bootloader gets destroyed this way.

The debugger setup in ac6 can only use application.elf. Maybe thats the key. Openocd is called with "-c program ...".

Command: program filename verify reset exit offset

From openocd docu:

# program and verify using elf/hex/s19. verify and reset
# are optional parameters
openocd -f board/stm32f3discovery.cfg \
	-c "program filename.elf verify reset exit"

# binary files need the flash address passing
openocd -f board/stm32f3discovery.cfg \
	-c "program filename.bin exit 0x08000000"

If possible one could make a Release setup in ac6 and then deploy application.bin to the right offset address.
The string "verify exit reset" can be found in ac6 only in binary file ..../debug/launching/MCUGdbLaunch.class

Dieter

I can found this problem on IAP sample code from STMicro.

Do any body have the solution?

i run custom bootloader at defautl reset handler that then jump to app reset vector located after in flash
is that what you trying to do ?
i can debug and load the app over eclipse/ac6 without bootloader overwrite
but reset and boot will go by the bootloader (that can be debug also )
I did this on a f407 but the same can aply to any cpu until you relocate vector handler

for this to work your app ld neeed to be addapted and app vector table changed

basiclay in ld file change the app "FLASH" to start after where you boot loader is
fo ex say 128K loader at flash origin
FLASH (rx) : ORIGIN = 0x8000000, LENGTH = 1024K
come =>
FLASH (rx) : ORIGIN = 0x8002000, LENGTH = 896K // origin+128K 1size 024K-128K

in the CMSIS driver look at /Drivers/CMSIS/system_stm32f4xx.c or yoru cpu xxxx.c

1. define VECT_TAB_OFFSET 0x20000 /*!< Vector Table base offset field. */

if shall work ! you boto load must ensure to relad teh proper app reset handler and also disbae irq before to jump on app

eclispe opencocd wil only program the flash that is the in app not the bootlaoder.

Hi Tickel_Guan

Have you found the solution?

I'm strugling with this same issue right now!

Hi Tickel_Guan

Have you found the solution?

I'm struggling with this same issue right now!

Nevermind!

Just found the solution

In Run > Debug Configurations select your debug config and go to the "Startup" tab

There you set the offset that you applied to your main application code in the "image offset (hex)" field (in my case was 4000)

now it's working 😊

Grr, I just lost the fairly long post I wrote up on this topic.

I'll try it again, but it's going to be just the bare bones, no examples, just hints.

The key to getting app and loader to coexist and load properly (without overwriting each other) with the SW4STM32 tools is to make sure you've got the linker config files (*.ld) for both loader and app set up properly.

Make sure that the MEMORY ROM region defined only includes the portion of FLASH that your loader or application will reside in. That is, the ROM definition should exclude the portion of FLASH that belongs to the other component.

In my particular case, the loader is allocated the first 16K, and the application gets the rest. If your FLASH size is 128K, you'd specify:

ROM (rx) : ORIGIN = 0x08000000, LENGTH = 16K
for the loader, and

ROM (rx) : ORIGIN = 0x08004000, LENGTH = 96K
for the application.

You need to make sure that the interrupt vectors are getting loaded into the right place. I recall having some problems with this at one time during development of my app/loader project, but looking at what I have now, I don't see the need to change anything related to the .isr_vector section handling in the linker config or the system_xxx.s source file where the vectors are defined.

If you're using a device with a M0 core (STM32F0xxx variant) you'll have to jump through a bunch of hoops and play around with RAM/FLASH overlaying to get the right interrupt vector table (app or loader) in effect. All other core types (including the STM32F4 - M4 core) you can just set SCB->VTOR to point to the IVT you want to be in effect.

One issue I DO have with all versions of SW4STM32 is that if I attempt to run a full debug session on my (F0-based) application, it won't start up properly after initial load, even if both loader and app are resident in FLASH. It seems as if the debugger does not perform a true target reset when it starts up; it tries to jump to the app entry point (which will fail miserably in a mixed app+loader environment, esp. on a M0 core with no VTOR), instead of resetting so the loader gets initial control. With the addition of the reset button in the debugger since ver. 2.0, I can work around this problem - the debugger works exactly as expected if I reset the target using the debugger UI's reset button first.

In the debug configuration startup tab, set the initial program counter to the initial PC from either the bootloader or the application.

The initial PC is stored in the second word of the binary image.

arm-none-eabi-objcopy -O binary boot.elf boot.bin

xxd -eg4 boot.bin | head

> arm-none-eabi-objcopy -O binary boot.elf boot.bin
> xxd -eg4 boot.bin | head

Many thanks to Peter Shook for his hint with startup option.

Alternative way is to fetch this address from output.map file. Search for line "Reset_Hanlder" and you'll find

 .text.Reset_Handler
                0x000000000800d5d0       0x50 startup/startup_stm32f103xb.o
                0x000000000800d5d0                Reset_Handler

Here 0800d5d0 is the PC value you'll need.
Moreover, in my case, these addresses differed by 1 (which is very strange), and only the value from output.map worked, whereas the first one did not.