• State Resolved
  • Locked Locked
  • Replies 5 replies
  • Answers 1 answer
  • Subscribers 81 subscribers
  • Views 638 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/MSP432P401R: MSP432P401R Launchpad, Using Clock_create() with Timeout = 0 FAILS

Eric Wilbur
Intellectual 780 points

Part Number: MSP432P401R

Tool/software: TI-RTOS

I am creating a new lab for the new TI-RTOS workshop we are releasing that covers Clock. We are using heap memory to create the instances. Below is a snippet of my code:

// Create Clock 1

Clock_Params_init(&clkParams);
clkParams.period = 500000/Clock_tickPeriod;
clkParams.startFlag = TRUE;

clk1Handle = Clock_create(
(Clock_FuncPtr)myClk1Fxn,
500000/Clock_tickPeriod,                //TIMEOUT VALUE
&clkParams,
NULL);

if (clk1Handle == NULL) {
System_abort("clock create failed");
}

Everything works FINE unless the timeout value = 0. I am not using a one-shot, but a periodic clock function. Why does the code get stuck in IDLE when I set the timeout value to zero? Is this some sort of race condition? I have the start flag set to true, so when clock_create() returns, the clock function should "start". But for some reason, a timeout value of ZERO causes the Clock function to completely fail. 

My question is very similar to this post: e2e.ti.com/.../604810

But the real question was never addressed in that post.

  • 0
    TI__Guru 74391 points
    Eric,
    The timeout is in terms of clock ticks. Does it make sense to have a value of '0'? Why would you not simply call the function before starting the clock (either with Clock_start() or startFlag is true).

    Is it accurate to state that your expected behavior is that the clockFxn would be called immediately after the start when timeout equals '0'?

    dev.ti.com/.../Clock.html

    Thanks,
    Chris
  • 0 in reply to Chris Sterzik
    TI__Guru 74391 points
    Eric,
    I should have done some more digging before replying. This has been identified as a bug. Unfortunately this has not been assigned and therefore there is no commitment date.

    Regards,
    Chris
  • 0 in reply to Chris Sterzik
    Intellectual 780 points

    Hi Chris,

    Thanks for the clarification. I did a little more digging as well:

    - With startFlag = FALSE, timeout =0, Clock_start() used to start clock function, clock function fails

    - With ANY combination of values/code, if timeout=0, it fails

    I guess my point here is this - if a user can enter a number into a field that is invalid or causes a complete failure, why allow that number to be used?

    Sure, users (like me) can screw up anything if we like...so it is impossible to guard against stupid numbers like zero in the timeout field.  ;-)

    For the workshop, though, it is good for us to point out that zero is invalid and causes a catastrophic failure. And, now that it has been discussed on the forum, others can see that this is a bug which, most likely, won't be fixed. 

    Thanks!  I appreciate the quick help.

  • 0
    Genius 3850 points
    "Everything works FINE unless the timeout value = 0."

    :)

    "I guess my point here is this - if a user can enter a number into a field that is invalid or causes a complete failure, why allow that number to be used?"

    that's the price you pay for having a powerful tool: in the right hands, it can help you greatly. in the wrong hands, it can hurt you greatly. if you instead need a nanny watching over your shoulder, well, get a nanny indeed.
  • 0 in reply to Danny F
    Prodigy 10 points

    I hear what you are saying, and while I agree with you in general, I think the API function should fail more gracefully.

    In other words, I'd agree with you if the Clock_create() function failed to provide a valid handle. In this case, it would be nice if they documented that the timeout could not be 0 for this function. But returning a valid handle is misleading. This leaves the user having to figure out that the clock isn't working properly at runtime, which could end up being pretty difficult in many applications.

    It seems this isn't a case of needing a nanny to hold your hand, or read the manual to you, but rather a case where the documentation was incomplete - but even worse - the implementation of the function is misleading. Shame on him if he didn't check the value that's returned, but shame on them if they return a valid handle to a non-working object.

    FWIW,
    Scott

**Attention** This is a public forum