Is ST Cube IDE a piece of buggy crap?

[Kjelt]

v 1.10.1 has just come out. Some bug fixes to do with file corruption in MX.
What I have been finding repeatedly over the last ~2 years is that when running under debug (compilation with F11) the system always breaks at some point, generally after some hours. This is with STLINK V2 or V3 debuggers, ISOL or not ISOL. PC comms with the debugger are lost. The problem is that this also kills the target.
It isn't a problem with normal breakpoint debugging but you can't have a target running for days looking for a breakpoint to get hit, because it will crash before then.
Can anyone reproduce this?

Running for days ....... I do not think it was ever intended for these kind of extreme long periods of time.
I would suggest for these kinds of things to write a monitor thread yourself and on the event, dump the entire stack tracing and all variables with it to an external file. Serious, even with a Keil pro of €1000+ I was glad if it would run for an hour consecutively without something breaking it up.

[peter-h]

Thanks

I did have a dig around for ways of making the debug stack analysis longer. Often, on a proper crash, you see just 3 entries there and all of them are the CPU obviously executing garbage. Googling around suggests there is no way to make this longer. Your suggestion would solve that, and then one just needs a prog which identifies the stack trace addresses by reference to the symbol table, perhaps the .map file.

I also noticed 1.10.x updates the STLINK firmware.

[Sal Ammoniac]

Running for days ....... I do not think it was ever intended for these kind of extreme long periods of time.

I use Rowley CrossWorks for ARM (and Segger's licensed version: Embedded Studio) for STM32 debugging and it will run for very long periods without losing connection with the target. I have one STM32H743 board on my desk that's been running for 4-1/2 months now under CrossWorks connected to the PC with a J-Link.

[Kjelt]

So your pc does not go to sleep after an idle period? No system updates? Your pc is running 4.5 months continuously in debug mode ? Special cabling/shielding ?
Well congratulations you must have a record there.
I once had a debug session abort after a colleague switched just an ac load 4 meters away from my desk. Probably emc related.
So I still would not recommend to rely on it for such prolonged periods esp. if you are for instance hunting for memory leaks that occur once a month or so. Pretty expensive if the test aborts after three weeks and you still have no data. But if it works for you perhaps you can help TS for a robust setup.

[nctnico]

So your pc does not go to sleep after an idle period? No system updates? Your pc is running 4.5 months continuously in debug mode ? Special cabling/shielding ?
Well congratulations you must have a record there.

From my experience with JTAG I'd say that a stable debugging environment starts with having a JTAG connection which is rock solid. A piece of flat cable or (worse) flying leads won't do. An on-board JTAG connection is better but you'll also need proper grounding of the target and the PC to avoid USB related problems. Likely an ethernet based JTAG interface will be less prone to problems related to connection between the computer and the JTAG interface.

[Sal Ammoniac]

So your pc does not go to sleep after an idle period? No system updates? Your pc is running 4.5 months continuously in debug mode ? Special cabling/shielding ?
Well congratulations you must have a record there.
I once had a debug session abort after a colleague switched just an ac load 4 meters away from my desk. Probably emc related.
So I still would not recommend to rely on it for such prolonged periods esp. if you are for instance hunting for memory leaks that occur once a month or so. Pretty expensive if the test aborts after three weeks and you still have no data. But if it works for you perhaps you can help TS for a robust setup.

Hey, that's nothing! Uptime on one of my web servers:

ubuntu@qwerty:~$ uptime
 00:02:59 up 1260 days,  2:35,  1 user,  load average: 0.07, 0.02, 0.00

[Kjelt]

From my experience with JTAG

It is probably only SWD but I think of something that might explain the different experiences.
You can change the SWD frequency from a couple of kHz to what is it 4MHz ?
It probably makes a world of difference which debug frequencies were used, and this might also be the reason they have a max frequency defined.

[Kjelt]

Hey, that's nothing! Uptime on one of my web servers:

Yeah completely different topic, Topper   

[peter-h]

It is an interesting point whether dropping the SWD frequency a long way might help with all this. See here for example
https://www.eevblog.com/forum/microcontrollers/10-pin-debug-connector-and-stlink-v3-isol-not-reliable/msg3564782/#msg3564782

I noticed Cube v10 starts up the debugger differently. If it can't get comms, it drops to a slower clock: 8MHz. Previous Cube versions just bombed out.

It would be unsurprising if the debugger communicated with the target continuously during running. I just don't know and haven't bothered to scope it. If it does, then a slower SWD clock should help.

[rsjsouza]

So your pc does not go to sleep after an idle period? No system updates? Your pc is running 4.5 months continuously in debug mode ? Special cabling/shielding ?
Well congratulations you must have a record there.
I once had a debug session abort after a colleague switched just an ac load 4 meters away from my desk. Probably emc related.
So I still would not recommend to rely on it for such prolonged periods esp. if you are for instance hunting for memory leaks that occur once a month or so. Pretty expensive if the test aborts after three weeks and you still have no data. But if it works for you perhaps you can help TS for a robust setup.

Hey, that's nothing! Uptime on one of my web servers:

ubuntu@qwerty:~$ uptime
 00:02:59 up 1260 days,  2:35,  1 user,  load average: 0.07, 0.02, 0.00

Indeed. Run the IDE on a decent OS and you will get great uptime as well. I've had TI's Code Composer Studio running debug sessions and automated tests on a Linux box continuously for days and weeks with no glitches. And it was not a very powerful one, just a midrange machine.

Windows as a development environment is not the most suitable for the task, especially with the newer releases 10/11 that constantly harass you with updates. Unfortunately this is the OS that we need to deal most of the time due to other necessities, though.

[peter-h]

Of course, a unix machine can have an uptime of years. I "run" several CENTOS 7/8 servers, Apache/NGINX, which haven't been touched for probably 5 years.

But that's hardly applicable to

- Cube (hacked in Java!!!)
- USB attached debugger (USB goes to sleep periodically, under Windoze)
- connection to the target (sometimes needs exit from Cube, sometimes Windows Task Manager and kill the ST processes)
- target power supply
- etc

On win7-64 (machines I built myself) I see uptime of several months, with a reboot necessary only in unusual situations e.g. some rogue USB device trashed something. And I run all sorts on these machines; VMWARE VMs, many apps...

[nctnico]

From my experience with JTAG

It is probably only SWD but I think of something that might explain the different experiences.
You can change the SWD frequency from a couple of kHz to what is it 4MHz ?
It probably makes a world of difference which debug frequencies were used, and this might also be the reason they have a max frequency defined.

AFAIK both JTAG and SWD use synchronous (clocked) data transfer. A single spike on the clock line screws everything up no matter what the working frequency is.

[Sal Ammoniac]

So your pc does not go to sleep after an idle period? No system updates? Your pc is running 4.5 months continuously in debug mode ? Special cabling/shielding ?
Well congratulations you must have a record there.
I once had a debug session abort after a colleague switched just an ac load 4 meters away from my desk. Probably emc related.
So I still would not recommend to rely on it for such prolonged periods esp. if you are for instance hunting for memory leaks that occur once a month or so. Pretty expensive if the test aborts after three weeks and you still have no data. But if it works for you perhaps you can help TS for a robust setup.

Hey, that's nothing! Uptime on one of my web servers:

ubuntu@qwerty:~$ uptime
 00:02:59 up 1260 days,  2:35,  1 user,  load average: 0.07, 0.02, 0.00

Indeed. Run the IDE on a decent OS and you will get great uptime as well. I've had TI's Code Composer Studio running debug sessions and automated tests on a Linux box continuously for days and weeks with no glitches. And it was not a very powerful one, just a midrange machine.

Windows as a development environment is not the most suitable for the task, especially with the newer releases 10/11 that constantly harass you with updates. Unfortunately this is the OS that we need to deal most of the time due to other necessities, though.

The 4-1/2 months I mentioned was on a Windows machine. The application running on the STM32 board was continuously sending serial data to the PC over a virtual serial port implemented by the J-Link.

[NorthGuy]

AFAIK both JTAG and SWD use synchronous (clocked) data transfer. A single spike on the clock line screws everything up no matter what the working frequency is.

JTAG has the TMS line which can be used to walk the controller to a known state. So, clock spikes are not the end of the world.

[ataradov]

And SWD has a parity bit and a line reset, so synchronization recovery is possible as long as the software is prepared to detect an error.

[rsjsouza]

AFAIK both JTAG and SWD use synchronous (clocked) data transfer. A single spike on the clock line screws everything up no matter what the working frequency is.

JTAG has the TMS line which can be used to walk the controller to a known state. So, clock spikes are not the end of the world.

Indeed. Clock recovery is not an uncommon feature of decent JTAG probes. One of the major issues I have seen are PC power down states that can trigger issues with external peripherals.

[nctnico]

AFAIK both JTAG and SWD use synchronous (clocked) data transfer. A single spike on the clock line screws everything up no matter what the working frequency is.

JTAG has the TMS line which can be used to walk the controller to a known state. So, clock spikes are not the end of the world.

But how do you know whether data got clocked in correctly? It is not about recovering the JTAG controller to a know state, but being sure that what you are transmitting is correct AND then being able to recover. The latter isn't trivial (to say the least) when you are feeding a CPU instructions to access the memory. An extra (or missing) clock means you are suddenly clocking in a different instruction or address.

[NorthGuy]

AFAIK both JTAG and SWD use synchronous (clocked) data transfer. A single spike on the clock line screws everything up no matter what the working frequency is.

JTAG has the TMS line which can be used to walk the controller to a known state. So, clock spikes are not the end of the world.

But how do you know whether data got clocked in correctly? It is not about recovering the JTAG controller to a know state, but being sure that what you are transmitting is correct AND then being able to recover. The latter isn't trivial (to say the least) when you are feeding a CPU instructions to access the memory. An extra (or missing) clock means you are suddenly clocking in a different instruction or address.

No. You recover the JTAG controller state before the transfer. There may be errors during transfer (clock or data error), but the errors do not linger after the transfer because for the next transfer you start by resetting the controller to a known state.

Are you trying to say that clocked transfers are inherently error prone while asynchronous transfers are error free?

[nctnico]

Once you have clocked in the wrong address or instruction into a CPU, recovery will be hard to do. Again, the JTAG interface is a paper thin access layer on top of a way more complex debugging interface. JTAG is nothing more than 2 simple shift registers which have next to no functionality in them. All the actual intelligence & complexity that is hard to recover errors from sits below JTAG. In the past I have done some work on MIPS support for OpenOCD and that doesn't have any way for recovery once things go wrong. Where it comes to MIPS you are basically feeding instructions into the CPU one by one into some kind of a virtual memory area.

Asynchronous interfaces have better resilience against spikes (look at a UART for example) but that doesn't mean it is suitable for remote debugging perse.

Where it comes to rock solid remote debugging over JTAG or SWD it comes down to getting the signal integrity right before anything else.

[NorthGuy]

JTAG is nothing more than 2 simple shift registers which have next to no functionality in them.

It's much more than that. JTAG is a formal state machine which transitions between states as commanded by the TMS line. It lets you reset the controller, feed commands and exchange data. The implementation will usually implement many shift registers. For example, in FPGA, some of the shift registers are implemented by hardware and can be used to configure FPGA, others may be implemented in fabric to do whatever you want - program onboard flash, get data from FPGA etc. JTAG provides mechanisms to coordinate the access to all these shift registers across multiple devices connected in a chain.

All the actual intelligence & complexity that is hard to recover errors from sits below JTAG.

Which has nothing to do with JTAG being a synchronous interface.

Where it comes to MIPS you are basically feeding instructions into the CPU one by one into some kind of a virtual memory area.

You missed all the fun with MIPS. Their debugger maps a memory area to the JTAG probe. Any reads/writes to this memory area are re-directed to the probe and the probe is responsible for supplying/consuming the data. You certainly can execute commands in this area and this way you'll have to furnish all the instructions through JTAG. This is rather dumb way of doing things though because the probe is slow and (as you have already noticed) doesn't have good recovery mechanisms.

Decent MIPS debuggers implant a resident program into the chip memory and execute from there. The JTAG-mapped area doesn't execute commands at all. Instead this area is used to exchange data with JTAG probe. This is much faster, and provides opportunity to add reliability checks if you wish.

This certainly has nothing to do with clocked protocols. The low reliability you've got with MIPS is simply a consequence of a bad design.

Where it comes to rock solid remote debugging over JTAG or SWD it comes down to getting the signal integrity right before anything else.

Sure. And with good enough SI, clocked interfaces are extremely reliable - just look at all these servers running DDR memory at very high loads and crazy speeds for years without encountering a single error.

[peter-h]

Cube v10 crashes a lot more often, and needs Windows Task Manager to shut it down.

[peter-h]

Someone may find this amusing.

I have a 32F417VGT6 project. The RAM goes 0x20000000 to 0x2001ffff. 1MB FLASH. A couple of boards were built with a 32F437VGT7 which is almost 100% identical but has an extra 64k RAM, so that goes 0x20000000 to 0x2002ffff. Actually I think the 32F437VGT7 has 2MB FLASH while a 32F437VGT6 would be 1MB but it is very hard to establish the part numbers (nothing in the data sheet).

It was not realised two of the boards were the 437 and indeed they run the same. In fact, speaking to one expert, the only known other difference in terms of backwards compatibility at the binary level is something around the way Vbat is measured with one of the internal ADCs.

But Cube does some funny stuff. With the 417, viewing memory (target stopped, obviously) around the top of RAM shows this



which is correct; the real physical end of memory is 0x2001ffff. I have an 8k stack at the top of memory, hence the values seen below 0x20020000. But on the 437, whose RAM continues past this, I see this data after 0x2001ffff



and I have no idea where this comes from. A watchpoint in there is never triggered, and no code of mine should be using that extra 64k. I recognise the data; it also appears lower down (it is stuff from MbedTLS) so this is a kind of mirroring thing. If I edit some of those values (say at 0x20020050) to say 0 and restart the system, they stay at zero until the very last instruction of the startupxxxx.s file and then as soon as I step (asm instruction step mode) into main.c those locations change to the values shown above. No interrupts, DMA, etc is running at this point.

I reckon Cube is just imagining data there because the CPU ID which it gets via the debugger is not the CPU type which has been configured in it.

It is possible for data in that memory to persist for ages since nothing is accessing it, but equally nothing should be writing in there.

[newbrain]

(nothing in the data sheet)

What is missing in the DS?

Chapter 8 gives you the ordering info, with the different codes for various packagings and flash size, table 2 clearly shows that RAM size is the same across the 437 family.

https://www.st.com/resource/en/datasheet/stm32f437vg.pdf

A 2 MB part would be VI, not VG, 6 and 7 indicate the temperature range.

[peter-h]

OK; I could not find the 6 v 7 meaning. The 437 can have 1MB or 2MB FLASH. I guess mine must be 1MB.

Anyway, that RAM display is curious. I should probably write some code and try reading the RAM with some asm or C. But if the data is really there (I am sure it isn't) how did it get there? That would be a massive bug.

[ataradov]

Actually I think the 32F437VGT7 has 2MB FLASH while a 32F437VGT6 would be 1MB but it is very hard to establish the part numbers (nothing in the data sheet)

How can you miss this very basic info? Section 8 "Part numbering" of the DS could not be more clear.

Flash memory size
G = 1024 Kbytes of Flash memory
I = 2048 Kbytes of Flash memory

32F437VGT7 is (V = 100 pins) (G = 1024 Kbytes) (T = LQFP) (7 = Industrial temperature range, –40 to 105 °C.)

2MB version would be 32F437VIT7