[BUG] STM32 HAL SAI abort and DMA stop logic is flawed
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2023-05-21 7:20 AM
The logic in functions HAL_SAI_Abort() and HAL_SAI_DMAStop() is flawed because the sequence of actions is wrong. A proper sequence is:
- Disable the SAI and wait for it to be actually disabled.
- Stop the DMA.
- 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.
Solved! Go to Solution.
Accepted Solutions
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2023-05-31 3:26 AM
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2023-05-28 11:33 AM
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
Thanks
Imen
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2023-05-31 3:26 AM
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2023-06-05 6:55 AM
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
Saket_Om
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2023-10-09 10:33 PM
Hello @Piranha ,
I just checked my code and found that I'm not using HAL, but copied the sequence from HAL:
- disable DMA request in SAI (clear SAI_xCR1_DMAEN)
- abort DMA
- disable SAI, wait for it
- 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?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2024-03-18 1:32 AM - edited ‎2024-03-18 1:34 AM
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).
Thanks
Imen
