This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

ADC0 FIFO reads via HWREG

Guru 55913 points
Part Number: TM4C1294KCPDT
Other Parts Discussed in Thread: EK-TM4C1294XL

Testing of ANIx inputs via EK-TM4C1294XL GPTM 102Hz generator via single test wire lead placed into each of 3 AINx inputs of SS1 reveals reading FIFO data fails via HWREG circular reads into specific array levels via Tivaware macro calls seem to fail. Although it seems SS1 step 0  had gone amuck, it was the HWREG reads of circular FIFO returning incorrect data upon END, IE of any last step minus a source pin. Other wise HWREG call fails to read any data if END IE exist on a step with a source pin. Although HWREG call reads sequencer FIFO into an dedicated array step, lastly drains any remained data it seemingly crosses with other sequencers data. Puzzling how FIFO filtering, checks, drains, overflow/underflow status type MACRO calls keeps any part of this train wreck from ultimate disaster is quite amazing that it simulates DSP signals like crazy. 

It would seem Tivaware skirts discovery of incorrect data from triggered reads of FIFO by doing BULK reads via ADCsequencerDataGet() of all steps placed into a single buffer array. Seemingly that is not maintaining compatibility of Stellarisware M3 codes that worked for reading single step FIFO data via migration to Tivaware and M4 Macro calls that seem to somehow cross FIFO data of the AD converter in the process.

The input source of AINx pin sampled via specific sequencer step as outlined in the datasheet seem to fail when HWREG reads sequencer steps are triggered by C+ directives on the circular FIFO.

How is cascading below capture possibly cross linking FIFO data between sequencers and arrays occurring from HWREG calls made into the sequencer FIFO? 

Why is there little to no 201Hz signal on one AINx input yet the other two have some resemblance of it yet at different  amplitudes occurring from the same source?   

Below 201Hz +3.2v GPTM AINx input source moved between 3 steps SS1 cause 3 different levels of FIFO data being returned. Even after adding dummy triggers (HWREG calls) to read back the 3 sequencer steps, the same amplitude of 201Hz GPTM data is not being returned as shown below. This issue is plaguing production of final product.

ui16ADC0DataRaw[1] = HWREG(ADC0_BASE + ADC_O_SSFIFO0);

/*************************************************************/

ulTemp=HWREG(ADC0_BASE + ADC_O_SSFIFO1);

ui16PhaseRaw[1] = HWREG(ADC0_BASE + ADC_O_SSFIFO1);


  • BP101,
    Did you check that the last conversion completed and there was new data in the FIFO before you did a direct read of the FIFO? (One reason we really push using TivaWare library routines is that many of these details are taken care of for you.)
  • Hi Bob,

    Of course the conversion completed as it trigged an NVIC interrupt from the FIFO sample ready END flag. Please read again the top post was re-factored after seeing some odd behavior. It would not be possible to do the complex sampling required for FOC commutation using Tivaware library calls that basically do the same HWREG macro calls. That HWREG macro seems to be failing to set the proper CPU instructions (pointers) that were functional for M3 sequencers.

    You may have noticed the last sequencer step was missing a source pin, configuration I posted was developed by TI engineers. That seems to be some kind of pointer failure to indicate where the FIFO data begins/ends via the Tail pointer. That Tail pointer is not being used by ADCsequencerDataGet() HWREG calls so that may be a bug from another point of view.

  • BTW: The first sequencer SS0 HWREG reads of step 0, 1 appear to be non impacted by tail pointer in HWREG calls. It is SS1 FIFO data that is being greatly impacted in this issue. Past M3 code ANIx samples were all part of SS0 so Stellaris engineers might not have picked up on this issue if it even existed back then.
  • BP101,
    TI has verified proper operation of the ADC and the FIFO. That along with the thousands of TM4C customers who are successfully using these devices suggest that the issue is most probably in your software or hardware. I cannot help you there. If you are able to create a stand-alone project, such as one that runs only on a launchpad, which demonstrates what you think is improper operation of the TM4C device, I will be glad to look at it.
  • Bob Crosby said:
    TI has verified proper operation of the ADC and the FIFO. That along with the thousands of TM4C customers who are successfully using these devices suggest that the issue is most probably in your software or hardware. I cannot help you there.

    How many customers are being bamboozled they are reading what they configured for sequencer 1 and above is more the question.

    If TI thinks (hw-adc.h) register offsets correct or made it part of the embedded MCU code it may explain why the head/tail pointers (ADCSSFSTAT) registers seem to not R/W correct index compounding the issue for array R/W above SS0 via HWREG access.

    Sequencer 0 step 0 FIFO data should not be readable from array[1] when it was not configured for step 1 has also been witnessed, indicating the index TPTR being questionable. The HWREG macros are part of Tivaware calls and need to properly retrieve data from any single sequencer in any order of the FIFO R/W process! It is not for the customer to fall victim of incorrect software functionality in or with the hardware to preform simple basic and necessary R/W sequencer operations.

    Again Tivaware has not proven correct ALL sequencers ability to R/W any single step and read circular FIFO data from said step thus matches the acquisitioned sample. That is typical sequencer functionality, not something we made up. The three cascading sample amplitudes being completely ignored rings a bell of concern, being amplitudes are far greater than +/-30 LSB!

    The problem is SS1 or SS2 Step 0 configured for AIN CH16 seems to cross data with another GPIO pins data ADCSSMUX 19:16 to 15:0 bit is being set

  • A quick test of alignment for the C+ array data locations remain consistent during HWREG triggered FIFO reads. Checking the tail pointer register 0x4003.8000 offsets (0x48, 0x68, 0x88, 0xA8) respectfully ADC0, FIFO 0-3 exactly matches the data storage location in the storage array[x]. The FIFO is 32bit with top 16 bits reserved so ui16 is less prone data errors >MSB 12 if we read results &0xFFF.

    Obviously 0xFF and 0xF are not the correct head or tail pointers for sequencer 1 or 2.

    if HWREG((ADC0_BASE + ADC_O_SSFSTAT2) & ADC_SSFSTAT1_TPTR_M == 0x0))
    {
      ui16ADCRaw[0] = HWREG(ADC0_BASE + ADC_O_SSFIFO1);
    }
    
    if HWREG((ADC0_BASE + ADC_O_SSFSTAT2) & ADC_SSFSTAT1_TPTR_M == 0x1))
    {
      ui16ADCRaw[1] = HWREG(ADC0_BASE + ADC_O_SSFIFO1);
    }
    
    if HWREG((ADC0_BASE + ADC_O_SSFSTAT2) & ADC_SSFSTAT1_TPTR_M == 0x2))
    {
      ui16ADCRaw[2] = HWREG(ADC0_BASE + ADC_O_SSFIFO1);
    }
    
    if HWREG((ADC0_BASE + ADC_O_SSFSTAT2) & ADC_SSFSTAT1_TPTR_M == 0x3))
    {
      ui16ADCRaw[3] = HWREG(ADC0_BASE + ADC_O_SSFIFO1);
    }

  • Originally I was thinking the index TPTR should be part of the FIFO address and not the SSFSTATn register address. On second thought after reading ADCSSMUX selects AINx 19:16 or 15:0 channels depending on EMUX0 bit being clear may better fit the CH16 issue of PK0 input data.

    Later we switched SS2 step 0 to use PK1 on CH17 to see if the floating voltage (158mV) discovered EKXL/EVM on CH16 PK0 changes.
  • 'WE???'      Did (more) than one witch - contribute to this 'thoughtful' brew?