stm32lib: Update STM32WB from v1.10.0 to v1.23.0. #27
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Signed-off-by: Damien George <damien@micropython.org>
From https://github.com/STMicroelectronics/STM32CubeG0.git tag v1.5.1 Signed-off-by: Damien George <damien@micropython.org>
Signed-off-by: Damien George <damien@micropython.org>
Signed-off-by: Damien George <damien@micropython.org>
From https://github.com/STMicroelectronics/STM32CubeH7.git tag v1.11.0 Signed-off-by: Damien George <damien@micropython.org>
From https://github.com/STMicroelectronics/STM32CubeH5.git tag v1.0.0 Signed-off-by: Damien George <damien@micropython.org>
Signed-off-by: Damien George <damien@micropython.org>
From https://github.com/STMicroelectronics/STM32CubeN6.git tag v1.1.0. Signed-off-by: Damien George <damien@micropython.org>
Signed-off-by: Damien George <damien@micropython.org>
The definition of NULL is the only reason stdio.h is needed, and including this standard header clashes with a CC3000 driver's definitions because the latter wants to redefine built-in macros. The patch here is the simplest way to deal with this but the proper fix is really to modify the CC3000 driver.
Instead of calling DMA_Init to set up everything it's possible sometimes to just call DMA_CalcBaseAndBitshift, so make the latter public.
Instead of calling DMA_Init to set up everything it's possible sometimes to just call DMA_CalcBaseAndBitshift, so make the latter public.
Previous to this patch the DMA was set-up and then the I2C address sent. If the I2C address sending failed (eg no I2C device on the bus) then the DMA was left in an inconsistent state. This patch moves the DMA setup to after a successful sending of the I2C address(es).
64-bit integer division brings a dependency on library functions. It is avoided here by dividing fck and baud by a common divisior. The error is the better (1/(2*0x300)) as with 64 bit division (1/(0x300)). This patch is originally from the MicroPython repository and due to Tobias Badertscher <python@baerospace.ch>.
The existing HAL code had two issues: - It used < instead of <= to compare INEPTFSAV with len32b, which meant that data would not be written to the FIFO if there was exactly enough room for the packet (it would require enough room plus one additional FIFO slot). So for IN endpoints that had a FIFO size the same as the maximum packet size, packets of maximum size could never be written. - If the write loop went around again it would use the old len32b to check if there was enough space, thereby missing some opportunities to write packets that were smaller than the previous len32b. This patch fixes these two issues.
The existing HAL code had two issues: - It used < instead of <= to compare INEPTFSAV with len32b, which meant that data would not be written to the FIFO if there was exactly enough room for the packet (it would require enough room plus one additional FIFO slot). So for IN endpoints that had a FIFO size the same as the maximum packet size, packets of maximum size could never be written. - If the write loop went around again it would use the old len32b to check if there was enough space, thereby missing some opportunities to write packets that were smaller than the previous len32b. This patch fixes these two issues.
The existing HAL code had one issue: - If the write loop went around again it would use the old len32b to check if there was enough space, thereby missing some opportunities to write packets that were smaller than the previous len32b. This patch fixes this issue.
RCC_CSR_BORRSTF is defined in the STM32F413 Reference Manual but missing from this header file, so add it in.
In the code CAPACITY is compared against number of logical blocks, not number of bytes, so should be expressed as 2GB in 512 blocks. This is how it's done in the F4 code.
UART9 and UART10 are on APB2, like UART1 and UART6. Fixes problem with wrong baud rate when APB1 and APB2 run at different clock rates.
Data loss can occur when using DMA Rx + hardware flow control. Consider the following situation where a device is receiving UART data that consists of one byte that gives the size of the data followed by "size" bytes: - MCU requests to read one byte from UART by calling HAL_UART_Receive_IT() - The remote may or may not have already sent the byte, but it doesn't matter, this works correctly. - After the UART_Receive_IT() callback, the MCU requests to read "size" bytes by calling HAL_UART_Receive_DMA(). - If the remote has not sent the next byte yet, then all is well, but it could have sent the next byte already, which is waiting in the DR register. The RTS line will be high which prevents the remote from sending any more data, so no overrun will occur. But since __HAL_UART_CLEAR_OREFLAG() reads the DR register, this byte will be lost and the DMA read will read one extra byte from the incoming stream causing the algorithm to get out of sync. This adds a check to see if flow control is enabled and only calls __HAL_UART_CLEAR_OREFLAG() if flow control is disabled. This should prevent breaking users who aren't using flow control and may already depend on this behavior.
This changes writes to the CR1 and CR3 registers to use bit-band access to atomically modify the registers. This is needed since the interrupt handlers also modify these same registers and an interrupt could occur in the time between when the registers is read and when the modify value is written back. This change is not made in the init functions since interrupts will not be enabled yet and it is more efficient to set more than one bit at a time.
USB_OTG_CfgTypeDef is a large struct, so passing by reference should be more efficient in terms of stack usage and code size. Signed-off-by: David Lechner <david@pybricks.com>
USB_OTG_CfgTypeDef is a large struct, so passing by reference should be more efficient in terms of stack usage and code size. Signed-off-by: David Lechner <david@pybricks.com>
USB_OTG_CfgTypeDef is a large struct, so passing by reference should be more efficient in terms of stack usage and code size. Signed-off-by: David Lechner <david@pybricks.com>
USB_OTG_CfgTypeDef is a large struct, so passing by reference should be more efficient in terms of stack usage and code size. Signed-off-by: David Lechner <david@pybricks.com>
USB_OTG_CfgTypeDef is a large struct, so passing by reference should be more efficient in terms of stack usage and code size. Signed-off-by: David Lechner <david@pybricks.com>
USB_OTG_CfgTypeDef is a large struct, so passing by reference should be more efficient in terms of stack usage and code size. Signed-off-by: David Lechner <david@pybricks.com>
USB_OTG_CfgTypeDef is a large struct, so passing by reference should be more efficient in terms of stack usage and code size. Signed-off-by: David Lechner <david@pybricks.com>
This same fix is applied in a later version of the F4 HAL. Signed-off-by: Damien George <damien@micropython.org>
This fix comes from the H7 HAL v1.9.0. Signed-off-by: Damien George <damien@micropython.org>
This fix comes from the H7 HAL v1.9.0. Signed-off-by: Damien George <damien@micropython.org>
Signed-off-by: Damien George <damien@micropython.org>
This bug was introduced in a136cb4 Signed-off-by: Damien George <damien@micropython.org>
On STM32L4P5 and STM32L4Q5 pin PA0 has TIM2_ETR on AF14. Required definition in stm32l4xx_hal_gpio_ex.h is missing. It is included for every other L4 part in the file. PA0-TIM2_ETR is verified as available in the data sheet and STMCUBEMX. Signed-off-by: Chris Mason <c.mason@inchipdesign.com.au>
So that the computed value is not faster than requested one. This fix is backported from the F4 HAL v1.27.1.
When USE_HAL_DRIVER is defined, assert_param is defined by stm32xx_hal_conf.h but stm32l1xx_ll_utils.c always define assert_param if USE_FULL_ASSERT is not defined. This change adds checking whether USE_HAL_DRIVER is defined.
This was referenced Oct 14, 2025
|
This PR is not quite right... it's going into vendor when it should be a working branch. But, I just merged U5 support, and want to update N6 support as well. So the working branch will be quite different. So I suggest just making this PR update the WB and not make a new working branch. I'll do that separately and do it for U5, N6 and WB updates all at once. |
|
Another problem with this PR is that it somehow adds the new WB 1.23.0 commit in the middle of the existing vendor history. Also, there are only 35 patches to apply for the working branch, not 48. I'm not sure what went wrong, but I suggest just doing a PR of an updated vendor branch that updates the WB code. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
8 participants
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Summary
This updates the STM32CubeWB HAL/LL library from v1.10.0 to v1.23.0, following the documented vendor/work branch workflow.
@dpgeorge this is a re-creation of the updates stmlib from micropython/micropython#15592 which should be correcly following the update process here.
The update includes:
F0-1.9.0+F4-1.16.0+F7-1.7.0+G0-1.5.1+G4-1.3.0+H5-1.0.0+H7-1.11.0+L0-1.11.2+L1-1.10.3+L4-1.17.0+N6-1.1.0+WB-1.23.0+WL-1.1.0STM32WBxx_HAL_Driver/Src/stm32wbxx_hal_smbus_ex.cTesting
The rebase completed successfully with no conflicts. All 48 patches applied cleanly:
This preserves all existing MicroPython customizations while gaining the latest STM32 vendor improvements.
Trade-offs and Alternatives
This follows the documented workflow in
README.mdfor managing vendor dependencies with MicroPython patches. The alternative manual approach was replaced with this proper vendor/work branch workflow to maintain clean separation between upstream code and MicroPython modifications.