Work around various silicon errata

[theAlexes]

Per the Microchip docs, one erratum may freeze the microcontroller (the SUPC/VREG operating in standby), another may cause increased power consumption from the TRNG not being properly disabled, and a third can hard-fault the chip if a standby occurs at the same time as a SysTick. This patch applies the recommended workarounds.

Also, we noticed that the sleep controller documentation specifies that you have to wait for the value to settle in the sleep mode register before actually WFI-ing, so we've modified the HAL to do that.

[WesleyAC]

Thanks for catching these!

Could you add references to specific section/page/etc numbers in the manual? That would be useful just to double check that this is all good.

I'm also curious if you have an idea of whether the RUNSTDBY / STDBYPL0 will affect power usage, although if the docs suggest it we should presumably do it either way, especially given recent reports of freezing issues.

[theAlexes]

Thanks for catching these!

Could you add references to specific section/page/etc numbers in the manual? That would be useful just to double check that this is all good.

updated accordingly, and included a link to the errata in the GH description.

I'm also curious if you have an idea of whether the RUNSTDBY / STDBYPL0 will affect power usage, although if the docs suggest it we should presumably do it either way, especially given recent reports of freezing issues.

power consumption is something we're pretty fuzzy on, unfortunately.

[matheusmoreira]

Looks great to me. Well referenced and explained by the comments, ensuring any future readers know why things work this way.

[matheusmoreira]

I'm also curious if you have an idea of whether the RUNSTDBY / STDBYPL0 will affect power usage, although if the docs suggest it we should presumably do it either way, especially given recent reports of freezing issues.

power consumption is something we're pretty fuzzy on, unfortunately.

That seems to be case for us all. There are some power consumption figures in the sensor watch documentation but they were measured with a Power Profiler Kit II. Absent access to such a profiler, I don't believe any objective statements regarding the power cost of any proposed change can be made.

In any case, if the silicon errata tells us to do something, we should probably do it regardless of any impact on power consumption, right?

[matheusmoreira]

Am now running this code on the real hardware. No problems so far.

[matheusmoreira]

My Sensor Watch Lite board is apparently unable to enter sleep mode when running this code. Have you or anyone else experienced this sleep mode issue?

• Reproduced the issue with multiple low energy timer preferences set
  • 10 minutes
  • 1 hour
• Confirmed that the clock face is returning true from its loop
  • Via simulator debugging
  • Indicates that it's not blocking the sleep mode
• This is the only patch set in my branch which touches sleep mode

The most recent change in main to sleep mode functionality:

Sensor-Watch/movement/movement.c

Lines 529 to 536 in af18673

	// if we run through the loop again to time out, we need to reconsider whether or not we can sleep.
	// if the first trip said true, but this trip said false, we need the false to override, thus
	// we will be using boolean AND:
	//
	// first trip | can sleep | cannot sleep | can sleep | cannot sleep
	// second trip | can sleep | cannot sleep | cannot sleep | can sleep
	// && | can sleep | cannot sleep | cannot sleep | cannot sleep
	can_sleep = can_sleep && wf->loop(event, &movement_state.settings, watch_face_contexts[movement_state.current_face_idx]);

I suspect it could be somewhat related due to short circuiting behavior which is potentially unintended and might be a bug. This is what actually happens:

// first trip  | can sleep | cannot sleep | can sleep    | cannot sleep
// second trip | can sleep | never runs   | cannot sleep | never runs
//          && | can sleep | cannot sleep | cannot sleep | cannot sleep

I need further testing to determine what impact this has, if any. However it appears you authored this change so I was hoping you'd clarify.

[matheusmoreira]

This is the only patch set in my branch which touches sleep mode

I stand corrected. It seems to be working perfectly. I eventually isolated the issue to the deadline watch face, PR #266.

So far this has been tested on real hardware by both @theAlexes and myself. Seems stable.