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.

LAUNCHXL2-RM46: Simple Configurable Blocking Delay Timer

Part Number: LAUNCHXL2-RM46
Other Parts Discussed in Thread: HALCOGEN

I'm trying to create a simple configurable *blocking* delay timer. I already have rtiNotification() handlers working for a couple of periodic timers, but of course they are not blocking. I have tried variations on:

void setDelayTimer(uint32_t milliseconds) {
    gTimerExpired = 0; // Gets set to 1 in RTI ISR for COMPARE2

    rtiSetPeriod(rtiCOMPARE2, milliseconds * 10000);

    while(gTimerExpired == 0) {
        // Do nothing - waiting for timer to stop before exiting
        __asm(" NOP");

gTimerExpired is a static variable visible to the rtiNotification() ISR, which sets it to 1 when the timer expires.

Seems like things get hung up in the while loop and the timer never expires. If I comment out the while loop the timer expires as expected, but I really need things to just stop during that period.

I'm sure I'm missing something simple. gTimerExpred probably needs to be updated within the while loop and can't just be "observed" when the timer expires. I have debug outputs to a UART in RTI ISR, and the timer is definitely not expiring.

Thanks in advance for any assistance!
- Tom

  • I should note that I did try adding another variable that gets initialized to 0 before the while() loop, used as the exit condition, and gets set to the value of gTimerExpired within the loop. Also did not work.

    timerCheck = 0;
    while(timerCheck == 0) {
        timerCheck = gTimerExpired;

    - Tom

  • Thomas Green1 said:
    gTimerExpired is a static variable visible to the rtiNotification() ISR, which sets it to 1 when the timer expires.

    Is gTimerExpired declared as volatile?

    If not, the compiler may turn the while loop in the setDelayTimer into an infinite loop, by only reading gTimerExpired once.

  • Thanks for the reply. gTimerExpired is declared as volatile. 

    I was avoiding the debugger because I've been loading the board via a CAN bootloader and was trying to figure this out late Friday afternoon, but I ran it in the debugger this morning and gTimerExpired exists in the namespace. 

    With the while loop in the code, the timer never expires. Comment the while loop out and the timer expires and gTimerExpired is modified, but that doesn't help me actually pause anything.

    Ah well; might be time to switch to counting SYS_TICKS.

    Thanks again!

  • Hello,

    rtiCOUNTER_BLOCK2 doesn't start. You use compare 2, but only compare 0 is started.

  • My understanding is that rtiCOMPARE2 runs from rtiCOUNTER_BLOCK0, based on my HalCoGen setup. It may be hidden, but rtiCOUNTER_BLOCK2 does not seem to exist, or at least it's not exposed in HalCoGen, for the RM46 variant I'm using.

    I was using rtiCOMPARE2 to produce a pulse train of three 250 ms pulses when commanded asynchronously, and it worked just fine. But I no longer need that functionality. Now I need to produce delays of 30 seconds or more prior to entering the interrupt-only while(1) loop.

    Stepping through with the debugger shows that the while(timerCheck ==0) loop tosses the program off into "prefetchEntry".

    Thanks for taking a look at this.

    - Tom

  • Hi Tom,

    I am sorry for misunderstanding your configuration. I thought compare 0/1 use counter 0 and compare 2/3 use counter 1. 

    Regarding prefetch abort, can you read out the Instruction Fault Status Register and the Instruction Fault Address Register from the CPU core? It will help us track the cause of the prefetch abort?

  • CP15 Instruction Fault Status : 0x0001008

    CP15 Instruction Fault Address : 0x20202020

    I moved the while() loop into sys_main.c, with only rtiNOTIFICATION_COMPARE2 enabled (it changes the global variable that should result in exiting the while()) and rtiCOUNTER_BLOCK0 started. Same result. Before this change I also had a periodic 10 ms task running on rtiCOUNTER_BLOCK1.

    Thanks again!

    - Tom

  • Hi Tom,

    I tested code on my TMS570LC43x launchpad. I did not get abort.

  • Tried your code in a new project, and it worked as expected. The only thing I changed was adding "rtiStopCounter(rtiCOUNTER_BLOCK0);" in the rtiNotification() handler since I want the timer to stop after each use. 

    My original project isn't too big yet, so I will add elements of it to this new project to see if and where something breaks. I was hoping the one other difference I noticed (setting the Continue on Suspend bit in ritREG1->GCTRL) would make my original code work, but no such luck.

    I definitely appreciate the time you took to try out the code yourself. I should have created a new project yesterday to try the delay timer out by itself. That's how I finally worked through the "magic number" issue for the CAN bootloader - isolating the problem to its own project.

    Thanks again!

    - Tom