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 two short videos (registration required) highlighting:

System Workbench for STM32

openocd + custom stm32f429 board flash issues


I am working on our company’s custom stm32f429 board which is fairly complicated with multiple peripherals. Till today morning the board worked fine with no issues. Once i shifted the board from the test bench to inside the robot (connected to a battery). It stopped responding well to openocd and gdb commands. I have debugged all possible electronic issues and no new parts have been added to the board recently (just to rule out the possibility of interference). Other boards working off the same power rail do not exhibit such issues. I replaced the chip twice to no avail. ST-link utility works fine as well.
Following is the output of openocd telnet session:
command: reset halt
output: “target state: halted
target halted due to debug-request, current mode: Thread
xPSR: 0x01000000 pc: 0x1fff5162 msp: 0x20002d40

As you can see the program counter does not reset to its intended location i.e. “0x08000200” and the msp points to the wrong address as well: 0x20002d40 instead of 0x20003000.

Following is the output of “flash write_image erase ”

flash write_image erase /home/talha/Seven_LLS_experimental/build/F429/src/stm32_uavcan/stm32_uavcan.hex
auto erase enabled
Padding image section 0 with 12 bytes
Padding image section 1 with 4 bytes
target state: halted
target halted due to breakpoint, current mode: Thread
xPSR: 0x61000000 pc: 0x20000042 msp: 0x20002d40
wrote 262144 bytes from file /home/talha/Seven_LLS_experimental/build/F429/src/stm32_uavcan/stm32_uavcan.hex in 7.289705s (35.118 KiB/s)

The program counter and msp point to the wrong address again. I have checked if there is any issue with the linker script or my code but the code runs flawlessly on the eval board.

I want to know if someone here has experienced a similar issue before? I strongly believe that this is a HW issue and i’ll have to perhaps solder a new board cry, but before i put in the effort i just want to ensure that there isnt anything else that i could try