Loading...
 

Zephyr project on STM32

   Zephyr Workbench, a VSCode extension to manage Zephyr on STM32.
It enables users to easily create, develop, and debug Zephyr applications.
Main features:
  • Install host dependencies.
  • Import toolchain and SDK.
  • Create, configure, build and manage apps.
  • Debug STM32.
You can directly download it from the VSCode marketplace
For more details, visit the Zephyr Workbench

System Workbench for STM32


Debugger is setting breakpoints at random locations

I am attempting to get a basic program working using an external interrupt for the STM32L152 Dev Kit. When I set a breakpoint in main the debugger seems to set it further down in the file. I attempted to just put a simple “x++” in the main to set a breakpoint and it got put about 10 lines lower in the init code. One of the weirder items is tha the “Breakpoints” window appears to say that it is located at the line I want it at but whenever I add/remove the breakpoint in the console it reports a different line number.



OS: Windows 7
STM32 Version: 1.8.0.201603291114
Board: Nucleio-L152RE Dev Kit

I’m having the same problem. It cropped up after I removed some conditional compile sections.

I tried performing a clean project and recompile. It didn’t help. My optimization is set to none. When I step with the debugger it lands on lines that don’t have code and skips over lines of code. Somehow the mapping between the source code and what it’s executing is broken, The problem I’m trying to solve depends on being able to tell if a particular conditional statement is being executed, so this makes it really difficult to figure out what’s going on.

Update: It turns out that I had a mashup of two different build configurations from some previous experiments with different build variants, and I still had an older build variant whose compiled binary was actually getting loaded even though the debugger was showing my latest code. I had deleted the older build variant folder from my project workspace but it that variant still existed in the project preferences, and apparently the files are still there on the file system.

I got clued in when I was making changes to the source code and the behavior was the same.

Deleting my unused build variants fixed the problem.