• State TI Thinks Resolved
  • Locked Locked
  • Replies 8 replies
  • Answers 2 answers
  • Subscribers 82 subscribers
  • Views 696 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.

TMS320F28027: why does switching execution context in interrupt routine reduce ADC precision??

Joern Rasmussen
Prodigy 60 points

Part Number: TMS320F28027

Hej allesammen,

I have a very interesting problem that I don't really quite grasp:

Observation:

I have a timer-interrupt routine that runs every 500us. Due to the frequency and the number of calculations, I put the interrupt routine into ramfuncs section:

#pragma CODE_SECTION(myVerySpecial_Timer2_Isr, "ramfuncs");

Now inside that routine I sample a GPIO using 

GPIO_getData(myGpioHandle, GPIO_Number_3)

Since this GPIO_getData function is located in flash and the compiler has probably no reason to inline it,
the CPU switches the context from RAM to FLASH.

Now, I have some ADC conversion routines going on during the meantime.
The ADC conversions jitter around a few millivolts with GPIO_getData !!!

Solution:

I replaced the GPIO_getData functions with direct register reading.
Same functionality, but now I have no Jitter anymore!

How can it be that replacing GPIO_getData solves my issue??
Does anyone have had similar observations?

Thank you for reading, looking forward to hear about your insights.

  • 0
    TI__Mastermind 32995 points

    Hi,

    I am not sure what you mean by ADC conversion routines going on during that time. Can you please explain?

    What GPIO are you reading? Could that affect the ADC results?

    Also, you can map your GPIO_getData function to ramfuncs as well and have it run from RAM. Or you can inline it as you mentioned.

    Hope this helps.

    sal

  • 0 in reply to Sal Pezzino
    Prodigy 60 points

    Hej Sal,

    Thanks for your reply.

    Well, I have HALL sensors on AIO6 and AIO4, the GPIO I am polling is on GPIO3. In the TSSOP housing, the pins are considerably far away, so they should not have any influence. Also my solution does not back this hypothesis.

    Sure I can map the GPIO_getData to ramfuncs or inline it.. but I would just rather not just solve that problem but understand why switching the context has such an influence on ADC conversion. I guess this "problem" requires very deep insight into the processor architecture.
    Maybe reading the flash draws just a little more current and doing it in a pulsed manner influences ADC reference voltage or something..
    It's just puzzling.. :-)

    thanks for your help,

    Jörn.

  • 0 in reply to Joern Rasmussen
    TI__Mastermind 32995 points

    Hi,

    "Maybe reading the flash draws just a little more current and doing it in a pulsed manner influences ADC reference voltage or something.." 

    This was my initial thought. 

    Let me request an ADC expert to consider this matter.

    sal

  • 0 in reply to Sal Pezzino
    TI__Guru 62975 points

    Jörn,

    I would not expect significant degradation in ADC performance. Most applications that use ADC in the field will also include access to flash in some form or another.

    Is this running on a custom board?  Is there similar degradation on a TI EVM?

    -Tommy

  • 0 in reply to tlee
    Prodigy 60 points

    hi Tommy.

    sorry to answer so late, I've been abroad.
    Yes, this is a custom board. And no, unfortunately I have no TI EVM for the TMS320F28027.

    Maybe I have some weird sideeffects in my code that are the root cause.
    I just have absolutely no clue what that could be...

  • 0 in reply to Joern Rasmussen
    TI__Guru 62975 points

    Joern,

    I suspect that it is more likely a hardware board issue rather than the software itself.  For example, an undersized 3.3V supply will appear to work fine until the software enables simultaneous circuits which may result in a power droop.

    -Tommy

  • 0 in reply to tlee
    TI__Guru 62975 points

    Joern,

    It has been a while since your last update. I assume that you were able to resolve your issue.

    If not, please reply to this thread. If the thread has locked due to timeout, please create a new thread describing the current status of your issue.

    -Tommy

  • 0 in reply to tlee
    Prodigy 60 points

    Hej Tommy,

    Unfortunately, I've not been able to dig down to the root cause of the observed problem/behaviour.
    As I have already resolved the problem, the topic remains academic and I am forced to put it on the
    "I will investigated that in detail later, when I have time to do so"-queue.
    Thanks to all of you for the suggestions and insights.

    Joern.