STM32CubeIDE 1.19.0 released

[Semer CHERNI]

We are pleased to announce that the release 1.19.0 of STM32CubeIDE is available.

What is new in 1.19.0:

• Microcontroller, microprocessor, and board lists aligned with STM32CubeMX v6.15.0:
• Added the support for STM32MP21xx microprocessors to the STM32MP2 series and extended the support for boards based on the STM32MP2 microprocessors
• Added the support for STM32WL30xx and STM32WL31xx microcontrollers to the STM32WL3x line
• Added automatic external memory loader prefilling in debug configuration for boards based on the STM32N6 series
• Added the support for OpenSTLinux 6.1.0 through the update site mechanism
• Added the support for STM32MP2x-M33-TD projects generated from STM32CubeMX standalone
• Added the Cortex®-A35 support in the SFRs view
• Added the capability to install OpenSTLinux through the update site mechanism on empty projects for STM32MP1 and STM32MP2 devices
• Added the support for TF‑M projects debugging for STM32MP2x-M33-TD
• Added the new view Flash memories programming allowing the programming of a TSV file for STM32MP1 and STM32MP2 devices in single or dual storage
• Added the support for new reset strategies when debugging with SEGGER J-Link
• Added incremental programming as an experimental feature for a defined set of devices:
• Internal flash memory programming is tested on the following microcontrollers:
  STM32C03xxx, STM32C05xxx, STM32C09xxx, STM32F101/F102/F103, STM32F37xxx,
  STM32F411xC/E, STM32F72xxx, STM32F73xxx, STM32F76xxx, STM32F77xxx, STM32G03xxx,
  STM32G04xxx, STM32G0B0xx/B1xx/C1xx, STM32G491xx, STM32H50xxx, STM32H523/533,
  STM32H562, STM32H563/573, STM32H723/STM32H733, STM32H725/STM32H735, STM32H730
  Value line, STM32H7R3/7S3, STM32H7R7/7S7, STM32L05xxx/L06xxx/L010xx, STM32L4P5/Q5,
  STM32L4x1, /STM32L475xx/STM32L476xx/STM32L486xx, STM32L5, STM32U0, STM32U3,
  STM32U535/545, STM32U575/585, STM32U595/5A5, STM32U599/5A9, STM32WB35xx/5xxx,
  STM32WBA52, STM32WBA54/55, STM32WBA62, STM32WBA63, STM32WBA64/65, and
  STM32WL
• External flash memory programming is tested on the following boards:
  STM32H735G-DK, STM32H7S78-DK, STM32H573I-DK and STM32U575I-EV

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:

• Under this link
• Or update your current installation of STM32CubeIDE using: Help > Check for updates (The intool update does not allow updating the drivers and STLINK server tool. Full installation is required for this to be done).

[sum1]

Hello, @Semer CHERNI 

but the code is not generated in STM32CubeIDE 1.19.0.

[Pavel A.]

> Added incremental programming as an experimental feature

Could you explain this feature please?

[CTapp.1]

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.

[Alex2670]

Description Resource Path Location Type
Project XXX has no explicit encoding set

Ctrl+1 working, but the project is not generated

[Pavel A.]

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).

[CTapp.1]

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 { ... }

[Pavel A.]

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 ?!

[stm32mp1--Player]

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.