CCS/CC3200SDK: RTC problem CC3200

Hi,

Have you checked to ensure that you are not running into any overflow or wraparound issues? The RTC register is 32 bits wide, so after about 10 hours you will be approaching the max value of a signed 32bit integer.

Also, how are you setting up and using the RTC? Are you using the SimpleLink APIs to set the RTC, or are you accessing the RTC directly through the PRCM driverlib functions? If you could include the code you are using for your RTC functionality that would be useful for understanding your use case.

Regards,

Michael

Hi Michael 

thinks for thank you for quick answer.

I already checked well if i have any overflow , in addition this issue don't need 10 hours to happen, some time after 2 hours or 6 hours so i don't think i reach the maximum value of RTC register.

I can't give you all code because he is integrated in our project and he is to long and  little complicated because we use RTC to take measurement in adequate time(each second) for our sensor.

but this a resume of RTC configuration and how we use it in our project.

/*--------------------------------------- initialize RTC--------------------------------------------- */ 

bool bTimeOk;

bTimeOk_ = MAP_PRCMRTCInUseGet();
IntPrioritySet(INT_PRCM, 2);// set interrupt priority 

uint32_t PRCMIntStatusV = MAP_PRCMIntStatus(); //clear interrupt 
MAP_PRCMIntRegister(PRCM_INT_Handler);

/* -------------------------------------Set RTC current time -----------------------------------------*/

// firstly take current time from NTP server 

// Set time given by NTP server to RTC 

MAP_PRCMRTCInUseSet();

MAP_PRCMRTCSet(NTP.second1970, NTP.subsecond);

/* -------------------------------------------Now we start using RTC---------------------------------------*/

// firstly we take current time with fonction  : vVcGetUnixTime(UnixTime_t* pxTime) . Note : pxTime is a struct which contain second and millisecond.

void vVcGetUnixTime(UnixTime_t* pxTime)

{

MAP_PRCMRTCGet((unsigned long*)&(pxTime->second1970), &(pxTime->subsecond));
while(pxTime->subsecond > 999)
{
pxTime->second1970++;
pxTime->subsecond -= 1000;
}

}

// then we configure  RTC to generate interrupt next second + 0 millisecond with fonction : vVcTimerStart(xVcTimer_t *pxTimer)

void vVcTimerStart(xVcTimer_t *pxTimer)

{

MAP_PRCMRTCMatchSet(pxVcTimer->u32StartSec1970, pxVcTimer->u32StartMilis);
uint32_t PRCMIntStatusV = MAP_PRCMIntStatus(); //clear int
MAP_PRCMIntEnable(PRCM_INT_SLOW_CLK_CTR);

}

// Then we configure RTC to generate interrupt current second + 500 millisecond with fonction : vVcTimerStart(xVcTimer_t *pxTimer)  in wake up  we initialize our hard configuration for our sensor.

// then we configure  RTC to generate interrupt next second + 0 millisecond, in wake up  we start take  one measurement for our sensor then we shut down hard.

// Then we configure RTC to generate interrupt current second + 500 millisecond with fonction : vVcTimerStart(xVcTimer_t *pxTimer)  when we wake up we initialize our hard configuration for our sensor.

// then we configure  RTC to generate interrupt next second + 0 millisecond, in wake up  we start take   measurement for our sensor then we shut down hard.

.

.

and so on 

In function interrupt handler we just read the interrupt status which will cleared it with API : MAP_PRCMIntStatus(); and we do some configuration .

this is work well but after some hours the RTC wake up in fake time. some time before required time some time after. i cheched well in i have any overflow in RTC configuration for next wake up but all is ok. i checked a time when interrupt is generated with fonction : vVcGetUnixTime(UnixTime_t* pxTime),

I discovered that : some times the time back and forth !!!

Important Note :  I tested RTC only (not in our project ) and with same algorithm during 3 days : I didn't find this issue so whats wrong when  i use it in our project   

Sorry i know its too long. but any suggestion or ideas  would be very appreciated.

Best regards.

Hi,

It's interesting that you say that if you run your RTC code standalone then it works, but if you integrate it into the rest of your project then you get the behavior described.

Are you using an RTOS? If so, the RTC is likely managed by it, and would explain the issues you are seeing.

Have you ensured that your stack space and heap are adequate for your RTC + application?

Also, what do you mean by "shut down hard"? Do you mean you go into hibernate?

If you haven't done so already, please look through this wiki page on the prcm module: http://processors.wiki.ti.com/index.php/CC3200_Power_Management_Framework

It contains a good explanation on the CC3200 RTC and the middleware APIs that you could use for reference in your application.

Regards,
Michael

Hi Michael 

Think you again for those details

Yes i'm using FreeRTOS. do u think freeRTOS  has a effect on RTC ? .  if yes i really have curiosity to know how !! do u have any suggestion to resolve this issue. 

I know that freeRTOS use basically heap(malloc) and  each task  take space from stack but i dont know that RTC need stack to run during a long time. do you think it can be stack overflow after  after some time of RTC running.

I means by "shut down hard" go into low power deep sleep mode(not hibernate mode) , but i deactivate sleep mode and this issue is still exist.

 Best Regards.

Hi,

FreeRTOS is a third-party software platform, so we are not as familiar with it and cannot support it directly on this forum. I suggest you take a look a the FreeRTOS documentation and source code for details on its use of the RTC. I suspect that it needs the RTC in order to be able to keep track of the wall time during hibernate.

As for memory overflows, each task has stack space that is taken from the heap. The RTC shouldn't be using much stack at all, assuming it is indeed controlled and monitored by FreeRTOS. However, there could be some other memory issues such as a stack overflow in another task, or a bad pointer access that causes the RTC to be offset. I suggest you take a look at that as well.

Regards,

Michael