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,084 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
979 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
980 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
%3CLINGO-SUB%20id%3D%22lingo-sub-2355434%22%20slang%3D%22en-US%22%20mode%3D%22CREATE%22%3EMCXN236VNLT%20custom%20board%20-%20RTC0%20Peripheral%20hanging%20code%20when%20clock%20enabled%3C%2FLINGO-SUB%3E%3CLINGO-BODY%20id%3D%22lingo-body-2355434%22%20slang%3D%22en-US%22%20mode%3D%22CREATE%22%3E%3CP%3EI%20have%20an%20MCXN236VNLT%20custom%20board%20being%20developed.%20When%20I%20enable%20the%20RTC0%20Peripheral%20the%20MCU%20hangs%20and%20my%20Cyclone%20loses%20connection%20when%20I%20enable%20the%20clock%20then%20access%20any%20registers%20on%20the%20RTC0.%26nbsp%3B%20clock_config.c%20does%20the%20following%3A%3C%2FP%3E%3CDIV%3E%3CDIV%3E%3CP%3E%3CSPAN%3ECLOCK_SetPLL0Freq(%26amp%3Bpll0Setup)%3B%20%3C%2FSPAN%3E%3CSPAN%3E%2F*!%26lt%3B%20Configure%20PLL0%20to%20the%20desired%20values%20*%2F%3C%2FSPAN%3E%3C%2FP%3E%3CP%3E%3CSPAN%3ECLOCK_SetPll0MonitorMode(%3C%2FSPAN%3E%3CSPAN%3EkSCG_Pll0MonitorDisable%3C%2FSPAN%3E%3CSPAN%3E)%3B%20%3C%2FSPAN%3E%3CSPAN%3E%2F*%20Pll0%20Monitor%20is%20disabled%20*%2F%3C%2FSPAN%3E%3C%2FP%3E%3CP%3E%3CSPAN%3ECLOCK_SetupOsc32KClocking(%3C%2FSPAN%3E%3CSPAN%3EkCLOCK_Osc32kToVbat%3C%2FSPAN%3E%3CSPAN%3E)%3B%20%3C%2FSPAN%3E%3CSPAN%3E%2F*%20OSC_32%20kHz%20output%20clock%20to%20%3C%2FSPAN%3E%3CSPAN%3EVbat%3C%2FSPAN%3E%3CSPAN%3E%20enabled%20*%2F%3C%2FSPAN%3E%3C%2FP%3E%3CP%3E%3CSPAN%3Evbat_osc_config_t%3C%2FSPAN%3E%3CSPAN%3E%20g_vbatOscConfig_BOARD_BootClockPLL150M%20%3D%20%7B%3C%2FSPAN%3E%3C%2FP%3E%3CP%3E%3CSPAN%3E.coarseAdjustment%20%3D%20%3C%2FSPAN%3E%3CSPAN%3EkVBAT_OscCoarseAdjustment05%3C%2FSPAN%3E%3CSPAN%3E%2C%3C%2FSPAN%3E%3C%2FP%3E%3CP%3E%3CSPAN%3E.enableInternalCapBank%20%3D%20true%2C%3C%2FSPAN%3E%3C%2FP%3E%3CP%3E%3CSPAN%3E.enableCrystalOscillatorBypass%20%3D%20true%2C%3C%2FSPAN%3E%3C%2FP%3E%3CP%3E%3CSPAN%3E.xtalCap%20%3D%20%3C%2FSPAN%3E%3CSPAN%3EkVBAT_OscXtal12pFCap%3C%2FSPAN%3E%3CSPAN%3E%2C%3C%2FSPAN%3E%3C%2FP%3E%3CP%3E%3CSPAN%3E.extalCap%20%3D%20%3C%2FSPAN%3E%3CSPAN%3EkVBAT_OscExtal12pFCap%3C%2FSPAN%3E%3CSPAN%3E%2C%3C%2FSPAN%3E%3C%2FP%3E%3CP%3E%3CSPAN%3E%7D%3B%3C%2FSPAN%3E%3C%2FP%3E%3CP%3E%3CSPAN%3EVBAT_SetOscConfig(VBAT0%2C%20%26amp%3Bg_vbatOscConfig_BOARD_BootClockPLL150M)%3B%3C%2FSPAN%3E%3C%2FP%3E%3CP%3E%3CSPAN%3ESYSCON-%26gt%3B%3C%2FSPAN%3E%3CSPAN%3ECLOCK_CTRL%3C%2FSPAN%3E%3CSPAN%3E%20%7C%3D%20SYSCON_CLOCK_CTRL_FRO1MHZ_CLK_ENA_MASK%3B%20%3C%2FSPAN%3E%3CSPAN%3E%2F*!%26lt%3B%20Enable%20FRO_1M%20is%20on%20*%2F%3C%2FSPAN%3E%3C%2FP%3E%3CP%3E%3CSPAN%3ECLOCK_EnableClock(%3C%2FSPAN%3E%3CSPAN%3EkCLOCK_Rtc0%3C%2FSPAN%3E%3CSPAN%3E)%3B%3CBR%20%2F%3ERTC0-%26gt%3BCTRL%20%7C%3D%20RTC_CTRL_CLK_SEL_MASK%3B%20(HANGS%20HERE!)%3CBR%20%2F%3E%3C%2FSPAN%3E%3C%2FP%3E%3CBR%20%2F%3E%3CP%3E%3CSPAN%3EIf%20I%20skip%20that%20line%20in%20the%20debugger%2C%20MCU%20startup%20continues%20until%20any%20other%20code%20tries%20to%20access%20any%20register%20on%20the%20RTC0.%3CBR%20%2F%3EI%20have%20tried%20everything%20I%20can%20think%20of%20so%20far.%20Systick%20and%20MRT%20are%20also%20running%2C%20with%20higher%20priority%20Interrupts%2C%20but%20even%20when%20disabled%2C%20it%20just%20seems%20to%20be%20a%20clock%20issue%20with%20RTC0.%3C%2FSPAN%3E%3C%2FP%3E%3CP%3E%3CSPAN%3EStrangely%2C%20when%20MCUxpresso%20stops%20connecting%2C%20it%20opens%20a%20tab%20for%20%22ADC0_IRQHandler()%20at%200x0%22%20and%20displays%20%22No%20source%20available%20for%20%22ADC0_IRQHandler()%20at%200x0%22%26nbsp%3B%22%3C%2FSPAN%3E%3C%2FP%3E%3CP%3E%3CSPAN%3EI%20am%20using%20an%20external%2032768%20crystal%2C%20if%20I%20change%20the%20clock%20to%20the%20internal%2016k%20one%2C%20the%20code%20runs%20a%20bit%20further%2C%20to%3A%3C%2FSPAN%3E%3C%2FP%3E%3CBR%20%2F%3E%3CDIV%3E%3CDIV%3E%3CP%3E%3CSPAN%3Estatus_t%3C%2FSPAN%3E%20%3CSPAN%3EIRTC_Init%3C%2FSPAN%3E%3CSPAN%3E(%3C%2FSPAN%3E%3CSPAN%3ERTC_Type%3C%2FSPAN%3E%3CSPAN%3E%20*base%2C%20%3C%2FSPAN%3E%3CSPAN%3Econst%3C%2FSPAN%3E%20%3CSPAN%3Eirtc_config_t%3C%2FSPAN%3E%3CSPAN%3E%20*config)%3C%2FSPAN%3E%3C%2FP%3E%3CP%3E%3CSPAN%3E%7B%3C%2FSPAN%3E%3C%2FP%3E%3CP%3E%3CSPAN%3Eassert(NULL%20!%3D%20config)%3B%3C%2FSPAN%3E%3C%2FP%3E%3CBR%20%2F%3E%3CP%3E%3CSPAN%3Eand%20fails%20at%20the%20%22assert%22.%20%22config%22%20%3D%20the%20configuration%2C%20not%20NULL%2C%20so%20what's%20up%20with%20that%3F%20Ugh!%3C%2FSPAN%3E%3C%2FP%3E%3CBR%20%2F%3E%3CP%3E%3CSPAN%3EAny%20fresh%20eyes%20or%20ideas%2C%20much%20appreciated!%3C%2FSPAN%3E%3C%2FP%3E%3CBR%20%2F%3E%3C%2FDIV%3E%3C%2FDIV%3E%3CBR%20%2F%3E%3C%2FDIV%3E%3C%2FDIV%3E%3C%2FLINGO-BODY%3E%3CLINGO-LABS%20id%3D%22lingo-labs-2355434%22%20slang%3D%22en-US%22%20mode%3D%22CREATE%22%3E%3CLINGO-LABEL%3EMCXN%3C%2FLINGO-LABEL%3E%3C%2FLINGO-LABS%3E%3CLINGO-SUB%20id%3D%22lingo-sub-2356383%22%20slang%3D%22en-US%22%20mode%3D%22CREATE%22%20translate%3D%22no%22%3ERe%3A%20MCXN236VNLT%20custom%20board%20-%20RTC0%20Peripheral%20hanging%20code%20when%20clock%20enabled%3C%2FLINGO-SUB%3E%3CLINGO-BODY%20id%3D%22lingo-body-2356383%22%20slang%3D%22en-US%22%20mode%3D%22CREATE%22%3E%3CP%3EHello%26nbsp%3B%3CA%20href%3D%22https%3A%2F%2Fcommunity.nxp.com%2Ft5%2Fuser%2Fviewprofilepage%2Fuser-id%2F8905%22%20target%3D%22_blank%22%3E%40jmullen_condose%3C%2FA%3E%26nbsp%3B%2C%3C%2FP%3E%0A%3CDIV%3E%0A%3CP%3EThank%20you%20for%20your%20post.%20As%20you%20mentioned%20in%20%3CA%20href%3D%22https%3A%2F%2Fcommunity.nxp.com%2Ft5%2FMCX-Microcontrollers%2FiRTC-failed-to-initialized-using-32k-osc-on-MCXN947%2Fm-p%2F2355961%2Femcs_t%2FS2h8ZW1haWx8dG9waWNfc3Vic2NyaXB0aW9ufE1PRDRaVERLOFpKMUcxfDIzNTU5NjF8U1VCU0NSSVBUSU9OU3xoSw%23M5291%22%20target%3D%22_blank%22%3EiRTC%20failed%20to%20initialized%20using%2032k%20osc%20on%20MCXN947%3C%2FA%3E%2C%20this%20issue%20is%20caused%20by%20the%20requirement%20to%20provide%20a%20clock%20source%20before%20RTC%20initialization%20and%20access%20to%20the%20RTC%20registers.%3C%2FP%3E%0A%3CP%3EBy%20default%2C%20the%20RTC%20CTRL%5BCLK_SEL%5D%20bitfield%20selects%20the%20FRO16K%20clock%20source.%20Therefore%2C%20the%20FRO16K%20clock%20must%20remain%20enabled%20until%20the%20RTC%20CTRL%5BCLK_SEL%5D%20is%20switched%20to%20the%20OSC32K%20clock%20source.%20This%20is%20the%20only%20correct%20way%20to%20properly%20initialize%20the%20RTCCLKSEL%20clock%20selector.%3C%2FP%3E%0A%3CP%3EIn%20addition%2C%20I%20will%20also%20create%20an%20internal%20ticket%20for%20MCXN236.%20Before%20a%20permanent%20fix%20is%20available%2C%20please%20refer%20to%20the%20workaround%20described%20in%20that%20post.%3C%2FP%3E%0A%3CP%3EHope%20it%20helps.%3C%2FP%3E%0A%3CP%3EBR%3C%2FP%3E%0A%3CP%3ECeleste%3C%2FP%3E%0A%3C%2FDIV%3E%3C%2FLINGO-BODY%3E