MSPM0L2228: CIO impact on RTC_A

***

Part Number: MSPM0L2228
Other Parts Discussed in Thread: SYSCONFIG

I am temporarily using CIO for inital development before developing a dedicated UART debug peripheral. The CIO features I am using are: printf() and fprintf(). I am capturing log records that are about 218 bytes tagged with a RTC_A timestamp.

Based on my current understanding the RTC_A that is clocked by LFCLK: LFOSC, any CIO process should not impact the RTC_A operation.

Over the course of 30 minutes of logging, I am experiencing over 15 minutes of RTC_A timestamp lag. I am trying to understand why?

Any information or technical details regarding the CIO impact on RTC_A would be appreciated.

2 months ago

0 Diego Abad Sajamin 2 months ago

TI__Mastermind 28452 points

Hi ***,
Some follow up questions to understand better the question:

1. What are you referrring as CIO?

2. What are you considering as "RTC timestamp lag"?

Best Regards,

Diego Abad

0 Bruce McKenney 2 months ago

Guru 103285 points

I suspect you need to set the RTC 's DBGCTL:DBGRUN=1. (This appears to be in LFSS->IPSPECIFIC_RTC.DBGCTL). I also see DL_RTC_Common_enableDebugMode()

[Ref CCS ARM CC UG (SPNU151W) Sec 7.2.3 and MSPM0L TRM (SLAU847F) Table 30-21]

0 *** 2 months ago in reply to Diego Abad Sajamin

Prodigy 170 points

Hey Diego Abad Sajamin

Diego Abad Sajamin said:
1. What are you referrring as CIO?

Console I/O, using printf() or fprintf();

Diego Abad Sajamin said:
2. What are you considering as "RTC timestamp lag"?

RTC_A was not staying synch, for every iteration of the while(1) loop, the RTC_A started lagging.

0 Keith Barkley 2 months ago

Guru 44165 points

I believe the debugger uses a memory transfer tor CIO, as such it has to stop things to access the memory, As Bruce pointed out, you may be able to re-enable things on a case by case basis. This is why I just use the UART for basic debugging messages, and is pretty much the first thing added to a new development.

0 *** 2 months ago in reply to Keith Barkley

Prodigy 170 points

Keith Barkley , I agree. I have implemented a simple UART Tx operation since then. At this point, I mostly trying to feed my curiosity or understanding. Based on my TRM interpretation and CIO operation understanding, though MCU core will be halted to service the CIO operations, RTC_A should not be halted.

I will try Bruce McKenney recommendation and share my findings.

0 *** 2 months ago in reply to Bruce McKenney

Prodigy 170 points

Bruce McKenney, Can this be configurable via CCS or SysConfig? I am trying to see where it might be hidden in CCS or .syscfg.

0 Keith Barkley 2 months ago in reply to ***

Guru 44165 points

In CCS you might have to write directly to the register.

0 *** 2 months ago in reply to Keith Barkley

Prodigy 170 points

Keith Barkley , I will poke around, try and share my findings! Thank you to you all for your time!

0 Bruce McKenney 2 months ago in reply to ***

Guru 103285 points

I don't see a sysconfig mechanism for setting this. I expect you'll have to add a call to DL_RTC_Common_enableDebugMode(RTC_INST).

My thought was that, if the RTC weren't frozen at a breakpoint, the DBGRUN bit would be unnecessary.

[Edit: Minor clarification]

0 *** 2 months ago in reply to Bruce McKenney

Prodigy 170 points

Bruce McKenney , Diego Abad Sajamin , Keith Barkley

Bruce McKenney said:
I expect you'll have to add a call to DL_RTC_Common_enableDebugMode(RTC_INST).

I added the call as follows...

    GetTimeEST(&startTime);
    HAL_RTC_SetTime(&startTime);
    
    DL_RTC_Common_enableDebugMode(RTC_A);
  
    HAL_RTC_Enable();  

    delay_cycles(4000000);

    // Read the RTC
    HAL_RTC_GetTime(&currentTime);

RTC is now tracking time correctly and not lagging over time!

**Attention** This is a public forum

MSP low-power microcontrollers

MSP low-power microcontroller forum

MSPM0L2228: CIO impact on RTC_A