Cube IDE poor reliability when debugging

[PHolt.1]

Here are some threads which describe the problems

https://community.st.com/t5/stm32-mcus-boards-and-hardware/32f417-how-to-use-swv-itm-swo-debug-output-without-cube-ide-or/td-p/843611/page/2

https://www.eevblog.com/forum/microcontrollers/stlink-debugger-configures-some-32f4-target-registers-e-g-swo-trace-macrocell/msg6056111/#msg6056111

Basically, if you want to do Statistical Profiling, you have to enable PC Sampling and then Cube leaks memory at around 100kbytes/sec. Eventually it crashes, obviously. The SWV ITM debug mode does not need PC Sampling and is thus a lot more reliable, but only in the OpenOCD debugger mode.

Instead of adding more stuff which nobody uses, ST should fix this program properly, starting with the famous "random file opening" issue which about 100 people have complained about.

Another way to crash Cube is to use a STLINK debugger with some unspecified fault on the USB side. Cube just leaks lots of memory and bombs. Poor error detection...

[Ozone]

> Basically, if you want to do Statistical Profiling, you have to enable PC Sampling and then Cube leaks memory at around 100kbytes/sec. Eventually it crashes, obviously.

You might have a look at Segger Ozone, a freestanding debugger.
AFAIK it's free for non-commercial use.

PS: and not related to my moniker here ... ;)

[AScha.3]

>Cube IDE poor reliability when debugging

You forgot to tell: 

- IDE version

- PC system 

- st-link type/version

- target cpu

btw 

I use actual MxLinux, IDE 1.18.1 , debug openOCD and GDBmultiarch ,

st-link V2 ("stick", mod. for SWO ) , or V3 mods and miniE ;

targets: F103, F303 , F411, H563, H7A3, H743 , H7S3 .

About "poor reliability when debugging" i admit: (seldom) there is a problem, sometimes debug not starting, so i just click on debug again..then it starts usually, as it should. And "live expressions" i dont use/recommend to use, strange behaviour, sometimes working fine, most times not. But anyway no important feature for me, so no drama.

[PHolt.1]

Various versions over past 5 years.
Win7-64, win10, 24GB, i7
STLINK V3 ISOL, V3 MINIE
32F407/417

I don't use live expressions. Normally Cube works for the usual cycle of download, breakpoints etc.

The fun starts if you want to use SWV / SWO stuff.

Yes everybody says Seggers are good but a) they are 1k+ and b) I much prefer to Cube-integrated system. I played with the cheap Edu one and saw no difference at all versus STLINK V3.

Didn't know the STLINK V2 does SWO. I used the V2 ISOL for a long time; works ok.

[AScha.3]

-- still no info:

- IDE version

you use.

+

>Didn't know the STLINK V2 does SWO

see manual:

on cheap V2 "clones" you have to solder it yourself, to get swv :

[Ozone]

Cube IDE isn't really aimed at professional customers who have to earn a profit with their products.
Thus fixing such bugs, even annoying ones', isn't a priority.
Adding new features and supporting more silicon in a free tool attracts more students and hobbyists who might later promote further silicon sales.

I had worked with Keil uVision, IAR-WB and other commercial toolchains on the job. They usually just work.
You get what you pay for.

[PHolt.1]

That is quite a statement :)

"This product is for hobbyists so it is OK if it does weird things".

Actually No. It is Eclipse based and lots of paid tools are same.

Cube does work OK for normal CPU flashing and breakpoint debugging. It is some extra stuff like above which is unreliable.

As I posted elsewhere here, I now have a working setup but it took a huge amount (many hours) of trial and error, OpenOCD mode with STLINK V3, the discovery that the V3 MINIE is actually hopeless for much beyond the most basic SWV ITM debugs, etc.

[Ozone]

> "... so it is OK if it does weird things".

Those are not my words - but, as I suspect, very likely ST's assessment.

> Actually No. It is Eclipse based and lots of paid tools are same.
Cube does work OK for normal CPU flashing and breakpoint debugging. It is some extra stuff like above which is unreliable.

Eclipse is the same for every Eclipse-based IDE (assuming the same version).
It is the integration that makes the difference.
And which suffers from the same problems with ST as Cube/HAL packages - new ones' have precedence over fixing bugs. Even annoying one's.

By the way, my company uses an Eclipse toolchain which comes with an equally bug-ridden IDE integration, at a rather stiff price. But we almost exclusively use the toolchain itself with make files from the console.

[PHolt.1]

AFAICT these tools are just problematic around the edges - regardless of whether they are free or cost $1000+.

And this is tacitly accepted by all, so ST have no reason to to fix anything.

I will try to borrow one of the expensive Segger debuggers to see if they work any better.

[Andrew Neil]

---

@PHolt.1 wrote:

I will try to borrow one of the expensive Segger debuggers to see if they work any better.

---

Segger have a tool to convert on-board ST-Links to J-Links:

https://www.segger.com/products/debug-probes/j-link/models/other-j-links/st-link-on-board/

That would allow you to try out Ozone before splashing out on a J-Link ...