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.

[Evgeny Erlihman]

Posted on November 02, 2017 at 19:20

How did you generate a cube project for winIDEA Open?

[Tesla DeLorean]

Posted on November 02, 2017 at 20:02

Probably this

http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.epm064410/index.html

 

[zabel]

Posted on November 03, 2017 at 08:43

I had found this, but I cannot see how one of the issues described in this document can explain the single-step problem. Might be insufficient insight on my side, of course, but could you tell which of these issues you meant:

7  New  832869  CatB    NDSM not inserted during periodic synchronization  

9  Updated  830976  CatC    ATB Flush acknowledged too early 12  New  833819  CatC    Exception entry directly followed by Multiple wrongly traced  13  New  835371  CatC    Exception level change not traced for exception 14  New  836619  CatC    Data events lost in overflow 15  New  836624  CatC    Preferred exception return address traced incorrectly on System Error exceptions

None of the implications listed in the respective issues seem to match the observed behaviour.

 Thanks

  DiZ

[mauro2399]

Posted on April 13, 2018 at 18:34

Hello Tarek,,

you mentioned that this bug is already worked around in Keil ST-Link DLL.

Can you tell me more about this?

I just updated my Keil MDK installation to rev. 5.25.2, but I see no difference.

Best regards,

Mauro

[world04]

Posted on April 13, 2018 at 23:23

Yes, it's just a regular ARM-GCC Project that's needs to be imported. I actually would not recomment using winIdea. They had dropped the j-link support in newer versions.

i had moved to atollic truestudio.

[world04]

Posted on April 13, 2018 at 23:25

Yes, sure - r0 and r1 of the STM32F746 got this issue. I had moved to J-link and don't checked this in newer CPU kernel who are released since this first M7 variants. 

[Tesla DeLorean]

Posted on April 13, 2018 at 23:56

ST doesn't seem to spin die on core revisions but rather uses new cores on new parts, the H743 uses the M7 r1p1, but having problems with the SWV currently, even when running slowly.

Nucleo H743ZI

Core=200000000, 200 MHz

CPUID 411FC271 DEVID 450 REVID 1003Cortex M7 r1p1STM32H7xxC0000018 20000438 0000000010110221 12000011 00000040FPU-D Single-precision and Double-precisionHCLK=200000000APB1=100000000APB2=100000000

[T J]

Posted on April 14, 2018 at 01:57

I thought the H7 series is 400 MHz.

are you running at 200MHz for the heat issues or die/peripheral  issues ?

[world04]

Posted on April 14, 2018 at 03:39

I am not sure if this is an issue of the kernal clock frequency. This is am issue of the clock speed of the 'serial wire view'. Just check out the debugger replacement of segger, who distribute this for free for the newer boards.

https://www.segger.com/downloads/jlink/&sharpSTLink_Reflash

  

https://www.segger.com/downloads/jlink/&sharpSTLink_Reflash

 makes it possible to swap between st-link and j-link. In atollic and keil , this is a quite faster and more stable solution for free. In addition you can use the also available debugging tools from segger - that's a great benefit, trust me.

[Tesla DeLorean]

Posted on April 14, 2018 at 04:23

I ran the board I had to hand to pull the revision/patch level, this is a board I was running slower to evaluate the Trace/SWV functionality I mentioned in the post.