2025-07-07 2:33 AM - edited 2025-07-07 10:19 AM
We are pleased to announce that the release 1.19.0 of STM32CubeIDE is available.
What is new in 1.19.0:
Main fixed issues in 1.19.0:
Refer to the STM32 microcontroller wiki at:
https://wiki.st.com/stm32mcu/wiki/STM32CubeIDE:STM32CubeIDE_errata_1.19.x
Known problems and limitations in 1.19.0:
Refer to the STM32 microcontroller wiki at:
https://wiki.st.com/stm32mcu/wiki/STM32CubeIDE:STM32CubeIDE_errata_1.19.x
How to get STM32CubeIDE 1.19.0:
To give better visibility on the answered topics, please click on Accept as Solution on the reply which solved your issue or answered your question.
2025-07-07 11:09 PM
2025-07-08 2:07 AM
> Added incremental programming as an experimental feature
Could you explain this feature please?
2025-07-09 4:11 AM - edited 2025-07-09 4:11 AM
The limitations include:
171852 | The implemented toolchain is allocating to an enum type only as many bytes as it needs for the declared range of possible values. |
Do you have any more information on this, such as a link to a forum post?
This may well be the result of a valid compiler optimisation and not an issue.
2025-07-09 8:15 PM - edited 2025-07-09 10:53 PM
Description Resource Path Location Type
Project XXX has no explicit encoding set
Ctrl+1 working, but the project is not generated
2025-07-09 10:48 PM
Try to build this program to see what is the size of enum by default:
typedef enum {
foo = 1,
moo,
goo,
} E;
int main() {
E x = goo;
return (int)sizeof(E);
}
Some GNU compilers by default allocate enum variables as ints. If you specify explicit option -fshort-enums or -fno-short-enums the result will differ. The question is what of these should be the default (when none options are specified).
2025-07-10 12:39 AM
Thanks, so the issue is really saying that the default behaviour would be to constrain the implementation-defined behaviour beyond what the C Standard does (i.e. either "always use smaller types when the enum fits" or "never use smaller types")?
The use of -fshort-enums may not be a good default though, as it can cause problems as it results in code that is not ABI compatible with code that doesn't use it (so watch out when linking with code built outside of the project, and don't use it per-file).
Another reason it will be good to get the GCC version up to one that supports C23, as enum base types will then be supported in a portable way:
enum E : uint8_t { ... }
2025-07-10 3:49 AM
Here you can get a toolchain that has GCC 14.3 with C23 (-std:c23).
It can compile enum: uint8_t ... but does not impement _BitInt ?!
2025-07-17 3:13 AM
hello,
regarding Segger new reset strategies, do you have any other document or info to dive more how this new strategies are implemented.
In our case we are using a custom board with a stm32mp153c and reset strategy in production mode is more complex because of binary load using remoteproc from linux side.
Are this new segger strategies adapted to stm32mp1xx ?
thanks.