MPC5777 EQADC REACM2 Undocumented Overheads

[TomE]

We are setting up the EQADC to continuously sample (triggered by the TBG) and then send the results to the Reaction Module.

The CPU is running at 250MHz and the ADC Clock is that divided by 8, or 31.25MHz.

We are loading the "eqadc_cmds_reacm2" array into EQADC CFIFO Zero set to a depth of "8":

#define CFIFO_BN(n) PSHIFT(6,(n)&1) /* Buffer Number */
#define CFIFO_ADC(n) CFIFO_BN(n)
#define CFIFO_CHAN(n) PSHIFT(23,n) /* CHANNEL_NUMBER: channel to convert */
#define CFIFO_TAG(n) PSHIFT(11,n) /* MESSAGE_TAG */
#define CFIFO_ALT_CFG(n) PSHIFT(31,(n+7)) /* ALT_CONFIG_SEL */

#define CFIFO_PAUSE PBIT(1) /* pause (wait for trigger) */
#define CFIFO_REP PBIT(2)   /* Repeat/loop Start Point Indication */
#define CFIFO_CAL PBIT(7)   /* Calibrate conversion result */
#define CFIFO_SAMP2 PSHIFT(13,0) /* ADC sampling time (clock cycles) */

/* queue an ADC conversion, add CAL or SAMP as required */
#define CFIFO_CONVERT(adc, chan, fifo)              \
    (CFIFO_ADC(adc) | CFIFO_CHAN(chan) | CFIFO_TAG(fifo))

/*
 * this command queue is loaded into cfifo0 once and repeated
 * in stream mode. CFIFO_EOQ not needed (but tested).
 */
static const u32 eqadc_cmds_reacm2 [] = {
    CFIFO_CONVERT(ADC0, 96, 0) | CFIFO_ALT_CFG(4) | CFIFO_CAL | CFIFO_SAMP2 | CFIFO_REP,
    CFIFO_CONVERT(ADC0, 97, 2) | CFIFO_ALT_CFG(4) | CFIFO_CAL | CFIFO_SAMP2,
    CFIFO_CONVERT(ADC0, 98, 4) | CFIFO_ALT_CFG(4) | CFIFO_CAL | CFIFO_SAMP2,
    CFIFO_CONVERT(ADC0, 96, 0) | CFIFO_ALT_CFG(4) | CFIFO_CAL | CFIFO_SAMP2,
    CFIFO_CONVERT(ADC0, 97, 2) | CFIFO_ALT_CFG(4) | CFIFO_CAL | CFIFO_SAMP2,
    CFIFO_CONVERT(ADC0,  6, 6) | CFIFO_ALT_CFG(4) | CFIFO_CAL | CFIFO_SAMP2,
    CFIFO_CONVERT(ADC0, 96, 0) | CFIFO_ALT_CFG(4) | CFIFO_CAL | CFIFO_SAMP2,
    CFIFO_CONVERT(ADC0, 97, 2) | CFIFO_ALT_CFG(4) | CFIFO_CAL | CFIFO_SAMP2| CFIFO_PAUSE
};
‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍

The above is then triggered by the Timebase Generator with the following code:

    const u32 period = REACM2_CFIFO_PERIOD - 1;
    const u32 tbg_cr = TBG_GEN | TBG_ADC0 | period;
    SIU->tbg_cr_a[0] = tbg_cr;
‍‍‍

There are 7 differential conversions and one single-ended one, all with two clock sample periods. So that should take (7 * (13+2) + (14+2)) or 121 clocks.

We also want to leave some time free for other ADC samples that are running on CFIFO One.

We expect the above to take 121 clocks. We're finding it actually takes 135 clocks. If we set "REACM2_CFIFO_PERIOD" in the above to any number less than 135 we get Trigger Overflow interrupts. Set to 135, CFIFO1 never gets any samples taken. Set to (135+16) we can see one CFIFO1 sample being taken for every run through the above sequence and so on.

So by reverse-engineering there's an unaccounted for (135-121=14) ADC Clock Overhead somewhere in the EQADC's operation.

Is this documented anywhere?

Tom

[davidtosenovjan]

Hi, what you describe rather shows as trigger delay than different conversion time. Something like that I have found sketched in in diagram below, however without any quantification. However I am not sure if it can be the reason, I would expect this time much shorter.

It should not be any overhead caused by reaction module or decimation module usage in relation to eQADC, at least I am not aware it would be specified.

[TomE]

Thanks for your reply. I've read through the whole EQADC section again, and as you say, that "delay" isn't described. But the "(Obs. 1) says the big delay is about 2 clocks, and the smaller one should be less than that.

However, I'm sending periodic triggers, and they should appear periodically after any and all delays, so this shouldn't matter.

There's a lot of internal complexity, and it is probably handled by state machines, maybe even programmed ones. They may be performing all the pointer stepping and command reading SEQUENTIALLY, and this may take a significant amount of time. Like DMA Controllers are always slower than you'd expect due to the internal overhead. These state machines don't have to be able to step (from one command to the other) any faster than the maximum ADC conversion rate (15 clocks). So they may be "executing the next step" while the previous conversion is happening, and taking up to 15 ADC clocks to do so. So the internal execution delay disappears in the pipeline.

Until it hits the "Pause". Then it might take an entire cycle to step from "Triggered" to "Waiting for Trigger" states and to be triggered to start converting again. That might explain the 14 ADC clock delay I'm seeing.

If I set the trigger to one ADC clock fewer, I get a trigger overflow. That's expected.

If I set the trigger to one clock more, I would expect that clock to be "wasted" while the state machine waits. I would expect to have to set it to at least 16 more to allow for a single 16-bit ADC conversion from another CFIFO.

However, what I see is that I can set it to "one clock more" and it seems to "accumulate" these bits. After 16 cycles it is able to fit in a 16 ADC-clock conversion from one of the other CIFOs. That would imply the trigger can also be "pipelined" up to 16 clocks "early" without causing the overflow. That's hard to explain (and probably even harder to document :-).

Tom

[davidtosenovjan]

I am sorry, but I still don't understand last paragraph, Could you please explain the situation you are facing when increasing mentioned 14 clocks by 1/2/3,...?

[TomE]

I'll try it graphically:

8 channels of CFIFO_0 taking 121 bits: [8*C_0]
Unexplained 14 bit overhead:           [14]
1 channel of CFIF0_1:                  [C_1]
"n" repeats of "[8*C_0][14]":          (n*([8*C_0][14]))

TBG Clock set to      Resulting Sampling
=============================================================
121+14=    135 Bits:  [8*C_0][14][8*C_0][14][8*C_0][14] ...
121+14+16= 151 Bits:  [8*C_0][14][C_1][8*C_0][14][C_1][8*C_0][14][C_1] ...
121+14+8=  143 Bits:  [8*C_0][14][8*C_0][14][C_1][8*C_0][14][8*C_0][14] ...
121+14+4=  139 Bits:  (4*([8*C_0][14]))[C_1](4*([8*C_0][14]))[C_1] ...
121+14+2=  137 Bits:  (8*([8*C_0][14]))[C_1](8*([8*C_0][14]))[C_1] ...
121+14+1=  136 Bits:  (16*([8*C_0][14]))[C_1](16*([8*C_0][14]))[C_1] ...


‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍

So when the TBG clock is set to allow all the 8 CFIFO_0 channels plus the 14-bit overhead, plus 16 bits for one CFIFO_1 sample, there's one CFIFO_1 sample taken per cycle. Exactly like you'd expect.

But when there's only one extra BIT allowed (136 clocks instead of 135), then one CFIFO_1 sample is taken for every 16 repeats of the CFIFO_0 cycle. And similarly for 2, 3 and 8 clocks. The "spare bits" seem to accumulate until there's enough for one whole 16-bit sample. Then that sample is taken.

Tom

[davidtosenovjan]

Are you using ABORT feature within ADC configuration? Do you always using multiple CFIFOs with this testing?

[TomE]

No abort.

CFIFO_0 is continuously converting 8 samples and forwarding to REACM2.

CFIFO_1 is being fed commands via EDMA programmed to cycle through 16 channels.

That's it.

Tom

[davidtosenovjan]

I see.

This is just time synchronization of two time domains. So the behavior does make sense.

So I think now the question is reduced to "why there is 14 clocks triggering delay". I will try to find out if I am able.