Problem with Single Step STMF7

[aaron239955_stm1_st]

Posted on December 07, 2016 at 21:47

There is a problem with IDE debuggers for STMF7, and as I understand, all ARM M7 core based processors. With other CORTEX controllers, when a debbuger pauses or hits a breakpoint, the debugger stops interrupt processing so that, even if interrupts are running in the system, when you single step, you go to the next line in the software module you are debugging. With the F7 debuggers, like GDB which is used by Eclipse, SW4STM32, Keil and other toolsets, when you hit a breakpoint and then try to single step, if any interrupts are running in the system, you step into an ISR, or the same instruction, not your next instruction and will keep doing this forever. The 'workaraound' is apparently to put your cursor on another line and tell the debugger to 'Run to Cursor'. But even this does not work until you disable the breakpoint where you stopped, because the interrupt return keeps taking you back to the breakpoint rather than going on.

Does anyone know if this is being fixed? Or if there is a workaround? Or if any toolsets have fixed it? I have been working on a complex application on the F746 Discovery board that uses FreeRTOS, STemWin, A/D's running interrupts etc. etc. and this bug makes it really painful to just operate. I am Using SW4STM32 but I assume this also affects the big money toochains that also use the basic GDB debugger as its main debug engine.

Help?

#f7 #sw4stm32 #ide Note: this post was migrated and contained many threaded conversations, some content may be missing.

[Walid FTITI_O]

Posted on December 08, 2016 at 12:02

Hi

Bauch.Aaron

,

Have you tried with other device using

SW4STM32

? Have you tried with other IDE than

SW4STM32 with the same device and you get the same issue?

-Walid F-

[aaron239955_stm1_st]

Posted on December 08, 2016 at 13:28

I use SW4F32 on many other processors in the F4, L4, F0, L0 and F3 families and none of them exhibit this behavior.  I have not tried other IDE's myself however there have been discussions about this on the Keil and ARM support forums describing the same problem with other toolchains which is why I believe it is a core related issue and not specific to SW4STM32.  However, for example IAR EWARM does not use the GNU GCC tool chain as its base and I don't know for sure whether they exhibit the same problem, but I also do not nave $4000 to drop on a license to find out.

I'd love to hear from someone who IS doing development on an F7 processor, using interrupts, who is NOT seeing this problem, and it would be nice to know what development environment they are using.

Thanks.

[Radek RIPA]

Posted on December 08, 2016 at 15:23

Hello,

Fortunately the problem which you are describing is present on the first generation of M7 core. The problem is described by arm. 

http://www.keil.com/support/docs/3778.htm

 

The problem is fixed on later M7 cores for example on STM32F769. 

What i understand that J-Link and Ulink debug probes have implemented workaround.

It is possible to change the St-Link to J-Link probe: 

https://www.segger.com/jlink-st-link.html

 

But i never test if this solve the M7 debug issue when is used on ST-Link

Best regards

Raek

[TarekB-ST]

Posted on December 08, 2016 at 20:40 ‌, Thank you ,I have totally forgotten about this.

I have got the confirmation that this bug is already workarounded in Keil ST-Link DLL.

‌, based on the workaround described in section STATUS of

http://www.keil.com/support/docs/37htm

, you can do a similar workaround in SW4STM

The workaround is based on gdb hooks, so you need to create a file named '.gdbinit' into your project directory (example : ~/STM32Cube_FW_F7_V1.4.0/Projects/STM32F746ZG-Nucleo/Examples/GPIO/GPIO_EXTI/SW4STM32/STM32746ZG_Nucleo/.gdbinit). This file will be loaded automatically by gdb. The '.gdbinit' content is the following :

define hook-continueunmaskintenddefine hook-rununmaskintenddefine hook-nextunmaskintenddefine hook-stepunmaskintenddefine hook-nextimaskintenddefine hook-stepimaskintenddefine hook-stopmaskintenddefine maskint# DHCSR.MASKINTS = 1set *0xE000EDF0 |= 0x8enddefine unmaskint# DHCSR.MASKINTS = 0set *0xE000EDF0 &= ~0x8end�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?

‌, please try this proposed workaround, and let un know if this solves your issue.

Best Regards,

Tarek

For more information please refer to:

• https://sourceware.org/gdb/onlinedocs/gdb/Hooks.html#Hooks

• https://sourceware.org/gdb/onlinedocs/gdb/Continuing-and-Stepping.html#Continuing-and-Stepping

[Ron Koch]

Posted on December 09, 2016 at 17:57

Did this work? I tried it and it had no effect. I'm using the same board. I'm using an Ac6 installation on a Mac.

Interesting that when I debug an example application (not CubeMX generated), I can step a few instructions before jumping to the handler, step through the handler, and step a few more instructions. I cannot do this in my MX generated code. It just repeats stepping through the handler. Makes me think there is some difference in the project properties, but I can't find one. 

[Vito Marolda]

Posted on December 22, 2016 at 14:51

Hello same problem here with Nucleo 144 F746ZG.

I have the same problem with both SW4STM32 and ATOLLIC 7.

I have tested the .gdbinit workaround on both, but in none solves the problem.

My project is generated by cubeMX with FreeRTOS and Timer1 as tick.

Every single step hits TIM1_UP_TIM10_IRQHandler.

Any other solution?

--Vito.

[Nor Sch]

Posted on December 22, 2016 at 15:46

That this is a ARM-Core-Bug explains some Trouble I had in a Project 1 Year ago with a Atmel SamV71 in Keil - not extremely penetrant, but also annoying.

[Vito Marolda]

Posted on December 22, 2016 at 16:26

Changing the debugger to Segger solves the issue.

--Vito.

[world04]

Posted on February 16, 2017 at 23:56

The  first revistions of the F7 ghas got a chip bug that's can be workaround by the debugger firmware. Segger done this and released a firmware replacement for the stm32 Disco / Nucleo on-board SWD firmware for free. This eleminates the problem pretty nice and in addition, the Segger firmware upload and debugging procedure is quite more faster. You can use the hole bunch of segger J-Link tools too. The SW4STM are not usable with J-Link as default but there is an eclpse plugin avaialbe by segger taht can be used.

I recomment to use an other IDE called WINidea Open, that support Segger and ST-Link direct. This is a havy modifiedeclipse too - it's support RTX, freeRTOS and a bunch more of RTOS. I had ported some project from SW4STM to WINidea Open and this works pretty easy because this also uses the GNU Toolchain.

I also had used some CubeMX  projects and this also works pretty.