ChibiOS Free Embedded RTOS

Hi,

i am experiencing DMA direct mode errors in an application which writes big amounts of data to SPI at high speed.
The errors are raised by the spi rx channel although i am doing SPI tx only.
According to the reference manual, DMA direct mode errors appear in peripheral-to-memory mode with MINC bit cleared only when

a DMA request occurs while the previous data have not yet been fully transferred into the memory (because the memory bus was not granted)

It seems that i was able to fix this by raising this particular DMA streams priority over the others but i don't feel good for a couple of reasons:

a.) I can't be sure this will happen again randomly because of my lack of understanding the issue.

b.) I don't see why peripheral-to-memory DMA is used at all when doing SpiSend (and not Transceive or Receive).

c.) As this data is discarded anyway doing a port_halt() in response creates the problem in the first place.

I would be very glad if someone could shed some light on this for me (and possibly others).
Thanks and with best regards,

Vinz

The DMA has to pull the data from the SPI quickly enough or overflows can occur, if you have massive DMA activity then tweaking the DMA priorities is the right thing to do. They are changeable for a reason.

The SPI always use 2 channels even when transmitting only in order to not let the SPI overflow, this could change of course, the driver could write only, ignore the RX overflows and then clear the overflow status at transfer end. You could give it a try.

Giovanni

Thanks for the quick reply.
How can i be sure not to ever hit that issue again just by tweaking DMA priorities?
E.g. imagine using two SPI interfaces on the same DMA at the same speed doing the same thing.

Cheers,

Vinz

Look at the DMA STORM demo, it is not that easy to saturate the memory bus.

Giovanni

My concern is not that it is likely to get a DMA error but that it is unlikely - but still possible.
If that error (direct mode error) occurs only once in a while it is very hard to catch at design time and will bite you after deployment.
I don't yet know about the conditions leading to that e.g. what about high spi frequencies but lower clocked core?
Does that raise the likeliness of "memory bus was not granted"?
In my application where i hit the issue, i am running an stm32f429 at 84 MHz and SPI at 42 MHz.
So the point i am trying to make is that a well designed system guarantees that this doesn't happen by design instead of likeliness.

Cheers,

Vinz

This could be a good question for ST's designers, is there any application note about DMAs?

Giovanni

There is an application note (from 02/2014) explaining DMA which seems to be worth reading:

http://www.st.com/web/en/resource/techn ... 046011.pdf

My conclusions from reading this so far:
- using DMA is not for free (-> don't use it when unnecessary e.g. spi_lld_send (rx) or spi_lld_ignore (rx))
- use CC SRAM for stack and heap when doing DMA on reduced clock (4.7 in the app note)
- DMA access latency to SRAM depends among other things also on what code the cpu is executing at that time (-> this makes it very difficult to tell if there is a rare problem or not)

I am playing with the DMA_STORM demo and as soon as the clock is reduced, problems start.
E.g. reducing the clock to 84 MHz and keeping the peripherals at their speed, the demo hangs immediately at the timeout timer.
Interestingly i don't currently see why that happens as i would have expected a dma error to fire before that timer hits.

It would not be a DMA error, it would be eventually an SPI/ADC overflow error.

Using CMM should help for sure, that makes the CPU use less bandwidth on the crossbar.

Giovanni