DMA buffers switching with SPI and TIMERS via PPI

[Michal Mrowiec]

While collecting 2-byte samples via SPI4 (with a 32 MHz clock) using PPI and timers—one triggering transfers at 400 kHz and another handling an interrupt every 512 samples (counter mode incrementing every SPI transfer end via PPI) to switch the SPI DMA buffer address—erroneous samples occur at buffer boundaries (mostly single, but sometimes multiple). Four buffers of 512 samples each are used.
It appears that either writing samples or switching buffers is not keeping up. However, the time between the 512-sample timer interrupt and the buffer address switch is shorter than the time until the next SPI transfer is triggered.

The program runs with Zephyr and BLE on net core. The sampling timer priority is set to 1, SPI and timer for switching buffers are set to 0 priority. Could Zephyr or other processor interrupts preempt the acquisition process to such an extent? Or is the issue elsewhere?

[Susheel Nuguru]

Hi Michal,

What you are running seems a bit tight. You are running one timer that is triggering the SPI samples every 2.5us and then the other timer is slow enough to trigger only when you have 512 samples. The issue is to find a safe spot to change the buffers when the other timer is not trying to access it 

I would use a mutual exclusion (mutex ) while accessing these SPI DMA buffers so that the DMA pointers are not changed while they are being used. 

[Michal Mrowiec]

Sounds good, how can I use mutex for sampling timer (2,5 us), while it's running without irq handler?

[Susheel Nuguru]

I) to switch the SPI DMA buffer address—

I missed the obvious point, didn't I?

This is a classic race condition between DMA buffer update and the next DPPI triggered SPI transfer which normally should be solved using software enabled methods.

Maybe it helps to chain this using suspend and resume tasks

Chain Timer A → SPI.TASKS_RESUME via PPI. 

After every 512 samples: Use TASKS_SUSPEND to pause SPI.Change the DMA buffer address.Then trigger TASKS_RESUME again via DPPI/PPI. 

I can not think of anything else right now apart form this.

[Michal Mrowiec]

Yes, I tried this also. Unfortunately, the problem still persists. After switching buffers, in the interrupt handler for the sample block, the pointer to the previous part of the buffer is placed into the queue using k_msg_put. The message is then processed by the memory write thread. The number of data buffers and the time between switches are sufficient to prevent data block overlap. However, could pointer transfer errors still occur in this configuration? Where else can I look for the source of the issue?