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.

[Matthew Staben]

Posted on April 26, 2018 at 17:21

I am developing on a custom board with the STM32F767IIT using primarily Crossworks with a CrossConnect debugger. I also use ST-LINK/V2 with AC6. My environment is set up so I can develop rapidly with Crossworks but pass out the source to other assisting developers who use AC6 and can compile the source tree exactly as I provide it without doing anything other than firing up either AC6 or Crossworks.

When single-stepping, I've never entered an ISR - sometimes a break-on-data will be in an ISR when it trips, but that's about it.

All that said, Crossworks is worth its weight in gold - its GCC implementation is advanced, and downloads are very fast with either Crossworks or STLINK/V2. I cannot say enough how much time it's saved. AC6, on the other hand, is a very slow pig. I've tried Atollic, and can't get the source to compile without much ado so I've put it aside for now, even though the same source without changes does readily in AC6 or Crossworks.

[Tesla DeLorean]

Posted on April 26, 2018 at 17:39

Crossworks was one of the best GNU based chains I've used. For the most part I use MAKE with GNU

[world04]

Posted on April 26, 2018 at 21:00

Hi Matthew,

you experiences are similar as my owen. ST wrote this errata for the STM32F74x only. I had checked the issue on different controllers as the 74x and did not found it again. Just two versions of the inital core r0p0 and r0p1 are buggy.

btw, i had not found a 746 who's used on the disco board, that used an newer core as those.

I agree in your experiences with the cossworks ide. That's one of the best i had used. It's not based upon eclipse as the most free available ones. 

[Oscar_Niño]

Hi

Could you help me? I have de same problem, I'm using the STM32F746G-Disco board I can debug by the same problem, I downloaded the STSW-LINK007 version 2.35.26 but it fails. Somebody could tell me how to resolve the problem of debug.

Best Regards

[Tesla DeLorean]

Please don't post to old/long threads. Start a new thread, refer to this as appropriate.

The debugger, not the pod, would need to address the deficiencies in the core.

[world04]

Well, using an old thread is not the best way finding a solution, but in this case i got an email About the Question and logged on to explain my solution - that Maybe helps to find a way,

A Hardware bug is responsible for this issue. The errata explains it further, but the solution will be done by a Firmware solution placed in the jtag Debugger.

I am not know how ST handle that issue in their Debugger Firmware. I had replaced the Firmware from st by the published j-link Firmware who are available at segger.com and especialy for the nucleo and discovery boards. Using this is not a point of no return - your are able to restore them an back, how often your are need that. In Addition, the j-link Firmware ist much more faster.

You should know that an external J-Link Debugger with Version 8, that often cheap available from China, will not work with F7 and later mcu's. A newer Version 10

is required. It's improved and uses a different Controller. The Link to the free available Firmware for the on-board jtag is available here:

https://www.segger.com/downloads/jlink/#STLink_Reflash

I will hope this helps you to debug without any unwanted stop's.

[Oscar_Niño]

Thank you all, apologies, it was helpful.

[Mario Ghecea]

Don't say ridiculous things before you know what you are talking about...No it does not work because it is a core issue...Regardless of debugger used!

[world04]

Vito Marola's advice is absolutely correct and so far it is the only solution I know of to circumvent the debugging problem.

Segger has implemented a work-round in the debugger firmware that makes the BUG tolerable in the first two versions of the STM32F7 CPU core.

That this firmware does not change the CPU bug itself, in the debugger hardly needs to be mentioned. But it changes the behavior so that you don't notice the bug.

It would be desirable that you keep your tone of voice at a respectful level. Comments like yours are neither helpful nor wanted.

Another note about the Segger Debugger. This is available free of charge as an in-system replacement for many ST-Disco and Nucelo boards and turns the on-board ST-LINK into an on-board J-LINK. This change is also reversible again.

The newer boards with STM32H7 processors use a more modern on-board ST-LINK V3 debugger. So far there is no OB-JLINK firmware for this.

[Mario Ghecea]

Nonesense I tried on both ST Link and OB-Jlink and the behavior is identical on both when accessing codecs...It has the freerunning issue when accessing codecs and maybe graphics or both. No your suggestion does not work with Segger implementation and there are a few on here making suggestions that it does work...It works on simple designs but on codecs and graphics more involved designs it exhibits the same issue on all JTAG USB debuggers. It is a core issue and there is no known fix for it so far because ST has fixed it in the next generation of products. Now my codec and touch gfx code runs but it does not break in either version (the latest) of both the Segger and ST-Link latest firmware debuggers on OpenOCD...Stop cheerleading for something that ST has sort of confirmed broken...That behavior is very annoying from you and a few other Segger cheerleaders...Knock it off...​You neubes should give it a rest...Even Clive1 has confirmed it ...The problem persists in all M7 cores except the new ones...