SW4STM32 and SW4Linux fully supports the STM32MP1 asymmetric multicore Cortex/A7+M4 MPUs

   With System Workbench for Linux, Embedded Linux on the STM32MP1 family of MPUs from ST was never as simple to build and maintain, even for newcomers in the Linux world. And, if you install System Workbench for Linux in System Workbench for STM32 you can seamlessly develop and debug asymmetric applications running partly on Linux, partly on the Cortex-M4.
You can get more information from the ac6-tools website and download (registration required) various documents highlighting:

System Workbench for STM32

Running bootloader + application solution

I have a bootloader + application solution on STM32F4 where i have trouble running application from Eclipse. In application linker script (.ld) file i have changed the ROM start address to have an offset of 0xC000 and i have reduced the ROM usable size. In map file it’s all fine and the application actually works when i downloaded it with bootloader.

But for faster programming i’d like to run the application from Eclipse and let the OpenOCD program it directly to MCU flash. The problem is that then the bootloader area gets overwritten by the application elf file content. I mean literally the same bytes as are in application elf file get written, not the true binary instruction data. I checked it with STM32 ST-Link utility. I have tried all kinds of offset options in Eclipse run/debugger settings and none helps. I’m not sure if the issue is in the OpenSTM32 toolchain or in OpenOCD. Does anybody have a clue?

I checked with Process Monitor utility with what arguments openocd.exe is invoked. Skipping the paths and exact names it is:

openocd.exe -f application.cfg -s ApplicationPath -s plugin\resources\openocd\scripts -c “program Debug/application.elf verify reset exit”


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


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

Do any body have the solution?

It would help if you gave a link to the sample code, as that would define the ST processor and the IAP method.

Has anyone solved this problem and can explain how to do correctly?

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. */

As your app is offset so does your vector table it need to be relocated to where the app handler are

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.

Could you use “run” button to program flash rather than “debug” button ?
Eclispe overwrite bootloader when I use run button to program flash.

Itried to change the ld file

FLASH (rx)  : ORIGIN = 0x8000000, LENGTH = 128K
come =>
FLASH (rx)  : ORIGIN = 0x8001800, LENGTH = 122K

in the CMSIS driver /Drivers/CMSIS/system_stm32f1xx.c I change this

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

but when I use “run” button to program flash ,exlipse overwrite the bootloader.
What is the problem?

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!


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

                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.