[Ovmsdev] questions on deep sleep

Fri Nov 18 21:42:16 HKT 2022

Patrick,

esp-idf 4 was a major break with both APIs and build framework of 
esp-idf 3. Espressif are now heading towards release 5, and I expect 
them to do the same again, obsoleting any work now done for esp-idf 4.

We added some stuff to the 3.3 release we needed, that wasn't all merged 
by Espressif. esp-idf 4/5 also require using the new xtensa toolkit / 
gcc release, so will need some further code rework from that as well.

TL;DR: it's not an easy migration.

There sure are a lot of fixes to gain, but there will also be new bugs. 
We should wait until release 5 is official, then go that way.

Regarding the deep sleep fix you found: you can try to backport that 
into the 3.3 code base if you think that will help.

It seems the fix is about disabling concurrency when calculating the RTC 
RAM CRC. A thought on this: we update RTC RAM whenever a persistent 
metric is updated.

Is it possible that happens while the ESP32 goes into deep sleep, 
corrupting the CRC?

We could explicitly stop all tasks (taskENTER_CRITICAL() / 
vTaskSuspendAll()) just before calling esp_deep_sleep() to avoid that.

Regards,
Michael

Am 15.11.22 um 09:20 schrieb Patrick Stein:
> @Michael: Thanx for all your answers - that helps me a lot.
>
> With your pointers I’ve started looking into esp documentation and found the *esp_get_deep_sleep_wake_stub* which would be exactly that kind of thing to run before the boot process, but using it does not work - it wakes from deepsleep and then enters a reset as it looks:
>
> ```
> I (1491) 12battery: sleepImmediately()2
> I (1491) 12battery: sleepImmediately()3
> I (4501) 12battery: sleepImmediately()4
> ets Jul 29 2019 12:21:46
>
> rst:0x5 (DEEPSLEEP_RESET),boot:0x1f (SPI_FAST_FLASH_BOOT)
> ets Jul 29 2019 12:21:46
>
> rst:0x7 (TG0WDT_SYS_RESET),boot:0x1f (SPI_FAST_FLASH_BOOT)
> configsip: 0, SPIWP:0xee
> clk_drv:0x00,q_drv:0x00,d_drv:0x00,cs0_drv:0x00,hd_drv:0x00,wp_drv:0x00
> mode:DIO, clock div:2
> ```
>
> I found that there was a bugfix for a sleep not using the wake stub code in https://github.com/espressif/esp-idf/issues/5983  and it seems the fix in https://github.com/espressif/esp-idf/commit/ff8d05466e83049bca44e1584891bfafc8c46cd7 is not OVMS.
>
> Maybe that’s also the problem with the buggy coming out of deepsleep behaviour with OVMS as well ?
> Are there so many changes in OVMS esp_idf part that OVMS can’t use the newest (presumably less buggy?) version of esp_idf ?
>
> Excuse my newbie questions - I’m not used to embedded programming or esp development.
>
> Regards, Patrick aka @jollyjinx
>
>
>> On 14. Nov 2022, at 17:26, Michael Balzer <dexter at expeedo.de> wrote:
>>
>> Patrick,
>>
>> Am 14.11.22 um 10:25 schrieb Patrick Stein:
>>>> As written in the issue discussion, there's a minimum load from the unswitchable components. In deep sleep mode, that's around 155 mW with the GPS antenna attached, and ~ 100 mW with GPS antenna detached. An option to control the GPS antenna could be using a simple 12V relay, either on SW_12V or on the ignition 12V line, to switch the antenna's GND connection.
>>>>
>>> I’ve never seen such a low value - lowest I’ve seen is 250 mW in deep sleep with all my four modules.
>> I did the measurements using a USB power meter, just verified with a multimeter for 12V (11.6V Lipo), which gave slightly higher results:
>>      • base load in Wifi mode, GPS antenna attached ~ 60 mA / 700 mW
>>      • sleep, GPS antenna attached ~ 16 mA / 180 mW
>>      • sleep, GPS antenna detached ~ 11 mA / 130 mW
>>
>> So nowhere near 250 mW. Mark, any idea about this?
>>
>>> About the 12v antenna switch that would make total sense to me to be able to switch that on/off. I can solder and have the equipment, but I’m not really into hardware modding. Can someone point me on what wires on the board need to be modified for that ?
>> I meant making your own external GPS antenna cable including the relay. Within the module you could use a custom pigtail cable, but I wouldn't recommend that, as these are fragile.
>>
>>
>>>> A more reliable approach could be to disable the standard auto init when going to sleep (see config auto init). My suggestion would be to add a third 'wakeup' auto init mode that tells the system to first check if it actually should do a full boot or return to deep sleep.
>>>>
>>>> That way you'll boot into the base operation mode and have access to the config store etc., while avoiding to power up optional components. If returning to sleep immediately, that would result in a necessary uptime of just ~ 5 seconds at base power consumption level.
>>>>
>>> Thanx for pointing that out - remember I’m new to OVMS I just got the development environment working on my arm mac natively. I have to learn on how the boot process works - I thought it would start in ovms_boot, but other code runs before. your mention of config auto init means the make menuconfig process ?
>> No, I mean the OVMS AutoInit system. The main controller for that is Housekeeping::Init(), which reads the config and calls the AutoInit() methods of the components enabled.
>>
>> The boot process basically consists of these phases:
>>      • Hardware init (esp-idf bootloader)
>>      • Application init (static object inits in __attribute__ init_priority order) ending with the FreeRTOS scheduler start
>>      • Application start (entry point: app_main() in ovms_main.cpp) (system is now in FreeRTOS mode)
>>      • Housekeeping init (starting dynamic components & peripherals according to user configuration)
>> Every phase resets the log time to 0.
>>
>> In the boot log, you can identify phase 2 begin/end by the "cpu_start" log lines, with the static object (object factory) inits logging their invocations including their init priority:
>>
>> …
>> I (2081) cpu_start: Pro cpu start user code
>> I (2086) spiram: Adding pool of 4096K of external SPI memory to heap allocator
>> I (92) ovms_main: Set default logging level for * to INFO
>> I (93) ovms_main: Initialising WATCHDOG...
>> I (93) ovms-duktape: Initialising DUKTAPE Registry (1000)
>> I (100) command: Initialising COMMAND (1010)
>> I (105) command: Expanding DUKTAPE javascript engine
>> I (110) boot: Initialising BOOT (1100)
>> …
>>
>> Boot::Boot() is the static init of the MyBoot object, this is executed quite early at init_priority 1100.
>>
>> This is the place we currently check if the 12V level is sufficient when waking up from deep sleep. From here we can go back to sleep immediately, but cannot yet access the config store.
>>
>> Phase 3 (app_main()) starts with logging "ovms_main: Executing on CPU core 0", then essentially mounts the configuration partition "/store" and hands over control to Housekeeping:
>>
>> …
>> I (1050) ovms_main: Starting HOUSEKEEPING...
>> I (1050) housekeeping: Initialising HOUSEKEEPING Framework...
>> …
>>
>> Houskeeping init finishes with starting the USB console:
>>
>> I (2450) housekeeping: Starting USB console...
>> …
>> Welcome to the Open Vehicle Monitoring System (OVMS) - Async Console
>> Firmware: 3.3.003-97-g5ccff7cf/factory/edge
>> Hardware: OVMS WIFI BLE BT cores=2 rev=ESP32/3
>> OVMS>
>>
>>
>>> Maybe it’s easiest to put a separate esp32board in front of the OVMS module to only switch on OVMS when battery level is high enough - maybe board designers can think of really low power deep sleep in the next interation of the OVMS module.
>> Sure. Or you could use an OBD cable with a manual power switch. Or you could use an OBD cable that connects to a 12V source that's switched by the car.
>>
>> Regards,
>> Michael
>>
>>
>> -- 
>> Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal
>> Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
>> _______________________________________________
>> OvmsDev mailing list
>> OvmsDev at lists.openvehicles.com
>> http://lists.openvehicles.com/mailman/listinfo/ovmsdev
> _______________________________________________
> OvmsDev mailing list
> OvmsDev at lists.openvehicles.com
> http://lists.openvehicles.com/mailman/listinfo/ovmsdev

-- 
Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal
Fon 02333 / 833 5735 * Handy 0176 / 206 989 26

-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature
Type: application/pgp-signature
Size: 203 bytes
Desc: OpenPGP digital signature
URL: <http://lists.openvehicles.com/pipermail/ovmsdev/attachments/20221118/59e4001b/attachment-0001.sig>