EK-TM4C1294XL: Sequencer FIF0 data pathway

Are you using TivaWare, or are you trying to use direct register writes?

It all Tivaware so I don't know what you are referring to since the FIFO via sequencer are triggered writes on the hardware level. Same results in HPTR/TPTR index occur using ADCSequenceDataGet() in ADC0 FIFO-1&2. Besides that Tivaware call not checking the FIFO for over/under flow and returning all results data (good or bad) is simply nuts, it don't even care! Far as sequencers configuration goes all are by ADCSequenceStepConfigure, like below.

Further debug investigation finds ADC0 FIFO-1&2 in CCS debug are not fully functional, both EKXL/EVM and custom PCB (TM4C1294KCPDT). Debug FIFO data is very sporadic if at all via 80us PWM trigger source and little to no action of TPTR/HPTR index most times remains 0x0, every once after several minutes TPRR may toggle. Seemingly can't be CCS debug GEL file unless the same incorrect mapping was done in both NCPDT and KCPDT targets. 

Yet SS0 FIFO-0 via same PWM GEN0 trigger source indicates data movement via ADCSSFSTAT TPTR/HPTR bits. Also ADC1 FIFO-1&2 appear to be working ok, that is the sequencers are triggering samples in 1 second intervals, the TPTR/HPTR move and don't perpetually just sit at 0x0 index. Configuring ADC1 SS0 replacing ADC0 - SS1&2 for the same 80us trigger source the TPTR/HPTR increments and FIFO data values are indicated. It would seem ADCSequenceStepConfigure could be muxing up ADC0 SS1&2 or they never really worked correctly.

FIFO values being read back are very low or even (rouge) since the TPTR index (next read) never matches consistently when checked against known index positions relative trigger source, PWM0 GEN0 (PWM_TR_CNT_LOAD). Fact is a GPTM set to trigger one shot (1.5us) after the beginning of each 80us period seems to gather more of ADC0 SS1 or 2 FIFO data but it is not capturing but very little data for application use. The sequencers have to work correctly no matter how they are being read, the ADCSSFSTAT TPTR/HPTR bits should not sit still for very long if the FIFO is actually sampling real time analog signals. CCS7 register view via ICDI (JTAG), custom PCB or EKXL/EVM produce the exact same results when back checking this issue.  

MAP_ADCSequenceConfigure(ADC1_BASE, 1, ADC_TRIGGER_PROCESSOR, 0);

/* Configure DCOMP after FIFO reads of analog data stops OSTAT/USTAT */
MAP_ADCSequenceStepConfigure(ADC1_BASE, 1, 0, PIN_MOSTEMP_LOW1);//AIN16
MAP_ADCSequenceStepConfigure(ADC1_BASE, 1, 1, PIN_MOSTEMP_HIGH1);//AIN9
MAP_ADCSequenceStepConfigure(ADC1_BASE, 1, 2, PIN_MOSTEMP_LOW1 | ADC_CTL_CMP0);
MAP_ADCSequenceStepConfigure(ADC1_BASE, 1, 3, PIN_MOSTEMP_HIGH1| ADC_CTL_CMP1 |
                                                         ADC_CTL_END | ADC_CTL_IE);


MAP_ADCSequenceConfigure(ADC0_BASE, 2, ADC_TRIGGER_TIMER, 1) //or ADC_TRIGGER_PWM0

/* Configure SS1 or SS2 for PWM0 trigger or GPTM trigger source */ 
MAP_ADCSequenceStepConfigure(ADC0_BASE, 2, 0, PIN_IPHASEA); //CH5
MAP_ADCSequenceStepConfigure(ADC0_BASE, 2, 1, PIN_IPHASEB); //CH1
MAP_ADCSequenceStepConfigure(ADC0_BASE, 2, 2, PIN_IPHASEC | ADC_CTL_IE); //CH2
MAP_ADCSequenceStepConfigure(ADC0_BASE, 2, 3, ADC_CTL_END);

BP101,
A couple of things I notice in your code. In the configuration of ADC1 sequence 1, you only have two ADC samples stored in the FIFO but only enable an interrupt for comparator 1. That interrupt will only happen under the circumstances defined in ADCComparatorRegionSet(). Unless you are emptying the FIFO in some place other than the interrupt routine, you will get FIFO overflows.

In the configuration of ADC0 sequence 2 you configure all four steps. The third step has the interrupt enabled. The fourth step does not specify a channel which by default will be channel 0. The first time you get an interrupt, there will be three samples in the FIFO. The second time there will be 4 because the channel 0 sample from the previous trigger will still be in the FIFO. Is this what you intended, or did you mean to configure only three steps?

Hi Bob,

Bob Crosby said:

the configuration of ADC1 sequence 1, you only have two ADC samples stored in the FIFO but only enable an interrupt for comparator 1. That interrupt will only happen under the circumstances defined in ADCComparatorRegionSet().

That is not exactly true and interrupt does occur at the END step defined (3), as IE should behave the same for any sequencer step configured IE. Perhaps your confusing comparator configure we can specify the region crossing drives an different interrupt event. The sample TC includes TS is based on the sequencer trigger source event. IE only occurs when last step conversion completes independent of digital comparator fault trigger if or when set for an interrupt event based on the conversion results data not being in the FIFO.

Bob Crosby said:

In the configuration of ADC0 sequence 2 you configure all four steps. The third step has the interrupt enabled. The fourth step does not specify a channel which by default will be channel 0. The first time you get an interrupt, there will be three samples in the FIFO

I tested ADC0 SS2 with END on step 2 (no step 3) getting the same results, e.g. no data in POP 16bit or 32bit array. Being aware of odd ADCSSFSTAT TPTR/HPTR behavior with FFIO results data the last step END without AINx does not default as CH0, agree it will if set END in any other step if AINx source is/was not specified. Again ICDI of EKXL/EVM struggles to read ADCSSFSTAT in all 8 sequencers where SS0 often only cycles from 0x0-0x6 when SS0 is configured for 3 steps. The reason it (TPTR) is bouncing, meaning it requires (two) transactions order to POP the FIFO contents into an C+ array, not just one as the datasheet states.

Tivaware ADCSequenceDataGet() covers over the TPTR errata by While loop POPs that can return incorrect results data in over/under flow conditions since it don't test TPTR for correct FIFO to AINx alignment. Suggesting TPTR errata since CCS debug ICDI register view (refresh continuous 100ms) can not properly indicate TPTR index even in 1 second intervals of sequencer trigger source for any configured sequencer steps. One WA is to POP bitwise OR compare of the step index (TPTR) in two transactions in the same array write directive. The actual FIFO step results data can not be confirmed unless by specific application operations such as digital readout shows a know voltage or FOC actually succeeds.

15.3.1:

When configuring a sample sequence, multiple uses of the same input pin within the same sequence are allowed. In the ADCSSCTLn register, the IEn bits can be set for any combination of samples, allowing interrupts to be generated after every sample in the sequence if necessary. Also, the END bit can be set at any point within a sample sequence. For example, if Sequencer 0 is used, the END bit can be set in the nibble associated with the fifth sample, allowing Sequencer 0 to complete execution of the sample sequence after the fifth sample.

After a sample sequence completes execution, the result data can be retrieved from the ADC Sample Sequence Result FIFO (ADCSSFIFOn) registers. The FIFOs are simple circular buffers that read a single address to "pop" result data. For software debug purposes, the positions of the FIFO head and tail pointers are visible in the ADC Sample Sequence FIFO Status (ADCSSFSTATn) registers along with FULL and EMPTY status flags. If a write is attempted when the FIFO is full, the write does not occur and an overflow condition is indicated. Overflow and underflow conditions are monitored using the ADCOSTAT and ADCUSTAT registers.

Bob Crosby said:

The fourth step does not specify a channel which by default will be channel 0.

Tivaware ADCSequenceStepConfigure() should not add a default CH0 channel on the last step specified END (only) it can be placed on any step. Datasheet does not imply or infer last step END must have AINx assigned or it defaults to CH0. Thought last step END can be seen in ADC_SSMUX with 0000 (4th Sample Select) that is the template for CCS debug register view GEL file results should be blank since END can be assigned to any step regardless of TPTR being erratic in ALL sequencers triggered via PWM0. or GPTM source.

However CH16 was originally on step 0 and was producing the same TPTR results not properly sequencing with the FIFO results data in the application retrieval of the POP (verified) TPTR data positions. That POP behavior seems to be AHB related or even CPU Thumb instructions are not producing correct alignments with the retrieved FIFO data and also effects CCS debug ADCSSFSTAT register view from GEL file transactions gone amuck. For instance WA to read step 0 data requires bitwise POP (TPTR=0x0 | 0x1) NOT (0x0) or even (0x1) fails to POP Any data into assigned array level unless it is very slow AHB retrieval in 1 second sample triggers. Even then the TPTR index skips past the last configured AINx source step no matter where END exists in any step.

I can see how anyone might assume CH0 was being appended 4th sample select. CCS debug register view Incorrectly indicates CH0 being configured for the END step 3. Fact is ADCSequenceStepConfigure() would then be bugged if it actually added an unassigned ANIx to step 3 past the ASSERT checks. Yet the ASSERT checks validity correct arguments exist in any given step, such that it rejects step 0 being configured without an AINx or any step other than the last sequencer step.

I double checked and the default 4th sample input select (register view) has 0x0000 no matter where END step is configured, e.g. last step being 2 or 3 with or without  AINx or END on 3rd samples, 4th sample input select always has 0x0000 showing.

Well at least I'm onto TPTR errata effecting all sequencers thus monotonic ratio metric slope can now be expected from the true FIFO read data INA240's created. The slope below builds from 0-235 -VREFP but a lot of zero acquisitions are also being read from FIFO or perhaps sampled in via GPTM trigger ADC0 SS1 or SS2. The mere fact RPM was always being reported result of FOC samples ADC0 SS0 step 1 being reconfigured on the fly during interrupt monitoring 3 AINx. That produced correct TPTR alignment only after 3rd sample step configured for END only. Scooby Doo has some work to do now!

The only bad part is the FIFO reading decreasing values refuse to drop below  VREFP start threshold, 1.0 amps. Notice as drag added on motor shaft the load current increases above 0-235 -VREP (yellow box) then falls to load release but only to the initial VREFP threshold of Cext charge sharing with CADC. Even adding a Min/Max for the current formula does not lower VREFP when load falls below the initial threshold or integers decrease below 235 decimal integer  @1.0 amp peak.

 

BP101 said:

The slope below builds from 0-235 -VREFP but a lot of zero acquisitions are also being read from FIFO or perhaps sampled in via GPTM trigger ADC0 SS1 or SS2

At full scale VREFP (3v3) repeating decimal 235 results POP reads ADC0 SS2 steps 0-2 (FIFO2), roughly 189mV. Those first few AIN acquisitions seem to defy 10x scope probe of analog signal, vertical attenuation 1x @10mV/CM.  That was the POP value of more than just first two samples @TSHN=0x2222, errata ADC#14 seems more widely spread than just the first two analog samples being incorrect. Also noticed numerous POP's of 0x0 were being acquisitioned between lower values when analog signal was well above 0v, near 3-4mV or more. Other words the AD converter is not settling to even 1/2 LSB upon first 100 or so sample triggers, according to the POP results of any modules FIFO.

Further example ADC#14; Two LM94022 AINx channels take near 6 seconds via GPTM initiated TriggerSourceProcessor() of ADC1 SS1 step 0/1 triggered intervals to produce correct and stable readings after MUC POR. Point is there is something wrong if ADC#14 is only supposed to occur on the first two samples in any given step.

Have to wonder why or what would cause all sequencers to have ADC#14 symptoms beyond the first two AD conversions being incorrect via CPU directive POP's of any FIFO. It seems like maybe CPU instruction decode is to blame!