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]

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.

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

[Bill Lewis]

Posted on April 21, 2017 at 20:07

Aaron,

I get that error   gbd --version  also, if I simply click the Debug icon.

I select from the dropdown the debug config itself (which I would think does the same thing), and then it just works.

Bill

[world04]

Posted on April 21, 2017 at 21:16

Why you do the rumble of configure the IDE instead using a full featured working one line 

http://www.isystem.com/download/winideaopen

 ?

It supports ST-Link and J-LINK, a bunch of RTOS liek freeRTOS, RTX and others. here an examples of my actual project of an F7DISCO board using an CubeMX generated freeRTOS project

[Adam BERLINGER]

Posted on September 25, 2017 at 15:47

Hello Tarek,

I tried your workaround and it didn't work. Butbased on your approach I found similar solution which works.

The solution is to implement similar hooks for the OpenOCD. Maybe the delay between the GDB and OpenOCD is too long for the workaround to work (since the

DHCSR

registermust be modified before the interrupt is triggered).

Also the modification of the DHCSR register requires special key in the upper 16-bits, otherwise the write operation is ignored.

Here is the possible solution:

1) In debug configuration select'user defined' configuration script. This will prevent the IDE from overwriting the *.cfg file (STM32746G_Nucleo Debug.cfg in my case)

EDIT: it seems the the default filename 'STM32746G_Nucleo Debug.cfg' can be deleted/overwritten is some cases by the IDE, so I would recommend choosing different name for the file (e.g.: 'STM32746G_Nucleo_custom.cfg').

2) Append the following code to the *.cfg file:

$_TARGETNAME configure -event halted {
 mww 0xE000EDF0 0xA05F000B
}
$_TARGETNAME configure -event resumed {
 mww 0xE000EDF0 0xA05F0001
}�?�?�?�?�?�?�?�?�?�?�?�?

I'm not sure if this will work in all scenarios, since it can interfere with the debugger configuration.

Best regards,

Adam

[May Z]

Posted on October 13, 2017 at 19:21

Thanks Nick, this worked for me too. I had the same issue while using the NUCLEO-L476RG board, running a UART example adapted to communicate with a Bluetooth module.

[Tesla DeLorean]

Posted on October 15, 2017 at 18:50

The L4 should run in a fairly linear fashion, turning off optimization will help with apparent jumping around as code will not be reordered, and you'll get a more one-to-one relationship between the C lines and the stream of instructions that translates to at a machine level.

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