+1 to the idea of being able to handle this at the module/package level to subscribe to 'shutdown' or 'sleep' events. The package level is the right place to handle this since the package itself is aware of the transport being used for drivers (I2C/SPI/etc.), and the pins that can be switched to an appropriate power-saving mode (disable internal pullups, etc.) and properly restored on wakeup. It does bring up the question of SRAM retention at the HAL level, though, and sharing access to whatever block of SRAM is being maintained in lower powder mode(s) if the scope here is larger than just 'shutting down' and 'starting up'?
> I guess device can be powered off simply as a power saving option or > shipping mode so perhaps 'reason' parameter could be added to shutdown > call. I do not know if it really matters to any package whether we shutdown > to reset device or just to power it off, but single extra parameter won't > hurt. > I think this is a good idea in situations where you might want to log the shutdown reason and perhaps check it on the next startup. For example, if we shutdown because the battery is critically low, and this is detected at the next startup, you can run through a config memory verification process, etc. Kevin
