I have reviewed the SAMD51 datasheet regarding the DFLL operating during STANDBY and I am a bit uncertain regarding an ambiguity. Specifically, the DFLLCTRLA register description reads as follows:
**Bit 6 – RUNSTDBY **Run in Standby This bit controls how the DFLL behaves during standby sleep mode: 0: The DFLL is not running in standby sleep mode if no peripheral requests the clock. 1: The DFLL is running in standby sleep mode. If ONDEMAND is one, the DFLL will be running when a peripheral is requesting the clock. If ONDEMAND is zero, the clock source will always be running in standby sleep mode.
The ambiguity arises because it is not clear what happens during standby sleep mode when RUNSTDBY = 0. From the description, it appears the DFLL will be on when the device enters STANDBY mode. I had the understanding that in STANDBY mode, all clocks are suspended. I am familiar with using the SAMD21 sleep and the SAMD21 datasheet describes RUNSTDBY a little different:
**Bit 6 – RUNSTDBY **Run in Standby This bit controls how the DFLL behaves during standby sleep mode: 0: The oscillator is disabled in standby sleep mode. 1: The oscillator is not stopped in standby sleep mode. If DFLLCTRL.ONDEMAND is one, the clock source will be running when a peripheral is requesting the clock. If DFLLCTRL.ONDEMAND is zero, the clock source will always be running in standby sleep mode.
The SAMD21 description is pretty clear that the clock is disabled during standby which has been my experience when using the SAMD21. The SAMD51 description appears to disable the DFLL in standby with the caveat "if no peripheral requests the clock". This seems similar to the "ONDEMAND" functionality but appears to apply even when "ONDEMAND" is not set.
My experience with the SAMD51 is that I think I am not disabling it in STANDBY mode. I am experiencing quite high current during STANDBY (1.3mA) than I expect which suggests the DFLL is still running. I have been unable to determine otherwise any peripheral or I/O that is responsible for the additional sleep current. I have connected a debugger and inspected the CTRL registers for all the peripherals and they are either not enabled or do not use a GCLK where the DFLL is the source. In my use case, the DFLL is the source for GCLK0 (main clock) and GCLK2.
I read some earlier posts here regarding disabling the USB and I have confirmed that the USB is disabled (enable = 0). The RTC clocks from the OSC32KULP. SERCOM1, 2, 4 and 5 are enabled but RUNSTDBY is disabled. SERCOM3 is disabled. SERCOM0 is enabled as an I2C slave with RUNSTDBY on. The I2C bus was disconnected so there was no clocking or address match on that port. Moreover, I also did a test where I disabled SERCOM0 and it did not reduce the current.
So, I am wondering if by design, the DFLL it is not intended to stop during STANDBY? Any suggestions for why the sleep current is so high?