Is ST Cube IDE a piece of buggy crap?

[paulca]

You can disable the whole feature.  The issue then becomes, it won't open or switch to any files automatically on break points.  You can still click the stack trace though.

[peter-h]

Where is this config?

Not switching to the file where the breakpoint was is useless, however.

[peter-h]

I finally found the config for disabling the automatic breakpoint in main().

Until a few versions ago it used to be under Debugger but then they moved it. In the new location, it was however grayed-out. But somebody found how to do it:

https://stackoverflow.com/questions/66566866/stm32cubeide-run-configurations-how-to-disable-set-breakpoint-at-main-if-gra

If you go into the config via this other route (which is totally not obvious) the option is not grayed-out.

Project / Debug As / Debug Configurations / Startup



And it works. F11 takes me straight to a running project. No more breakpoint at main().

[peter-h]

One thing I find, which may or may not be specific to Cube and/or STLINK debuggers, is this:

If something happens on the PC with USB, say you plug in a USB drive and the PC does some sort of re-enumeration, it can mess up the debugger (via its USB cable) which then crashes or just reboots the target.

And Windoze sometimes does "funny USB stuff" on its own, without you doing anything.

A bit hard to deal with if you want to run debug mode for hours...

If you just want to run code, best to exit Cube and that seems to prevent the debugger getting screwed up. Better still unplug the USB cable. Unplugging the debugger from the target may be harder, depending on the connection.

And this is with STLINK V3 ISOL i.e. isolated, so it doesn't appear to be just a "spike", but who knows?

[rsjsouza]

If something happens on the PC with USB, say you plug in a USB drive and the PC does some sort of re-enumeration, it can mess up the debugger (via its USB cable) which then crashes or just reboots the target.

I don't have much experience with ST, but I haven't seen this happen with other manufacturers (TI, FSC, etc.)

And Windoze sometimes does "funny USB stuff" on its own, without you doing anything.

A bit hard to deal with if you want to run debug mode for hours...

That can happen with anyone, especially if Windows is set to use weird power modes that, among other things, may put the USB subsystem to sleep.

[peter-h]

It could indeed be some low power mode switch on USB (not supposed on a desktop PC but one never knows) but should a debugger affect the running target?

Obviously I can see Cube IDE shutting down a Debug mode (thus losing the ability to set a breakpoint etc) if the USB port goes to sleep, but the target should keep running. So I am suspecting something to do with the Reset signal from the debugger.

[abyrvalg]

Disconnect it (RESET) then? It is not so important if your firmware doesn’t remap SWD pins. The core still can be reset by a write to AIRCR reg and usually there is a setting which kind of reset to use.

[peter-h]

You mean here?



From the Cube IDE manual https://www.st.com/resource/en/user_manual/um2609-stm32cubeide-user-guide-stmicroelectronics.pdf



Two of those options look like a register write...

[rsjsouza]

It could indeed be some low power mode switch on USB (not supposed on a desktop PC but one never knows) but should a debugger affect the running target?

Obviously I can see Cube IDE shutting down a Debug mode (thus losing the ability to set a breakpoint etc) if the USB port goes to sleep, but the target should keep running. So I am suspecting something to do with the Reset signal from the debugger.

Once the Debug Probe is shut down from its USB port, there is a chance it will be inadequately powered from the target via a JTAG/SWD line or even via a secondary UART channel (if the Probe is furnished with such capability). This can cause inadvertent/spurious signaling that can disrupt the target (even your hypothesis of inadvertently resetting the target board).

[Ario]

Just a comment -->

I use to use cube IDE along with  cube mx at my previous work. And noticed that these tools are sometimes especially buggy when updates have been done on both cube IDE AND OR separately by eclipse itself.(STMIDE is basically a "Distro" or flavor of eclipse). So according to me the biggest issue is that there are two different independent developer companies both doing updates that might effect each other.

Realized that it is best to avoid all updates as far as possible, and only updating when it is necessary for the current project. Also in the past I have had problems when I update cube mx but not cube IDE or rather vice versa.

Is anyone else think the same way?

[DavidAlfa]

Yes, updating is usually a mess.
I always delete the entire cubeIDE installation directory, including the hidden metadata folder in the workspace, then install the new version.
I have to reinstalll the plugins (Egit, etc) but nothing too serious, then import the existing projects and done.

[peter-h]

Yes; my procedure, which I have tested many times, is

- do a clean install of Cube (having also deleted the previous version's c:\st directory tree)
- copy over the project to say c:\projectname
- import project into Cube using the project import into workspace function
- Clean project
- Index project

Most Cube settings reside in the c:\projectname in some .project .cproject .xml etc files so this copies them over. Not all; stuff like spell checker you have to set up in Cube itself.

Never used MX but seeing what it does I never want to

[dkonigs]

Meanwhile, for the past couple of years, I just install updates normally via the usual mechanisms, and it kinda just works fine.  Its been a long time since anything broke my workspace.
I don't have 32 pages of rants and complaints, and the only major annoyance I have is that part where the debugger randomly opens a file.

Am I doing something wrong?

(Of course I probably avoid a lot of the minor annoyances by using CubeMX to generate the initial project code "out of band" and don't even have a .ioc file in my Eclipse/CubeIDE project for it to try to do anything with.)

[DavidAlfa]

Welcome to the club!
Currently I like it pretty much, it was a lot worse 1-2 years ago, the computer felt like was 15 years older, but it seems they finally fixed most of the issues after v1.7.0 or so.
The random file opening issue has been there for ages, nobody know how to *** stop it  .

[paulca]

As we discussed elsewhere, your projects should be independent of any and all IDEs.

In most places checking in IDE files is considered taboo.  IDE settings, paths, local build envs etc. etc.  They are up to the individual dev.

Most problems come from customisations.  The more you fiddle things away from default the harder it will be on you and... anyone else who uses your project, especially if you didn't follow the first two points.

If it is done right, then I can open your project in the IDE I choose and work on it along side you.  Everyone should be free to check the project out and get it building in their IDE of choice.

IDEs however have other ideas.  They would like to take ownsership of your project, put it's preference files, settings and caches in it.  You just intervene, most don't put up much of a fight.

[NorthGuy]

As we discussed elsewhere, your projects should be independent of any and all IDEs.

That's right. There were always problems with various IDEs. I use a text editor instead. Never had a problem.

[westfw]

it was a lot worse 1-2 years ago

(Back when this thread started.)
I think we have to have a major debate on whether it's a good thing that the ST-provided "stuff" has undergone so much improvement (even two years ago, people were claiming that it had improved a lot since versions PRIOR to that), or whether it's terrifying that there is so much "churn" in what ought to be simple and stable code.  :-(

[abyrvalg]

You mean here?

Two of those options look like a register write...

Yes, that’s it. Disconnect the hardware RESET signal and select either a “Software” or “Core” reset there.

[peter-h]

Yes indeed.

The random file opening bug has been well characterised (Cube opens whichever file contained code executing when the CPU is reset/restarted) but it needs somebody familiar with the ST SWD debugger implementation in Cube. Other manufacturers' Eclipse + debugger implementations reportedly do not have this problem. That is where the problem is. For some reason ST are unable or unwilling to do this, and with c:\st containing 18442 files (the actual value on my PC!) and a lot of them being java, probably nobody else wants to get stuck into it. Especially as ST are not really responsive to bug reports (they make all the "right noises" on the ST forum) and then whatever fix is developed will be overwritten by the next Cube update.

The "contact lost with the debugger" problem has always been there, and makes it hard or impossible to run a program in Debug mode for more than a few hours. It is just not a robust implementation. I suspect the problem is in the USB code, because I can have the same target running in Debug for minutes or (rarely) days before it loses contact, so it isn't a problem with my SWD wiring. And USB is unbelieveably complex...

I am on v 1.12 which apart from the above works satisfactorily.

Disconnect the hardware RESET signal and select either a “Software” or “Core” reset there.

Thanks. I will try that. So the debugger must somehow force the CPU to execute that code - like discussed previously - without modifying the FLASH and, presumably without placing the code in RAM.

[paulca]

I might be mistaken, but my understanding of the SWD is it connects via the ARM debug subsystem and provides the PC direct control over the main clocks.  No "STEP" on computer, no run.  There should also be a heartbeating mechanism which allows "is connected" to be determined.

I suspect that "keep alive" protocol is being failed by Windows, WinUSB, Cube or the STM drivers.... or any/all of the above.

When one launches GDB on a target you have the option of connecting in stopped state.  ie.  It will stop on the first instruction of the binary.  Alternatively you can have it stop on a symbol, having given is a symbol rich binary or a symbol file.

So the process is to launch GDB to connect via the SWD driver to the ARM core.  STM have claimed they cannot, for whatever, stop GDB emitting all symbols it's passes while they are waiting on the entry point of main().

To be honest, that might very well be the problem.  "main()" is NOT the first instructions executed.  As we know from all the startup.s etc. it launches before main.  So they can't be firing GDB up properly, configuring it properly or using it properly.  It's not firing "Break point caught" events as it doesn't stop, so they appear to be consuming the full symbol output or something?

EDIT:
Cube does not deploy the symbol rich binary.  So one would assume they launch GDB with a symbol file which is aware of the target's memory model.   (That's remote connection based cross-compile debugging, not exactly easy).  They may be intercepting these to do some memory model translations to determine true symbol addressing.  In that case they may be unable to stop Eclipse from recieving all those same events.

I have breifly used ESP32's JTAC based Eclipse debugger and I don't recall the phantom breakpoint noise there either.

[newbrain]

I might be mistaken, but my understanding of the SWD is it connects via the ARM debug subsystem and provides the PC direct control over the main clocks.  No "STEP" on computer, no run.  There should also be a heartbeating mechanism which allows "is connected" to be determined.

It's at the same time simpler and more complicated than that.
The debug host can let the core run and wait for a breakpoint to be hit. A gdb "stepi" will just exercise the machinery described below by setting up a halted core to execute the next instruction, then stop. It can also let it run freely until a set breakpoint etc. etc.

A brief description of the debugging mechanism on Arm, literature reference will follow:
1. Debugging Arm cores is based on CoreSight DAP - Debug Access Port
2. A DAP can be accessed with either JTAG or SWD transport, it's up to the implementer to choose one or both - I'll talk about SWD as that's the most common interface used, but there's not much of a difference.
3. A DAP contains in general one DP (Debug Port) and a number of APs (Access Ports)
4. The DP provides access to the APs through a JTAG or SWD state machine, in turn the APs can read and write memory, processor registers, and debug only registers (e.g. to set clear breakpoints, allow for a single step etc.). The available APs can be detected by scanning the DP, and specific capabilities are described in ROM tables inside each AP.
5. Protocol (e.g. SWD, Serial Wire Debug) exchanges (i.e. reads or writes) between a debugger and the DAP are always initiated by the debugger. There is no spontaneous signalling from the DAP.
6. The DAP just acknowledges every read or write.
7. This means that setting a breakpoint and letting the core run (or performing a single step) must be followed by polling to know when the breakpoint has been hit.
8. All this low-level churning on the wire is hidden partly by the protocol between the debugger probe and the gdb server on the debugging host. The abstraction level can range from essentially zero (e.g. the first version of the picoprobe), to very low (e.g. CMSIS-DAP protocol), to medium (ST-Link protocol) to high (J-Link protocol).
9. the gdb server translates the debugger protocol to the gdb remote target protocol.
10. gdb manages direct user inputs (through CLI) or IDE inputs (usually through the machine friendly MI syntax) and issue the relevant remote target commands towards the the gdb server.

So, it's a complicated journey from the core to gdb command interpreter...

References:
Understanding DAP
ARM Debug Interface Architecture Specification ADIv6.0
The CMSIS-DAP protocol
The Remote Target protocol
The gdb MI protocol

Bonus:
gdb uses the remote target in a redundant and predictable way, requiring only minimum state in the gdb server:
Common debug sequences

Why I (pretend to) have an idea of all this:
- contributed legacy picoprobe implementation to pyocd
- contributed Thread-X RTOS support to pyocd
- wirtten a debug monitor for the debug impaired Teensy 4.1 - single thread works very well, not ready for prime time as FreeRTOS multi thread stepping is still a bit flaky.

[peter-h]

Bloody hell this is incredibly complicated... no wonder nobody can fix that bug.

FreeRTOS multi thread stepping

What is that? AIUI, IME, single stepping in Cube just executes the source code, one line at a time (or one asm line at a time if stepping in the asm mode) and the RTOS is frozen.

OTOH I have this setting in Cube



and there is another setting somewhere (I can't find it right now) which stops the timers also once a breakpoint has been hit. With the watchdog this is obviously essential otherwise you could never debug anything. And stopping the timers running also stops RTOS task switching (systick); if the RTOS continued to run you could also not step through any code. I must be missing something obvious

Funnily enough even though I have the above setting set to No Configuration (the screenshot shows Disable), the watchdog does not reset the target during stepping. Maybe the timers-stop setting overrides the watchdog options...

Breakpoints usually break the target (ETH or USB can withstand a few hundred ms IME) so they are a one-off debug feature; the target has to be restarted afterwards.

I never used the Enable RTOS Proxy and IIRC one needs to write some code to make that do something, like displaying RTOS tasks in "real time".

[newbrain]

Bloody hell this is incredibly complicated... no wonder nobody can fix that bug.

FreeRTOS multi thread stepping

What is that?
[...8<...]
I never used the Enable RTOS Proxy and IIRC one needs to write some code to make that do something, like displaying RTOS tasks in "real time".

Note: I do not use Eclipse based crap, I value my time and blood pressure. So I don't know whether that "RTOS Proxy" is something else entirely. From what I can read it enables stack traces on non-running tasks. I get them for free with my monitor, pyocd, and VS-Code - no instrumenting needed, and the same should be for you. Instrumenting i needed if one wants details on the stack percentage used or on the execution times of the threads.

If you are not using the RTOS awareness at all, I imagine you cannot see the names of the threads, or see easily which one are stopped and for which reason, if you not using just the proxy you are missing out on the stack trace.

It's quite helpful: you get good stack traces for each thread/task (gdb/FreeRTOS name) instead of only the one for the currently executing task, you can step a single thread - of course this means the others may run until the step is completed - and you can inspect and modify their local variables.

Note also that gdb supports two modes for multi thread debugging, one where everything stops when one thread is interrupted (e.g. BP or Ctrl-C) one where only that single thread is stopped, while the others still run (my monitor only supports stop mode now - working on it).

gdb will negotiate with the debug server using the remote target protocol to understand its capabilities, e.g. whether it supports the extra messages to gather and set thread data, and non-stop multithread mode, if not it will just use basic protocol and single thread debugging.

The problem (I mean, feature) with Teensy is that to make it as much Arduino like as possible for programming/booting all the debugging has been crippled: JTAG/SWD is completely taken over by the extra Kinetis MCU on the board, and it is not even possible to enable the Debug Monitor exception that would allow simple gbserver-like handling via serial port (TBH: I have very few gripes with Mr Teensy, his code is usually very good, a step above 99% of the Arduino libs I happened to look at).

So I had to use a SVC call to emulate breakpoints, making sure not to interfere with FreeRTOS (which luckily just use SVC-00, and only at startup), meaning that breakpoints can only be set in RAM code (and no, I did not manage to make address translation work, probably tied to the same settings that prevent the use of debug monitor and HW breakpoints).

Moreover, to implement reasonable single instruction stepping etc. I need to calculate the length of the replaced instruction, keep track of IT instructions and so forth, quite a deep dive in the Arm architecture and instruction format(s)!

Making this pseudo debug monitor FreeRTOS aware entails also some introspection in the RTOS data structures, as gdb expect to be able to unwind the stack of all the threads it finds and needs the SP and registers of each one.
Implementing the sending and receiving of the protocol messages on a dedicated UART was in fact the simplest part of the endeavor.
Everything seems to work, with the exception that gdb gets confused by some of my answers when I try a single step on a thread that's not the active one at the moment.

[peter-h]

OK; thanks.

I have RTOS data but via a different route: an RTOS task which is within the HTTP server and which displays a status page like



where the RTOS stuff is generated by interrogating FreeRTOS data structures. The FR doc supplies the code for that.

I also have a win32 app which displays the entire FR memory block, graphically, so I can see stack usage for each task. I posted this before. It is really good.

Amazing that one can step through one RTOS task while other tasks are running normally. Could be very useful because ETH or USB can run in the background. The way I use Cube, everything stops on a breakpoint - interrupts, the whole lot.

[DavidAlfa]

I think it's time to change the thread title? No only because it's missleading, but because it's more like "CubeIDE bits and odds" (Not sure how to call it in English, like small details, everyday issues, howtos...).
We've talked about almost everything about it. The IDE might not be perfect, but it's pretty good.

Some dinosaurs still argue emacs/text editor is the way to go...
But no thanks, it's like saying hand-made iron smelting in clay furnaces by sweating slaves is better than modern industrial techniques  .

- Real-time syntax checking just great, makes your life easier. I appreciate my time, with a simple text editor, you won't notice if you accidentally typed "rpintf" until compiling.
- Control+click and mouse hovering are great to have a quick glance/fly to the declaration/definition, it's incredibly useful, otherwise you hav to remember everything.
- Embedded debugging, variables, expressions, all-in-one package makes it extremely simple to setup...
- Making Makefiles by hand? Erm, no thanks, I already waste a lot of time with those heeecking registers and buggy peripherals