X-CUBE-AI issue on STM32N6 Nucleo with SAI peripheral

[s319189]

In an Edge AI audio project that I'm working on, there is SAI2 peripheral that stops audio transmission after a while when the AI algorithm in the while loop of the main.c has done some inferences.

The AI algorithm code was generated with Cube AI Studio and, when STM32CubeAI_Studio_AI_Process() is commented, the SAI peripheral works normally without interruptions.

The board used is a NUCLEO-N657X0-Q.

The version of software used is:

-ST Edge AI Core: version 4.0.0

-STM32CubeIDE: version 2.0.0

-Cube AI Studio: version 1.1.0

I've tried to search on internet for a solution and there is no material concerning it! I've tried to ask for help in other posts, but nobody helped me. Can somebody try to explain why and find a solution? I'm desperate and I don't know what to do for my project but withdraw.

[Julian E.]

Hi @s319189,

Does the issue come from the audio streaming or the inference?

Can you bypass the inference in order to validate your implementation of the audio streaming first?

Does it bug again when you reactivate the inference?

Where does it stops?

Have a good day,

Julian 

[s319189]

1) "Does the issue come from the audio streaming or the inference?"

The issue comes from inference: when audio streaming is done without inference in the ground, audio is transmitted smoothly without any interruptions. However, when inference is done in the background instead, audio becomes corrupted and at a certain point the audio transmission is stopped...

2) "Can you bypass the inference in order to validate your implementation of the audio streaming first?"

Sorry, maybe it's my problem of understanding but I've not understood the second question

3) "Does it bug again when you reactivate the inference?"

Yes, it does exactly so...

4) "Where does it stops?"

Appearently at "STM32CubeAI_Studio_AI_Process();" line of code

I'll upload my project if it can be useful...

I've noticed using Oscilloscope probes that SAI1 SCK and FS lines get corrupted when inference is done, I don't know if it's a problem that can be solved

[Julian E.]

@s319189,

I shared your comment to our devs.

Have a good day,

Julian

[s319189]

Ok thank you! Let me update when you will get results as soon as possible!

[s319189]

More than a week has passed. Could I have updates?

[Tuomas95]

Have you enabled __HAL_RCC_SAI2_CLK_SLEEP_ENABLE();? Also if using DMA __HAL_RCC_GPDMA1_CLK_SLEEP_ENABLE();.

[s319189]

I don't find those lines of code, what's the purpose of including them and what should solve? Where should I write them precisely (in what part of the program should I put them)?

Anyway I've found out that the .zip file that I've exported from Cube IDE, I don't know why, it has not included main.c and it's not the first time that Cube DE exports an empty project without several important files...

@Julian E. for the employees that you have forwarded the message, could you tell them to look up this .zip file uploaded below instead?

[Julian E.]

Hi @s319189,

Yes, I will share you new .zip.

Have a good day,

Julian

[Tuomas95]

This is maybe not related to you problem, but when you call LL_ATON_OSAL_WFE() e.g. the system will go to sleep or similar lower power mode, in this mode most clocks are stopped. If you are receiving data with SAI, you need to explicitly tell that the SAI clock should stay active when the system goes to sleep, otherwise SAI and the DMA working with SAI will stop once you call LL_ATON_OSAL_WFE(), as the clocks stop. Calling __HAL_RCC_SAI2_CLK_SLEEP_ENABLE() once before LL_ATON_OSAL_WFE() tells the system to keep the SAI2 clock running even in sleep mode.

Again, this might not fix your issue, but i had similar issue where the SAI stopped receiving new data after calling  LL_ATON_OSAL_WFE(), this issue was fixed by adding the CLK_SLEEP_ENABLE's.