Loading...
 

SW4STM32 and SW4Linux fully supports the STM32MP1 asymmetric multicore Cortex/A7+M4 MPUs

   With System Workbench for Linux, Embedded Linux on the STM32MP1 family of MPUs from ST was never as simple to build and maintain, even for newcomers in the Linux world. And, if you install System Workbench for Linux in System Workbench for STM32 you can seamlessly develop and debug asymmetric applications running partly on Linux, partly on the Cortex-M4.
You can get more information from the ac6-tools website and download (registration required) various documents highlighting:

System Workbench for STM32

Forum List Topic List

[ prev topic ]  

Single Stepping with STM32F7

Posted by bobesch on 2016-04-22 17:27

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

Reads: 8109
Link
Posted by MattReed59 on 2016-04-22 18:19

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

Link

Posted by bobesch on 2016-04-23 11:45
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,
Link


Posted by aaronbauch on 2016-06-15 15:17

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!

Link