32F4: Can a target crash or affect Cube IDE?

[peter-h]

Here is a funny Q on Cube, running a STLINK debugger:

Is there any way for a "dodgy" target to hang or crash Cube, or cause Cube to lose contact with the debugger, or mess up a part of Cube's debug functionality e.g. the SWV ITM debug output feature?

I would think that the answer must be NO unless you are running in Debug mode. But who knows? There is still a USB connection PC to debugger, and I can see there is probably continuous data on that cable.

In Debug mode, there is definitely constant USB data.

Reason I ask is that over the 2-3 years I've been writing and debugging code (mostly with STLINK V2 ISOL or STLINK V3 ISOL) I have found that sometimes the Debug mode runs for no more than an hour (or even much less) and sometimes it seems to run for weeks, before it drops Debug mode. Right now, on the current and nearly final generation of my code, Cube does run for weeks in Debug.

And this is at two different sites (home and office).

Sometimes Cube loses breakpoints until you exit it and restart it. Weird stuff like that.

Is that possible?

[nctnico]

Very probable. Keep in mind that JTAG / SWD is a synchronous protocol and 1 false clock on the clock line can screw things up badly.

[ajb]

I've definitely seen issues with multiple debug environments along these lines.  Not necessarily a target crash, but something goes wrong somewhere in the debug chain, and debugging won't work again until you restart the IDE and/or unplug/replug the debug tool.  There's a lot that goes on between click "Debug" and actually getting the debug session up and running, and a lot of software involved: UI stuff in the debug environment, the debug backend, USB drivers, OS-level USB support, firmware on the probe, etc, plus electrical aspects of the SWD/JTAG interface.  So lots of opportunities for errors to occur, and lots of code that needs to be able to handle those errors appropriately. 

FWIW, I mostly saw these sorts of issues when using an ST-Link V2.  IME, J-Link probes are much more reliable, and also generally faster.  I've still had to restart an IDE once in a while when using a J-Link, but overall FAR fewer issues than with an ST-Link.  No experience with the newer ST-Links.

[DavidAlfa]

I've had issues with the IDE getting slower and slower when debugging with SWO enabled, until eventually crashing, mostly when using SWD Data Trace plot.
It's been a long time since last time, back then the IDE was a lot slower and greedy for RAM, opening large source files made it extremely sluggish, requiring all the smart code functions to be disabled.
I've never had that issue again since 1.09 or so, so the SWD slowdown might be also fixed by now.

[Siwastaja]

Buggy software usually fails to validate/sanitize input data, plus abstractions between modules are leaky spaghetti mess, so yes, anything is possible.

[peter-h]

I've had issues with the IDE getting slower and slower when debugging with SWO enabled, until eventually crashing

Yes; stuff like that.

It's got better but not properly fixed. Cube has to be restarted.

But the strange thing is that the target software affects how [un]reliable it is. It almost looks like something subtle is affecting Cube. I have two targets which have suddenly become much more reliable after I put in the CPU ID checks for making use of the extra 64k of the 437. But only one of the two targets actually has a 437 The other is a 417. So it looks like calling the CPU ID check func changes something.
https://www.eevblog.com/forum/microcontrollers/32f417-32f437-auto-detect-of-extra-64k-ram/

A bit more detail in case anybody thinks of something:

Cube gets the CPU ID (and rev code etc) for the debugger init, obviously (it shows the detail, too).
My boot block gets the CPU ID, but it runs fully in 417 mode and the only thing it does differently if it is a 437 is that it fills the 437 stack (8k, top of RAM) with "S", whereas with a 417 it fills the 417 stack (also 8k, top of RAM) with "s".
Then it jumps to main() which also gets the CPU ID and uses it for various things, especially the Vbat measurement R ratio.

[DavidAlfa]

Have you ever tried emBitz? Last time I used it was astonishing fast.
Then I stopped for a while and I simply forgot.
I want to try running the HK32/PY32 there!

[peter-h]

No; I am stuck with Cube IDE, for many reasons.

[newbrain]

I have managed to repeatably crash gdb while developing my debug monitor with an out of sequence message.
No SWD involved, just serial (over USB, admittedly).

[peter-h]

Should there be any SWD activity if no breakpoints are set in Cube?

I have no dual-use SWD or BOOT pins, and everything is pulled up/down.

AIUI, SWD or JTAG is a huge PISO+SIPO shift register which goes all around the CPU and you can read, or even write, various things. But if not writing (which is possible only while stopped anyway) the CPU should not be affected and it should not affect anything via SWD/JTAG.

[abyrvalg]

The never stopping USB activity doesn’t necessarily mean SWD activity:
- ST-Link V3 has a virtual serial port, the OS should poll it even if you close the IDE
- There can be something like continuous target voltage sensing by the IDE

[peter-h]

Right, but something is terminating the Debug mode. This happened after an unusually long time - a few days. Most people report hours or less...



In the absence of breakpoints set, what could terminate the Debug mode?

Tried all the usual things over the years e.g. running SWD at some low frequency, etc.

It might be related to getting the CPU ID - as I posted above.

But why would Cube even be aware that the target is running, if there are no breakpoints? Does SWD have a CRC on it, so if Cube is running a continuous clock+data around the chip and gets a bad CRC...? I guess Cube does not assume it knows about breakpoints (especially the five "hardware" ones) so it is continuously polling the loop.

[Perkele]

STLinkv3, MCU connected over SWD, ITM used as debug print output.
STM32CubeIDE crashes if I leave it for more than one hoour with debugger running.

I wasn't bothered with finding the cause, because I don't use Cube regularly.
Connected a logic analyser and used GPIOs and UART instead of breakpoints.
Found the cause of issues in firmware and successfully continued to ignore the existence of STM32CubeIDE.

[abyrvalg]

But why would Cube even be aware that the target is running, if there are no breakpoints?

In theory there are ways to initiate debug halt from the firmware side w/o setting any breakpoints from the IDE:
- executing a BKPT instruction
- setting a breakpoint by programming the FPB unit
- halting directly by a write to CoreDebug->DHCSR

While 2nd and 3rd ways looks quite exotic to be supported by the IDE, the BKPT instruction was seen in some panic()- and exit()-like functions. So they could've decided to poll the halt state regardless of BPs being set.

[peter-h]

I can understand you, but why would Cube be doing this on a target running under Debug, or how could the target cause Cube to drop the Debug mode (and say "target is not responding")?

Taking that error message as correct (probably unwise) what kind of "response" would Cube be looking for? Is the target sending some data unilaterally? AIUI, SWD/JTAG is a synch protocol, with the PC supplying the clock.

[DavidAlfa]

Don't try to find reasonable explanations for buggy software 
Seriously, give a try to emBitz, shouldnt be hard and it will peacefully coexist with the CubeIDE project files.
I'm not telling to use it for developing, just for long debugging sessions.

[peter-h]

What I found to be much more "reliable" is that the use of the SWV ITM debug feature bombs Cube much faster, but that was only during the target actually outputting.

The problem was not related to the clock speed used for SWV ITM.

[DavidAlfa]

For only the de ITM console you can use STLink utility.

[peter-h]

I had a play with that and it looks like it has great potential, but it is difficult to get it to work. Maybe some subtle config issue.

I have a printf redirected to SWV ITM and this works with Cube IDE. This comes out shortly after startup and outputs "Hello" and PCLK1/2 etc.

I managed to get the line of output to come out but only a bit at a time, say 5 chars, by pressing start/stop on the SWV console, but that was my entire success. Then that stopped... I am using the System Reset button to restart the target so I can get the output, and the reset works ok.

For SWV to work one has to config the CPU clock, which I have at 168000000. The 2000kHz SWV clock is not evidently configurable anywhere. For the SWD clock, currently 8000kHz, I have tried all speeds.

Cube IDE not running, is correct, I presume. It can run but not with any debug functionality since the USB debugger port cannot be shared.

EDIT: I got it running eventually, by disconnecting the STLINK USB cable a few times Let's see how long it lasts for... The output is rendered much faster than in Cube. Probably the STLINK utility isn't running 10k lines of Java for each byte

Spotted something curious: the debug console expands \r to \r\n. I checked this with a breakpoint on the actual ST low level function. IOW, a pure "CR" (a line overwriting itself) cannot be implemented e.g.
printf("In app.c %010lu\r",loopcnt++);

[peter-h]

How does the ST-LINK Utility implement a continuously updated live view on RAM, on a running target?

It must be halting the target and reading out the RAM, surely?

This is the stack area, continuously changing as the interrupts etc are running. Quite impressive.

[abyrvalg]

Cortex debug port has direct system bus access, no need to halt the core to read/write memories. Debugger just writes addresses/access types and transfers the data. That’s great, compared to i.e. older ARM7, where you needed to inject a load/store instruction and observe/overwrite right bus cycle.

[ajb]

The Debug support section of the datasheet should have a diagram showing how the debug components interface with the system.  Between that and the bus matrix diagram you should see that the debug support components have access to memory (and everything else on the bus) independent of the core.  Since the bus matrix supports multiple masters anyway (it has to for DMA to work, and to support multi-core architectures) the debug interface can operate as just another bus master and initiate accesses independently of the core.  It may incur a performance penalty, though, since even with a comprehensive bus matrix there may still be some contention for access to the same resources.

[peter-h]

This is an impressive tool.

I guess most use it to also set things like level 2 security, even though your code can do the same.

[DavidAlfa]

Anyways, you can leave the target running and connect later on when it crashes.
Check the STM32CubeIDE manual, "Attach to running target", and better read it whole!