• State
  • Locked Locked
  • Replies 10 replies
  • Subscribers 84 subscribers
  • Views 1891 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/TMS320F28075: Timer_start() does not work every now and then

benjo
Intellectual 275 points
Part Number: TMS320F28075


Tool/software: TI-RTOS

Hi there

I am using the timer 1 with the following configuration in the cfg-file:

var timer0Params = new Timer.Params();
timer0Params.instance.name = "TIMER1_HWI";
timer0Params.period = 200;
timer0Params.startMode = xdc.module("ti.sysbios.interfaces.ITimer").StartMode_USER;
Program.global.TIMER1_HWI = Timer.create(1, "&TIMER1INT_ISR", timer0Params);

Unfortunately, a call of

Uint16 key = Hwi_disable();
Timer_start(TIMER1_HWI);	// clears counters, clears any pending interrupts, and enables the timer interrupt before starting the timer.
Hwi_restore(key);

sometimes does not lead to the expected interrupt. I can say, that the problem occurs approximately in 7 out of 1000. Any ideas on this?
I've read in another https://e2e.ti.com/support/embedded/tirtos/f/355/p/262151/917974 that the interrupt was simply not enabled as it should by Timer_start(), so maybe a bug?

Using SYS/BIOS V6.51.0.15

Cheers Benjo

  • 0
    Intellectual 275 points
    after further investigation I can confirm, that the IER bit for INT13 is not set in case of the error. More precisely, AFTER calling Timer_start() and BEFORE calling Timer_stop() the IER holds the value 0x39A1 in the case of no error and 0x29A1 in the case of the mentioned error.
    Is there any mechanism that keeps me from setting (indirectly via Timer_start) the bit? Or is there any mechanism, that can reset the bit?

    cheers benjo
  • 0 in reply to benjo
    TI__Guru* 96960 points
    Hi Benjo,

    Where are you starting the timer (e.g. in a Task, Swi, Hwi or main())? Can you look in Tools->ROV->Hwi->Basic and Module to make sure the ISR is there. Also look at ROV->Timer->Basic before and after you call Timer_start. Can you attach the images of ROV->Hwi and Timer?

    Can you also confirm that the Clock module is not using the same timer?

    Todd
  • 0 in reply to ToddMullanix
    Intellectual 275 points

    Hi Todd

    the clock module uses timer2:

    Clock.timerId = 2;

    I tried both, calling Timer_start() in a Task and Interrupt context, both failed. Then I tried another "test task" with nothing in it except Timer_start() and Timer_stop() plus some variable incrementing. And, surprisingly, it worked in that "test task".

    Concerning your ROV questions - It's quite hard to have the error occuring while debugging but I'll do my best to reproduce it and send you the screenshots.

    cheers benjo

  • 0 in reply to benjo
    TI__Guru* 96960 points
    Can you make sure that no stacks are being blown? An easy way to check is to do ROV->BIOS->Scan for errors.
  • 0 in reply to ToddMullanix
    Intellectual 275 points

    Hi Todd

    I checked for a stack overflow and couldn't detect one. Furthermore I attach the requested screenshots, taken after Timer_start() and when the error occured

    ROV->BIOS->scan for errors: ROV->HWI->BASIC: ROV->HWI->MODULE:

    ROV->TIMER->BASIC:

    Cheers Benjo

  • 0 in reply to benjo
    Intellectual 275 points
    I also found out, that the bit 0x1000 in the IER register is set correctly after calling Timer_start(). So the failure must happen somewhere in between calling Timer_start() and the first elapsed timer period.
  • 0 in reply to benjo
    TI__Guru* 96960 points
    Hi Benjo,

    Are you always getting the warning in Scan for Errors? For example, even when you get to main()?

    Todd
  • 0 in reply to ToddMullanix
    Intellectual 275 points
    Hi Todd

    yes I get the warning right after starting the debug session, halting at the beginning of main(). I don't really know what it tries to tell me. You think it's related to the timer HWI issue?

    benjo
  • 0 in reply to benjo
    TI__Mastermind 30830 points

    Can you provide details about the Timer interrupt function? Is there any path through it that calls Task_enable()?

    The corresponding Hwi entry for Timer 1 shows the disable and restore IER masks seem to be correct. The non-zero IRP value in the Hwi detailed view indicates that the Timer interrupt did indeed occur and was serviced by the interrupt dispatcher. 

    I'm suspected that there are corner cases within the Timer ISR where the ISR function never returns. This could happen if the Task scheduler was mistakenly enabled when a task was unblocked within an interrupt function. Rather than returning from the ISR, the thread of execution would immediately proceed to the unblocked task thread, leaving the Timer interrupt disabled.

    Alan

  • 0 in reply to Alan DeMars
    Intellectual 275 points

    Hi Alan

    atm I am absorbed by another task but I'll be back with information asap!
    In the meanwhile: I found out, that when I never call the Timer_stop() the problem does not occur. All I do now is call Timer_start() right at the beginning and use a flag in the ISR to decide whether ISR code should be executed or not. Restarting/syncing is achieved by simply calling Timer_start() again at a desired point of time.

    cheers benjo