SAML21 RTC SYNCBUSY Lock-up - Page 1
Forum section: electronics / general

author: cburgess
author_rank: Contributor
timestamp: August 16, 2022, 01:47:12 pm
content: We've got a real head-scratcher with the SAML21 RTC peripheral at the moment.It is only present on some of our boards - which leads us to think there may be a hardware influenceAll we are doing is:Set the SWRST bit in the CTRLA register to reset the peripheralWait until the SWRST bit clears in the SYNCBUSY register - this stalls on the "bad" boardsRTC is using the external 32kHz crystal oscillator - which we know is good because we are using the same clock for a timer and also the DFLL - we are getting the expected 48MHzClock configuration is:/* Turn on the digital interface clock */system_apb_clock_set_mask(SYSTEM_CLOCK_APB_APBA, MCLK_APBAMASK_RTC);/* Select RTC clock */OSC32KCTRL->RTCCTRL.reg = RTC_CLOCK_SELECTION_XOSC32K;/* Reset module to hardware defaults. */rtc_count_reset();... we are locking-up in "rtc_count_reset" waiting for SYNCBUSY to clearAny clues?~ Carl ~

author: ataradov
author_rank: Super Contributor
timestamp: August 16, 2022, 05:51:28 pm
content: Are you sure it is actually running? Do you see oscillations on the pins?DFLL will keep on running even without reference clock. It won't be as accurate, but it will produce something close to 48 MHz.

author: cburgess
author_rank: Contributor
timestamp: August 16, 2022, 07:12:42 pm
content: A bit more testing:XOSC32 is running - this feeds GCLK1 which in turn drives TC2 - we see TC2 incrementingChanged RTC to use RTC_CLOCK_SELECTION_ULP32K - problem is still there.Tried this:RTC->MODE0.COMP.reg = 0xABCD;while (RTC->MODE0.SYNCBUSY.reg) { }This works (I can see the value in the debugger) which implies the RTC is getting a clockthen:RTC->MODE0.CTRLA.reg = RTC_MODE0_CTRLA_SWRST;while (RTC->MODE0.SYNCBUSY.reg) { }- The previously written COMP register is now zero, but we get stuck in the SYNCBUSY test...- Also the SWRST bit in CTRLA is stuck at '1'

author: ataradov
author_rank: Super Contributor
timestamp: August 16, 2022, 07:47:12 pm
content: In cases like this I just create the simplest application I can that still reproduces the issue. Start with the default clock for the GCLK0 and not enabling any other clock sources or peripherals.There are too many things that can potentially go wrong. One thing to check for sure is that you are setting PL value correct.

author: cburgess
author_rank: Contributor
timestamp: August 17, 2022, 06:48:56 am
content: OKPLCFG = 2 - so we were running at PL2 and enabled.Running GCLK0 with OSC16M and the problem goes away.I think we may be homing in on the problem

author: ataradov
author_rank: Super Contributor
timestamp: August 17, 2022, 06:56:05 am
content: And just double checking - you have flash wait states (RWS) set correctly as well? It should not lead to locks like this, but worth checking anyway.Try running from the DFLL, but use OSCULP32K as a reference for the FDLL.And still, check that the crystal oscillator is actually running. Either by observing the XIN/XOUT pins or by connecting it to one if the GCLK_IO [ x ] pins.

author: cburgess
author_rank: Contributor
timestamp: August 17, 2022, 08:30:28 am
content: We're running with 2 wait states : system_flash_set_waitstates(2); - confirmed by inspecting NVMCTRL->CTRLBManaged to get GCLK1 (XOSC32) onto PA15 - 'scope showing 32.77kHz with σ = 4.46Hz, 47% duty cycle - looks cleanGoing to try OSCULP32K for the FDLL now

author: cburgess
author_rank: Contributor
timestamp: August 17, 2022, 02:09:28 pm
content: Running with OSCULP32K for the DFLL made no difference.I noticed that Table 46-6 Maximum Peripheral Clock Frequencies has the APBA clock frequency pegged at 6MHz for PL0 & PL2when Clock domain = BACKUPThis change seems to have fixed it:system_backup_clock_set_divider(SYSTEM_MAIN_CLOCK_DIV_8);

author: ataradov
author_rank: Super Contributor
timestamp: August 17, 2022, 03:27:42 pm
content: Oh, yes, you need to respect maximum clock frequencies.