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.

AM4379: FIFO behavior in ADC example

Part Number: AM4379

Hi,

to get the ADC interrupt running, I used Suresh' updated files which was very helpful.
That saved a lot of time - Thanks for that!

During further tests a question raised up concerning the FIFO behavior.

After reading the TRM chapter, I assume that every access to the FIFO register forces the sequencer
internally to provide data content of next enabled step. I have checked this and used the step ID tag enable.

But when accessing FIFO data first to get 12 bit data and then to extract 4 bit step ID tag using TI's functions,
2 consecutive register accesses are done. Is the result (data couple of value and step ID tag) consistent?
For that case I would expect expect that it's necessary to read complete 32 bit and mask afterwards.

From my point of view, explanations for FIFO behavior in general would be an important topic for the TRM.

Kind Regards,
Thomas

  • Hi Thomas,

    Are you concerned with the hardware behavior, or the behavior of a specific example from the PSDK which you modified using code you obtained on forum?

    Thanks,
    Frank

     

  • i Frank,

    Sorry, I expected that a 'related question' is always referenced to the origin topic.
    I'm referring to https://e2e.ti.com/support/processors/f/791/t/843907 describing the
    migration of starterware ADC example  pdk_am437x_1_0_15\packages\ti\starterware\examples\adc.

    My question is related to SW when accessing the FiFo content by reading the register value.

    I haven't found a description how it is managed to provide different channel data by only
    reading identical register all the time.

    I was wondering if there could be inconsistent data 'couples' if first 12 bit data value is read
    and 4 bit step ID tag afterwards (2 register accesses using TI functions).

    And I asked myself why there is a size of 64 entries with 16 bit for each FiFo.
    Is this size required for sampling by average?

    Regards,
    Thomas

  • Hi Thomas,

    Sorry for taking so long to respond.

    >> I assume that every access to the FIFO register forces the sequencer internally to provide data content of next enabled step.

    The FSM executes enabled steps in sequence after a SW or HW trigger. Enabled steps are executed, and ADC output samples are written to the FIFO selected for the each step.

    >> But when accessing FIFO data first to get 12 bit data and then to extract 4 bit step ID tag using TI's functions, 2 consecutive register accesses are done. Is the result (data couple of value and step ID tag) consistent? For that case I would expect expect that it's necessary to read complete 32 bit and mask afterwards.

    The Startware ADC example <PDK>\packages\ti\starterware\examples\adc (and Suresh's modified
    example) calls the function TSCADCFIFOADCDataRead() to obtain sampled data from FIFO0 and FIFO1 once the main thread detects the End Of Sequence interrupt has occurred. This function performed a 32-bit read of the selected FIFO.

    uint32_t TSCADCGetFifoData(uint32_t baseAddr, uint32_t fifoSel)
    {
        uint32_t fifoReg = 0;
    
        if (TSCADC_FIFO_SEL_0 == fifoSel)
        {
            fifoReg = ADC0_FIFO0DATA;
    	}
        else
        {
            fifoReg = ADC0_FIFO1DATA;
        }
    
        return(HW_RD_FIELD32((baseAddr + fifoReg), ADC0_FIFO0DATA_ADCDATA));
    }
    

    I agree two reads of the FIFO will return two different results, and the sampled data and sequence ID won't match for the two separate reads.

    >> I haven't found a description how it is managed to provide different channel data by only reading identical register all the time.

    Enabled steps write the selected channel output the selected FIFO (0 or 1). This is described in the TRM, 11.4 Operational Modes. A FIFO output is accessible from a single memory-mapped location. 

    >> I was wondering if there could be inconsistent data 'couples' if first 12 bit data value is read and 4 bit step ID tag afterwards (2 register accesses using TI functions).

    Yes, the data would be inconsistent for two different reads. Which TI functions are referring to?

    >> And I asked myself why there is a size of 64 entries with 16 bit for each FiFo.
    >> Is this size required for sampling by average?

    Each 16-bit entry contains a 4-bit step tag along with a 12-bit ADC sample.

    64 entries provides buffering for ADC samples to avoid overrun, i.e. the time constraint for the CPU or DMA reading the samples is relaxed.

    Averaging is performed before the data is written to the FIFO, please see this comment in the TRM, 11.3.3 Averaging of Samples (1, 2, 4, 8, and 16):

    If averaging is turned on, then the channel is immediately sampled again (up to 16 times) and final averaged sample data is stored in the FIFO.

    Regards,
    Frank

  • Frank,

    Thank you for the detailed answering of my questions.

    In addition to the topic:

    >> I was wondering if there could be inconsistent data 'couples' if first 12 bit data value is read and 4 bit step ID tag afterwards (2 register accesses using TI functions).
    Yes, the data would be inconsistent for two different reads. Which TI functions are referring to?

    I am referring to TSCADCGetFifoData() that you already mentioned. But I think a part of your answer is not correct:

    "This function performed a 32-bit read of the selected FIFO."

    This is the macro define:

    /**
     *  \brief This macro calls read field API for 32 bit register. It also
     *         frames the mask and shift from register field macro.
     *
     *  \param regAddr        Register Address.
     *  \param REG_FIELD      Peripheral register bit field name, from which
     *                        specified bit-field value has to be read.
     *  \return Value of the bit-field
     */
    #define HW_RD_FIELD32(regAddr, REG_FIELD)                                      \
        (HW_RD_FIELD32_RAW((uint32_t) (regAddr), ((uint32_t) REG_FIELD##_MASK),                   \
                              ((uint32_t) REG_FIELD##_SHIFT)))

    Calling this macro by TSCADCGetFifoData() will return a bit masked value, not complete 32 bit.
    So one will get either 12 bit data value or 4 bit step ID tag, not both when calling the function.

    Best regards,
    Thomas

  • Hi Thomas,

    Thanks, you're right about the TSCADCGetFifoData() function.

    Inspecting <PDK>/packages/ti/starterware/dal/tsc_adc_ss.c, I see two API functions are provided for reading the FIFO:

    uint32_t TSCADCGetFifoData(uint32_t baseAddr, uint32_t fifoSel)
    uint32_t TSCADCGetFifoStepId(uint32_t baseAddr, uint32_t fifoSel)

    Each of these functions will perform an independent 32-bit read from the FIFO. I don't see a function for a single 32-bit read and subsequent masking to extract the Step ID & ADC values as you suggest.

    Grepping the code for ADCCHNLID, I see there is other PDK code which uses this approach:

    <PDK>/packages/ti/board/diag/adc/src/adc_am65xx.c:192: stepID = ((fifoData & ADC_FIFODATA_ADCCHNLID_MASK) >>
    <PDK>/packages/ti/board/diag/adc/src/adc_am65xx.c:193: ADC_FIFODATA_ADCCHNLID_SHIFT);
    <PDK>/packages/ti/board/diag/adc/src/adc_test_v2.c:221: stepID = ((fifoData & ADC_FIFODATA_ADCCHNLID_MASK) >>
    <PDK>/packages/ti/board/diag/adc/src/adc_test_v2.c:222: ADC_FIFODATA_ADCCHNLID_SHIFT);
    <PDK>/packages/ti/csl/example/adc/adc_singleshot_test_app/adc_app.c:300: stepID = ((fifoData & ADC_FIFODATA_ADCCHNLID_MASK) >>

    From what I can determine, none of this code is intended for an AM437x platform. My suggestion would be to create something in tsc_adc_ss.c like this function:

    <PDK>/packages/ti/csl/src/ip/adc/V0/priv/adc.c:263:uint32_t ADCGetFIFOData(uint32_t baseAddr, uint32_t fifoNum)

    The Step ID & ADC sample value can then be extracted from the returned 32-bit value.

    I'll raise this issue with the development team so it's fixed in a future release.

    Regards,
    Frank