• State Resolved
  • Locked Locked
  • Replies 21 replies
  • Answers 2 answers
  • Subscribers 32 subscribers
  • Views 3680 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.

RTOS/TM4C1292NCPDT: Timer reset

sandra george78
Intellectual 980 points
Part Number: TM4C1292NCPDT
Other Parts Discussed in Thread: SYSBIOS

Tool/software: TI-RTOS

Hi,

I am using TIRTOS 2.16.01.14.

I configured a timer module in the configuration file as shown below.

To start the timer I am using the code,

Key = Hwi_disable();

Timer_stop(Wdt);

Timer_setPeriodMicroSecs(Wdt,(timeoutValue[0] * 1000));

Timer_start(Wdt);

Hwi_restore(Key);

I want to clear the counter of timer. For that which API I have to use? I couldn't find any API for clearing counter register of timer in the cdoc document. Can you please tell me how to reset the counter of timer?

Regards

Sandra

  • 0
    Guru 55913 points
    HI Sandra,

    Wouldn't it be nice if it were that simple to configure the Watch Dog timer peripheral in RTOS. There may be help if you use CCS6-7 REX to traverse folder tree, search for RTOS example projects folders. There are several pre configured peripherals including WDT in the (EK_TM4C1294XL.c) board found in some example projects.
  • 0 in reply to Genatco
    Intellectual 980 points
    Hi,
    Thanks for the reply.

    I want to use a general purpose timer.
    Isn't any API available for timer reset?

    I tried with the code,
    HWREG(TIMER3_BASE + TIMER_O_TAV)=0;

    But this is not resetting the counter. Any solution for it?
  • 0 in reply to sandra george78
    Guru 55913 points
    You are aware GPTM3 is not a Watch Dog timer and can only be configured four different ways per datasheet text?

    You have to access the GPTM3 specific register in periodic mode to reset a specific count. Believe the reset count register name changes relative the count direction up or down.
  • 0 in reply to Genatco
    Intellectual 980 points
    I am using GPTM3 in periodic mode with count direction up.

    "Reset count register name changes" means, the register TIMER_O_TAV may change?

    Can you please give an example?
  • 0 in reply to sandra george78
    Guru 117855 points

    sandra george78 said:
    Isn't any API available for timer reset?

    When the "mighty" API - "Lacks such exact function" - might that indicate that there are (other means - w/in the API) to achieve the sought objective?

    Would not your desire for, "timer reset"  be satisfied  via, "Timer Load" (of 0 - when counting up, or max timer value - when counting down)?

    Note that neither firm nor I employ  "vendor limited" RTOS (or other "aids") - the method described may not apply - when under such RTOS restriction.

  • 0 in reply to cb1_mobile
    Intellectual 980 points
    In the post referred in the link

    e2e.ti.com/.../651080

    it was suggested that not to use driverlib calls.

    Can I use driverlib calls if the timer is configured in the configuration file?
  • 0 in reply to sandra george78
    Guru 117855 points

    Sorry - as stated - clients demand that firm/I AVOID any "vendor restricted" (RTOS or program "aids.") (other than the wonderful API - of course...)

    Only you/your team know, "If the (potential) benefits - promised by the (limited) RTOS" - justify the LOSS of the, "Speeding, Easing, Enhancing" API!

    Never having reason to (even briefly) glance at your  "vendor limited RTOS"  - "IF a "Timer Load" function exists therein - that should suffice as "Timer Reset" - when  "loaded as detailed", earlier...

  • 0 in reply to cb1_mobile
    TI__Guru* 96960 points
    Hi Sandra,

    Just to confirm...you are wanting a timer such that if it expires after some period of time X, you want to do some type of recovery action (e.g. reset the device). In other words...a watchdog. Off-hand I can think of four solutions with TI-RTOS.

    1. Use the Watchdog driver in TI-RTOS
    2. Create a TI-RTOS Kernel timer (as you did) and simply use Timer_stop/Timer_start (without disabling interrupts). The Timer_stop will disable the timer. The Timer_start will start the timer again back with the initial period.
    3. Use a Clock function (and save a timer). Similar to the Timer module, there is a Clock_stop/Clock_start to "reset" the countdown. The period needs to be a multiple of the Clock module (default is 1ms).
    4. Use driverlib calls to manage the timer, but plug in the interrupt with the Hwi_create function with a priority of 0. This tells the kernel to not manage this interrupt. The ISR cannot call a kernel API (e.g. Semaphore_post) since it is out of the kernel's playground.

    Todd
  • 0 in reply to ToddMullanix
    Intellectual 980 points

    Todd,

    Thank you for the information.

    I am now using  watchdog driver . I opened the watchdog as below,

    Watchdog_Params_init(&wdtParams);

    wdtParams.callbackFxn = (Watchdog_Callback)WatchdogResetFxn;

    wdtParams.resetMode = Watchdog_RESET_OFF;

    wdtHandle = Watchdog_open(Board_WATCHDOG1, &wdtParams);

    Watchdog_setReload(wdtHandle, (timeoutValue[0] * 1000));

     

    Here, timeoutValue[0] is the value I will be getting from a register. Can I set reload value like this?

    The watchdog is working fine at the first time. While trying to reopen the watchdog, it is not opening. I tried to use the API  Watchdog_close(wdtHandle) before reopening.

    But in the WatchdogTiva.h File Reference, I saw that Watchdog_close() is not supported by this driver implementation.

    What's the alternate solution I can use? Can you please suggest a solution?

     

    Regards

    Sandra

     

     

  • 0 in reply to sandra george78
    TI__Guru* 96960 points

    Sandra,

    I modified the Watchdog example in TI-RTOS. I changed the watchdogCallback to this

    #include <ti/sysbios/knl/Clock.h>

    void watchdogCallback(uintptr_t unused)

    {

       static int tick = 0;

       static int prevTick = 0;

       static int reloadVal = 90000000;

       static int delta    = -10000000;

       reloadVal += delta;

       if (reloadVal <= 10000000) {

           delta = 10000000;

       }

       prevTick = tick;

       tick = Clock_getTicks();

       System_printf("tick delta = %d val = %d\n", tick - prevTick, reloadVal);

       /* Clear watchdog interrupt flag */

       Watchdog_setReload(watchdogHandle, reloadVal);

       Watchdog_clear(watchdogHandle);

       GPIO_toggle(Board_LED0);

    }

    I also bumped the SysMin.bufSize to 1024 in the .cfg file. Try running this and then halt it and look at SysMin in ROV. You can see that the tick count is changing accordingly.

    You can also see the change in the LED toggling.

    What you are doing should be fine. What value are you using? Are you calling Watchdog_clear in the callback function?

    Todd

  • 0 in reply to ToddMullanix
    Intellectual 980 points
    Todd,

    Thank you for the reply. Reload value set is working fine. I have used Watchdog_clear() in callback function.

    While reopening the watchdog, the watchdog is not opening.

    In the thread
    e2e.ti.com/.../631194
    I saw that watchdog can be closed only if hardware reset is done.

    But in my application, hardware reset can't be done for closing watchdog. Is there any other method to close the watchdog?

    In my application, I have two modes. In the mode1, I am opening the watchdog. In the mode2, I have to close the watchdog. Then when a condition occurs, again comes to mode1. Then watchdog has to be reopened. Since close is not happening properly, I can't reopen the watchdog.

    I tried to do this with timer. In the mode1, I started timer and in mode2 I stopped it. But I was not able to reset the counter of timer.

    Can you please give a suggestion, which option will be better?
    Also please tell me how to close the watchdog properly.

    Regards
    Sandra
  • 0 in reply to sandra george78
    Guru 55913 points

    Hi Sandra,

    Glad to see you choose the RTOS dog device, I can't even see the dog in my tree :(

     
    Why not leave the dog out in the yard and only feed him to keep from expiring each time a task loop begins. That is typical dog behavior in many applications. As long as the dogs timer is reloaded each time task/loop begins it will never expire and cause a software MCU reset or branch to another function.

  • 0 in reply to Genatco
    TI__Guru* 96960 points
    I agree with BP101.

    Watchdog_close is not supported since the idea of a watchdog is to have a safety net. You can set the reload value to a larger value during your "mode2" condition.
  • 0 in reply to ToddMullanix
    Intellectual 980 points

    Hi,

    Thank you very much for the reply. This is working.

    Thanks & Regards

    Sandra

  • 0 in reply to sandra george78
    Intellectual 980 points
    Hi,

    By default, watchdog load is set as 80000000 for 1s period at default CPU clock frequency. As the maximum loadable value is 32 bit, is the maximum timeout value that can be set , (2^32 / 80000000)s ? Can I set watchdog timeout value which is equivalent to days period?

    Regards
    Sandra
  • 0 in reply to sandra george78
    Guru 55913 points
    Todd agrees BP101 yet No award green for dogs best behavior, surely pat on head make dog wag tail for days on end.
  • 0 in reply to Genatco
    TI__Guru* 96960 points
    Sandra,

    Please refer to the TM4C data sheet to see the capabilities of the Watchdog in regards to legal values. The driver just writes whatever you give. You are not going to be able to get that long of a period.

    Todd
  • 0 in reply to sandra george78
    Guru 117855 points

    sandra george78 said:
    Can I set watchdog timeout value which is equivalent to days period?

    Such "overly extended period" (a day!) is FAR OUTSIDE "normal/customary" watchdog utilization.    (the limitation in "maximum loadable" - watchdog value - IS - by intent!)

    Watchdog is more normally employed to "catch an MCU "issue" (in milliseconds or less, usually) - and (only then) generate an "orderly recovery process" (via an MCU Reset).

    That VITAL functionality has been abandoned by such proposed, "Watchdog Misuse!    NOT Good!

  • 0 in reply to cb1_mobile
    Guru 55913 points
    Objectively it could be said the dog timer can be made to never expire if the application loop that feeds the dog never ceases execution.

    Dogs expire time is fairly long (80000000 ticks) 666ms laps time of 120Mhz SYSCLK.

    Seemingly Wdogs expire time can be made longer, if needed even a minute and agree 100% to what end of setting days to expire.
  • 0 in reply to Genatco
    Guru 117855 points

    BP101 said:
    ...Wdogs expire time can be made longer, if needed even a minute and agree 100% to what end of setting days to expire.

    Even after three reads - 2 staff members & I - prove,   "unable to grasp your meaning."     Might you oblige us (likely others, too) and describe again?

  • 0 in reply to cb1_mobile
    Guru 55913 points

    To what end of setting days for dog to expire as long as a function loop never ends, idea of loading days as a period is counter intuitive. Wasn't that your point as well. Poster is seemingly unaware how the watch dog has ability to branch program execution via RTOS callback (as is "null") or simply POR on second timeout.