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.

TMS320F2802: ADC SOC0 and internal temperature sensor

Guru 10980 points
Part Number: TMS320F2802

Hi,

[Question1]

I use an internal temperature sensor to monitor the temperature, but sometimes it captures abnormal values.

Looking at the errata, it says to lengthen the sampling period from the error "ADC: Temperature Sensor Minimum Sample Window Requirement".

I increased ACQPS from 6 to 63, but the situation doesn't improve. 

Please let me know if you have any countermeasures.

 

[Question2]

Does the error "ADC: Initial Conversion" described in Errata (sprz292s) of TMS320F2802x exist even on the devices currently on the market?

 

Thanks,

Koki

  • Hello,

    A subject-matter expert reply your question. However, we have been dealing with inclement weather and power outages in the area and responses may be slow.

  • Koki,

    Yes, this errata applies to devices currently in production. 

    If you are only sampling the internal temperature sensor with the ADC you will need to perform a dummy sample on this input to avoid the ADC first sample issue.  In this case there is no need to shorten the sample and hold window of the temp sensor sample as this meets the other workaround listed for the temp sensor min sample case.

    Let me know if this addresses your issue, or you still see abnormalities with the workaround in place.

    Best,

    Matthew  

  • Hi, Matthew  

    Currently, I'm taking measures for the contents surrounded by the red frame, but the situation is not improve.

    Could you tell me more specifically what I need to do?

     

    Best,

    Koki

  • Koki,

    For the purpose of debug could you try the workaround #1 and see if it resolves the issue you see?  #2 will work, but there are also restrictions on the valid values for ACQPS listed in the TRM.  I'd like to make sure we can get good results from #1 and then we can get the right ACQPS to make #2 work.

    Best,

    Matthew

  • Hi, Matthew 

    > there are also restrictions on the valid values for ACQPS listed in the TRM.

    I couldn't find a description in TRM about the limits of ACQPS. Where on what page is it listed?

     

    I have already verified # 1.

    It is incorporated into SOC14 and SOC15 for double-sampling. Both may be abnormal.

    # 2 I increased ACQPS from 6 to 63, but the value doesn't improve.

     

    Currently, abnormal output is avoided by detecting when the reference temperature is exceeded 10 times in a row.

    Please let me know if you have any countermeasures.

     Best,

    Koki 

  • Koki,

    Would you be able to post 10 consecutive values from the temp sensor for just SOC15(discard SOC14), for me to see the magnitude of the difference.  If its simpler you could make all conversions SOC0-15 read the temp sensor (and then trigger them all) and report out SOC1-15.

    If you could also attach the C file where you've set up the ADC I can take a look at that as well.

    Can you also comment on the resolution in degrees C that you are trying to use in your system?  i.e. you need to detect a 10 deg rise/fall, etc.

    Best,
    Matthew

  • Matthew

    I'm sorry for being late.

    >Would you be able to post 10 consecutive values from the temp sensor for just SOC15(discard SOC14),

     Since the value of the anomaly is rare, I attach the graph of CCS instead of the conversion result of 10 consecutive pieces.

      

     ■Nomal value

      AdcResult.ADCRESULT15(=temp) = 1914~1921

      degC=40~42

      

     ■Abnormal value

      AdcResult.ADCRESULT15(=temp) = 4090

      degC=429

     

     ■temp graph

      If an abnormal temperature is detected, the operation will stop.

      Therefore, the image remains anomalous value, but the anomalous value occurs temporarily.

     

     

     ■ degC graph

     

     

     

      

    >If you could also attach the C file where you've set up the ADC I can take a look at that as well. 

     Attach the main.c file that sets up the ADC.

    HVLLC-Main.c
    Fullscreen
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    //----------------------------------------------------------------------------------
    // FILE: HVLLC-Main.C <Refine>
    //
    // Description: Half-Bridge LLC Resonant DC/DC Converter with Synchronous Rectification
    //
    // Version: 1.0
    //
    // Target: TMS320F2802x (PiccoloA),
    //
    //----------------------------------------------------------------------------------
    // Copyright Texas Instruments 2004-2010
    //----------------------------------------------------------------------------------
    // Revision History:
    XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

     

    >Can you also comment on the resolution in degrees C that you are trying to use in your system? 

     ■Usage of temperature sensor

      PWM output stop processing is performed when C2000 exceeds 120 ℃.

     

     ■Resolution in degrees

      1℃ is sufficient for the resolution.

      

    Please let me know if you need any additional information.

     

    Best,

    Koki

  • Koki,

    Thanks for providing more details.  I had not expected that the error term on the temp sensor was a saturated ADC conversion; the temp sensor should not be capable of providing this kind of output voltage to the converter(as the temperature calculation bears out).  When there is an issue, does the conversion always go to rail/4095?  This is not a behavior I have seen even using the temp sensor out of spec.

    Can you comment on the pin ADCINA5 and what it is connected to externally?  I want to rule out a over-voltage on this pin somehow corrupting the voltage output of the temp sensor before it gets to the ADC.

    Is it possible that the "temp" variable gets overwritten, and the conversion is in the right range?  One option would be to feed ADCRESULT15 directly to the temp sensor function and see if the issue goes away.  I realize that "temp" us used immediately, but would be good to check this out.

    Best,
    Matthew

  • Hi, Matthew

    Thank you for your prompt response.

      

    >When there is an issue, does the conversion always go to rail/4095?

    →The ADC conversion result has various abnormal values. (For example temp = 2170)

      

    >Can you comment on the pin ADCINA5 and what it is connected to externally?

    → TMS320F28027 does not have ADCINA 5 pin.

     

    >Is it possible that the "temp" variable gets overwritten, and the conversion is in the right range?

    >One option would be to feed ADCRESULT15 directly to the temp sensor function and see if the issue goes away. 

    →The temperature was calculated using the ADC conversion result directly.

     However, the situation is the same, and abnormal value occur.

     

    Thanks,

    Koki

  • Koki,

    I'm discussing this internally with some other team members to see if they have seen this behavior from the temp sensor.  I may need an extra day or 2 before my next reply while I get more data.

    Best,

    Matthew

  • Matthew

    thanks, I am waiting for your reply.

    Best,

    Koki

  • Koki,

    I've looked through the code you attached a few posts up, can you also attach a screen grab of all the ADC registers after the initial setup is complete?  I want to verify exactly how the ADC is configured before you start the control loops/sampling.

    Once this is set, can you also confirm it doesn't get changed during run time, i.e. all that happens is ADC triggers and register reads?

    Finally, if you could give an idea of the different trigger sources and how often they would occur, i.e. SOC1 is tied to PWM SOCA and it happens every 10kHz, etc.

    Best,

    Matthew

  • Hi, Matthew

    >you also attach a screen grab of all the ADC registers after the initial setup is complete?

    The following are the ADC register settings after ADC initialization.

     

    >can you also confirm it doesn't get changed during run time, i.e. all that happens is ADC triggers and register reads?

    The following are the ADC register settings during ADC conversion.

    ADCCTL1 ・・・ constantly changing (lower byte E5 is fixed)

    ADCINTFLG ・・・0x0000

    ADCINTOVF ・・・ 0x0080

    SOCPRICTL・・・ constantly changing (lowest byte 0 is fixed)

    ADCSOCFLG1 ・・・constantly changing

     

    >if you could give an idea of the different trigger sources and how often they would occur,

    >i.e. SOC1 is tied to PWM SOCA and it happens every 10kHz, etc.

    I changed from a software trigger to a PWM4 (fixed at 100kHz) trigger.

    It was operated for 1 hour, but no abnormal value occurred.

    At the time of software trigger, it occurred in a few minutes.

     

    Thanks,

    Koki

  • Koki,

    Thanks for collection this information, it helps alot.  I believe I know what is happening to cause the "random" bad temp sensor reading.

    In your system(and many control systems) there are usually multiple sampling domains, such that the order of conversions may not be consistent as the time domains of the sampling frequencies move about one another.

    In the case of the temp sensor, when it is on its on SW trigger schedule you have to account for the initial conversion sample, so you need to double sample the channel.  From your code above, this is:

    There is potential for one of the other ADC ISRs to come between these instructions, which would negate the dummy sample and could make SOC15 a first sample from ADC idle.  This will cause SOC15 to have an inaccurate reading.

    When you SOC14/15 into the same ePWM trigger as the other SOCs you guarantee that the ADC will not stop until those last channels are converted.

    I believe that if you replaced the lines above with

    AdcRegs.ADCSOCFRC1.all = 0xC000;

    it would also have the same effect, since the force register would get written with both bits at the same time.

    Let me know if you have more questions, but either the method you've implemented previously or the above should solve this issue.

    I really appreciate your patience and help in working with me to solve the issue

    Best,

    Matthew

  • Hi,

    Thank you for your polite response.

    I changed the description you provided.

    The frequency of abnormal values being detected has decreased, but it still occurred once after about 4 hours of operation.

    Is there anything I can do to improve this?

     

    Depending on the timing of the ADC end interrupt, SOC14 may not be the dummy sample and SOC15 may be the first sample.

    Therefore, anabnormal value was detected.

    Is my perception correct?

    Also, could you tell me in detail the flow when an abnormal value is detected?

     Ex) SOC14 start → SOC15 start  ...

     

    I couldn't understand the next line very much.

    want to understand the cause firmly, so please explain the following line in detail.

     > In your system (and many control systems) there are usually multiple sampling domains, 

     > such that the order of conversions may not be consistent as the time domains of the sampling

     > frequencies move about one another.

     

    Thanks,

    Koki

  • Hi Koki, Friday was a TI holiday and Matt is out of the office today, he should be back tomorrow with a response.  Thank you for your patience.

    Regards,

    Joe

  • Hi, Joe

    OK, thank you for contacting!

    Koki

  • Koki,

    Your understanding of SOC15 sometimes becoming the 1st sample is correct, and if that happens it will be impacted by the errata we've discussed earlier in the thread.

    What was meant by the different sampling frequencies, that there will be inconsistent behavior when SOC15 is the 2nd sample or the 1st sample depending on when the other SOCs get triggered by the ePWM(in your system).

    When you mention that when you implemented the previous workaround, and you still see the issue after 4hours, was this writing the SOC.all = 0xC, or associating the Temp sensor with the ePWM triggers?

    Best,

    Matthew

  • Matthew

    AdcRegs.ADCSOCFRC1.all = 0xC000;

    After operating for 4 hours with the above settings, an abnormal value was detected once.

    Thanks,

    Koki

  • Would it be possible to place the register write inside one of your PWM ISRs or PWM update functions?  I'd like to see if we can guarantee the timing of the temp sensor sample in relationship to the update loop frequency to try and avoid any potential disruption in the sample order.

    The alternative would be to move the SOC14/15 trigger to one of the PWMs as you did earlier.  This would eliminate the possibility of the SW write getting co-mingled with the other SOC from the PWM modules.

    Best,

    Matthew 

  • Hi, Matthew

    I don't really understand what you say about the ADC operation flow when an error occurs.

    Now, SOC14 and SOC15 are double sampled.

    SOC14 has a higher priority than SOC15, so sampling starts first.

    The Round Robin pointer indicates the channel that is being converted or has been converted most recently.

    Therefore pointer indicates SOC14 during conversion, and when SOC14 is completed, pointer indicates SOC15 and starts conversion

    Is this perception correct?

    If it is correct, in the case of double sampling, I think that the conversion in the order of SOC14 → SOC15 always holds.

    ============================================================

    AdcRegs.ADCSOCFRC1.bit.SOC14 = 1; // SOC14 SW trigger

    AdcRegs.ADCSOCFRC1.bit.SOC15 = 1; // SOC14 SW trigger

    while(AdcRegs.ADCINTFLG.bit.ADCINT8 == 0) {} // SOC15 SOC end wait

    AdcRegs.ADCINTFLGCLR.bit.ADCINT8 = 1; // ADCINT8 FLG clear

    temp = AdcResult.ADCRESULT15; // Get temp sensor sample result from SOC15

    ============================================================

     

    Would it be possible to place the register write inside one of your PWM ISRs or PWM update functions? 

    Sorry, please tell me the procedure in a little more detail.

    Thanks,

    Koki

  • Koki,

    Your understanding of the ADC state machine is correct.  However, since some of the ADCSOCs are tied to PWM triggers directly there is possibility that these come asynchronously to the the CPU/SW triggers that rely on the C28x executing code to latch the SOC14/15 to the ADC state machine.

    In this manner it would be possible that a PWM triggered SOC comes in between the temp sensor SOC14 and SOC15.  I had hoped that using:

    AdcRegs.ADCSOCFRC1.all = 0xC000;

    would eliminate the possibility of this happening, but while it reduced the occurrence of the bad temp sensor reading significantly it did not remove it completely(I believe you saw bad value after 4hr of running). 

    I believe there is still a chance that SOC14/15 are getting set while other SOCs are still pending, or other SOCs are getting triggered from the PWM modules which are on their own time bases vs your linear C code.

    I think there are two options to try:

    1)Switch the trigger source for SOC14/15 from SW trigger one of the already used PWM triggers:  This would ensure that these get latched and serviced in the prescribed order always, since they would get triggered from a known time based, i.e. the PWM compare value.  The downside to this is that perhaps you are keeping the ADC busy for 2 sample longer, and it could impact your other PWM triggers.  Depending on those update rates it may not matter.  This would be the cleanest soln if it is OK for your system.

    2)Place the SW trigger/write inside one of the PWM ISRs(assuming you have ISRs tied to some PWM events for updates).  This would guarantee a synchronous write of the triggers with respect to the other events in the system.  If you don't need to sample the temp sensor this often you could insert a compare of a local counter to limit the ADC usage here, in case of any ADC BW need we may be taking.  Something like every 100th time the ISR is called, go ahead and force SOC14/15.

    Let me know if the above provides additional clarity on what I think the issue may be and the soln.

    Best,

    Matthew

  • Hi, Matthew

    since some of the ADCSOCs are tied to PWM triggers directly there is possibility that these come asynchronously to the the CPU/SW triggers that rely on the C28x executing code to latch the SOC14/15 to the ADC state machine.

    I don't understand the quoted sentence. Please explain in detail.

    I'll also try two solutions and I'll tell you the results later.

    Thanks,

    Koki

  • Koki,

    For instance you have SOC0 and SOC1 configured to trigger from ePWM1 ADCSOCA, SOC2 and SOC3 from ePWM5 ADCSOCB, SOC4 and SOC5 from ePWM7 ADCSOCB, etc. 

    All these triggers are potentially different points in time, and not necessarily sync'd with the SW force you use for SOC14/SOC15 in the CPU domain.  If these are non integer multiples of one another they will shift in and out of phase and potentially overlap. 

    To be fair, this wouldn't be an issue if we didn't have the first sample errata on this device, but since that exists it presents some unique problems here.

    Best,

    Matthew

  • Hi, Matthew

    By using the PWM trigger in (1), the abnormal value detection was resolved.

    Thank you again for your polite response.

    Koki