• State Resolved
  • Locked Locked
  • Replies 12 replies
  • Subscribers 32 subscribers
  • Views 2388 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.

LM4F timer module ‘wait-for-trigger’ daisy-chain mode

Jim_McCormack
Intellectual 260 points


 Hi All,

                LM4F timer module ‘wait-for-trigger’ daisy-chain mode.

I am using the Stellaris LM4F120 LaunchPad Evaluation Board (EK-LM4F120XL).

I cannot get a timer to wait on the trigger reliably - sometimes it does, sometimes not. First, some relevant issues/posts I have found:

#1 There is a LM3S post on daisy-chaining timers (http://e2e.ti.com/support/microcontrollers/stellaris_arm/f/471/p/168248/663408.aspx#663408) and an LM3S Errata (wait-on-Trigger does not assert unless the TnOTE bit is set in the GPTMCTL register). I tried this fix but no luck – maybe not relevant for the LM4F.

#2 There is a post on daisy-chaining timers (http://e2e.ti.com/support/microcontrollers/tiva_arm/f/908/t/237672.aspx) for an LM4F232 which did not resolve my issues here.

#3 There is a known issue with PWM mode in the Errata: GPTM#04 — “Wait-for-Trigger Mode is not Available for PWM Mode”.

Here is my simple example. I am trying to have a one-shot timer2 trigger a periodic timer3. The timers run slowly for easy debugging  :-

      // [In startup, clk=80MHz]
       SysCtlPeripheralEnable(SYSCTL_PERIPH_TIMER3) ;
       SysCtlPeripheralEnable(SYSCTL_PERIPH_TIMER2) ;
      // ...

 

      // Repeat from here
      TimerConfigure(TIMER3_BASE, TIMER_CFG_A_PERIODIC) ;
      TimerConfigure(TIMER2_BASE, TIMER_CFG_A_ONE_SHOT) ;

 

      // Period 5 seconds
      unsigned long uT = SysCtlClockGet() * 5 ;

 

      TimerLoadSet(TIMER3_BASE, TIMER_A,  uT) ;
      TimerLoadSet(TIMER2_BASE, TIMER_A,  uT) ;
      // [Clears Raw Interrupt Status TATORIS, time-out interrupt occurred]
      TimerIntClear(TIMER3_BASE, TIMER_TIMA_TIMEOUT) ;
      TimerIntClear(TIMER2_BASE, TIMER_TIMA_TIMEOUT) ;

 

      // Once enabled, T3 should wait on T2 to timeout
      TimerControlWaitOnTrigger(TIMER3_BASE, TIMER_A, true) ;

 

      // Display timer values every 1sec
      for(i = 0 ; i < 15 ; i++)
      {
            UARTprintf("[%02d] T2=%09u, T3=%09u\n",
                  i,
                  HWREG(TIMER2_BASE + TIMER_O_TAV),
                  HWREG(TIMER3_BASE + TIMER_O_TAV)
            ) ;

 

            Delay(1.0f) ;

 

            if (i == 0)
                  TimerEnable(TIMER2_BASE, TIMER_A) ;
            else
            if (i == 2)
            {
                  DumpRegisters(TIMER2_BASE) ;
                  DumpRegisters(TIMER3_BASE) ;
                  TimerEnable(TIMER3_BASE, TIMER_A) ;
            }
      }

 

      TimerDisable(TIMER2_BASE, TIMER_A) ;
      TimerDisable(TIMER3_BASE, TIMER_A) ;

 

 

After a board ‘reset’ I get the following results :-

On the first run, timer T3 is enabled at t=2s, and it waits correctly on T2 to timeout at t=5s :-

[00] T2=400000000, T3=400000000 [Enable T2]
[01] T2=399999477, T3=400000000
[02] T2=319990121, T3=400000000 [Enable T3]
[03] T2=196295683, T3=400000000
[04] T2=116285767, T3=400000000
[05] T2=036275937, T3=400000000
[06] T2=400000000, T3=356266393 << Correct, T3 starts
[07] T2=400000000, T3=276256355
[08] T2=400000000, T3=196246361
[09] T2=400000000, T3=116236443
[10] T2=400000000, T3=036226611
[11] T2=400000000, T3=356217008
[12] T2=400000000, T3=276206896
[13] T2=400000000, T3=196196822
[14] T2=400000000, T3=116186828

 

But on the second run T3 starts immediately without waiting:-

[00] T2=400000000, T3=400000000 [Enable T2]
[01] T2=399999477, T3=400000000
[02] T2=319990121, T3=400000000 [Enable T3]
[03] T2=196295687, T3=399999310 << Not correct
[04] T2=116285769, T3=319989392
[05] T2=036275981, T3=239979604
[06] T2=400000000, T3=159970138 << T3 should start here instead
[07] T2=400000000, T3=079960276
[08] T2=400000000, T3=399950613
[09] T2=400000000, T3=319940577
[10] T2=400000000, T3=239930583
[11] T2=400000000, T3=159920565
[12] T2=400000000, T3=079910625
[13] T2=400000000, T3=399900884
[14] T2=400000000, T3=319890770

 

Running instead in the debugger, sometimes the result is reversed, i.e. the first time around, T3 does not wait, the second time it does, sometimes neither. This is curious. But from a ‘reset’ on the board it always gives the same result as shown.

There is a dump, see below, of all the registers (just before timer 3 enable) for timers 2 and 3, but there are no obvious relevant differences between the two runs. Only the precise timer values differ by just a few ticks (as we would expect). The mode, control and interrupt registers are identical.

I tried clearing bits not needed in registers GPTM Timer A/B Mode. Timer 2 requires only GPTM Timer A Mode = 0x1 (TAMR=one-shot), and timer 3 needs only GPTM Timer A Mode = TAWOT (wait-on-trigger) and TAMR=0x2 (periodic), GPTM Timer B Mode = 0 for both. But the result is exactly the same.

I tried different timers, and wide timers too (in 32-bit mode), again same result. I removed all other code except that needed for UARTprintf(), Delay() and DumpRegisters(). I switched out the DumpRegisters() call (just in case this was corrupting something), same result. I tried different combinations of one-shot and periodic modes. Interestingly, the one-shot to one-shot case works most of the time, but it sometimes fails. I have looked for any other code that might be corrupting the timers.

I moved the timer3 enable call (TimerEnable()) to before the timer2 enable (as suggested in post #2 above), but, same behaviour – sometimes timer3 waits, sometimes not.

So my questions are:

-          Has anyone out there used timer daisy-chaining on the LM4F or equivalent? A ‘yes, it works for such-and-such’ would be very helpful to know.

-          If timers 2 & 3 are in the same state (just before enabling timer 3) for both runs (see below), what could be changing the timer behaviour? Are there some other registers which control timer behaviour?

Thanks for any help ...

Jim

---

Device info: ID’s are DID0: 0x18050003, DID1: 0x1004602c, device part marking:  980 YF LX4F120H5QRFIGA3 29C1ZFW G4.

[The ‘X’ in LX4F120H5QR stands for ‘experimental’ release (significant?), ‘A3’ is the revision.]

Stellaris Firmware Development Package, revision 9453.

Code Composer Studio, Version: 5.2.1.00018.

 

 

These are the timer module registers just before enabling timer 3 (see code above, DumpRegisters()) :-

-------------
First run
-------------

 

TIMER2_BASE [0x40032000]
Value       Value (binary)                           Offset  Register Name
0x00000000, 0000 0000 0000 0000 0000 0000 0000 0000, [0x000] GPTM Configuration
0x00000221, 0000 0000 0000 0000 0000 0010 0010 0001, [0x004] GPTM Timer A Mode
0x00000200, 0000 0000 0000 0000 0000 0010 0000 0000, [0x008] GPTM Timer B Mode
0x00000001, 0000 0000 0000 0000 0000 0000 0000 0001, [0x00c] GPTM Control
0x00000000, 0000 0000 0000 0000 0000 0000 0000 0000, [0x010] GPTM Synchronize
0x00000000, 0000 0000 0000 0000 0000 0000 0000 0000, [0x018] GPTM Interrupt Mask
0x00000000, 0000 0000 0000 0000 0000 0000 0000 0000, [0x01c] GPTM Raw Interrupt Status
0x00000000, 0000 0000 0000 0000 0000 0000 0000 0000, [0x020] GPTM Masked Interrupt Status
0x00000000, 0000 0000 0000 0000 0000 0000 0000 0000, [0x024] GPTM Interrupt Clear
0x17d78400, 0001 0111 1101 0111 1000 0100 0000 0000, [0x028] GPTM Timer A Interval Load
0x000017d7, 0000 0000 0000 0000 0001 0111 1101 0111, [0x02c] GPTM Timer B Interval Load
0xffffffff, 1111 1111 1111 1111 1111 1111 1111 1111, [0x030] GPTM Timer A Match
0x0000ffff, 0000 0000 0000 0000 1111 1111 1111 1111, [0x034] GPTM Timer B Match
0x00000000, 0000 0000 0000 0000 0000 0000 0000 0000, [0x038] GPTM Timer A Prescale
0x00000000, 0000 0000 0000 0000 0000 0000 0000 0000, [0x03c] GPTM Timer B Prescale
0x00000000, 0000 0000 0000 0000 0000 0000 0000 0000, [0x040] GPTM TimerA Prescale Match
0x00000000, 0000 0000 0000 0000 0000 0000 0000 0000, [0x044] GPTM TimerB Prescale Match
0x0d7be6f3, 0000 1101 0111 1011 1110 0110 1111 0011, [0x048] GPTM Timer A
0x00000d6f, 0000 0000 0000 0000 0000 1101 0110 1111, [0x04c] GPTM Timer B
0x0d6338f7, 0000 1101 0110 0011 0011 1000 1111 0111, [0x050] GPTM Timer A Value
0x00000d56, 0000 0000 0000 0000 0000 1101 0101 0110, [0x054] GPTM Timer B Value
0x00007fff, 0000 0000 0000 0000 0111 1111 1111 1111, [0x058] GPTM RTC Predivide
0x00000000, 0000 0000 0000 0000 0000 0000 0000 0000, [0x05c] GPTM Timer A Prescale Snapshot
0x00000000, 0000 0000 0000 0000 0000 0000 0000 0000, [0x060] GPTM Timer B Prescale Snapshot
0x00000000, 0000 0000 0000 0000 0000 0000 0000 0000, [0x064] GPTM Timer A Prescale Value
0x00000000, 0000 0000 0000 0000 0000 0000 0000 0000, [0x068] GPTM Timer B Prescale Value
0x00000000, 0000 0000 0000 0000 0000 0000 0000 0000, [0xfc0] GPTM Peripheral Properties

 

TIMER3_BASE [0x40033000]
Value       Value (binary)                           Offset  Register Name
0x00000000, 0000 0000 0000 0000 0000 0000 0000 0000, [0x000] GPTM Configuration
0x00000262, 0000 0000 0000 0000 0000 0010 0110 0010, [0x004] GPTM Timer A Mode
0x00000200, 0000 0000 0000 0000 0000 0010 0000 0000, [0x008] GPTM Timer B Mode
0x00000000, 0000 0000 0000 0000 0000 0000 0000 0000, [0x00c] GPTM Control
0x00000000, 0000 0000 0000 0000 0000 0000 0000 0000, [0x010] GPTM Synchronize
0x00000000, 0000 0000 0000 0000 0000 0000 0000 0000, [0x018] GPTM Interrupt Mask
0x00000000, 0000 0000 0000 0000 0000 0000 0000 0000, [0x01c] GPTM Raw Interrupt Status
0x00000000, 0000 0000 0000 0000 0000 0000 0000 0000, [0x020] GPTM Masked Interrupt Status
0x00000000, 0000 0000 0000 0000 0000 0000 0000 0000, [0x024] GPTM Interrupt Clear
0x17d78400, 0001 0111 1101 0111 1000 0100 0000 0000, [0x028] GPTM Timer A Interval Load
0x000017d7, 0000 0000 0000 0000 0001 0111 1101 0111, [0x02c] GPTM Timer B Interval Load
0xffffffff, 1111 1111 1111 1111 1111 1111 1111 1111, [0x030] GPTM Timer A Match
0x0000ffff, 0000 0000 0000 0000 1111 1111 1111 1111, [0x034] GPTM Timer B Match
0x00000000, 0000 0000 0000 0000 0000 0000 0000 0000, [0x038] GPTM Timer A Prescale
0x00000000, 0000 0000 0000 0000 0000 0000 0000 0000, [0x03c] GPTM Timer B Prescale
0x00000000, 0000 0000 0000 0000 0000 0000 0000 0000, [0x040] GPTM TimerA Prescale Match
0x00000000, 0000 0000 0000 0000 0000 0000 0000 0000, [0x044] GPTM TimerB Prescale Match
0x17d78400, 0001 0111 1101 0111 1000 0100 0000 0000, [0x048] GPTM Timer A
0x000017d7, 0000 0000 0000 0000 0001 0111 1101 0111, [0x04c] GPTM Timer B
0x17d78400, 0001 0111 1101 0111 1000 0100 0000 0000, [0x050] GPTM Timer A Value
0x000017d7, 0000 0000 0000 0000 0001 0111 1101 0111, [0x054] GPTM Timer B Value
0x00007fff, 0000 0000 0000 0000 0111 1111 1111 1111, [0x058] GPTM RTC Predivide
0x00000000, 0000 0000 0000 0000 0000 0000 0000 0000, [0x05c] GPTM Timer A Prescale Snapshot
0x00000000, 0000 0000 0000 0000 0000 0000 0000 0000, [0x060] GPTM Timer B Prescale Snapshot
0x00000000, 0000 0000 0000 0000 0000 0000 0000 0000, [0x064] GPTM Timer A Prescale Value
0x00000000, 0000 0000 0000 0000 0000 0000 0000 0000, [0x068] GPTM Timer B Prescale Value
0x00000000, 0000 0000 0000 0000 0000 0000 0000 0000, [0xfc0] GPTM Peripheral Properties

 

-------------
Second run
-------------

 

TIMER2_BASE [0x40032000]
Value       Value (binary)                           Offset  Register Name
0x00000000, 0000 0000 0000 0000 0000 0000 0000 0000, [0x000] GPTM Configuration
0x00000221, 0000 0000 0000 0000 0000 0010 0010 0001, [0x004] GPTM Timer A Mode
0x00000200, 0000 0000 0000 0000 0000 0010 0000 0000, [0x008] GPTM Timer B Mode
0x00000001, 0000 0000 0000 0000 0000 0000 0000 0001, [0x00c] GPTM Control
0x00000000, 0000 0000 0000 0000 0000 0000 0000 0000, [0x010] GPTM Synchronize
0x00000000, 0000 0000 0000 0000 0000 0000 0000 0000, [0x018] GPTM Interrupt Mask
0x00000000, 0000 0000 0000 0000 0000 0000 0000 0000, [0x01c] GPTM Raw Interrupt Status
0x00000000, 0000 0000 0000 0000 0000 0000 0000 0000, [0x020] GPTM Masked Interrupt Status
0x00000000, 0000 0000 0000 0000 0000 0000 0000 0000, [0x024] GPTM Interrupt Clear
0x17d78400, 0001 0111 1101 0111 1000 0100 0000 0000, [0x028] GPTM Timer A Interval Load
0x000017d7, 0000 0000 0000 0000 0001 0111 1101 0111, [0x02c] GPTM Timer B Interval Load
0xffffffff, 1111 1111 1111 1111 1111 1111 1111 1111, [0x030] GPTM Timer A Match
0x0000ffff, 0000 0000 0000 0000 1111 1111 1111 1111, [0x034] GPTM Timer B Match
0x00000000, 0000 0000 0000 0000 0000 0000 0000 0000, [0x038] GPTM Timer A Prescale
0x00000000, 0000 0000 0000 0000 0000 0000 0000 0000, [0x03c] GPTM Timer B Prescale
0x00000000, 0000 0000 0000 0000 0000 0000 0000 0000, [0x040] GPTM TimerA Prescale Match
0x00000000, 0000 0000 0000 0000 0000 0000 0000 0000, [0x044] GPTM TimerB Prescale Match
0x0d7be6f7, 0000 1101 0111 1011 1110 0110 1111 0111, [0x048] GPTM Timer A
0x00000d6f, 0000 0000 0000 0000 0000 1101 0110 1111, [0x04c] GPTM Timer B
0x0d6338fb, 0000 1101 0110 0011 0011 1000 1111 1011, [0x050] GPTM Timer A Value
0x00000d56, 0000 0000 0000 0000 0000 1101 0101 0110, [0x054] GPTM Timer B Value
0x00007fff, 0000 0000 0000 0000 0111 1111 1111 1111, [0x058] GPTM RTC Predivide
0x00000000, 0000 0000 0000 0000 0000 0000 0000 0000, [0x05c] GPTM Timer A Prescale Snapshot
0x00000000, 0000 0000 0000 0000 0000 0000 0000 0000, [0x060] GPTM Timer B Prescale Snapshot
0x00000000, 0000 0000 0000 0000 0000 0000 0000 0000, [0x064] GPTM Timer A Prescale Value
0x00000000, 0000 0000 0000 0000 0000 0000 0000 0000, [0x068] GPTM Timer B Prescale Value
0x00000000, 0000 0000 0000 0000 0000 0000 0000 0000, [0xfc0] GPTM Peripheral Properties
TIMER3_BASE [0x40033000]
Value       Value (binary)                           Offset  Register Name
0x00000000, 0000 0000 0000 0000 0000 0000 0000 0000, [0x000] GPTM Configuration
0x00000262, 0000 0000 0000 0000 0000 0010 0110 0010, [0x004] GPTM Timer A Mode
0x00000200, 0000 0000 0000 0000 0000 0010 0000 0000, [0x008] GPTM Timer B Mode
0x00000000, 0000 0000 0000 0000 0000 0000 0000 0000, [0x00c] GPTM Control
0x00000000, 0000 0000 0000 0000 0000 0000 0000 0000, [0x010] GPTM Synchronize
0x00000000, 0000 0000 0000 0000 0000 0000 0000 0000, [0x018] GPTM Interrupt Mask
0x00000000, 0000 0000 0000 0000 0000 0000 0000 0000, [0x01c] GPTM Raw Interrupt Status
0x00000000, 0000 0000 0000 0000 0000 0000 0000 0000, [0x020] GPTM Masked Interrupt Status
0x00000000, 0000 0000 0000 0000 0000 0000 0000 0000, [0x024] GPTM Interrupt Clear
0x17d78400, 0001 0111 1101 0111 1000 0100 0000 0000, [0x028] GPTM Timer A Interval Load
0x000017d7, 0000 0000 0000 0000 0001 0111 1101 0111, [0x02c] GPTM Timer B Interval Load
0xffffffff, 1111 1111 1111 1111 1111 1111 1111 1111, [0x030] GPTM Timer A Match
0x0000ffff, 0000 0000 0000 0000 1111 1111 1111 1111, [0x034] GPTM Timer B Match
0x00000000, 0000 0000 0000 0000 0000 0000 0000 0000, [0x038] GPTM Timer A Prescale
0x00000000, 0000 0000 0000 0000 0000 0000 0000 0000, [0x03c] GPTM Timer B Prescale
0x00000000, 0000 0000 0000 0000 0000 0000 0000 0000, [0x040] GPTM TimerA Prescale Match
0x00000000, 0000 0000 0000 0000 0000 0000 0000 0000, [0x044] GPTM TimerB Prescale Match
0x17d78400, 0001 0111 1101 0111 1000 0100 0000 0000, [0x048] GPTM Timer A
0x000017d7, 0000 0000 0000 0000 0001 0111 1101 0111, [0x04c] GPTM Timer B
0x17d78400, 0001 0111 1101 0111 1000 0100 0000 0000, [0x050] GPTM Timer A Value
0x000017d7, 0000 0000 0000 0000 0001 0111 1101 0111, [0x054] GPTM Timer B Value
0x00007fff, 0000 0000 0000 0000 0111 1111 1111 1111, [0x058] GPTM RTC Predivide
0x00000000, 0000 0000 0000 0000 0000 0000 0000 0000, [0x05c] GPTM Timer A Prescale Snapshot
0x00000000, 0000 0000 0000 0000 0000 0000 0000 0000, [0x060] GPTM Timer B Prescale Snapshot
0x00000000, 0000 0000 0000 0000 0000 0000 0000 0000, [0x064] GPTM Timer A Prescale Value
0x00000000, 0000 0000 0000 0000 0000 0000 0000 0000, [0x068] GPTM Timer B Prescale Value
0x00000000, 0000 0000 0000 0000 0000 0000 0000 0000, [0xfc0] GPTM Peripheral Properties

 

 

  • 0
    Guru 117855 points

    Must comment - "Truly spectacular post!"  

    You really (above/beyond) did your homework (past forum history: searched/reviewed/summarized here) - gave a detailed and complete explanation of both your program goals and results (sure beats infamous, "Does not Work!") - and then provided all reasonable data collection for analysis.

    So - simply great job.

    That said - I was past (failed) helper in this matter - could not achieve desired daisy chaining w/LX4F -  Rev A1.  Your post is so good....(almost) tempted to "try again" but hope that factory guys/gals (w/their insider info) can respond...

    Good luck...

     

  • 0 in reply to cb1_mobile
    TI__Expert 3445 points

    Jim,

    First of all, great post. It's thorough, informative, and really going to help as we look further into this.

    I ran a quick approximate test with your code (but with different board, chip rev, and delay function) and could not reproduce your results. T3 started counting down correctly on the first time and after a reset.

    How did you implement your Delay() function? I just used SysCtlDelay(SysCtlClockGet()/10).

    I will do a more rigorous test with your board and part revision tomorrow.

  • 0 in reply to Stellaris John
    Intellectual 260 points

    Thanks for your comments cb & John,

    I am a newbie to Stellaris/ARM/32-bit MPU's and like what I see.

    I am afraid that, to be clearer, I should have written the example code like this (but it seemed a bit cumbersome in a post) :-

    for (iRun = 0 ; iRun < 2; iRun++) {
    TimerConfigure(TIMER3_BASE, TIMER_CFG_A_PERIODIC) ;
    TimerConfigure(TIMER2_BASE, TIMER_CFG_A_ONE_SHOT) ;
    // ... <rest of timer code in here>
    TimerDisable(TIMER2_BASE, TIMER_A) ;
    TimerDisable(TIMER3_BASE, TIMER_A) ;
    }

    It is on the second time around the loop that the timer does not wait (even though the timer states seem to be near identical).

    For my delay I use a timer (timer5) which I have already assigned for taking 'snapshot' times. Now I am most probably wrong on this, but I was worried that since SysCtlDelay relies on machine cycles in code, that above 40MHz it might not work as expected due to wait cycles in flash. I haven't tested this, it was just a hunch, but since I have a dedicated hardware timer already available, I chose to use it for delays too.

    Anyway, I did previously try SysCtlDelay in place of my Delay but with the same result. I also tried slowing the MPU clock to 10Mhz just for luck (thinking it could be some kind of hardware glitch), but no luck! 

    One new thing I did try just now was to remove my Delay from code (and the initialization of timer5). Now I get the same basic result, but in one pair of runs, the timers did not configure themselves right at all ... I am not seeing very consistent behaviour in the timer module. I am beginning to wonder if this particular board is the problem.I have another one in the cupboard gathering dust unopened, I will plug it in and see what I get ...

    Jim

    ---- 

     

  • 0 in reply to Jim_McCormack
    Intellectual 260 points

    Update: I tried another Stellaris LM4F120 LaunchPad Evaluation Board (EK-LM4F120XL) but alas I get the same result.

    Jim

    ------

  • 0 in reply to Stellaris John
    Guru 117855 points

    Stellaris John said:
    ran a quick approximate test with your code (but with different board, chip rev, and delay function)

    @ Stellaris John,

    In the past our group/others also tried (and failed) to achieve poster's desired, "wait for trigger - daisy-chain..."

    Might you detail the actual MCU - and Rev - with which you succeeded?  And - did you truly, "daisy-chain?"

  • 0 in reply to cb1_mobile
    TI__Expert 3445 points

    Jim,

    I was thinking that you were resetting the board in between the two runs. I ran your updated code with the runs separated by the calls to TimerDisable(), and I got the same result as you did.

    I looked around in the datasheet and I can't find how to specifically reset the daisy chain timer trigger, but I tried using the SysCtlPeripheralReset() function to reset  Timer3 at the end of each run. This produces your desired result (at least on the TM4C123G board with Rev 6/B1 silicon I was testing with).

  • 0 in reply to Stellaris John
    Expert 2415 points

    Hi all,

    I'm rummaging though the various peripherals on the TM4C line, and now it was time for getting deep in with the timers - and after seeing this thread I couldn't resist trying, too!

    First my hardware/software setup:

    • 980 YF XM4C123G H6PMI6 32AYD2W G4 (aka early Tiva C LaunchPad)
    • CCS 5.5.0.00077
    • TI ARM compiler updated to v. 5.1.2

    Here's what I'm doing:

    1. Timer0 is configured as a periodic down-counter, with a 5 second period
    2. Timer1 is configured as a one-shot down-counter, with a 4 second period and the wait-on-trigger bit enabled
    3. Timer2 is configured as a one-shot down-counter, with a 3 second period and the wait-on-trigger bit enabled
    4. Timer0 is enabled
    5. Using a custom scheduler (found the TI one "too late"), a call is made to enable Timer1 every 10 seconds starting at the 2 second marker, also prints "Timer2 enabled" to UART
    6. Likewise, a call is made to enable Timer2 every 10 seconds starting at the 3 second marker
    7. The scheduler is also set to print the elapsed time along with T0,T1 and T2 values every 500 ms, to UART

    Note that at no point do I disable nor reconfigure any of the timers, nor do I re-set the wait-on-trigger bit. I only re-enable timers 2 and 3, every 10 seconds.

    And here's what I'm seeing on the UART:

      500 ms | T0: 360000276 T1: 320000000 T2: 240000000
     1000 ms | T0: 320000276 T1: 320000000 T2: 240000000
     1500 ms | T0: 280000276 T1: 320000000 T2: 240000000
     2000 ms | T0: 240000276 T1: 320000000 T2: 240000000
    Timer1 enabled.
     2500 ms | T0: 200000276 T1: 320000000 T2: 240000000
     3000 ms | T0: 160000276 T1: 320000000 T2: 240000000
    Timer2 enabled.
     3500 ms | T0: 120000276 T1: 320000000 T2: 240000000
     4000 ms | T0: 80000276  T1: 320000000 T2: 240000000
     4500 ms | T0: 40000274  T1: 320000000 T2: 240000000
     5000 ms | T0: 274       T1: 320000000 T2: 240000000
     5500 ms | T0: 360000275 T1: 280000263 T2: 240000000
     6000 ms | T0: 320000275 T1: 240000263 T2: 240000000
     6500 ms | T0: 280000275 T1: 200000263 T2: 240000000
     7000 ms | T0: 240000275 T1: 160000263 T2: 240000000
     7500 ms | T0: 200000275 T1: 120000263 T2: 240000000
     8000 ms | T0: 160000275 T1: 80000263  T2: 240000000
     8500 ms | T0: 120000275 T1: 40000263  T2: 240000000
     9000 ms | T0: 80000275  T1: 263       T2: 240000000
     9500 ms | T0: 40000275  T1: 320000000 T2: 200000252
    10000 ms | T0: 275       T1: 320000000 T2: 160000252
    10500 ms | T0: 360000276 T1: 320000000 T2: 120000252
    11000 ms | T0: 320000276 T1: 320000000 T2: 80000252
    11500 ms | T0: 280000276 T1: 320000000 T2: 40000252
    12000 ms | T0: 240000276 T1: 320000000 T2: 252
    Timer1 enabled.
    12500 ms | T0: 200000276 T1: 320000000 T2: 240000000
    13000 ms | T0: 160000276 T1: 320000000 T2: 240000000
    Timer2 enabled.
    13500 ms | T0: 120000276 T1: 320000000 T2: 240000000
    14000 ms | T0: 80000276  T1: 320000000 T2: 240000000
    14500 ms | T0: 40000276  T1: 320000000 T2: 240000000
    15000 ms | T0: 276       T1: 320000000 T2: 240000000
    15500 ms | T0: 360000277 T1: 280000265 T2: 240000000
    16000 ms | T0: 320000277 T1: 240000265 T2: 240000000
    16500 ms | T0: 280000277 T1: 200000265 T2: 240000000
    17000 ms | T0: 240000277 T1: 160000265 T2: 240000000
    17500 ms | T0: 200000277 T1: 120000265 T2: 240000000
    18000 ms | T0: 160000277 T1: 80000265  T2: 240000000
    18500 ms | T0: 120000277 T1: 40000265  T2: 240000000
    19000 ms | T0: 80000277  T1: 265       T2: 240000000
    19500 ms | T0: 40000277  T1: 320000000 T2: 200000254
    20000 ms | T0: 277       T1: 320000000 T2: 160000254
    20500 ms | T0: 360000278 T1: 320000000 T2: 120000254
    21000 ms | T0: 320000278 T1: 320000000 T2: 80000254
    21500 ms | T0: 280000278 T1: 320000000 T2: 40000254
    22000 ms | T0: 240000278 T1: 320000000 T2: 254
    Timer1 enabled.
    22500 ms | T0: 200000278 T1: 320000000 T2: 240000000
    23000 ms | T0: 160000278 T1: 320000000 T2: 240000000
    Timer2 enabled.
    23500 ms | T0: 120000278 T1: 320000000 T2: 240000000
    24000 ms | T0: 80000278  T1: 320000000 T2: 240000000
    24500 ms | T0: 40000278  T1: 320000000 T2: 240000000
    25000 ms | T0: 278       T1: 320000000 T2: 240000000
    25500 ms | T0: 360000279 T1: 280000267 T2: 240000000

    Points of interest:

    • 5000 ms; T0 reaches zero; T1 begins counting
    • 9000 ms; T1 reaches zero; T2 begins counting
    • 10000 ms; T0 reaches zero; T1 does not begin counting
    • 15000 ms; T0 reaches zero; T1 begins counting
    • 19000 ms; T1 reaches zero; T2 begins counting
    • etc...

    As you can see, the W-o-T only works once, to have another go the timer in question needs to be re-enabled. Now, this kind of makes sense for the one-shot mode.

    What happens if we configure T1 as a periodic down-counter, everything else remaining identical? This happens: T1 waits for the first trigger from T0, and correctly starts counting when it is received. But, it does not stop upon reaching zero - instead it goes on as if it were a vanilla down-counter. T3 continues to receive the triggers from T1 every time it wraps around, and (provided that it is enabled at that moment) starts counting as expected.

    This pretty much confirms what cb1 and Jaime found out in the earlier thread linked to by Jim.

    In this light, what the datasheet says is a bit confusing (though not outright incorrect - they don't say much to be wrong about!). My thoughts:

    • Both the one-shot and periodic modes - can act as a trigger source (pwm discarded due to errata)

    • The only usable trigger receiver is the one-shot mode
    • You can use the timer interrupt to re-enable itself, resulting in something very much like what we would expect the periodic wait-on-trigger to be. I tested this and it works as expected - T1 begins counting every time T0 wraps, without "external" calls to re-enable the timer, only through the interrupt. Obviously this approach has it's limitations when dealing with fast timings.

    I hope this helps (and I didn't forget anything crucial - it's very late where I'm at). I'm happy to provide further details if needed, but it'll have to wait for tomorrow :-)

    Best,

    Veikko

  • 0 in reply to Stellaris John
    Intellectual 260 points

    Thanks John and Veikko for your help,

    I tried a SysCtlPeripheralReset on the waiting timer (timer3 in my example) and this fixes the problem.

    The timer will now wait every time for the correct trigger.

    But I can't imagine that calling SysCtlPeripheralReset is the intended mode of operation? As pointed out, it could be too slow for some timing uses.

    Anyway, thanks again ...

    Jim

    -----

     

     

  • 0 in reply to Jim_McCormack
    Guru 117855 points

    Jim_McCormack said:
    can't imagine that calling SysCtlPeripheralReset is the intended mode of operation

    So, so true - bandaid @ best - and inefficient/unavoidably error-adding as well...

    Thus, "Daisy-Chain" - as long past reported - (achieved by far simpler (ancient even) MCUs) appears beyond the reach of MCU's here...    Pity that - and pity further than past mention/alert (by outsiders) appears to have yielded little corrective action...  (i.e. no such corrective action notes have been made easily/readily available...imho)

    Applause to, "Veikko" for the care & precision reflected w/in his (outsider) post. 

    and...@ Jim - that "Verify" seems inappropriate - likely this should fester till really fixed... 

  • 0 in reply to cb1_mobile
    Intellectual 260 points

    cb1_mobile said:

    and...@ Jim - that "Verify" seems inappropriate - likely this should fester till really fixed... 

    Yes, very true, I think TI need to look at daisy-chaining, but to be fair to John he did find a solution which works for me for which I am grateful so I pressed 'yes'!...

    Jim

    ----

  • 0 in reply to Jim_McCormack
    Guru 117855 points

    Do let the record show that day earlier - via post memorialized (and verified) below - I highlighted the unfortunate, "burying" of that key, fixing function!  "SysCtlPeripheralReset()"  

    http://e2e.ti.com/support/microcontrollers/tiva_arm/f/908/t/293950.aspx 

  • 0 in reply to cb1_mobile
    TI__Expert 3445 points

    All,

    I agree that resetting the whole timer is an inelegant solution to clearing the trigger. We are looking into whether or not this is how the timers are supposed to work.