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


Single Stepping with STM32F7

Hello,

running with both openocd and origin/openstm32 while single stepping as soon as an interrupt happens, gdb stops at the interrupt too and loops the original line as long as there are interrupts:
Breakpoint 1, main () at uart.c:71
71 {
(gdb) n
74 uint32_t baud = 115200;
(gdb) n
91 NutRegisterDevice(&DEV_CONSOLE, 0, 0);
(gdb) n
98 uart = fopen(DEV_CONSOLE.dev_name, “r+”);
(gdb) n
109 _ioctl(_fileno(uart), UART_SETSPEED, &baud);
(gdb) n
115 _write(_fileno(uart), banner, strlen(banner));
(gdb) n
116 clk = NutGetCpuClock();
(gdb) n
USART1IrqEntry (arg=0x29) at /devel/ethernut_sf/build/../nut/arch/cm3/dev/stm/ih_stm32.c:188
188 CREATE_HANDLER(USART1, USART1, NUT_IRQPRI_DEF); // USART 1
(gdb) n
main () at uart.c:116
116 clk = NutGetCpuClock();
(gdb) n
USART1IrqEntry (arg=0x29) at /devel/ethernut_sf/build/../nut/arch/cm3/dev/stm/ih_stm32.c:188
188 CREATE_HANDLER(USART1, USART1, NUT_IRQPRI_DEF); // USART 1
...
(gdb) n
USART1IrqEntry (arg=0x29) at /devel/ethernut_sf/build/../nut/arch/cm3/dev/stm/ih_stm32.c:188
188 CREATE_HANDLER(USART1, USART1, NUT_IRQPRI_DEF); // USART 1
(gdb) n
main () at uart.c:116
116 clk = NutGetCpuClock();
(gdb) n
117 fprintf(uart, “Running at %3ld.%06ld MHz\n”, clk / 1000000,
(gdb) n


Does something similar happen to others?

Thanks

I don’t use gdb in it’s ‘raw’ mode like that. And since this is a forum for the System Workbench, which has a built-in debugger, I could doubt anyone here does. (yeah, the bult-in dugger uses gdb but but that’s kinda hidden from normal use).

In the System Workbench (aka AC6) and in other debuggers I have seen the lines ‘bounce’ around. This is due to optimization, the assembly line the code is actually on does not match-up to an actual ‘C’ line, and/or the optimizer has merged several lines, and/or some of the code is in-lines and some is in a library that has no debugging symbols, etc, etc, etc.

Check the makefiles, or the build setup and make sure debugging is turned on and optimizations are turned off.

-Matt


Just a hint to Matt: If you want to debug, use -Og and not -O2 as optimization. -Og optimizes decent, but keeps program flow in line with code flow,


It looks like it is not a “problem” with the M7 core, but rather a different way that the core handles pending interrupts compared to other Mx cores. I would assume that all debuggers will need to support this if they want to claim support for the F7 core.

Saying this is a core bug is like saying the F7 superscalar execution and cache support are bugs as well since they behave differently than previous core implemetations.

Is there any plan tp fix this in the GDB debugger? Debugging F7 code is painful without it!


 

Newest Forum Posts

  1. reservation car service Seattle by Jamesprede, 2025-05-01 10:06
  2. Last day: drone bonus by Danielrug, 2025-04-19 16:55
  3. SPI on Nucleo_STMH533RE by higginsa1, 2025-03-25 07:37
  4. SPI on Nucleo_STMH533RE by royjamil, 2025-03-23 11:31
  5. SPI on Nucleo_STMH533RE by higginsa1, 2025-03-23 09:33
  6. Configuring DMA for ADC in SW? by sam.hodgson, 2025-03-04 12:58
  7. Insightful Perspectives on This Subject by davidsycle, 2025-03-04 05:45
  8. Build a project in "release" mode by info@creosrl.it, 2025-02-20 18:12
  9. Build a project in "release" mode by info@creosrl.it, 2025-02-20 17:05
  10. Build a project in "release" mode by tang, 2025-02-20 10:36

Last-Modified Blogs