ST 32F4xx debugging

[peter-h]

I am working on a project using the Cube IDE and the ST-Link isolated adaptor.

It all works fine but I have some fairly basic questions which the docs I have read don't address. Well, they contain huge complicated explanations which make sense only if you already know the environment.

Various different breakpoints can be set - Regular / Temporary / Hardware / Hardware Temporary.

From my embedded days (decades of it, Z80 etc era) breakpoints are either implemented on the CPU, with a breakpoint address register, or in software by replacing (or inserting) a bit of the code with a jump. On this chip the code runs out of FLASH so the only way to do the latter is to recompile the program each time there is any change of breakpoints, and the Debug As function does indeed seem to do this. Of course none of the old chips had hardware breakpoints. Actually there were even ways to single step through ROM code, by copying the ROM code to RAM a piece at a time and setting a breakpoint in RAM, and then copying over some more...

Now these breakpoints obviously slow down the code running, once they are hit. And since you are then single stepping, of course the program stops There is no real time trace, like one used to have on the in circut emulators of many years ago.

So what is the difference with a "hardware" breakpoint? It may run faster IF there is an associated skip count but does the 32F400 support a hardware skip counter? If not, what is the difference?

A skip counter which runs at full CPU speed, or something anywhere near close, could be useful. But one can attach expressions to breakpoints and obviously they can't be implemented on-chip. Where are they evaluated? For single stepping it doesn't matter because the program is not running at any speed anyway, but it could be handy if one could skip a breakpoint until say i=20, and do this at a fair speed.

In this thread
https://www.eevblog.com/forum/microcontrollers/st-32f4xx-spi-weird-behaviour-with-multiple-slaves-and-clock-polarity-phase/new/#new
it was suggested that the Segger adaptor is much better than ST-Link but apart from their eye watering pricing I find it hard to work out if there is anything useful there. Can anyone give concrete example? I wonder if this is related to my questions above.

[newbrain]

From my embedded days (decades of it, Z80 etc era) breakpoints are either implemented on the CPU, with a breakpoint address register, or in software by replacing (or inserting) a bit of the code with a jump. On this chip the code runs out of FLASH so the only way to do the latter is to recompile the program each time there is any change of breakpoints, and the Debug As function does indeed seem to do this. Of course none of the old chips had hardware breakpoints.

In general, there's no need to recompile anything to change/add/remove breakpoints.
It's probably an artefact of Eclipse bone-headedness, if you inhibit flashing (in one of the eleventythousand panels and dialogs) you'll see that your breakpoints still work as expected.

Arm MCUS have a variable number of HW breakpoints and watchpoints, e.g. the STM32F4xx, as most Cortex-M4s, has 6 breakpoints and 4 watchpoints.

The debugger SW (say, gdb) will communicate with the probe through a debug server (can be skipped for some type of probes, e.g. Blackmagic), which will talk to the probe.
The probe, through its SWD or JTAG interface, will  set the internal comparator registers of the Flash Patch and Breakpoint Unit (FPB) for breakpoints or the Data Watchpoint and Trace Unit for watchpoints (they can do more than watch and break points, but let's keep it to the basics).

Look at what happens when setting more than the HW provides (this is an STM32L476, also with 6 HW breakpoints and 4 watchpoints):

Code: [Select]

C:\Users\newbrain> pyocd cmd --target stm32l476rgtx
Connected to STM32L476RGTx [Running]: 0674FF535752877167093659
pyocd> break 0x80000C0
Set breakpoint at 0x080000c0
pyocd> break 0x80001C0
Set breakpoint at 0x080001c0
pyocd> break 0x80002C0
Set breakpoint at 0x080002c0
pyocd> break 0x80003C0
Set breakpoint at 0x080003c0
pyocd> break 0x80004C0
Set breakpoint at 0x080004c0
pyocd> break 0x80005C0
Set breakpoint at 0x080005c0
pyocd> break 0x80006C0
Failed to set breakpoint at 0x080006c0
pyocd>
pyocd> watch 0x20000000
Set watchpoint at 0x20000000
pyocd> watch 0x20000080
Set watchpoint at 0x20000080
pyocd> watch 0x20000100
Set watchpoint at 0x20000100
pyocd> watch 0x20000140
Set watchpoint at 0x20000140
pyocd> watch 0x20000190
0100032:ERROR:dwt:No more watchpoints are available, dropped watchpoint at 0x20000190
Failed to set watchpoint at 0x20000190
pyocd>

For breakpoints, when the address programmed in a comparator register is hit by the PC, the processor stops.
As communications on the SWD interface can only be initiated by the probe, it's its task to poll the debug registers to understand when the the breakpoint has been hit.

Hard breakpoints are useful for code running in flash, while soft breakpoints (= replace an instruction with the BKPT op code, as you mentioned) can be used in RAM.
Temporary breakpoints are simply breakpoints that the debugger SW will cancel once hit, and it's still a function of the debugger SW to take care of complex breakpoints with hit counter or a guard expression.

Arm processors offer also advanced tracing support, in the form of the ETM and ITM for more complex debugging.

[peter-h]

Thanks for your explanation and the links. Interesting indeed. The 32F can feed a BRK opcode to the CPU when it gets an address match, which is damn clever because it enables "software" breakpoints in FLASH.

Both "standard" and "hardware" breakpoints offer the option of a condition and a count



Based on what I read and what you say, that the debugger should be able to reprogram the breakpoints dynamically via Jtag. And you are quite right; it can. One can add and delete breakpoints and just run it (with F8 etc). It is only the Debug (F11) or Debug As... functions which do a Make.

[peter-h]

It appears that the main thing you get on the expensive Stegger debuggers is the dynamic flash patching, which enables unlimited breakpoints with code running in flash
http://www.segger.com/products/debug-probes/j-link/technology/flash-breakpoints/

Their top model has a 64MB trace buffer. Does anyone know the performance hit when using this feature? Clearly it is not an old-style ICE (zero perf hit); it must be setting breakpoints, and processing the data, as fast as it can.

[Siwastaja]

Those are like sports cars, they are entertainment devices.

A professional drives a normal reliable car; or mostly uses other strategies than advanced debugging probes. 99% of the work with MCUs does not involve using a debugger of any kind. Remaining 1% does not require specialized high-end features, 6 breakpoints is more than fine, and it's completely irrelevant whether adding a breakpoint takes a millisecond or a second. Even having to add BKPT in your code and reflash isn't a real problem, if you find it slows your workflow down the solution is to fix the workflow.

Of course you can always use a golden hammer decorated with diamonds, to drive a screw.

[peter-h]

I would agree, and breakpoints / single stepping is used mostly for debugging one's logic or algorithm (well it can hardly be used for debugging stuff which works when slow and breaks when fast ) although stuff like execution profiling is nice for the times one needs it.

And I don't see any way of doing that anywhere near real time, because the only way I see of doing it is by setting breakpoints at sequential addresses, across a specified address range, and logging the value of a time counter when each breakpoint gets hit, and then very quickly removing the breakpoint and moving it to address+1. Eventually you build up a histogram of where the time was being spent.

[Siwastaja]

Breakpoints and single-stepping is a stone-age method for debugging logic or algorithms. It's not even using a hammer for a screw, it's hitting a screw with a stone.

Separate the logic and algorithms to stand-alone functions (or code modules, if large enough) and unit-test them with generated test vectors. This is trivial on PC and you can get much more visibility into the system, even run all possible input combinations, or play back real-world input data, than running the "production code" inside the miniature MCU with debugger probe attached then hope to catch something interesting.

Even in MCU production code, use your own assert()-like error handling/logging system. You can even catch a rare bug on the field! No need to try to reproduce it on lab table with Segger connected.

You can replace this ST LINK stone with a fancier stone, like a diamond (an expensive Segger), but it's still hitting the screw with a stone because the root issue of the wrong workflow isn't fixed.

Debugger features are useful when some hardware peripheral produces unexpected result that can't be easily simulated through test vectors, i.e., put a breakpoint in the ISR and look at the peripheral registers.

Or to quickly see why the CPU isn't starting up properly or enters some hardfault or busfault handler. With a debugger, you can quickly see where the exception occurred and start looking for the reason.

Although MCU manufacturers make even that quite difficult because many peripherals have strange features like reading out a status register clears it, so if the debugger reads it out, the state changes, and if you trust the transparency of debugger, you are wrong and being mislead. So even in such cases, it's often more powerful - and more understandable - to add the required visibility by explicit code written by you as a part of the application; for example, read out status register at a certain point in ISR and add a comment that this read resets the register. Store in a variable for later use / report / logging.

Tools are easy to explain to management and easy to buy, though. And expensive tool must be good! Give the boys the toys and so on. The management thinks the expensive toy "pays for itself" quickly.

[rhodges]

Debugger features are useful when some hardware peripheral produces unexpected result that can't be easily simulated through test vectors,

This might be helpful:

Code: [Select]

> alias arm-gdb echo You probably forgot to enable the clock.


[peter-h]

One annoying problem I get with the Cube IDE and the ST Link (isolated, £60) debugger is that every so often it says it cannot connect to the GDB thingy on port xxxxx and the only way to make it work is to reboot my PC, which is a PITA since I have a load of stuff running on it. A reboot is unusual; it is win7-64 and usually runs for some months before it needs a reboot.

The error message is all over the internet (as usual) and nobody has a clue (as usual)

Disconnecting and reconnecting the USB cable doesn't fix it, though it does fix another error which happens sometimes. Also exiting and restarting Cube is sometimes needed. But nothing easy solves the GDB can't-find problem.

Would another debugger be more robust in this respect?

[newbrain]

One annoying problem I get with the Cube IDE and the ST Link (isolated, £60) debugger is that every so often it says it cannot connect to the GDB thingy on port xxxxx

What is saying what about what port?
I'm asking, as there are usually at least two kind of ports involved, one is the USB port the probe is connected to, and the other one is the TCP port GDB uses to connect to the debug server (this might not be there, there are other ways to communicate between gdb and a gdbserver).

For the former, USB, it's usually enough to disconnect and reconnect the probe, as you mention. It happens to me sometimes also with DAPLlink and CMSIS-DAP  .
In extreme cases, it might help disabling and re-enabling the device from the Device Manager.

For the latter, it might happen that the gdbserver process is still holding the port (maybe a zombie from a previous debug session).
In this case, you could try to find the gdbserver process name (each vendor tends to have its own, or it might be a generic one as pyOCD/OpenOCD) and kill it, from Task Manager or PowerShell, then do disconnect reconnect dance.

[DavidAlfa]

Yes, the ST-LINK has its issues... it might hapen randomly, or if you accidentally click again on debug/run too quickly, requiring removing & plugging again. Even the IDE crashes badly sometimes.
I noticed this happens a lot more often when you power the stm32 from the stlink power.
Since I have a ST-Link v2 clone, with the white plastic housing, there's a lot of room inside.
I opened it and soldered 100uF tantalum capacitors at the input & output of the LDO.
Since ​then the crashes are very rare. That was few months ago, I've used it a lot since then, so I can ensure it's not placebo effect.

I also have one of these $3 ST-Link mini, that bastard crashes more often than I breathe.
There isn't space inside for bigger caps, so I threw it into the "misc" crap box, reserved for emergency only.

[peter-h]

I emailed Segger with some questions but got no reply... they must be selling plenty

Dear Sirs,

I am working on an STM 32F417 project and using STLINK V2 ISOL & STLINK V3 ISOL debuggers.

The V2 is rock solid but slow and there is no easy way to connect to the 10-way debug connector with it.

The V3 is rock solid if you either do not use the ISOL module, or use the 20-way header. With the fine pitch 10-way cable, it works 100% for code download but is not reliable for stepping, and with the ISOL module is so unreliable it is almost useless (but it does basically work).

I am getting a bit fed up with this, especially as the 20-way cable and the 10-way cable come off the same PCB in the V3 and should be the same physical signals.

Are your debuggers any better and if so, which one would you recommend? I don't want to pay more than about €200. I have seen some for €1500+ which seem to have clever features like unlimited breakpoints in FLASH (by reprogramming the FLASH) but we don't need that.

Having fast breakpoints is a good thing, and the STLINK V3 (NON ISOL) can run at 24MHz.

The devt environment is ST Cube IDE v1.6.1 which supports some SEGGER debuggers.

Thank you in advance for your reply.

"For the latter, it might happen that the gdbserver process is still holding the port (maybe a zombie from a previous debug session).
In this case, you could try to find the gdbserver process name (each vendor tends to have its own, or it might be a generic one as pyOCD/OpenOCD) and kill it, from Task Manager or PowerShell, then do disconnect reconnect dance."

Yes, that works well. I don't recall the process name but it is fairly obvious. One obviously has to exit Cube when doing the deletion.

[ajb]

IME, the J-Link products have several advantages that make them worth the price for me, at least compared to the ST-Link v2 (I haven't used the v3). 

• Reliability: I've had WAY fewer weird failures during debugging with a J-Link than with the ST-Link, almost none in fact.  I would have to disconnect and reconnect the ST-Link at least once a day during normal development
• Speed: The J-Link is substantially faster, especially on parts with large memories.  Part of this is compare-before-write that skips re-writing flash that hasn't changed, but subjectively just basic throughput seems substantially faster as well
• Flexibility: One tool supports multiple brands of MCUs
• Additional capabilities: The J-Link Plus and up give you access to J-Flash (customizable one-click programming including of external memories) and Ozone (standalone debugger that works directly from an .elf file) which can be great problem solvers.

The price is a bit high, but with the above and the solid (IME) support from Segger it's well worth it for professional situations.  Especially the reliability--when debugging subtle problems you need to have confidence that the tool itself isn't part of the problem, and I've definitely wasted time on that with the ST-Link.  YMMV.

[Sal Ammoniac]

Are your debuggers any better and if so, which one would you recommend? I don't want to pay more than about €200. I have seen some for €1500+ which seem to have clever features like unlimited breakpoints in FLASH (by reprogramming the FLASH) but we don't need that.

Is this a personal, noncommercial project? If so, get the J-Link EDU, which is about $60 and has most, if not all, of the capabilities of the J-Link Base (the cheapest J-Link for commercial use).

[JOEBOBSICLE]

Make sure you dial down the debug baud rates if you have problems.

I have found that vendor IDEs are pure rubbish. Get something like vs code or clion. You don't have to use eclipse based tools in 2021.

[peter-h]

I am stuck with ST Cube IDE because, currently, the structure of the project is beyond my level of understanding, and somebody has set it up for me. I go back to ~1980 so I know about makefiles etc but used to edit these by hand, but all projects I did were 10x to 100x simpler than modern ARM stuff where you have hundreds of source files.

The unreliability of the debuggers doesn't appear to be speed related.

One thing I do like is isolation. It makes it much harder to blow things up. I don't think the sub-€1000 Segger units are isolated. Some pics of the PCBs clearly show they are not. The downside is that the target has to power the isolated side of the debugger - unless there is a DC-DC converter in the debugger, which usually there isn't (but could be, at the price, and the STLINK V3 ISOL does actually have one but it doesn't appear to be used for this job).

The STLINK V3 ISOL is very hard to beat, at ~€70, IF one can get it running reliably. It is reliable if you remove the ISOL board, or (with ISOL) if you use the 20-way connector (not the little 14-way one).

The Segger units are around €400 e.g. the J-Link Base
https://uk.farnell.com/segger/8-08-00-j-link-base/jtag-emulator-usb-for-arm/dp/2098541

The Edu
https://www.mouser.co.uk/ProductDetail/Segger-Microcontroller/80890?qs=d0WKAl%252BL4KahvecKZdeiVg%3D%3D
claims to be the same as the Base:

SEGGER Microcontroller J-Link EDU Debug Probe is identical to and offers the same functionality as the J-Link BASE. This debug probe supports a broad range of microcontrollers and multiple CPUs including 8051, PIC32, RX, ARM7/9/11, Cortex-M/R/A, and RISC-V. The J-Link EDU debug probe features a download speed of up to 1MBps. Unlimited breakpoints in the flash memory feature can be used for evaluation

so how does this work, at 1/5 of the price of the Base? Segger don't respond to tech questions so it can't be a different level of support

These all have the 20-way connector so I would need an adaptor like this (but not exactly like this; I have the 10-way 0.050" pitch connector)
https://uk.farnell.com/segger/8-06-00-j-link-19-pin-cortex-m-adapter/adaptor-j-link-19-pin-for-cortex/dp/2098534

The really funny thing is that the STLINK V3 ISOL is solidly reliable when I connect my target with the 20-way cable. So I bought this
https://www.amazon.co.uk/gp/product/B0888961J5



and will see if that solves it. I can't believe it is the fine pitch cable that is causing it, especially as every 2nd wire is GND. I tried to buy some of this stuff from Olimex in Germany but they won't ship to the UK below €200 (same old story).

I also wonder how the Segger utilities integrate with Cube. For example they do the J-Mem Memory Viewer for viewing memory and registers, but there is, I think one in Cube which does that (certainly for registers). Then there is the J-Link SWO Viewer which seems to do the same thing as the ST "SWV ITM data console" (??).

[Siwastaja]

The root cause of all your issues is inheriting an overly complex bloated project you can't understand and work with. Really, I see two options;

1) Start over. Don't create hundreds of source files for no good reason. Don't use Cube. Allocate enough time to do the project properly.

2) Communicate closely with the original author/team. Only they are able to guide you through things that take days on your own, in minutes. This is likely the quickest way.

If 2) is not possible and you don't get resources to do 1), then what happens is,

3) Try random things and finally get an unmaintainable system you don't understand kind-of-work. Issues surface years to come destroying your mental health and you just want to have a new project and forget about this.

[peter-h]

I appreciate your advice, Siwastaja. However, I have written a fair bit of code for this project and it all runs 100% solidly. I am pretty impressed at how solid it is - once I get silly bugs out. So I am confident that once I have done my testing etc, it will be solid enough.

The issues are in the libraries from, I believe, ST, which even I can see are full of crap, but there is no choice, because practically nobody is going to write code from scratch for USB and ETH. And the result would not be any better, unless somebody has no life and spends a year or two on it. This, I think, is how life is for an embedded systems guy these days, if you want ETH and stuff like that. FYI, the only reason I got into this ARM stuff was because customers are asking for ETH, which is not practical with the old slow micros.

Back to the topic, why is J-link Edu 1/5 of the price of J-link Base, while the description claiming it is the same thing. Are there some software licenses involved, which the Edu does not have?

AIUI, the way this stuff works is

1) Cube IDE has its own debug features, and it uses SWD (or JTAG) in a simple generic mode to talk to a debugger, which is accessed via USB, via some generic drivers

2) The J-Link stuff, looking at its 406-page manual, has tons of software utilities, some GUI and some command-line, and these can be used standalone if not running Cube IDE, but presumably not concurrently with it

Is this correct?

Is the J-Link SWO Viewer the same thing as the ST "SWV ITM data console" but presumably usable only outside Cube IDE?

FWIW I have just been testing STLINK V3 (not ISOL) at 24MHz, with SWV ITM data console running, running over the fine pitch 10-way cable (not the 20-way one which seems reliable anyway een with the ISOL option) and with a breakpoint running (at maybe 100Hz) with an ignore count of 10000, and apart from occassional debug data corruption I can't make it go wrong. This is a €30 debugger... what would a J-Link Edu do in addition to this?

All this looks to me like

- the STLINK V3 debugger is flakey when the ISOL board is added
- the 10-way debug connector on STLINK V3 has some problem, which becomes bad enough with the ISOL board to make it almost useless
- there may be a problem with the ST drivers (one does get the occassional "can't find the SDB" problem)
- some debuggers may be faster (but will they be faster than 24MHz STLINK V3 ?) or more reliable

I can just buy the Edu for £60 and not spend time posting these questions, and if it is no good, chuck it in the bin

[JOEBOBSICLE]

You can reprogram a nucleo to work as a jlink to try it out.
 
The main advantage of j link is software support, only recently has openocd been super reliable and only recently has very low cost debuggers like the st link been available. The jlink gdb server is rock solid plus they have libraries for real-time trace that you can put in.

You can get visual gdb for visual studio and import your st project by the way.  There's a free trial for it and it has fantastic intellisense plus debugging.

The main advantage is you can use ninja plus cmake plus all the thread aware debugging it has and live graphing.  Ninja is so much faster than make which is what every eclipse IDE uses under the hood

I too am sympathetic of those maintaining software for these complex microcontrollers,  it's something that takes years to understand

[Sal Ammoniac]

You can reprogram a nucleo to work as a jlink to try it out.

Yes, but I believe that this only applies to Nucleo boards with built-in STLINK V2. Newer Nucleos based on STLINK V3 don't support this.

[peter-h]

I bought the J-Link Edu and it works.

The SW debug console runs at the max speed of 4.5MHz (STLINK v3 is 2MHz max) and that will help in some applications where you don't want to load up the target.

It has some FreeRTOS support but on a quick play around - didn't have much time - I could not find what that did.

It does reprogram your debugging settings, notably setting the CPU clock to 16MHz, so your SW debug stops working

As regards reliability, I will retest it soon with the 20-way to 10-way adaptor cable (bought some Olimex ones on Ebay; Olimex Germany don't ship to the UK below €200) and buzzed them through and the connections are right.

[Sal Ammoniac]

Now that you have a J-Link, you can use Segger's Ozone debugger. It's quite nice and very robust.

[lucazader]

The SW debug console runs at the max speed of 4.5MHz (STLINK v3 is 2MHz max) and that will help in some applications where you don't want to load up the target.

Not sure where you got that number from.
The ST-Link V2 has up to 2MHz SWD speed.

The ST-Link V3 has up to 24MHz SWD and 16MHz SWO
(Source: section 7.1.1, pg12 https://www.st.com/resource/en/user_manual/dm00526767-stlinkv3set-debuggerprogrammer-for-stm8-and-stm32-stmicroelectronics.pdf)

[peter-h]

2 MHz SWO max showing in the pulldown menu



For SWD, the V3 does 24MHz but not with the ISOL board. Then it fails to work at much above 8MHz. This has been measured across several of them.

It doesn't matter whether the core clock is 16MHz or 168MHz. The max SWO shows 2000kHz.

[lucazader]

2 MHz SWO max showing in the pulldown menu
It doesn't matter whether the core clock is 16MHz or 168MHz. The max SWO shows 2000kHz.

Are you using a ST-Link V2? If so, this makes sense.

If not, then I would guess that this is a limitation of the CubeIDE.

Edit: Just installed the cubeide and had a look.
It does seem to be a limit of either the ide, or the st provided gdb server, or a combination of both.

I believe with openocd or similar tools you should be able to specify higher swo speeds with the st-link V3