- This topic has 1 reply, 2 voices, and was last updated 3 years, 7 months ago by
.
-
Posts
-
Hi,
We ha a system with a STM32F071 MCU. We have a boot-loader compiled with Keil, and the application compiled with VS/VisualGDB.
We have some problems with debugging/singles-tepping as the code ran to invalid address ranges, and VisualGDB reports that it cannot find the source file. If trying to run further the application crashes. Simultaneously the stack-pointer moves approximately 0x4000 bytes down, and overwrites the application data. In free run the application program runs as expected.
Another really odd problem is regarding the en chip watch dog. We had some problems with the bootloader that was reset all the time in an endless loop. We do not use the watch dog in the bootloader. We tried to disable the bootloader from the application software, and all seems better when running the application without the VisualGDB debugger. But running from the debugger the watch-dog is enabled, and when the application program resets to enter the bootloader during DFU, the bootloader resets in an endless loop. We have some trace output during boot that reports that it was a watch dog reset that causes the reset. Very od, because the watch dog was never activated, AND a reset should disables the watchdog.
Do anyone share out observations?
Hi,
VisualGDB itself would not modify the stack pointer unless you change it via the Watch window. However, because stopping the CPU does not always stop other peripherals (e.g. timers, DMA), stepping through code could trigger bugs that would otherwise never happen. You can try creating a GDB log to double-check the communication between VisualGDB and the target.
The watchdog issue is likely similar – stopping the CPU in the debugger likely doesn’t stop the watchdog, and it ends up resetting the chip. One option would be to try selecting OpenOCD (ST fork) as the debug method and then clicking the “Stop Watchdog” checkbox. It will suspend the watchdog while the CPU is stopped in the debugger.
Generally, as the issue is hardware-specific, the support we can provide here is somewhat limited. If you can get it working with another GDB-based IDE (e.g. STM32CubeIDE), we can help you configure VisualGDB to match the results. If the device generally behaves incorrectly when debugged, VisualGDB will not automatically fix it, as it uses the same mechanisms as other debuggers.
If you would like us to review your project structure, debug configuration, and advise a specific debugging setup, we can gladly do it as a part of our consulting services, however we will have to charge a consulting fee for it.
- You must be logged in to reply to this topic.