2021-11-04 02:49 AM
In the application BLE_OTA for STM32WB55 NUCLEO 64 board there is no Debug configuration. It is also mentioned in the project's readme.txt file that "Debug configuration of BLE_Ota CubeIDE project is not supported by current BLE_Ota application settings". However, in the "STM32WB Getting Started Series: Part 7, Over-the-Air (OTA)" (https://www.youtube.com/watch?v=mRzZOa3jmuM) it looks like there is a version of the BLE_OTA application which supports the debug configuration. Is it possible to get the version of BLE_OTA with debug configuration?
2022-04-28 10:13 AM
I have the same problem!!!
2022-05-06 04:17 AM
Hi..
I'm facing the same issue
it's unable to debug even with the debug version
Any update on this, ST Community ?
2022-12-31 08:23 AM
I have an issue with BLE_OTA; it failed to run from main() where the breakpoint is set.
2022-12-31 08:35 AM
MCU: STM32WB55CG Nucleo
WB package: STM32Cube_FW_WBV1.15.0
BLE Stack: stm32wb5x_BLE_Stack_full_fw
Bootloader example: STM32Cube_FW_WB_V1.15.0\Projects\P-NUCLEO-WB55.Nucleo\Applications\BLE\BLE_Ota
Documentation: AN5247
2022-12-31 09:03 AM
Fixed, there is a missing debug in the build/debug configuration. Simply copy the release config into the new debug configuration with the new name: Debug and then find the setting debugging from the list column and then set to maximum debug. This activates the debug feature and traps the breakpoint as per the video. I don't know why they removed it.
2024-10-15 02:28 PM
I made the new build Debug configuration and changed the Debugging settings in both the MCU GCC Assembler and the MCU GCC Compiler to maximum (-G3).
I wanted to use Optimization: none but it won't fit into the 6 available sectors for it, so I tried optimization: O1 and optimization debug (Og) and optimize for size (Os) With any of those optimization settings it just blows right past every breakpoint without stopping.
I made sure I was using a new debug configuration that points to the Debug/ .elf and the Debug build configuration.
2024-10-17 03:31 PM
After reviewing the code, I see that the startup script calls a function that will branch to the user's application code at 0x08007000 before main is even called. I think this is why the breakpoint at the start of main is ineffective.