• State
  • Locked Locked
  • Replies 25 replies
  • Subscribers 34 subscribers
  • Views 2457 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.

TM4C129X , resetting the Timer2 value to zero, is hanging the TIVA.

Sanchit Mehra
Expert 1360 points

Hi,

I am using timer2, in tiva c series mcu.

This is my initialisation code:

UARTprintf("\nIR Noise Timer initialised ...\n");
ROM_SysCtlPeripheralEnable(SYSCTL_PERIPH_TIMER2);
TimerClockSourceSet(TIMER2_BASE,TIMER_CLOCK_PIOSC); // clock source
ROM_TimerConfigure(TIMER2_BASE, TIMER_CFG_PERIODIC_UP);
ROM_TimerLoadSet(TIMER2_BASE, TIMER_A,IR_NOISE_TIMEOUT);

and in someother interrupt when I try to clear the interrupt value using below code ....


ROM_TimerIntDisable(TIMER2_BASE, TIMER_TIMA_TIMEOUT);
ROM_IntDisable(INT_TIMER2A);
ROM_TimerDisable(TIMER2_BASE, TIMER_A);

HWREG(TIMER2_BASE + TIMER_O_TAV)=0; // added by sanme to debug the noise in IR

ROM_TimerLoadSet(TIMER2_BASE, TIMER_A, IR_NOISE_TIMEOUT); //load the timer in the timeout interrupt handler.

The code is hanging on the marked red line.

Please throw somelight on this , I have many timers in my code and I am resetting those timers also to zero using similar way.

I cannot figure out , why resetting the timer2 to zero, is hanging the tiva.

Thanks,

Sanchit Mehra

  • 0
    Expert 1360 points
    and this is happening after performing some iterations and not every time.
  • 0
    TI__Guru**** 244400 points
    Hello Sanchit,

    This is a known issue and we have mentioned that timers on TM4C129x must not be used with PIOSC as clock source. The timer must only be used with System Clock.

    Regards
    Amit
  • 0 in reply to Amit Ashara
    Expert 1360 points
    Hi Amit,

    The reason why I used PIOSC is that I need precision is the measurement of time in milliseconds between the two edges of pulses in IR.
    It is not possible to get the width b/w the two edges in IR.
    As per IR NEC protocol standard, the width between the edges specifies the 0 or 1.

    So to decode the width bw the rising and falling edges, I used PIOSC as a clock source.
    It was nearly not possible to measure the width accurately with MOSC as a clock source.

    Do you have any other way by which , width between two pulses could be measured ?

    Thanks,
    Sanchit Mehra
  • 0 in reply to Sanchit Mehra
    TI__Guru**** 244400 points
    Hello Sanchit,

    If the scale is in ms then System Clock can be used as well.

    Please note the MOSC is way more stable the PIOSC on TM4C

    Regards
    Amit
  • 0 in reply to Amit Ashara
    Expert 1360 points

    Thanks Amit,

    If the scale to be measured is  0.250 milliseconds.

    Will MOSC is precise enough to measure at this scale ?

    Thanks,

    Sanchit Mehra

  • 0 in reply to Sanchit Mehra
    TI__Guru**** 244400 points
    Hello Sanchit,

    When using the PLL the system clock is 120MHz (8.33ns) while the scale you are looking for is 250us. Definitely yes!

    Regards
    Amit
  • 0 in reply to Amit Ashara
    Guru 47900 points

    May I add - that for more than 30 years - proper (external) crystal controlled MCUs have (easily) met your timing requirements.
    It is (always) the "non-xtal controlled" internal oscillator which is challenged by accuracy & stability - over temperature, voltage & aging...

    Poster's grasp of, "external crystal or crystal oscillator vs. internal oscillator" appears "180° out of phase" w/reality!

  • 0 in reply to cb1
    TI__Guru**** 244400 points
    Hello cb1

    The internal oscillator even with the drift over time will still meet the requirement if sufficient guard band is created or if the trim is implemented?

    Regards
    Amit
  • 0 in reply to Amit Ashara
    Guru 27665 points
    It depends on whether the poster needs accuracy as well as the stated precision (It seems likely).

    IR probably needs accuracy similar to asynchronous serial, in which case I would say no. If it's similar to LIN then there is a possibility of it being sufficient.

    Robert
  • 0 in reply to Amit Ashara
    Guru 47900 points
    May I agree w/Robert - and stand by my assertion that External Crystal - along w/spec bypass Caps - most always outperforms MCU's internal oscillator. As I wrote - poster expressed an exactly opposite opinion - and was Dead Wrong!
  • 0 in reply to cb1
    Guru 27665 points
    Even a resonator would be more accurate. I would not expect otherwise until we see a micro with a built-in MEMs oscillator.

    Robert
  • 0 in reply to Robert Adsett
    Guru 47900 points
    Might it be that poster's, "New (MCU) world view" reflects that of another forum "trailblazer?"
  • 0 in reply to cb1
    Expert 1100 points

    Sometimes the Vendor's data (and by that I don't just mean TI) on the internal oscillator is a bit lacking, especially for things like performance and stability over temperature. By using a fully external oscillator it can make for an easier and more predictable design. Plus when you have a tried and tested oscillator it can be carried to the next design.

  • 0 in reply to Pete Carston
    Guru 27665 points
    Yes, what a vendor is not willing to commit to is sometime more important than what they do commit to.

    On a side note, it looks like MEMS oscillators are becoming inexpensive. A lot simpler than properly designing a xtal oscillator.

    Robert
  • 0 in reply to Robert Adsett
    TI__Guru**** 244400 points
    Hello cb1,

    I am not at all disagreeing with any of the arguments. For this specific application, the PIOSC would be good enough. For applications like USB, Ethernet or UART at high speed, definitely not.

    Regards
    Amit
  • 0 in reply to Sanchit Mehra
    Expert 1100 points
    Dear Sanchit,
    Again my exprience is that the external crystal performs very well for such short term timing durations and where absolute accuracy isn't required. You mention this:
    "and this is happening after performing some iterations and not every time."
    which makes me wonder are you incurring an accumulating error? Is the timing window so narrow as to be thrown out after so many bits have been processed?
  • 0 in reply to Pete Carston
    Guru 117855 points

    Pete Carston said:
    ...(one) wonders... are you incurring an accumulating error?

    Good that, Pete.   I suspect that those here before you "missed" that fact due to poster's proclamation of PIO's superiority.

    Now - one, "Not so" Good that.   You write, (I abbreviate/modify) "external xtal performs well...where absolute accuracy isn't required."  

    To me - this (almost) suggests that poster's belief of PIO "OVER" external Xtal (for accuracy) proves correct - which of course - it does not.   Might you clarify?

  • 0 in reply to cb1_mobile
    Expert 1100 points
    Not sure I understand what you're asking cb. Would you say again a different way.
  • 0 in reply to Pete Carston
    Guru 117855 points

    Pete Carston said:
    Again my exprience is that the external crystal performs very well for such short term timing durations and where absolute accuracy isn't required.

    Kindly view those words in highlight, Pete.   Especially the second grouping.   That "absolute accuracy isn't required" statement - which operates against your earlier mention of "external crystal" - suggests that PIO may be more accurate.  (than external xtal)

    That's patently untrue - I doubt it's what you meant.   Is this clearer?

  • 0 in reply to cb1_mobile
    Expert 1100 points
    Yes it is more clear. I see what you mean. What I meant was that the external crystal couldn't be depend on for things like precise frequency measurement or precise timing measurement, but that it's likely to be okay over the shorterm unless the oscillator design is pretty bad. That the problem is sometimes one of uncertainty in the hardware it's attached too. And yes the PIO looks to be less accurate. From a quick look at the datasheet it looks like it'll be drifty with temperature too, well pretty much everything is, but even more drifty if you see what I mean.
    Sometimes crystal oscillator design with discretes pays dividends as you know exactly what you've got. Then again pre-built modules can be good as they're encapsulated and usually (hopefully!) proven.
  • 0 in reply to Pete Carston
    Guru 117855 points

    OK - good - at least we've communicated.

    My point - all along - was that poster expressed (repeatedly) his belief that the PIO was more accurate than an external xtal.

    For those reading at home - that is NOT the case.   Viva the external xtal or xtal osc. - required when frequency stability is demanded!   (PIO - not so much - it's merit is cheap (free) and pcb space saving - which become meaningless should your communication link fail - due to that (slight) "savings!"

    Moral of this story - Accuracy & Design Robustness FIRST - Cost/Space Savings (maybe) later - as/if needed...

    If your design is flawed/buggy - you will be UNABLE to (even) "Give it Away - for FREE!"   Do consider that - too many do not!

  • 0 in reply to cb1_mobile
    Expert 1100 points

    "PIO - not so much - it's merit is cheap (free) and pcb space saving - which become meaningless should your communication link fail - due to that "savings!"
    Usually the merit of an internal oscillator is that it gets you a faster reliable start up if the device is asleep as you don't have to wait for an external crystal oscillator to start up, which might take hundreds or even thousands of machine cycles. In some very low power applications you can wake up, service a request and go back to sleep even before a crystal has sorted itself out. And if the crystal oscillator design is marginal it may never startup.
    I would guess that the OP has gone with the PIOSC due to it being called 'precision'.

  • 0 in reply to cb1_mobile
    Guru 27665 points

    Generally in order of increasing accuracy and increasing cost

    1. Internal Oscillator, generally 5-10%, varies with temperature and supply voltage
    2. Precision Internal Oscillator, also called a calibrated internal oscillator. Generally from 2.5% to 5% over a narrow temperature and voltage range.
    3. Resonator. Generally 0.1 - 0.5%. Good enough for some asynchronous communications protocols. A few pennies cheaper than a crystal
    4. Crystal or External Oscillator. On the order of 1 to 50ppm usually either for a crystal oscillator or an external oscillator. An external oscillator runs 3 to 5x the cost of a crystal generally but is easier to design and develop with. MEMS based oscillators are relatively new and coming down in cost.
    5. OCXO. specified in the ppb range. considerably more expensive than the others.

    LIN is designed to work with 1 and 2 but I don't think any other protocol is.

    Robert

  • 0 in reply to Robert Adsett
    Guru 47900 points
    Excellent - copy/pasted into our firm's, "tech resource" book - thank you, Robert.

    Do you foresee "mems" (downstream) landing w/in OCXO - and possibly reducing cost?
  • 0 in reply to cb1
    Guru 27665 points
    I've not been following details of the Si processing for MEMS (I do miss the EE Times print edition sometimes). I think the holy grail they are chasing is making the process compatible with the IC process so they can integrate with the processor.

    With that caveat, they are coming down in price and I suspect they will start encroaching on crystals. I can imagine the processes improving upon crystals and encroaching upon ocxo. Whether they can match the better ocxos with just process control and temperature compensation I do not know. I can also imagine them adding an integrated oven with the MEMs and approach OCXO performance that way. Whether either of those is economically or technically feasible I don't know.

    MEMS oscillators are one of those items I check once in a while to see if they are in a good enough price/performance range to use. It looks like they are reaching that point for me for some projects at least.

    Robert