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.

[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

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

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

[world04]

Posted on April 20, 2017 at 22:45

If i remember it right, this issue was common like jumpin into the isr handler, even no breakpoint was placed their.

I also have seen something like this if the ASM-View is active at the same time i had the c source code trace active.

I guess the JTAG-Trace interpret's the asm code and in most cases this has got more lines as the C sorce equivalent. In my debugger it' possible to choose, if the debugger stopps before, at, and a line after the C command where the breakpoint is placed. winIDEA uses the regular ARM Toolchain and i guess that this are just a command line switch that could be turn on or off. I can imagne that the behavior of the debugger is not different on the OSX MAC.

So, the ST-Link does not fix the ISR CHip bug and it's possible to control the stop condition or behavior of a placed breakpoint, this could looks like your experiences.

[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 modified

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

[T J]

Posted on April 20, 2017 at 01:16

I have had the same problem, on uV5 with st-link.

I fixed it by turning off, Data and Program cache.

[world04]

Posted on April 20, 2017 at 22:35

Woow, i had not checked this - a good idea to taste it. I will check out this issue at the weekend, too. Very interessting - thank's alot for your experiences. 

[aaron239955_stm1_st]

Posted on April 21, 2017 at 13:47

I'm glad to see that many people have had success in fixing this based on the Segger J-Link mod.  I have come back to this myself, having worked along just using ctrl-r to run to cursor locations in the source code to avoid the problem.

However, when I install the J-Link firmware on my discovery board, the install works however the IDE needs some help to use it.  I am using the AC-6 SW4STM32 free IDE which works quite well as an un-restricted development environment.  However since it is essentially Eclipse pre-configured for ST's chips it does not have all of the ARM tools installed that would support other vendors chips as well as other vendors tools.  Specifically it does not have the plugins installed that would be aware of a J-Link as a debug connection.  It only has the ST-Link option for the 746 disco board.

I have started the process of adding the missing pieces but am still not quite there. 

Has anyone out there done this using this tool chain?  Specifically the SW4STM32 IDE?  If so, did you do something specifically to enable the J-Link interface?  If not, I will post my process once I get it working.

Thanks.

[Bill Lewis]

Posted on April 21, 2017 at 16:06

To use this updated J-Link firmware I bit the bullet and switched from SW4STM32 IDE to a regular Eclipse/CDT with the ARM plug-in. 

And then I used this:  

http://gnuarmeclipse.github.io/debug/jlink/

 

Had to change a lot of stuff to make the CubeMX project work there, but I was more interested in seeing if the new debugger would work.  Planning to try to get the J-Link working in SW4 but haven't looked into it yet.

[aaron239955_stm1_st]

Posted on April 21, 2017 at 17:07

Thanks, William.  It's good to at least hear others have seen the same issue and confirm that I am not just chasing ghosts.  I've installed the J-link plugin into SW4STM32 so I can find the J-link as an available debig profile, but it still is not quite there.  I'm getting a gdb --version error.  I'm currently in the process of adding the ARM packages to SW4STM32 and I'll post what I did if I am able to get it running.

[zabel]

Posted on October 26, 2017 at 10:40

Is there any official erratum concerning this problem? So far I don't find any _official_ information from ST nor from ARM.

[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

[A L]

Posted on April 22, 2018 at 14:33

Hi. I have the

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

on an

http://www.st.com/en/microcontrollers/stm32f746zg.html

board; single stepping in GDB is impossible due to the pending interrupt bug.

Here, some info on my particular type of microcontroller:

ARM Cortex-M7 r0p1

Unique ID: 0x00420037, 0x32355112, 0x35353534

CPUID 410FC271 DEVID 449

System Clock: 216000000 Hz

C0000038 2004FD18 00000000

10110021 11000011 00000040

FPU-S Single-precision only

Are there any workarounds for debugging it with GDB that solve this issue? (I have not read the whole thread yet...)

Does it make sense to try to change the DHCSR register in GDB?

And are there any chips with fixed r0p2 cores available already?

Any help would be appreciated. I have this issue since 2016, and hoped that it would be fixed in more recent chips, but it wasn't when I've ordered new ones recently..

[Tesla DeLorean]

Posted on April 22, 2018 at 16:01

ST's policy up to now has been to keep using the same core for a specific product, and only step their peripheral IP around it.

The F77x/F76x and H7xx use different cores

CPUID 411FC270 DEVID 451 REVID 1000

Cortex M7 r1p0

STM32F76xxx or F77xxx

C0000018 20021EB0 00000000

10110221 12000011 00000040

FPU-D Single-precision and Double-precision

SystemCoreClock: 200000000, 200.00 MHz

CPUID 411FC271 DEVID 450 REVID 1003

Cortex M7 r1p1

STM32H7xx

C0000018 20000438 00000000

10110221 12000011 00000040

FPU-D Single-precision and Double-precision

SystemCoreClock: 400000000, 400 MHz

My general recommendation would be to try the J-Link firmware, and to instrument your code to understand flow and interaction.

The situations where I need to single-step my code to know what it is doing is an extremely fractional case, static analysis is very effective, and knowing, via reporting, what it is doing dynamically augments that. Add code to get the visibility you need, and use bit flags or levels to turn on/off or isolate reporting.

[world04]

Posted on April 23, 2018 at 13:43

I am sure that their is an errata available who figures out what kernel step's are got this bugs.

ARM Cortex-M7 r0p0 and ARM Cortex-M7 r0p1 if i remembered it right

[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

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