K(60) DMA arbitration and pre-emption

[comsosysarch]

I am seeing "slips" or missed samples when sampling an external audio ADC using the I2S via DMA with continuously looping scatter-gather.

There could be a number of reasons this is occurring but what I am wondering here is if there is something with channel priority / arbitration / pre-emption that I am not doing the best way which could be causing my problem.

Currently I have the channel priority at the defaults (priority equal to channel number), my channel in question is channel 15 (highest priority), the DMA is left on fixed (not round robin) arbitration.

According to the channel priority register channel 15 (or any other) *can* pre-empt lower-priority channels which seems to be the default.

According to the channel priority register *no* channel can *be* pre-empted by higher-priority channels which also seems to be the default.

Depending on the details of how DMA channel arbitration works (ie is it per-peripheral-hardware-request, per TCD block access, or when exactly)... it may be that activity on lower priority DMA channels is causing the highest priority channel to stall waiting for some minor or major cycle completion, since the lower priority channels may not be pre-empted by the higher priority channel?

Might this be true? If so, what is the effect on the lower priority
channel(s) if I enable pre-emption? Do they suspend and then resume
where they left off when the higher priority channel is done (and is
this when the single transfer is done or when the minor/major loop is
done)?

I do believe what I am seeing is more than just a one-transfer (one
external ADC sample) "slip" but I do have several other lower-priority DMA
activity going on some of which uses iteration counts which are fairly
lengthy.

[admin]

What is the speed of your K60 and the configuration of your I2S?  Frame sync rate, sample size and number of samples?

We are getting ready to use the I2S (what will be the SAI in Si rev. 2.x parts) and DMA and have a test prepared to verify no loss of samples once we have everything coded.  We planned on running the core at 96MHz with the I2S setup as a slave with a 200kHz frame rate, 16 bit samples and any where from 2-6 samples (6.4MHz-19.2MHz bit clock).

In the following reference, it's stated that the clock can not be any faster than 1/5 the peripheral clock which means we are limited to a maximum of 3 samples in our application:

K60 Sub-Family Reference Manual, Rev. 6, Nov 2011

pp 1737-1738

53.4.2 I2S clocking

We are looking to use the K60 Si rev. 2.x parts in our design which doesn't have a RM available yet therefore Freescale pointed us to the K10 RM in the time being.  Now, the K10 Sub-Family Reference Manual, Rev. 2, Feb 2012 makes no reference to this requirement in the new SAI chapter.  We are asking if this was just missed or is a requirement of the SAI as well.

Even if we are limited to 1/5 the peripheral clock, the new K60 Si rev. 2 parts have two channels which we "could" received 3 samples on each

[comsosysarch]

IIRC we're running the K60 at 50/50/50/25 MHz clock scheme (ie everything 50 except flash clock).

I2S serial bit clock should be < 500 kHz, with I2S master clock sourced by the K60 to the external A/D < 2 MHz. Yes an abnormally low sample rate. But certainly well within the 1/5 CPU clock spec (which I am guessing would be 10 MHz here).

Have picked apart the DMA pre-emption scheme and learned a lot doing so but have not fixed my problem with the data hiccups. Unfortunately the pre-emption did have a slight effect which is the worst possible news since it may mean that there is still a lingering DMA throughput issue (yeah... using a lot of DMA for various things).