MCXN236VNLT custom board - RTC0 Peripheral hanging code when clock enabled

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

MCXN236VNLT custom board - RTC0 Peripheral hanging code when clock enabled

Jump to solution
1,007 Views
jmullen_condose
Contributor III

I have an MCXN236VNLT custom board being developed. When I enable the RTC0 Peripheral the MCU hangs and my Cyclone loses connection when I enable the clock then access any registers on the RTC0.  clock_config.c does the following:

CLOCK_SetPLL0Freq(&pll0Setup); /*!< Configure PLL0 to the desired values */

CLOCK_SetPll0MonitorMode(kSCG_Pll0MonitorDisable); /* Pll0 Monitor is disabled */

CLOCK_SetupOsc32KClocking(kCLOCK_Osc32kToVbat); /* OSC_32 kHz output clock to Vbat enabled */

vbat_osc_config_t g_vbatOscConfig_BOARD_BootClockPLL150M = {

.coarseAdjustment = kVBAT_OscCoarseAdjustment05,

.enableInternalCapBank = true,

.enableCrystalOscillatorBypass = true,

.xtalCap = kVBAT_OscXtal12pFCap,

.extalCap = kVBAT_OscExtal12pFCap,

};

VBAT_SetOscConfig(VBAT0, &g_vbatOscConfig_BOARD_BootClockPLL150M);

SYSCON->CLOCK_CTRL |= SYSCON_CLOCK_CTRL_FRO1MHZ_CLK_ENA_MASK; /*!< Enable FRO_1M is on */

CLOCK_EnableClock(kCLOCK_Rtc0);
RTC0->CTRL |= RTC_CTRL_CLK_SEL_MASK; (HANGS HERE!)

 

If I skip that line in the debugger, MCU startup continues until any other code tries to access any register on the RTC0.
I have tried everything I can think of so far. Systick and MRT are also running, with higher priority Interrupts, but even when disabled, it just seems to be a clock issue with RTC0.

Strangely, when MCUxpresso stops connecting, it opens a tab for "ADC0_IRQHandler() at 0x0" and displays "No source available for "ADC0_IRQHandler() at 0x0" "

I am using an external 32768 crystal, if I change the clock to the internal 16k one, the code runs a bit further, to:

 

status_t IRTC_Init(RTC_Type *base, const irtc_config_t *config)

{

assert(NULL != config);

 

and fails at the "assert". "config" = the configuration, not NULL, so what's up with that? Ugh!

 

Any fresh eyes or ideas, much appreciated!

 

 

Labels (1)
Tags (2)
0 Kudos
Reply
1 Solution
902 Views
Celeste_Liu
NXP Employee
NXP Employee

Hello @jmullen_condose ,

Thank you for your post. As you mentioned in iRTC failed to initialized using 32k osc on MCXN947, this issue is caused by the requirement to provide a clock source before RTC initialization and access to the RTC registers.

By default, the RTC CTRL[CLK_SEL] bitfield selects the FRO16K clock source. Therefore, the FRO16K clock must remain enabled until the RTC CTRL[CLK_SEL] is switched to the OSC32K clock source. This is the only correct way to properly initialize the RTCCLKSEL clock selector.

In addition, I will also create an internal ticket for MCXN236. Before a permanent fix is available, please refer to the workaround described in that post.

Hope it helps.

BR

Celeste

View solution in original post

0 Kudos
Reply
1 Reply
903 Views
Celeste_Liu
NXP Employee
NXP Employee

Hello @jmullen_condose ,

Thank you for your post. As you mentioned in iRTC failed to initialized using 32k osc on MCXN947, this issue is caused by the requirement to provide a clock source before RTC initialization and access to the RTC registers.

By default, the RTC CTRL[CLK_SEL] bitfield selects the FRO16K clock source. Therefore, the FRO16K clock must remain enabled until the RTC CTRL[CLK_SEL] is switched to the OSC32K clock source. This is the only correct way to properly initialize the RTCCLKSEL clock selector.

In addition, I will also create an internal ticket for MCXN236. Before a permanent fix is available, please refer to the workaround described in that post.

Hope it helps.

BR

Celeste

0 Kudos
Reply