STMicroelectronics / STM32CubeU5

Full Firmware Package for the STM32U5 series: HAL+LL drivers, CMSIS, BSP, MW, plus a set of Projects (examples and demos) running on all boards provided by ST (Nucleo, Evaluation and Discovery Kits).
Other
121 stars 67 forks source link

DAC related HAL functions stalling when timebase interrupts are disabled #21

Closed DonBrus closed 1 year ago

DonBrus commented 1 year ago

Describe the set-up

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

RJMSTM commented 1 year ago

Hello @DonBrus

Thank you for your contribution. Actually, the point you raised has already been dealt and fixed internally. The fix will be made available in the frame of a future release.

We cannot share a date for the moment. So, stay tuned and thank you once more for your contribution and for your patience.

With regards