I'm running the FATFS example on "System A", the ATSAME54 XPlained Pro board. I'm running the identical code on "System B", a custom ATSAME54 board.
On System A, the code runs fine.
On System B, the code hangs waiting for the RTC to sync:
atmel_start_init()
. system_init()
. . CALENDAR_INTERFACE_INIT()
. . . calendar_init(&CALENDAR_INTERFACE, RTC)
. . . . _calendar_init(&calendar->device)
. . . . . hri_rtcmode0_get_CTRLA_ENABLE_bit(dev->hw)
. . . . . . hri_rtcmode0_wait_for_sync(hw, _SWRESET | _ENABLE | _COUNTSYNC)
. . . . . . . while (((Rtc *)hw)->MODE0.SYNCBUSY.reg & reg) {}
Both systems are configured with identical clock settings (both systems are running the same firmware!).
Both systems have an external 32KHz xtal and an external 12MHz main xtal.
Both processors are Rev A silicon.
In Atmel START => Dashboard => CALENDAR_INTERFACE, I've checked the "Force reset RTC on initialization", so I *assume* that would force a reset of the RTC on initialization.
If I explicitly do a software reset on the RTC before the call to CALENDAR_INTERFACE_INIT(), System B does not hang:
// perform a software reset on RTC
hri_rtcmode0_set_CTRLA_SWRST_bit(RTC);
hri_rtcmode0_wait_for_sync(RTC, RTC_MODE0_SYNCBUSY_SWRST);
CALENDAR_INTERFACE_init();
Two questions:
- Can you think of any reason that System B (the custom SAME54 board) would hang, while System A (the stock SAME54 Xplained Pro board) does not?
- Shouldn't Atmel START have generated code to reset the RTC?
Perhaps there is some stored state that's not erased during programming that's making the difference?
Environment:
- Microchip Studio Version 7.0.2542
- Atmel Kits (7.0.132)
- ASF (3.49.1)
- Atmel START (1.0.198.0)
- Windows 10 Pro v 21H1
