• State TI Thinks Resolved
  • Locked Locked
  • Replies 4 replies
  • Answers 1 answer
  • Subscribers 98 subscribers
  • Views 327 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/AM5728: Counter32k bug

Jussi Pajala
Prodigy 200 points

Part Number: AM5728

Tool/software: TI-RTOS

Hi,

I'd like to report a bug in file 

ti\pdk_am57xx_1_0_13\packages\ti\osal\src\nonos\counter_32k\v0\counter_32k.c

The function doesn't work with small millisecond values, because the "baseTime" is seen in the register for too long time.

The bug causes the function to bail out, because it is assumed that the timer is not running at all. See the code snippet below. The function works, if you replace the

if(exitCount == nTicks)  by  if(exitCount == 10000), for example.

if (sampTime == baseTime) {

exitCount++;

}
/* Exit the loop if counter_32k is not running */
if (exitCount == nTicks)
{

break;

}

BR,

--Jussi

  • 0
    TI__Guru** 116780 points

    Jussi,

    Can you please indicate or provide details on how you tested this issue in your setup. You indicated small millisecond values cause this issue, is the mechanism working with larger values and could you specify how small a value you have used with the setup.

    I will try to reproduce the issue at my end and report the issue if you can provide the details that I requested above.

    Regards,

    Rahul

  • 0 in reply to Rahul Prabhu
    Prodigy 200 points

    I was using 10ms delays to implement signal waveform using GPIO pins. Using oscilloscope I was able to verify, that most of the delays were very short (microseconds), while sometimes I got almost exactly 10ms that I was requesting.

    Using 500ms delays I would always get accurate delays.

    Also, I added debugging variable greatestExitCount to check what was the greatest "exitCount" variable value ever recorded. The variable was updated just before the return row:

    if(greatestExitCount < exitCount) greatestExitCount = exitCount;

    With a short test run I got greatestExitCount value of 49, which tells that delay shorter than 49 would sometimes bail out before the 32KHz clock had changed once. 

    BR,

    --Jussi

  • 0 in reply to Rahul Prabhu
    Prodigy 200 points

    Hi Rahul,

    was the information enough?

    BR,

    --Jussi

  • 0 in reply to Jussi Pajala
    TI__Guru** 116780 points

    Jussi,

    Yes, the information is enough. We are looking into this issue and trying to provide a fix for the issue. 

    Regards,

    Rahul