cancel
Showing results for 
Search instead for 
Did you mean: 

Problem with Single Step STMF7

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.
64 REPLIES 64
Posted on April 17, 2017 at 22:11

I tried the .gdbinit file and it had no effect.

This issue makes the STM32F7 Disco board useless to me.

Posted on April 17, 2017 at 23:18

I had descripted the issue and the solution or better to circumwork to eleminate them. This bug is not able to eleminate by  any other place as in the debugger firmware or ba replace the MPU to a last revision. ST does'nt fixed this issue in their debugger firmware and Segger offer a J-LINK  replacement for the F7 on-board jtag of nucleo or discovery.

This is not a oneway procedure, so it's possible to revert this back to the st-Link again. I had done this some times in the past. AC6 does'nt support any other debugger as the st-link by default. I had not implemented a j-Link support in ac6 (Eclipse) successfully, but i use the OZONE Debugger from segger instead. It's supports some RTOS like RTX, freeRTOS and some other commercial brands. I had done some experiences with this combination and was very surprized about the speed and versatibility of the OZone. 

Actually i had went away from ac6 to 'WINIdea Open', who is also a customized Eclipse environment, but this supports both debugger - ST-Link and J-Link. The bug-issue is also unsolved if an ST-Link is used, but you are able to flip em.
Posted on April 17, 2017 at 23:28

Others have had success flashing the ST-LINK with the Segger firmware.

Although it might be instructive to learn how to debug code without single-stepping it to understand how it works. This was quite an effective technique when a Microprocessor ICE systems cost as much as a small car, and you could take a tea break waiting for the code to compile. You thought about the logic a lot more carefully.

Tips, Buy me a coffee, or three.. PayPal Venmo
Up vote any posts that you find helpful, it shows what's working..
Posted on April 18, 2017 at 00:30

Turvey.Clive.002

: This was quite an effective technique when a Microprocessor ICE systems cost as much as a small car, and you could take a tea break waiting for the code to compile. You thought about the logic a lot more carefully.

Yoooah, that's a word. I am use the debugger more often as it requires in regular case. This is very helpful to ensure that the code works a you had assumed is does.

I had taste the Keil µVision IDE and this also requires longer if the project is greater that a few lines. I am not sure the price of them but this is in a range of $10000.- or more.

Eclipse CDE has often a parallel build available that uses more than one thread to compile the code. This saves some time if the program code normaly needs more time. The Link process will be finished by just one thread, of course.

If an incremental build is available, this could save also much compilation time. Keil often lacks this - i guess this issue is related by the project manager and the header file references in the code. I had never attempt to find out how this is related by - Keil is to expensive for just enjoy my ham radio hobby projects.

The price of the 'winIDEA Open' i actually use is a sub of their winIDEA IDE, that's based upon Eclipse, but deep customized and optimized for using Embedded developing only. I can recommend using the open version even some little things are missing like parallel build or finding a source file of a variable. The most IDE are able to do all this.

It's supports many RTOS and Debugger. The most common are the ST-Link or J-Link and it' support their owen brand of very specialized hardware for commercial usage. I am not known what the price is for the simple model, but this will be higher that a 'Segger JTAG-Trace', where i am interessting in.

Yes, your are right - this tools are very expensive but they also very productive and the documentation is quite good.

As an example - i had finished all issues i work actually try to find an open alternative in the Keil µVision in just a few hours. The same project based upon the GCC instead Keils Arm compiler consumes much more time and some issues are unsolved, yet.

In a hand of a professional embedded developer who needs to finish a firmware in a fixed and predictable time frame, this will save money. It's just a point of view.

Posted on April 19, 2017 at 17:46

I was (obviously, mistakenly) under the impression a Segger pod would have to be purchased, that is why I didn't look into the reflashing of the ST-Link.  I've gone ahead and done that, installed all the bits, added the J-Link option to the ARM plug-in, and confirm that it all works.  So I'm happy again. :) 

Thank you, Clive, for nudging me in that direction.

That said, I don't need to revisit how to study and debug code with pencil and paper.  I've spent more than enough time on an IBM mainframe with keypunch machines and core dump listings, and burning EPROMs on micros to hold me.

Posted on April 19, 2017 at 20:54

Woow, puncher and reader - i had used this device some decates ago, too. This was serial linked to an Apple II and had programmed some numerical controlled milling maschines. I had left that company in the mit 1998 and had never seen such biest again.  

Posted on April 19, 2017 at 21:04

Yepp, i have purchaised a J-Link 8.0 too. Segger had changed their product line and have now more versions available. I am sure they does not just changed the variant name and implement the license in the device only. I assume that Segger had extend the hardware and spend some time into the firmware development. I love that J-Link because it's comes into the market with a full functional long term support and very good product for a payable price. The other fishes in the see of the debugger market are often quite more expensive and less usable for smaller business.

An real time debug stream tracer is an expensive extension and very helpfull to check the realtime behaviour of the written program. I wanna have such thing even this is used just for my hobby. I like it if things working.
T J
Lead
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.

Posted on April 20, 2017 at 16:59

I find this new J-Link flash to work well. Faster than that ST-Link / openocd combination.

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.