STM32CubeProgrammer getting buggier

[David Littell]

2.8.0 doesn't handle multiple ST-LINKs correctly. A new instance of CubeProgrammer usually makes the absolute wrong decision to use an ST-LINK already assigned to another CubeProgrammer instance.

2.8.0 seems to have become more unforgiving with issues on the target processor (being held in reset, etc.) and simply crashes.

[Houda GHABRI]

Hi @David Littell​ ,

Let me be sure that I understand the issue, a new instance always select a serial number already assigned and you need that Cubeprogrammer switch to unused one?

This is the default behavior and common to all CubeProgrammer version , user have to to select manually different Serial number :

 

Hope this helps you.

Houda

[David Littell]

Yeah, I know what it does. I'm saying what it does is stupid - there's no sane reason for a new instance of CubeProgrammer to by default select an ST-LINK that's already in use by another instance of CubeProgrammer.

[Tesla DeLorean]

There doesn't seem to be any "Dog Fooding" testing at ST, whereby actual use of the software by the development group, in a real-world sense, would allow for observation of basic bugs, user interface issues, diagnostic reporting and generally annoying behaviour, and fix them immediately.

[RRoma.4]

Hello David, I confirm your issue: unconnected processor or simply plugging in an ST-Link (2 for sure, 3 not at hand now) when you hit "connect" crash.

[Vahid Ajallooeian]

What is the reason behind having two programmers connected while working with the cubeProgrammer? I think the use case of cubeProgeammer is in the production line, no other thing.

[RRoma.4]

Hello, Cube programmer has some feature that help debugging multiprocessor systems.

Example, debugging state on one processor and start stop or reset another processor.

Why? Cube programmer simply can access debug, cube IDE instead reload code wearing flash. Start stop restart just at one button press.

This scenario 3 or more programmer active is not an isolated case.

Flash area patch on the field to change some table of specific processor across cluster... Every node can be accessed and tables changed on the fly.

This Way is not a production dedicated but a powerful debugging and/or tuning instrument.

Save state of program to flash, debugger cannot be used without erasing data so log can be dumped only using cube programmer

[David Littell]

Hi Vahid,

Consider having multiple processors on a board (or in a system). What's the easiest and fastest way to load and run images on those processors? An ST-LINK per processor and multiple instances of STM32CubeProgrammer.

[Uwe Bonnes]

This seems to be a hijack of the original thread. No good idea.

Anyway, either connect the processors a s a JTAG chain or with multi drop capable processors,use a multidrop capable debugger or do it as you proposed. However I do not know about the status of SWD multidrop on Stlink....