Problem with Single Step STM32F7

[aaron239955_stm1_st]

Posted on December 07, 2016 at 21:47

There is a problem with IDE debuggers for STM32F7, 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]

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.

[arnaljl]

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

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/ :smiling_face_with_heart_eyes:

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. }

[jerry_sandc]

i'm seeing this on our STM32F779 too, and its making me cry.  Anything I find online about this is cryptic.  I'll try your painful workaround above.

 

[Tesla DeLorean]

The F779 should have a different ARM core than the F746, you likely have a different problem.

Code stepping and jumping around in the C file, most likely need to turn OFF optimization, so there's a simpler/singular line to line relationship.

Perhaps better tackled in a new thread than this near decade old one.

//****************************************************************************

void CORECheck(void) // [e-mail]
{
 uint32_t cpuid = SCB->CPUID;
 uint32_t var, pat;

 printf("CPUID %08X DEVID %03X REVID %04X\n", cpuid, DBGMCU->IDCODE & 0xFFF, (DBGMCU->IDCODE >> 16) & 0xFFFF);

 pat = (cpuid & 0x0000000F);
 var = (cpuid & 0x00F00000) >> 20;

 if ((cpuid & 0xFF000000) == 0x41000000) // ARM
 {
 switch((cpuid & 0x0000FFF0) >> 4)
 {
 case 0xC20 : printf("Cortex M0 r%dp%d\n", var, pat); break;
 case 0xC60 : printf("Cortex M0+ r%dp%d\n", var, pat); break;
 case 0xC21 : printf("Cortex M1 r%dp%d\n", var, pat); break;
 case 0xC23 : printf("Cortex M3 r%dp%d\n", var, pat); break;
 case 0xC24 : printf("Cortex M4 r%dp%d\n", var, pat); break;
 case 0xC27 : printf("Cortex M7 r%dp%d\n", var, pat); break;

 case 0xD21 : printf("Cortex M33 r%dp%d\n", var, pat); break;

 default : printf("Unknown CORE\n");
 }
 }
 else
 printf("Unknown CORE IMPLEMENTER\n");
}

//****************************************************************************