January 2026 - OvmsDev - Open Vehicles

Firmware size approaching 4 MB limit
by Michael Balzer 07 Apr '26

07 Apr '26

Everyone, with the latest vehicle additions, the firmware size has now grown to 4,015,328 bytes in build 3.3.005-485-gc4664881. Our flash partitioning scheme is currently designed to provide three firmware partitions (factory, ota_0 & ota_1) of 4MB = 4,194,304 bytes each. So we've now got 178,976 bytes = ~4% left. Options beyond the 4 MB limit: a) split features, e.g. vehicle support, into two or more builds b) repartition into two firmware partitions of 6 MB each, reusing the factory partition for OTA c) switch to an ESP32 WROOM module with 32 MB flash (possible?) We've got some time left, new vehicles normally don't need that much space, I just wanted to raise awareness. Regards, Michael -- Michael Balzer * Am Rahmen 5 * D-58313 Herdecke Fon 02330 9104094 * Handy 0176 20698926

5 33

esp-idf update fixing spi_flash mutex priority inheritance bug
by Michael Balzer 28 Jan '26

28 Jan '26

Everyone, TL;DR: update your local esp-idf clone from our esp-idf repository before doing the next firmware build. While testing the Mongoose API lock I found out the Mongoose task priority would still occasionally get raised to 22 = wifi task priority. In combination with the Mongoose task essentially being 100% busy while outside the locked poll call, this lead to blocking all other tasks from Mongoose, which caused at least one of the crash effects observed (watchdog timeout from our events task). Adding a priority fix to our netmanager eliminated quite a lot of these crashes. I then investigated this, as I thought that priority bug was originally coming from the buggy POSIX mutex implementation we fixed in July 2020 (→ http://lists.openvehicles.com/pipermail/ovmsdev/2020-July/006971.html) It turned out I was wrong, the actual culprit is a bug in the esp-idf spi_flash component: each access to the SPI flash memory needs to be running at maximum priority. The spi_flash methods did this by temporarily changing the current task priority, and reverting to the previous priority without taking into account that the task may have had an inherited priority from an aquired mutex lock. Thus the priority inherited from e.g. the Wifi task would stick. That was especially present and reproducable when opening the web UI's Config→Firmware page, as that page handler reads the OTA status, which in turn reads the current boot configuration from flash. It also affected the AutoFlash task during firmware updates, and there may be more paths, basically running any "ota" command via a network channel. As config reads & writes also use SPI flash, these also could produce the bug for any task trying to lock some mutex also being requested by a higher priority task. This SPI flash bug has been found by other esp-idf users, and has finally been fixed, but only for esp-idf 4.3 & higher: * https://github.com/espressif/esp-idf/issues/5116 * https://github.com/espressif/esp-idf/issues/7580 I have now backported the fix to our version, and haven't had a single unplanned priority change since. Positive side effect: I see no event queue overflows & almost no effect on the overall performance during an OTA flash process now. This is though probably not the only cause of remaining watchdog timeouts -- crash reports will tell. Regards, Michael -- Michael Balzer * Am Rahmen 5 * D-58313 Herdecke Fon 02330 9104094 * Handy 0176 20698926

1 0

Heap corruption alerts & heap tracing
by Michael Balzer 24 Jan '26

24 Jan '26

Everyone, from the crash reports (https://ovms.dexters-web.de/firmware/developer/) most remaining crashes seem to be caused by heap corruptions. Not all heap corruptions are easily detectable from the backtrace analysis, and the component or action causing the corruption isn't detectable at all that way. So I've added a debug option to enable a regular heap integrity check ever 5 minutes, with the module sending an alert notification when a corruption has been detected. Example: > Heap corruption detected; reboot advised ASAP! > Please forward including task records and system log: > > CORRUPT HEAP: Bad tail at 0x3f8e44f0 owner 0x3ffea9bc. Expected > 0xbaad5678 got 0xbaad5600 I also added a final heap integrity check to our crash handler, so the crash debug records should now show exactly which crashes occurred with a corrupted heap. In combination with the system log and the task log, that should give us some more opportunities to narrow down the cause(s). I've also added task ownershop to the heap corruption report. Note, this needs my latest additions to our esp-idf fork, so take care to pull these before building. Be aware, task ownership of corrupted blocks doesn't necessarily tell about the task doing the corruption. If the tail canary is compromised, and no other block located before that block is compromised, it *may* be that task doing the out of bounds write. But it may also be a use after free of some previous owner. So take task ownership with a grain of salt. The corruptions are most probably caused by some unclean shutdown of a component or by an undetected race conditions within a shutdown procedure. The heap seems to be stable on modules with standard configurations and components not being started & shut down on a regular base. The heap corruptions are especially present now with Smart (SQ) vehicles -- as the Smart doesn't keep the 12V battery charged from the main battery, most Smart users probably use the power management to shut down Wifi and/or modem while parking. So our main focus should be on analysing what happens before the corruption. Ask users reporting heap corruptions to provide their system logs, and possibly also their task logs. To encourage enabling these, I've added the config to the web UI (Config→Notifications). Once you can reproduce (!) the corruption, heap tracing might provide some more insight as to where exactly the corruption occurs. Heap tracing means recording all memory allocations and frees. This adds a recording layer on top of the heap functions, so comes with some cost, even when inactive. CPU overhead is low, but stack overhead may be an issue, so I think we should not enable heap tracing by default for now, but rather use a debug build specifically in cases we think heap tracing might help. To enable heap tracing on some user device, I've reworked the ESP-IDF heap tracing to enable remote execution and to also include the task handles performing the allocations and deallocations. To enable heap tracing for a build: > * Under|makemenuconfig|, navigate > to|Componentsettings|->|HeapMemoryDebugging|and > setCONFIG_HEAP_TRACING > <https://docs.espressif.com/projects/esp-idf/en/v3.3/api-reference/kconfig.h…>. > There's also an option to set the number of stack backtrace frames. Tracing with two frames is mostly useless in our (C++) context, as it will normally only show some inner frames of the allocator. I've tried raising that to 5, and got an immediate crash in the mdns component. I assume raising the depth will need raising some stack sizes. If you find a good compromise, please report. Heap tracing will work best in a reduced configuration. In normal operation, my module fills a 500 records buffer within seconds. The buffer is a FIFO, so will always contain the latest n allocations, and the last entry in the dump is the newest one. Reduced example dump: > OVMS# mod trace dump > Heap tracing started/resumed at ccount 0x1c70b453 = logtime 19415 > 1000 allocations trace (1000 entry buffer) > 258 bytes (@ 0x3fffb3a8) allocated CPU 1 task 0x3ffc92e8 ccount > 0x89074e74 caller 0x4031d4f0:0x4031f553 > freed task 0x3ffc92e8 by 0x4031d514:0x4031f595 > 201 bytes (@ 0x3f8e92f4) allocated CPU 1 task 0x3fff2290 ccount > 0x89218bbc caller 0x40131b12:0x4014633c > freed task 0x3fff2290 by 0x402c4634:0x402cb14d > 112 bytes (@ 0x3ffebc80) allocated CPU 1 task 0x3ffee918 ccount > 0x8a25d47c caller 0x4029b455:0x4017a5dc > freed task 0x3ffee918 by 0x4029b744:0x4017a5dc > 112 bytes (@ 0x3ffebc80) allocated CPU 1 task 0x3ffee918 ccount > 0x8db89c40 caller 0x4029b455:0x4017a5dc > freed task 0x3ffee918 by 0x4029b744:0x4017a5dc > 12 bytes (@ 0x3f85d0d4) allocated CPU 1 task 0x3ffdfcd0 ccount > 0x8fccdfd8 caller 0x40131b12:0x4014633c > freed task 0x3ffdfcd0 by 0x402c4634:0x401e0a04 > […] > 12 bytes (@ 0x3f85d0d4) allocated CPU 1 task 0x3ffdfcd0 ccount > 0x3cf429f4 caller 0x40131b12:0x4014633c > freed task 0x3ffdfcd0 by 0x402c4634:0x401e0a04 > 112 bytes (@ 0x3ffebc80) allocated CPU 1 task 0x3ffee918 ccount > 0x3fe1a0bc caller 0x4029b455:0x4017a5dc > 229 bytes alive in trace (3/1000 allocations) > total allocations 1207 total frees 3356 > (NB: Buffer has overflowed; so trace data is incomplete.) "ccount" is the ESP32 CCOUNT register (CPU cycles), so provides an orientation on when the allocation occurred. Some more basics on heap debugging are also covered here: https://docs.espressif.com/projects/esp-idf/en/v3.3/api-reference/system/he… Regards, Michael -- Michael Balzer * Am Rahmen 5 * D-58313 Herdecke Fon 02330 9104094 * Handy 0176 20698926

1 7

OVMS VW e-UP T26 connector
by Mark Webb-Johnson 19 Jan '26

19 Jan '26

We’ve had some enquiries regarding making a standard OVMS cable T26 for VW eUP, Skoda E IV, and Seat MII electric. From my understanding, the cable is variant 1 described here: https://docs.openvehicles.com/en/latest/components/vehicle_vweup/docs/index… https://docs.openvehicles.com/en/latest/components/vehicle_vweup/docs/index… If there anybody here knowledgeable about this, that could help specify the cable exactly? Things like: Exact T26 connector Length of each cable segment Cable wire type Pinouts Preferable somebody who has already done it and can document exactly what they have. Also presumably this requires unplugging the existing OCU, and what is the impact of that? Regards, Mark.

4 10

ABRP TLS certificate changed to Amazon
by Michael Balzer 11 Jan '26

11 Jan '26

See: https://github.com/iternio/ovms-link/issues/35#issuecomment-3734643142 Apparently iternio.com changed their certificate provider on January 8 to Amazon. To install the Amazon CA PEM, save the following as|/store/trustedca/amazon.pem|and issue command|tls trust reload|: |-----BEGIN CERTIFICATE----- MIIEXjCCA0agAwIBAgITB3MSOAudZoijOx7Zv5zNpo4ODzANBgkqhkiG9w0BAQsF ADA5MQswCQYDVQQGEwJVUzEPMA0GA1UEChMGQW1hem9uMRkwFwYDVQQDExBBbWF6 b24gUm9vdCBDQSAxMB4XDTIyMDgyMzIyMjEyOFoXDTMwMDgyMzIyMjEyOFowPDEL MAkGA1UEBhMCVVMxDzANBgNVBAoTBkFtYXpvbjEcMBoGA1UEAxMTQW1hem9uIFJT QSAyMDQ4IE0wMTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAOtxLKnL H4gokjIwr4pXD3i3NyWVVYesZ1yX0yLI2qIUZ2t88Gfa4gMqs1YSXca1R/lnCKeT epWSGA+0+fkQNpp/L4C2T7oTTsddUx7g3ZYzByDTlrwS5HRQQqEFE3O1T5tEJP4t f+28IoXsNiEzl3UGzicYgtzj2cWCB41eJgEmJmcf2T8TzzK6a614ZPyq/w4CPAff nAV4coz96nW3AyiE2uhuB4zQUIXvgVSycW7sbWLvj5TDXunEpNCRwC4kkZjK7rol jtT2cbb7W2s4Bkg3R42G3PLqBvt2N32e/0JOTViCk8/iccJ4sXqrS1uUN4iB5Nmv JK74csVl+0u0UecCAwEAAaOCAVowggFWMBIGA1UdEwEB/wQIMAYBAf8CAQAwDgYD VR0PAQH/BAQDAgGGMB0GA1UdJQQWMBQGCCsGAQUFBwMBBggrBgEFBQcDAjAdBgNV HQ4EFgQUgbgOY4qJEhjl+js7UJWf5uWQE4UwHwYDVR0jBBgwFoAUhBjMhTTsvAyU lC4IWZzHshBOCggwewYIKwYBBQUHAQEEbzBtMC8GCCsGAQUFBzABhiNodHRwOi8v b2NzcC5yb290Y2ExLmFtYXpvbnRydXN0LmNvbTA6BggrBgEFBQcwAoYuaHR0cDov L2NydC5yb290Y2ExLmFtYXpvbnRydXN0LmNvbS9yb290Y2ExLmNlcjA/BgNVHR8E ODA2MDSgMqAwhi5odHRwOi8vY3JsLnJvb3RjYTEuYW1hem9udHJ1c3QuY29tL3Jv b3RjYTEuY3JsMBMGA1UdIAQMMAowCAYGZ4EMAQIBMA0GCSqGSIb3DQEBCwUAA4IB AQCtAN4CBSMuBjJitGuxlBbkEUDeK/pZwTXv4KqPK0G50fOHOQAd8j21p0cMBgbG kfMHVwLU7b0XwZCav0h1ogdPMN1KakK1DT0VwA/+hFvGPJnMV1Kx2G4S1ZaSk0uU 5QfoiYIIano01J5k4T2HapKQmmOhS/iPtuo00wW+IMLeBuKMn3OLn005hcrOGTad hcmeyfhQP7Z+iKHvyoQGi1C0ClymHETx/chhQGDyYSWqB/THwnN15AwLQo0E5V9E SJlbe4mBlqeInUsNYugExNf+tOiybcrswBy8OFsd34XOW3rjSUtsuafd9AWySa3h xRRrwszrzX/WWGm6wyB+f7C4 -----END CERTIFICATE----- | Should we add the CA to our standard CA set, given flash space is getting tight? I haven't had any other reports of people trying to access some Amazon hosted/certified API. Regards, Michael -- Michael Balzer * Am Rahmen 5 * D-58313 Herdecke Fon 02330 9104094 * Handy 0176 20698926

1 0

Config framework: race condition fix & storage transaction scheme [PR #1310]
by Michael Balzer 10 Jan '26

10 Jan '26

Happy new year everyone :) I've been working on a somewhat larger rework of the config framework: https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/pull/1310 This touches a lot of places and changes an 8 year old foundational framework component, so I'd love to get some audit and test feedback for this before actually including this in the edge build. Thanks & kind regards, Michael -- Michael Balzer * Am Rahmen 5 * D-58313 Herdecke Fon 02330 9104094 * Handy 0176 20698926

1 1

More support for Scripting a Vehicle implementation
by Michael Geddes 05 Jan '26

05 Jan '26

I'm well on the way to finishing bms and vector support in scripted vehicle implementation via the DBC infrastructure. This is the documentation I'm adding into the 'DBC Introduction' page. It's kind of the correct place, but it's going to be common to the other script support for polling.. so maybe I should link to it in a common area. //.ichael DBC Signals <#dbc-signals> DBC Signal names can be used to store values directly into metrics. Eg a signal v_b_soc would be sent to the metric v.b.soc. If the unit name on a signal matches a valid ‘unit code’ or ‘unit label’, then this will be passed on too. For signal names, _ will get translated to a . for looking up metrics (. is still a valid character in a DBC ID). It is also possible to store into a vector by putting a number at the end of the signal id. Eg the signal v_t_pressure_0 would be sent to the first element of the v.t.pressure vector. BMS Targets <#bms-targets> There are also special BMS (battery management) targets that make sure the averages etc are calculated. The format is: bms.*{type}*.*{operation}*[*.* *{index}*]. The *{type}* is either v for voltage or t for temperature. Operation Description Has Index n Total number of cell voltage readings No m Readings per module No r Reset stats Optional c Cell value Yes DBC Examples <#id1> Example Description bms.t.n Set total number of cell temperature readings to incoming value. bms.t.m Set total number of cells per grouping to incoming value. bms.v.r Reset stats for cell voltages (ignore value) bms.v.r.0 Reset stats and set Voltage at index *0* to incoming value bms.t.c.2 Set cell temperature at index *2* to incoming value. bms.v.c.5 Set cell voltage at index *5* to incoming value.

2 1