cancel
Showing results for 
Search instead for 
Did you mean: 

[BUG] STM32 HAL SAI abort and DMA stop logic is flawed

Piranha
Chief II

The logic in functions HAL_SAI_Abort() and HAL_SAI_DMAStop() is flawed because the sequence of actions is wrong. A proper sequence is:

  1. Disable the SAI and wait for it to be actually disabled.
  2. Stop the DMA.
  3. Flush the SAI FIFO.

In the current implementation the function SAI_Disable() is called after stopping the DMA. This causes a SAI underrun and a data glitch at the end of stream. The bug seems to be present for all series with SAI peripheral.

Also the two functions do almost the same and the code is also almost the same, which is an example of a bad and bloated design.

1 ACCEPTED SOLUTION

Accepted Solutions
Piranha
Chief II

Transmitting/receiving anything other (including the silence) than the intended data creates a glitch. And in general an underrun/overrun is an abnormal situation, not something that is acceptable to happen almost always.

The particular issue is not even close to being complex and the fact, that the HAL team cannot understand such a simple issue even when pointed to it, just proves again what I'm saying all the time - the level of incompetence is just absolutely tragic.

View solution in original post

5 REPLIES 5
Imen.D
ST Employee

Hello @Piranha,

It seems Data glitch cannot happen with the current HAL_SAI implementation. Because the SAI sends a MUTE value (0x00) in case of underrun.

I will escalate this internally for deep check.

Thanks

Imen

When your question is answered, please close this topic by clicking "Accept as Solution".
Thanks
Imen
Piranha
Chief II

Transmitting/receiving anything other (including the silence) than the intended data creates a glitch. And in general an underrun/overrun is an abnormal situation, not something that is acceptable to happen almost always.

The particular issue is not even close to being complex and the fact, that the HAL team cannot understand such a simple issue even when pointed to it, just proves again what I'm saying all the time - the level of incompetence is just absolutely tragic.

OSAKE.1
ST Employee

Hello @Piranha,

I confirm the first issue and it is reported internally.

Internal ticket number: 152756 (This is an internal tracking number and is not accessible or usable by customers).

With regards

Omar

If your question is answered, please close this topic by clicking "Accept as Solution".

Thanks
Omar
LCE
Principal

Hello @Piranha ,

I just checked my code and found that I'm not using HAL, but copied the sequence from HAL:

  1. disable DMA request in SAI (clear SAI_xCR1_DMAEN)
  2. abort DMA
  3. disable SAI, wait for it
  4. flush FIFO

I never got an underrun error (or so I think...), I can't really say anything about glitches, because I never listen to SAI data, just checking it visually in our scope / FFT app.

When I switched the order of disables (as you suggest) I didn't see any difference.

Question:

I would prefer to have the currently used DMA buffer filled completely, but right now I'm not sure how to get there cleanly.
Maybe via transfer complete interrupt, set flag there, check flag elsewhere, then stop sequence? 

Imen.D
ST Employee

Hello All,

I would inform you that this issue is fixed in the new release of STM32CubeF4 (v1.28.0).

The HAL SAI has been updated to improve audio quality (avoid potential glitch).

 

When your question is answered, please close this topic by clicking "Accept as Solution".
Thanks
Imen