Custom bootloader and debugger issues

[JR2963]

Hello,

I am using an STM32WB with a custom bootloader, which is currently simple and only knows how to jump to a specific address to start the application. I upload firmware using debuggers (STLink V3 and JLink). When I upload the bootloader and the application separately, then make reset of MCU everything works – the bootloader launches the application, and it seems to run fine. However, if I have the bootloader already uploaded and I upload only the application via the debugger, it often happens that the application does not start (in debug mode). The bootloader seems to be active, probably sending a command to jump to the application (that's just my guess), and in debug mode, I see that the application gets stuck right at the reset handler, and nothing can be done with it. Sometimes switching from JLink to STLink or vice versa helps. It's very frustrating to debug software when most of the time it doesn't work. Do you have any idea what could be the issue?

Thank you.

 

 

[Radosław]

1 solution,  marge bootloader to  aplication.

2. load bootloader  when debug is started (see lauch configuration)

[SMarie]

Hello,

Did you update your linker script with the start address of your application and applied it in Properties>C/C++ Build>Settings>MCU GCC Linker>General ?

Then, did you add the start address in your debug configuration ?

[JR2963]

"configurations": [
 {
 "name": "J-Link Build & Debug Microcontroller",
 "cwd": "${workspaceFolder}",
 "type": "cortex-debug",
 "executable": "${command:cmake.launchTargetPath}",
 "request": "launch",
 "servertype": "jlink",
 "device": "STM32WB55RGVx", //MCU used
 "interface": "swd",
 "serialNumber": "", //Set J-Link ID if you use multiple at the same time
 "runToEntryPoint": "main", 
 "svdFile": "${config:STM32VSCodeExtension.cubeCLT.path}/STMicroelectronics_CMSIS_SVD/STM32WB55_CM4.svd",
 "v1": false, //Change it depending on J-Link version
 "serverpath": "C:/Program Files/SEGGER/JLink/JLinkGDBServerCL.exe",
 "armToolchainPath": "${config:STM32VSCodeExtension.cubeCLT.path}/GNU-tools-for-STM32/bin",
 "gdbPath":"${config:STM32VSCodeExtension.cubeCLT.path}/GNU-tools-for-STM32/bin/arm-none-eabi-gdb",
 "serverArgs": ["-if", "swd", "-device", "STM32WB55RGVx", "-speed", "4000"],
 "preLaunchTask": "Build project",
 "postRestartCommands": [
 "monitor reset"
 /* "monitor halt"*/
 ]
 },
 {
 "name": "Build & Debug Microcontroller - ST-Link",
 "cwd": "${workspaceFolder}",
 "type": "cortex-debug",
 "executable": "${command:cmake.launchTargetPath}",
 // Let CMake extension decide executable: "${command:cmake.launchTargetPath}"
 // Or fixed file path: "${workspaceFolder}/path/to/filename.elf"
 "request": "launch",
 "servertype": "stlink",
 "device": "STM32WB55RGVx", //MCU used
 "interface": "swd",
 "serialNumber": "", //Set ST-Link ID if you use multiple at the same time
 "runToEntryPoint": "main",
 "svdFile": "${config:STM32VSCodeExtension.cubeCLT.path}/STMicroelectronics_CMSIS_SVD/STM32WB55_CM4.svd",
 "v1": false, //Change it depending on ST Link version
 "serverpath": "${config:STM32VSCodeExtension.cubeCLT.path}/STLink-gdb-server/bin/ST-LINK_gdbserver",
 "stm32cubeprogrammer":"${config:STM32VSCodeExtension.cubeCLT.path}/STM32CubeProgrammer/bin",
 "stlinkPath": "${config:STM32VSCodeExtension.cubeCLT.path}/STLink-gdb-server/bin/ST-LINK_gdbserver", 
 "armToolchainPath": "${config:STM32VSCodeExtension.cubeCLT.path}/GNU-tools-for-STM32/bin",
 "gdbPath":"${config:STM32VSCodeExtension.cubeCLT.path}/GNU-tools-for-STM32/bin/arm-none-eabi-gdb", 
 "serverArgs": ["-m","0"],
 "preLaunchTask": "Build project"
 /* If you use external loader, add additional arguments */
 //"serverArgs": ["--extload", "path/to/ext/loader.stldr"],
 },

Actually no I do not even know how to change it. I thought it should do the

"runToEntryPoint": "main",  but obviously not.

, I wanted the bootloader to do its job every time the application is uploaded (calculate the application's CRC and then jump to the application). If I wanted to skip the bootloader immediately after uploading, what should I ideally add? I have both STLink and JLink. 

[Tesla DeLorean]

Add some more diagnostic or telemetry from the loader, about what's happening, and the integrity of the app image.

When it fails determine if the IDE or upload process has trashed the loader, or failed to load the app image such that it doesn't match the PC side image. Perhaps in a post-link step CRC or SHA the app image so the loader can determine if it is complete and intact, and report such before jumping or dying.

Don't have any silent death while(1) loops in Error_Handler or HardFault_Handler

[Radosław]

Maybe bootloader is stack when mcu is not hard reset but only by core reset?   Some loaders liitle mess with that,