Is this possible to disable / monitor trigger memorization on DMA on STM32U575?

[Bastien LS]

Context

I am working on NUCLEO-U575ZI-Q with an external ADC wired to the board. The ADC generated a rising edge on one of its pins, "DRDY" each time a sample is available.

My objective is to retrieve the ADC sample without involving the CPU. The current solution is a DMA triggered by DRDY sending X dummy bytes to SPI TX register (X is the size of one sample from the ADC). The SPI then send (and read) 3 bytes to/from the ADC, receiving the sample. 

The bytes received are read with another DMA, but that is not the subject of this topic.

In a normal case, the DMA gets triggered (ADC says "data are ready"), 3 bytes are sent so 1 sample is read, then another sample is ready, etc.. All is fine.

In a case where the DMA is blocked for whatever reason, it will be triggered once (hit and fire, referring to figure 64 or RM0456 Rev 3, page 663), then a second trigger will occur (hit and memorize), and finally a third trigger will occur (hit and trash), generating a "trigger overrun event". There is an error with sample reception (2 samples were lost) and an error was triggered (overrun condition).

In an intermediate case where the DMA is slightly slowed down, the DMA may be triggered only twice in a row (losing the first sample), but no error is detected by the SW.

Questions

I am thus wondering is there is any solution for the software to disable the trigger memorization, or to detect that a memorization occurred.

Furthermore, is there an obvious way to retrieve external ADC samples without triggering an interrupt for every single sample?

[Mohamed Aymen HZAMI]

Hello @Bastien LS​,

>In an intermediate case where the DMA is slightly slowed down, the DMA may be triggered only twice in a row (losing the first sample), but no error is detected by the SW.

What do you mean by the DMA is slightly slowed down?

>Furthermore, is there an obvious way to retrieve external ADC samples without triggering an interrupt for every single sample?

Can you please clarify more this question?

for your question about the software solution:

• Try to increase the time between the triggers of the external ADC to be bigger than the transfer period

Can you please share your software?

Mohamed Aymen

[Bastien LS]

Hello @Mohamed Aymen HZAMI​ ,

>Can you please clarify more this question?

I have an external ADC generating 32768 samples per second. When a sample is ready, one of the pins of the ADC is raised. The pin name is "Data Ready".

To retrieve this sample, the microcontroller (STM32U5) must initiate a SPI communication = send 3 bytes of dummy data on MOSI. The ADC will then respond by putting the sample (3 bytes) on MISO.

How can the STM32 do that without generating an external interrupt on each sample (32768 interrupts per second is not conceivable) ?

Today, I use 2 DMAs as explained in my first post. This system works, but has an issue and I can't find a solution.

Maybe there is an other way to acquire this data with minimal interrupts and I a not aware of it.

>What do you mean by the DMA is slightly slowed down?

Maybe I am wrong, but I think a DMA might be slowed down for some reasons (like when a higher priority DMA is already doing a transfer). I don't know if putting the DMA at highest priority is enough to ensure that the DMA is never slowed down.

By "DMA slowned down", I mean that there might be a delay between the moment a DMA is triggered (by software, or by a hardware trigger), and the moment the DMA start the transfer.

And this delay, if it is not too long but not too short, might result in a loss of ADC sample in the mechanism I use today. I will try to explain again what I mean by that.

Case 1: No delay / short delay

1. ADC has generated a new sample of data, and overwrites its internal DATA register.
2. ADC pin Data Ready pulse.
3. A DMA is triggered by the pulse.
4. The DMA pushes 3 bytes on the SPI TX register.
5. The SPI peripheral sends 3 bytes and receive 3 bytes on RX (the ADC sample).
6. Another DMA retrieve the 3 bytes on SPI RX.
7. etc. (go back to step 1)

No data was lost.

Case 2: Big delay / DMA is stuck

1. ADC has generated a new sample of data, and overwrites its internal DATA register.
2. ADC pin Data Ready pulse.
3. A DMA is triggered by the pulse. (hit)
4. (The DMA does not push 3 bytes. It is slowed down for whatever reason)
5. ADC has generated a new sample of data, and overwrites its internal DATA register. (1 sample from the ADC is lost, as it was not retrieved, and it was overwritten)
6. ADC pin Data Ready pulse.
7. A DMA is triggered by the pulse. (Memorize)
8. (The DMA is still doing nothing)
9. ADC has generated a new sample of data, and overwrites its internal DATA register. (a second sample is lost)
10. ADC pin Data Ready pulse.
11. A DMA is triggered by the pulse. (Overrun)
12. The DMA Overrun error flag is raised.

We lost some data, but the software knows about it as the flag "overrun" was raised.

Case 3: middle delay / DMA slightly slowed down

1. ADC has generated a new sample of data, and overwrites its internal DATA register.
2. ADC pin Data Ready pulse.
3. A DMA is triggered by the pulse. (hit)
4. (The DMA does not push 3 bytes)
5. ADC has generated a new sample of data, and overwrites its internal DATA register. (1 sample from the ADC is lost, as it was not retrieved yet)
6. ADC pin Data Ready pulse.
7. A DMA is triggered by the pulse. (Memorize)
8. The DMA start pushing 3 bytes on the SPI TX register.
9. The SPI peripheral sends 3 bytes and receive 3 bytes on RX.
10. Another DMA retrieve the 3 bytes on SPI RX.
11. As 1 trigger was memorized, the first DMA starts pushing 3 bytes to SPI TX immediately.
12. The SPI peripheral sends 3 bytes and receive 3 bytes on RX.
13. Another DMA retrieve the 3 bytes on SPI RX.

We lost 1 sample from de ADC (we have twice the same sample instead), but the software can't be aware of it.

>for your question about the software solution:

• Try to increase the time between the triggers of the external ADC to be bigger than the transfer period

The time of the transfer is negligible. The problem I am referring to is a delay between the trigger of the DMA and the actual beginning of the transfer.

>Can you please share your software?

Unfortunately I cannot share the software.

Best regards,

Bastien Le Saulnier

[Mohamed Aymen HZAMI · Accepted solution]

>I am thus wondering is there is any solution for the software to disable the trigger memorization, or to detect that a memorization occurred.

No, it's not possible to disable the trigger memorization by software.

You can calculate the transfer DMA time by toggling a GPIO in the Transfer complete call back of the SPI-DMA API, and than you can know the time needed to regenerate a trig from the external ADC.

Mohamed Aymen