Version 3.0 is not working properly in my project. After upgrading, a project that previously compiled, uploaded and communicated normally started having serial-port related problems.
The main issue is the serial/USB port. After flashing or resetting the board, the serial port may disappear or fail to become available again. The IDE then fails to open the expected COM port, producing errors such as:
Error: cannot open port \\.\COMx: The system cannot find the file specified.
In some cases, subsequent read/write attempts also fail or time out because the serial device is no longer available.
The important point is that this is reproducible with version 3.0, while downgrading to the previous core version restores normal serial-port operation on the same hardware, USB connection and project.
This strongly suggests a regression involving USB CDC / Serial initialization, re-enumeration, reset handling, or the startup sequence introduced in version 3.0.
Besides fixing this regression, I think a few low-level improvements would be very useful for advanced STM32 projects:
-
Official API to enter the STM32 system bootloader
Something like jumpToSystemBootloader() or rebootToSystemBootloader() would be extremely useful. The core could safely handle SysTick shutdown, pending interrupts, NVIC state, peripheral/HAL deinitialization, vector-table configuration, MSP restoration and the jump to the correct system-memory bootloader address for each supported STM32 family.
-
Improved external interrupt API
Better control over EXTI interrupts would be useful, including explicit priority configuration, safer attach/detach/reconfiguration and proper clearing of pending interrupt flags.
-
Consistent interrupt priority control
A simple API for configuring EXTI interrupt priority, similar to what is already possible with timers, would be valuable for real-time applications.
-
Safer interrupt shutdown/deinitialization
A core helper for stopping SysTick, disabling NVIC IRQs, clearing pending interrupts and deinitializing peripherals before a bootloader jump or firmware hand-off would reduce duplicated and error-prone application code.
-
More robust USB/Serial reset handling
USB CDC should reliably disconnect and re-enumerate after reset, firmware upload or bootloader transitions. The core should also avoid leaving the host with a stale COM port while the device fails to enumerate again.
-
Better backward-compatibility testing
Regression tests using existing STM32 Arduino projects, especially USB CDC/Serial, attachInterrupt(), timers and bootloader-related use cases, would help catch this kind of issue before releases.
-
Clearer migration diagnostics
When an old API or configuration is no longer supported, a clear compile-time diagnostic would be preferable to failures during linking or unexpected runtime behavior.
For now I am downgrading to the previous version because it works correctly and the serial port remains stable with exactly the same project and hardware.
Version 3.0 is not working properly in my project. After upgrading, a project that previously compiled, uploaded and communicated normally started having serial-port related problems.
The main issue is the serial/USB port. After flashing or resetting the board, the serial port may disappear or fail to become available again. The IDE then fails to open the expected COM port, producing errors such as:
Error: cannot open port \\.\COMx: The system cannot find the file specified.In some cases, subsequent read/write attempts also fail or time out because the serial device is no longer available.
The important point is that this is reproducible with version 3.0, while downgrading to the previous core version restores normal serial-port operation on the same hardware, USB connection and project.
This strongly suggests a regression involving USB CDC / Serial initialization, re-enumeration, reset handling, or the startup sequence introduced in version 3.0.
Besides fixing this regression, I think a few low-level improvements would be very useful for advanced STM32 projects:
Official API to enter the STM32 system bootloader
Something like
jumpToSystemBootloader()orrebootToSystemBootloader()would be extremely useful. The core could safely handle SysTick shutdown, pending interrupts, NVIC state, peripheral/HAL deinitialization, vector-table configuration, MSP restoration and the jump to the correct system-memory bootloader address for each supported STM32 family.Improved external interrupt API
Better control over EXTI interrupts would be useful, including explicit priority configuration, safer attach/detach/reconfiguration and proper clearing of pending interrupt flags.
Consistent interrupt priority control
A simple API for configuring EXTI interrupt priority, similar to what is already possible with timers, would be valuable for real-time applications.
Safer interrupt shutdown/deinitialization
A core helper for stopping SysTick, disabling NVIC IRQs, clearing pending interrupts and deinitializing peripherals before a bootloader jump or firmware hand-off would reduce duplicated and error-prone application code.
More robust USB/Serial reset handling
USB CDC should reliably disconnect and re-enumerate after reset, firmware upload or bootloader transitions. The core should also avoid leaving the host with a stale COM port while the device fails to enumerate again.
Better backward-compatibility testing
Regression tests using existing STM32 Arduino projects, especially USB CDC/Serial,
attachInterrupt(), timers and bootloader-related use cases, would help catch this kind of issue before releases.Clearer migration diagnostics
When an old API or configuration is no longer supported, a clear compile-time diagnostic would be preferable to failures during linking or unexpected runtime behavior.
For now I am downgrading to the previous version because it works correctly and the serial port remains stable with exactly the same project and hardware.