• State Answer Suggested
  • Locked Locked
  • Replies 9 replies
  • Answers 1 answer
  • Subscribers 30 subscribers
  • Views 917 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

Can not poll ADC1 Trigger_Processor step set END.

Genatco
Guru 55913 points
Other Parts Discussed in Thread: LM3S8971

MCU: TM4C1294NCPDTI3

For some reason ADC1 SS1 FIFO1 will not sample data without IE being enabled in the sample sequence step along with END.

The END only step sample starts by a polling session calling the function which issues a Trigger_Processor and executes the sampled data in that same function. The sample is supposed to be ready by END alone and not require IE being present in the step for the sample to at some point exist in the FIFO. 

That polling process should not require IE or even an interrupt vector as the sample step is configured for END of sample is complete.

Currently have SS1 working by polling Trigger_Processor during TMR0A (1.6us interval) and sample step set END | IE.

The very odd part is also have to issue a second Trigger_Processor in the interrupt handler after extracting the FIFO data or Exception 11 occurs immediately after POR even with an interrupt priority set on SS1.

  • 0
    TI__Guru**** 244400 points
    Hello BP101,

    Without the IE bit being set how would you be knowing when the data is ready to be read?

    Regards
    Amit
  • 0
    Guru 55913 points

    Seems plausible the sample and hold time value when passed in the ADCSequenceStepConfigure() ui32Config variable is not getting set as expected?

    How could that macro possibly know where in the ui32Config value passed (ADC_CTL_SHOLD_4) will plug in, does it have that kind of ability? Likely not or at least it is not very obvious. Besides there is no sample data present on END alone so it stands to reason it is not setting the value passed in the step configure and is a broken linked macro.

    The alternative is more direct HWREG(ADC1_BASE + ADC_O_SSTSH1) = 0x4; Why is ADCSequenceStepConfigure messing with register if there is no way to determine the passed variable position in the configuration stream.

    void
ADCSequenceStepConfigure(uint32_t ui32Base, uint32_t ui32SequenceNum,
                         uint32_t ui32Step, uint32_t ui32Config)
    //
    // Set the sample and hold time for this step.  This is not available on
    // all devices, however on devices that do not support this feature these
    // reserved bits are ignored on write access.
    //
    HWREG(ui32Base + ADC_SSTSH) = ((HWREG(ui32Base + ADC_SSTSH) &
                                    ~(0x0000000f << ui32Step)) |
                                (((ui32Config & 0xf00000) >> 20) << ui32Step));

  • 0 in reply to Amit Ashara
    Guru 55913 points
    Hi Amit,

    By random polling the FIFO for any sampled data. Never would find any sample data in the FIFO, only 0x0000.0000.
    Oddly the ADC sequencers Stellaris LM3S8971 allow FIFO sample review with out IE when polling Trigger_Processor. The reason for switching over to polling FIFO mode, exception 11 just after POR and could not figure why.

    The older M3 ADC sequencers must not auto clear the FIFO value on every sample taken so there was data some of the times polled. The M3 didn't like IE with Trigger_Processor and would halt the MCU. The odd thing TMC4 sample trigger processor IE worked with UARTprintf(sample) until pushing that same (sample) into IOT cloud. Then exception 11 started. Who knew adding Trigger_Processor at the end of the IE called function would be the cure. Have witnessed past and strange behavior with Trigger_Processor.
  • 0 in reply to Genatco
    Guru 47900 points

    Here is code which ran upon LX4F: (and - this much agrees w/bp101's desire)

        ADCSequenceDisable(ADC1_BASE, 1);
        ADCSequenceConfigure(ADC1_BASE, 1, ADC_TRIGGER_PROCESSOR, 1);
        ADCSequenceStepConfigure(ADC1_BASE, 1, 0, PIN_SPEED_IN);
        ADCSequenceStepConfigure(ADC1_BASE, 1, 1, ADC_CTL_TS | ADC_CTL_END);  
        ADCSequenceEnable(ADC1_BASE, 1);
        ADCProcessorTrigger(ADC1_BASE, 1);

    Now we polled the ADC (based upon key "wraps") of "SysTick" which may "excuse" the lack of, "ADC_CTL_IE" in the above code...

    Now Amit (earlier) asked, "How would we know that ADC Data was ready?"

    And the answer is we don't - but in this case we test w/in the function called by the "key wrap count of SysTick."   And - our "poll" of this ADC function is at a rate which is unlikely to be "too soon" - and that's tracked (thus can be adjusted) by 2 counters (bad & good spd).

    if(HWREG(ADC1_BASE + ADC_O_SSFSTAT1) & ADC_SSFSTAT1_EMPTY)

    {

    ulData1 = 0XABCD;

    bad_spd ++;

    }

    else

    {

    good_spd ++;

    ulData1 = HWREG(ADC1_BASE + ADC_O_SSFIFO1);

    }

    // Retrigger ADC Sequence 1

    HWREG(ADC1_BASE + ADC_O_PSSI) |= ADC_PSSI_SS1;

    Surely this (old) code "escapes" the "Ban DRM" ruling as it was self-developed - and no TI staff were harmed (nor tormented) in its creation...

    Believe this 5+ year old code meets BP's: Poll & ADCProcessorTrigger() demand...

    Note: I did not - and would not - tick, "Suggested Answer!"   Have no idea why that's appeared...

  • 0 in reply to cb1
    Guru 55913 points
    Absent Systick could be why other timer also a very fast timer (1.6us) was somehow missing the FIFO samples. Or perhaps the sample hold value TM4C was not being set after recently incorporating hold value into ADCSequenceStepConfigure.

    Agree Amit makes a very good point order to synchronize with sample END times the IE vector call is most prudent.
  • 0 in reply to cb1
    Guru 55913 points
    Wonder why triggering from any timer the very first and repeating Trigger_Processor events doesn't seem to capture the FIFO data. Notice the cure, that same Trigger_Processor at the end of the function. My first WA was configured Trigger_Processor in the polling interval start and not at the end of the function. Odd thing is that same order Trigger_Processor works great with two other sequencers where IE is also set.
  • 0 in reply to Genatco
    Guru 47900 points

    BP101 said:
    Notice the cure, that same ADC_Trigger_Processor at the end of the function

    That's very well noted BP101!   Indeed - much like your fan control - we don't require motor speed reads faster than ~100mS intervals - thus inserting that ADC Trigger (after) the most current conversion starts the ADC process (again) immediately - and may lead to the highest possible "Polled" conversion rate.   (ALL Interrupts - ALL the Time - proves not (always) best/brightest...)

    As the code (above) reveals - that "ADC_CTL_IE" is not a (universal) requirement - and adds complexity where (as KISS dictates) such is not always needed - nor welcome...

  • 0 in reply to Amit Ashara
    Guru 55913 points
    Hi Amit,

    I see some of the problem that each individual step in the sequence depth needs to have THn and Nsh set. Originally only set for one step deep in { HWREG(ADC1_BASE + ADC_O_SSTSH1) = 0x4; } So 0x44 would be needed when 2 steps deep and 0x44444444 if 8 steps deep.

    Adding (ADC_CTL_SHOLD_4)one time into the ADCSequenceStepConfigure() for all steps should do the same if the macro is some how concatenating this ui32Config value passed to it. How the macro knows that (ADC_CTL_SHOLD_4) is the value to assign each step is puzzling.
  • 0 in reply to cb1
    Guru 55913 points
    > (ALL Interrupts - ALL the Time - proves not (always) best/brightest...)

    Have to agree nothing flawed in that logic. I was triggering that first sample (yours ADCINIT) in the start of the polling cycle and never again. Seems that should have caught something at 1.6us polling interval but zippo was being returned.