OS: OSX 12.1 IDE: STM32CubeIDE: 1.8.0 (fresh installation, all defaults)

Application builds with no errors, but when data transmission from USB->USART does not work correctly. Only 1 character is transmitted, second and subsequent characters do not appear. By contrast, USART->USB works correctly - all characters are transmitted.

It appears that the call back HAL_UART_TxCpltCallback is not called on second and subsequent characters.

[Both the USB and USART via STLink VCP are connected to using screen]

Describe the set-up

It is better to not introduce any text which is not UTF-8 encoded.

I could see 6 issues:

Drivers/CMSIS/Device/ST/STM32U5xx/Include/stm32u5xx.h:  *              - To use or not the peripheral<92>s drivers in application code(i.e.
Drivers/CMSIS/Device/ST/STM32U5xx/Include/stm32u5xx.h:  *                code will be based on direct access to peripheral<92>s registers
Drivers/STM32U5xx_HAL_Driver/Src/stm32u5xx_hal_pwr_ex.c:      The Stop 3 mode is based on the Cortex<AE>-M33 Deepsleep mode combined with
Drivers/STM32U5xx_HAL_Driver/Src/stm32u5xx_hal_pwr_ex.c:      (+) After exiting reset, the USB Type-C <93>dead battery<94> behavior is enabled,
Drivers/STM32U5xx_HAL_Driver/Src/stm32u5xx_hal_pwr_ex.c:  * @note   After exiting reset, the USB Type-C <93>dead battery<94> behavior is
Drivers/STM32U5xx_HAL_Driver/Src/stm32u5xx_hal_pwr_ex.c:  * @note   After exiting reset, the USB Type-C <93>dead battery<94> behavior is

Additional context

Reported in automatic style check in https://github.com/ARMmbed/mbed-os/pull/15022

It seems that some UTILS_SCALEY_LATENCYX_FREQ definitions are wrong:

https://github.com/STMicroelectronics/STM32CubeU5/blob/0eedae3d2a7997a2b5fbfdb57f54c7201e0827c8/Drivers/STM32U5xx_HAL_Driver/Src/stm32u5xx_ll_utils.c#L69-L71

12.5000000 and 37.5000000 look erroneous. Can you confirm ?

Setup

Keil uvision 5.35, ac6

Description

Variables in a ThreadX module do not get their initial values as expected. Static or global variables are not initialized to 0 and variables in general do not get the initial value assigned in their definition.

Additional context

The call that is supposed to perform the C runtime initialization of a module is commented out in txm_module_initialize.S (line 73). This is not specific to stm32u5xx or cortex-m33 since the same line is also commented out in other ports to ac6. The code seems to be the same in the Azure RTOS repo, so perhaps this should be reported to them?

Describe the set-up

• Nucleo-U575ZI-Q
• STM32CubeIDE 1.7.0
• Firmware Package version : V1.0.2
• Toolchain (default STM32CubeIDE): GNU Tools for STM32 (9-2020-q2-update)

Describe the bug (skip if none)

HardFault on execution of this condition: Drivers/STM32U5xx_HAL_Driver/Src/stm32u5xx_hal_spi.c, line 2930

In function SPI2_IRQHandler()->HAL_SPI_IRQHandler()

After the call of HAL_SPI_Transmit_DMA().

Additional context

The code is generated with STM32CubeMX. The Cube project is configured with a SPI peripheral, and 1 DMA channel linked to the TX of the SPI. Both IRQ Hanlder and HAL handler generation are ticked for both SPI and DMA channel interrupts.

The HAL_SPI_IRQ_Handler is trying to access the field "hspi->hdmarx->Mode" although hspi->hdmarx is NULL since no DMA channel is linked to SPI RX. This generates the HardFault.

It seems that the code is designed so that the year field is less than 99 (2 digits). But the year field for 2022 is 2022-1900 = 122 which is a value > 99 and 3 digits.

This causes 2 problems.

File stm32u5xx_hal_rtc.c (also applicable on other STM32)

1/ assert_param(IS_RTC_YEAR(sDate->Year));

We still have this assert since sDate->Year > 99 in 2022.

(Note that the control is not good on the month either since the valid values go from 0 to 11 and the control checks that the values go from 1 to 12)

2/ (uint32_t)RTC_ByteToBcd2(sDate->Year)) << RTC_DR_YU_Pos)

We have 3 digits in 2022, the conversion to BCD is done for 2 digits (no of the function and comment of the function) but it happens that it works and it will continue to work, the bug will appear only in 2060.

osEventFlagWait option can be wait for any (OR) or wait for all (AND)

IMPORTANT INFORMATION

Contributor License Agreement (CLA)

• The Pull Request feature will be considered by STMicroelectronics after the signature of a Contributor License Agreement (CLA) by the submitter.
• If you did not sign such agreement, please follow the steps mentioned in the CONTRIBUTING.md file.

I/O Port I is currently not configured as a nonsecure device in the TFM application. The commits in this pull requests will fix that.

My company did sign a CLA and send it to your legal department on March, 25th 2022.

[update] Update the wrong word

IMPORTANT INFORMATION

Contributor License Agreement (CLA)

• The Pull Request feature will be considered by STMicroelectronics after the signature of a Contributor License Agreement (CLA) by the submitter.
• If you did not sign such agreement, please follow the steps mentioned in the CONTRIBUTING.md file.

This isn't a bug as such, but it is a trap for anyone porting from STM32L4 (and maybe other older STM32s) to the U5 HAL.

The parameter SrcDataSize in the function DMA_SetConfig() has a different meaning from STM32L4 - this is due to the difference between the U5 GPDMA GPDMA_CxBR1 register BNDT field - which is the number of bytes to transfer (RM0456 17.8.12) and the L4 DMA DMA_CNDTRx register NDT field which is the number of DMA transfers (RM0432, 11.6.4).

If the source and destination datawidths are both bytes then DMA_SetConfig() functions identically on the U5 and L4, but if the datawidth is half-word or word then on the U5 the DMA transfer ends after either 1/2 or 1/4 of the DMA is complete since each transfer counts for 2 or 4 bytes,

static void DMA_SetConfig(DMA_HandleTypeDef const *const hdma,
                          uint32_t SrcAddress,
                          uint32_t DstAddress,
                          uint32_t SrcDataSize)   <<< this parameter is a byte count on the U5 and a transfer count on L4

https://github.com/STMicroelectronics/STM32CubeU5/blob/2e2b3e4733ddcde7af1e91f1c27ef7bea84389ce/Drivers/STM32U5xx_HAL_Driver/Src/stm32u5xx_hal_dma.c#L1588

This difference in functionality affects any callers of either HAL_DMA_Start() or HAL_DMA_Start_IT(). It's possible to fix this with conditional compilation in the application code, but it's not ideal to have a near identical HAL API with different functionality. In theory DMA_SetConfig() could read the burst length configured in the hdma struct and multiply the SrcDataSize accordingly and I think that this would lead to a consistent API behavior on the U5 to the L4 - but perhaps it's too late to make this change since it would likely break existing applications. Perhaps a comment above the function prototypes to draw attention to the difference ?

Describe the set-up

• This behavior is platform independent
• Arm GNU Toolchain 12.2.MPACBTI-Bet1

Describe the bug

Additional delays are inserted in some of the DAC HAL functions, which make use of HAL_Delay timebase function, whose purpose is supposedly avoiding fast switching of the DAC peripheral state, thus enforcing a minimum delay between various operations. Not only can this become cumbersome by itself, as the delay (1ms) can be considered quite large in some applications, but the biggest issue at hand is that, should the HAL timebase be temporarily suspended, i.e. because the corresponding timer is paused or the ticker ISR is not called, these functions will completely block the processor in an infinite loop.

Affected functions are:

HAL_DAC_Start()
HAL_DAC_Start_DMA()
HAL_DAC_Stop()
HAL_DAC_Stop_DMA()
HAL_DAC_ConfigChannel()

How to reproduce the bug (skip if none)

1. Indicate the global behavior of your application project
   • It is sufficient to have an application making use of the DAC HAL .
2. List the modules that you suspect to be the cause of the problem (Drivers, BSP, MW...)
   • DAC HAL
3. Describe the use case that generates the problem
   • Calling one of the aforementioned functions in a context where the HAL timebase counter variable, i.e. uwTick doesn't get incremented during the function operation
4. How we can reproduce the problem
   • Recreate context:
     • Stop the Systick timer, or any timer used for generating the timebase (and thus calling HAL_IncTickon a periodic fashion), or
     • Enter an ISR with an higher priority than the timebase interrupt, or
     • Temporarily disable interrupts
   • Then call one of the aforementioned functions

Additional context

It would be sufficient to remove these HAL_Delay functions inside the DAC HAL. This would also remove the cumbersome 1ms delay which is in most cases unneeded. It should also be noted that this driver is one of the very few introducing these delays, the other being the USB driver and the OPAMP driver.

Another possibility would be adding a toggle variable in the DAC HAL that conditionally calls these delays when enabled.

At the current state, if maintaining the current HAL version in your own project the solution is simply copy-pasting these functions in equivalent ones without the HAL Delay call, which is not an insignificant annoyance

Describe the set-up

• The board NUCLEO-U575ZI-Q
• IDE or at least the compiler and its version STM32CubeIDE Version: 1.10.1 Build: 12716_20220707_0928 (UTC) compiler: gcc 10.3-2021.10

Describe the bug (skip if none) The board can not enter the relative low power mode.

How to reproduce the bug 1 remove the JP5 and connect an amperemeter to it 1 compile and download the demo code under Projects\NUCLEO-U575ZI-Q\Examples\PWR\PWR_ModesSelection 2 config the low power via the usart 3 finish the config and enter the low power mode 4 in STOP0 mode the current consumption should be about 39uA，but it's about 7mA

Additional context I did some work on tracing the issue. And I find the program blocked after run into the function system_config

I hope someone can help me out~

While tracking down a flash bug in Zephyr on the STM32U585, I discovered that the stm32u585xx.h header defines FLASH_PAGE_NB based on FLASH_BANK_SIZE rather than FLASH_SIZE, meaning that FLASH_PAGE_NB equates to what was defined on other platforms (or at least in the stm32l5_hal_flash.h) as FLASH_PAGE_NB_PER_BANK. This doesn't make much sense to me.

The most straightforward fix, in my opinion, would be to add the FLASH_PAGE_NB_PER_BANK macro and redefine the FLASH_PAGE_NB macro to accurately represent the total number of flash pages on the platform.

I discovered this issue while modifying the Nucleo example project: STM32CubeU5\Projects\NUCLEO-U575ZI-Q\Examples\ADC\ADC_DifferentialMode

The ADC conversion returns correct 14 bit values when oversampling is disabled: hadc1.Init.OversamplingMode = DISABLE;

When I try to enable oversampling I get incorrect values - to a different extent depending on which oversampling I select.

These settings under-read by factor of 3  (0.33)
  hadc1.Init.Oversampling.Ratio = ADC_OVERSAMPLING_RATIO_64;
  hadc1.Init.Oversampling.RightBitShift = ADC_RIGHTBITSHIFT_6;

These settings under-read by factor of 3  (0.83)
  hadc1.Init.Oversampling.Ratio = ADC_OVERSAMPLING_RATIO_16;
  hadc1.Init.Oversampling.RightBitShift = ADC_RIGHTBITSHIFT_4;

I discovered the problem is that the macros ADC_OVERSAMPLING_RATIO_16, ADC_OVERSAMPLING_RATIO_64, and their corresponding macros LL_ADC_OVS_RATIO_X are copied from earlier HAL, which is compatible with the STM32L4+, but not compatible with the STM32U575 ADC1.

The STM32L4 ADC oversampling ratio can only be set as a power of 2 (which corresponds to LL_ADC_OVS_RATIO_X). From RM0432 section 21.6.5 ADC configuration register 2 (ADC_CFGR2):

Bits 4:2 OVSR[2:0]: Oversampling ratio
This bitfield is set and cleared by software to define the oversampling ratio.
000: 2x
001: 4x
010: 8x
011: 16x
100: 32x
101: 64x
110: 128x
111: 256x

The STM32U5 oversampling ratio is set to any number between 1 and 1024. From RM0456 section 29.6.5 ADC configuration register 2 (ADC_CFGR2):

Bits 25:16 OSR[9:0]: Oversampling ratio
This bitfield is set and cleared by software to define the oversampling ratio.
0: 1x (no oversampling)
1: 2x
2: 3x
...
1023: 1024x

Therefore the macros ADC_OVERSAMPLING_RATIO_X defined in stm32u5xx_hal_adc.h and LL_ADC_OVS_RATIO_X defined in stm32u5xx_ll_adc.h are not compatible with the STM32U575 ADC1 ADC_CRGR2 register - which can cause confusion when porting a project from an older STM32.

Note that these macros do appear to be compatible with ADC4 on the STM32U575 - (according to RM0456 30.7.5 ADC configuration register 2 (ADC_CFGR2)) - so perhaps simply renaming the macros in stm32u5xx_hal_adc.h to ADC4_OVERSAMPLING_RATIO_X would make this clearer.

In stm32u5xx_hal_adc.h, the ADC4_RESOLUTION_XB macros are under the ADC_HAL_EC_RESOLUTION group. However, using these defines to configure ADC resolution with ADC4 does not lead to the correct resolution.

Looking in stm32u5xx_ll_adc.h, we can see that the LL_ADC_RESOLUTION_XB_ADC4 macros are labeled with a comment saying /* Internal values only, please do not use */. But this same comment does not exist in stm32u5xx_hal_adc.h, which can lead to confusion.

Comment should be present in both header files, and it should be clarified that the ADC4_RESOLUTION_XB macros cannot be used for ADC initialization.