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.

[world04]

They don't seem to get the statement right or they wouldn't repeat their views.

For you again in plain language:

The first two versions of ST's f7 cores are buggy and nobody is able to changes that. Can we consider this point as done?

Second point - the Segger Debugger does not change anything on the bug - it does not change anything that applications would now behave correctly. To assume this would actually be absurd, but no one has claimed either.

With the Segger debugger, however, it is possible to look at parts of the code without constantly ending up in the ISR. The debugger does not do more. The Lauterbach Debugger does a lot more here, but at best it is only an aid that can serve to use this MPU at all, taking the restrictions into account. The fact that ST published the problems in the errata is neither new nor has it been questioned.

The ST-Link V2 and many other debuggers are absolutely useless because they run permanently in the ISR.

I think that it should now be clear to you too what Segger can and cannot do.

If you use such a buggy controller in your project, the fault is clearly yours. The errata has been around for a long time and the problem is well known and documented. They already indicated something like that themselves.

So you check beforehand with the manufacturer of project-relevant components to see whether there are previously known problems that could be project-relevant.

You seem to have managed it that way too, so just come back to the floor of politeness and just stop nagging. It's not doing well and it doesn't support your point.

[waclawek.jan]

@Mario Ghecea​ ,

Can you please start a new thread, stating exactly what hardware/software are you using, and what are the symptoms?

JW

[Vito Marolda]

?

It solved the issue which this thread refers to, for me, four years ago. Segger implemented the workaround to disable interrupts before stepping, if I remember well. That allolwed me to finish my job. If this sounds ridiculous to you, maybe the issue you are facing is a different one. Best Regards.

[arnaljl]

I'll add my 2 cents on this impossible stepping debug matter. 😅

Right now, I'm debugging my project on an STM32F746-DISCO Board, with the cursed M7 core revision, obviously. :persevering_face:

The project uses LTDC + TouchGFX, FreeRTOS and a heap_4 scheme for 7MB heap located on external RAM, mixed languages (both C/C++, since it uses touchGFXlib, LwIP... et caetea, et caetera... the whole wizbang... undebuggable without step-through. :skull:

But the embedded ST-LINK V2 on this discovery board is tricky to push into DFU mode.

So I tried the aforementioned ST-LINK to J-LINK soft conversion, one could still found here on Nov.2020 :

https://www.segger.com/products/debug-probes/j-link/models/other-j-links/st-link-on-board/ 😍

And it's reversible... thanks Segger !

But...of course, this Segger J-Link conversion console utility needs the device to be in DFU mode... 'figures.

Otherwise, the device won't be found. :weary_face:

And pushing the embedded ST-LINK into DFU mode was a hassle for me. A big one. I might have missed some important knowledge on the how-to.

So I used a dirty trick : :smirking_face:

1. Start STM32 ST-LINK Utility, go to ST-LINK>Firmware update and on this dialog, do what's required to enter DFU mode.*
2. Leaving these windows open, launch your computer processes manager, and kill the ST-LINK Utility process along with all of its hierarchy.**
3. Use the Segger J-LINK conversion utility, tadaaa... on-board Segger J-LINK, free of charge.

You and I can finally debug without suffering from spurious interrupts jumps.

Hope this will help some.

{*WARNING : the ST-LINK device will be released from DFU mode if you close this dialog...However, it needs to be released from the running process in order to upgrade it externally.}

{ ** I insist on killing, i.e terminating the process without legal signaling, not "ending" the task as per Microsoft terms, of closing the program )

On Windows 10, it would be from the details tab of the task manager, using the contextual menu to End process tree. Do not end the task from the process tab, as it will signal the ST-Link Utility, pulling the programmer out of DFU mode. }

[JKuen.2]

I've tested the Segger J-Link solotion and it works for me, debugging single step without any problem. I'm using STM32CubeIDE 1.9.0 which offers Segger J-Link for debugging. My board is a NUCLEO-F756ZG and with the ST-Link debig interface not really usable.