CC3220SF-LAUNCHXL: RTC Wrong readings

By the way, how to read the RTC value directly from the internal registers? I cannot find them in the CC3220SF datasheet.

Hnz wrote:
RTC is in NWP (network processor) and from this reason you need to use sl_ API for get/set RTC value.

I'm confused about the Slow Clock then.
The docs (SWRU465) says:

page 496: Hibernate mode (HIB) - Wake on RTC (for example, the 32-KHz slow clock counter) or selected GPIO

page 504: Hibernate (HIB) - Slow clock counter – Always-on 32.768-KHz counter

page 506: Slow Clock Counter - The CC32xx has a 48-bit on-chip always-on slow counter running at 32.768 KHz, which can wake up the
device from hibernate low-power mode


Hence RTC = Slow Clock.

Furthermore here the implementation of PRCMSlowClkCtrGet:

unsigned long long PRCMSlowClkCtrGet()
{
  unsigned long long ullRTCVal;

  //
  // Latch the RTC vlaue
  //
  PRCMHIBRegWrite(HIB3P3_BASE+HIB3P3_O_MEM_HIB_RTC_TIMER_READ, 0x1);

  //
  // Read latched values as 2 32-bit vlaues
  //
  ullRTCVal  = PRCMHIBRegRead(HIB3P3_BASE + HIB3P3_O_MEM_HIB_RTC_TIMER_MSW);
  ullRTCVal  = ullRTCVal << 32;
  ullRTCVal |= PRCMHIBRegRead(HIB3P3_BASE+HIB3P3_O_MEM_HIB_RTC_TIMER_LSW);

  return ullRTCVal;
}

where is even more clear that the SlowClock IS the RTC.

So, please, would you help me to understand why I need to use the slDeviceGet function?

Hi,

I removed this post because it was not 100% correct. Functionality of PRCM peripheral is little bit more complex due to shared resources with NWP.

Jan

Mark,

What does the structure look like for tm t? In your previous post, you took dateTime, and put it into a new structure called tm.

Can you check if dateTime is correct before you move this to your new struct?

VR

I did. Just few posts later. It's the dateTime structure that is wrong, with one bit set.

Alright i see it.

What is inside your SImpleLink init function?

VR

Here it is:

static int32_t InitSimplelink(uint8_t const role)
{
    s_AppContext * const pCtx = &gAppCtx;
    _i32 ret = -1;

    pCtx->role = role;
    pCtx->currentState = APP_STATE_STARTING;
    pCtx->pendingEvents = 0;

    // DNS
    SlNetAppDnsClientTime_t Time;
    Time.MaxResponseTime = 2000;
    Time.NumOfRetries = 10;
    ret = sl_NetAppSet(SL_NETAPP_DNS_CLIENT_ID, SL_NETAPP_DNS_CLIENT_TIME, sizeof(Time), (_u8*) &Time);
    ASSERT_ON_ERROR(ret);

    // Disable IPv6
    _u32 ifBitmap = 0;
    ret = sl_NetCfgSet(SL_NETCFG_IF, SL_NETCFG_IF_STATE, sizeof(ifBitmap), (uint8_t *) &ifBitmap);
    ASSERT_ON_ERROR(ret);

    SignalEvent(APP_EVENT_STARTED);
    pCtx->asyncEvtTimeout = ASYNC_EVT_TIMEOUT;
    StartAsyncEvtTimer();
    return ret;
}

Thank you very much for your support.

MAJOR UPDATE

I set up a very simple firmware to do another test:

void ApplicationTask(void)
{
    InitSimplelink(ROLE_STA);

    for (;;)
    {
        GetEpoch();
        Platform_Sleep(100);
    }
}

time_t GetEpoch(void)
{
    _i16 ret;
    _u8 pConfigOpt = SL_DEVICE_GENERAL_DATE_TIME;
    _u16 pConfigLen = sizeof(SlDateTime_t);

    // read RTC 
    SlDateTime_t dateTime = {0};
    ret = sl_DeviceGet(SL_DEVICE_GENERAL, &pConfigOpt, &pConfigLen, (unsigned char *) &dateTime);
    ASSERT_ON_ERROR(ret);

    // convert to epoch time
    struct tm t;
    time_t t_of_day;
    t.tm_year = dateTime.tm_year - 1900;
    t.tm_mon = dateTime.tm_mon - 1;
    t.tm_mday = dateTime.tm_day;
    t.tm_hour = dateTime.tm_hour;
    t.tm_min = dateTime.tm_min;
    t.tm_sec = dateTime.tm_sec;
    t.tm_isdst = -1;
    t_of_day = mktime(&t);

    // read Slow Clock Counter
    _u32 slowClk = PRCMSlowClkCtrGet();

    // print out all
    UART_PRINT("%d/%d/%d %d:%d:%d\t%lld\t%ld\r\n", dateTime.tm_year, dateTime.tm_mon, dateTime.tm_day, dateTime.tm_hour, dateTime.tm_min, dateTime.tm_sec, t_of_day, slowClk);
    return t_of_day;
}

In few minutes I got several errors in the dateTime readings:

dateTime	mktime	slow clock	/ 32768
2013/1/1 0:4:24	1356998664	8652950	264
2013/1/1 0:4:24	1356998664	8656423	264
2017/4/3 10:46:32	1491216392	8659897	264
2013/1/1 0:4:24	1356998664	8663370	264
2013/1/1 0:4:24	1356998664	8666844	264

2013/1/1 0:8:21	1356998901	16433816	501
2013/1/1 0:8:21	1356998901	16437290	501
2017/4/3 10:50:29	1491216629	16440763	501
2013/1/1 0:8:21	1356998901	16444237	501
2013/1/1 0:8:21	1356998901	16447711	501

2013/1/1 0:8:56	1356998936	17587047	536
2013/1/1 0:8:56	1356998936	17590520	536
2017/4/3 10:51:4	1491216664	17593994	536
2013/1/1 0:8:57	1356998937	17597468	537
2013/1/1 0:8:57	1356998937	17600941	537

The firmware ran for 17 minutes:

• about 9750 calls to sl_DeviceGet() and PRCMSlowClkCtrGet()
• 14 are wrong!
• the difference between correct values is always 134.217.728 which is 0x0800 0000

But the slow clock values are always correct!

Hence, I assume the problem is in the sl_DeviceGet() function. Of course maybe I'm using it wrongly. I followed the manuals but as you can see from my other posts there are a lot of mistakes in them.

 

Please, help us to fix this weird behavior. We're behind the deadline to delivery 1000 boards to our customers due to this problem.

 

Hi,

I tested same thing with my CC3220SF (RTC value get was integrated into my code). I called sl_DeviceGet() four times per second all of 6000 readings returned proper value. My cca3220SF was in AP mode with connected client(s). It was used SDK version 1.60 and latest ServicePack.

Value 0x08000000 looks like a problem with some signed/unsigned values or some kind of memory overflow. I am not able simulate this issue, please wait for answer from TI if they was able do that.

Jan

Thank you very much for the taking the time to test it. I also cannot reproduce the problem with ALL boards. But there's no evidence (at the moment) of an hardware failure that could lead to such a behavior.

Hi,

Just to be sure, do you have same ServicePack version inside all your boards?

Jan

Yes, currently I'm running SDK 1.50.00.06 and ServicePack sp_3.5.0.0_2.0.0.0_2.2.0.5.bin. I know there's a newer SDK but it seems does not add anything useful to my application and because we're going to delivery the products there's no time to try risky things like updates.

EDIT: of course until there is an evidence that they fixed something about RTC - but looking at the change log here it doesn't seem so.

I gave a try with the newer SDK - nothing has changed. The errors are the same.