What is the maximum hibernate duration for the P2? The prototypes appear to accept system_tick_t (uint32_t) with a granularity of 1sec despite being in msec.
uint32_t 0xFFFF_FFFF => 49.71days, but I don't think that's true.
I have a suspicion the maximum hibernate is less than 1day.
What is the official stance on this maximum?
The timer API in the RTL872x SDK takes a uint32_t and a time in milliseconds, which implies a very long sleep duration.
However, basic timers use the 32 kHz peripheral clock. It looks like LPTIM0 - LPTIM3 don't have a prescaler, which implies that the counter might actually be in 32 kHz ticks. This would imply a maximum value of 131,072 seconds or 36 hours, which sort of fits your one day observation.
I do not know this to be the case, and I might have misunderstood the datasheet, but it's plausible.
Sleep uses a separate RTC/AON (always-on) timer which is 32kHz based with a max value of 0x3FFFFFFF. So, this should equal to 546 mins or ~9.1 hours.
Looks like we are missing an upper bounds check during sleep configuration validation, this should be fixed in the next 5.x release.
Documentation for maximum sleep duration for Gen 4 devices (P2, Photon 2, M-SoM) has been updated.
0x3FF_FFFF would be 67108.863s = 1118.48m = 18.64hr, but I have empirical evidence that contradicts 0x3FF_FFFF as the upper limit.
I have a theory that the maximum is actually 65535000msec = 65535s (0xFFFF sec). I'm running a test to prove that theory now. And I'll post my findings later tonight.
Sleep uses a separate RTC/AON (always-on) timer which is 32kHz based with a max value of 0x3FFFFFFF. So, this should equal to 546 mins or ~9.1 hours.
I missed that additional 0x3FFF_FFFF, so maybe I'm missing something in the calculation. Would you spoon-feed me on how the calculation is made using the 32kHz timer?
0x3fffffff * (1/(32768 Hz) /* period */) = 32768 seconds = 546 minutes = 9.1 hours.
Timer resolution is in seconds, not milliseconds.
Thank you. Yes, timer resolution is in seconds, but the API implies loading in msec, so the maximum value should be divide by 1000 to get the seconds, e.g., calling with 0xFFFF_FFFFmsec = 0x41_8937 sec (4294967sec).
I think the maximum is 18.2hrs
Just for reference:
Appreciate the source link. Yes, I agree with the SOCPS_AONTimer() being loaded with a u32 in seconds; however, how does the previous API load msec into a call that uses sec? You cannot guarantee the maximum 0x3FFF_FFFF since the Particle API suggests msec, which would require a divide by 1000.
There's some other kind of calculation that affects the entry into SOCPS_AONTimer()
Ok, my test has confirmed the 9.1hrs as @avtolstoy has mentioned.
But that is most likely setting the duration to 32767000msec = 32767sec = 546.116min = 9.10hr
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.