December 2025 - 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

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

OVMS v2 crashing module
by Aaron Carson 29 Dec '25

29 Dec '25

Hi folks, Hope you’re all keeping well and that your holidays have been lovely so far! I’ve been watching the OVMS project for just over a year since Mercedes announced they were going to shut down the Smart EQ servers (UK 453 Brabus). Then, we got my mum a module for Christmas so finally getting to play with it properly 😄 However, I’m having some trouble with the V2 server. I’m using Dexter’s cloud server for now (thank you for hosting it!) with the aim to set Mum up with the Quarz iOS app (https://apps.apple.com/gb/app/quarz/id6740280553) <https://apps.apple.com/gb/app/quarz/id6740280553> If I start V2 on the module, it either crashes instantly or does so within a few minutes. If I enable autostart on it, it boot loops for a minute and then needs a manual reboot. Not so bad in the summer but having to go back outside to the car in 1°C weather isn’t my idea of fun 😂 Problem is: when it crashes, there’s no crash data. Last crash: IllegalInstruction exception on core 0 Registers: PC : 0x00000000 PS : 0x00000000 A0 : 0x00000000 A1 : 0x00000000 A2 : 0x00000000 A3 : 0x00000000 A4 : 0x00000000 A5 : 0x00000000 A6 : 0x00000000 A7 : 0x00000000 A8 : 0x00000000 A9 : 0x00000000 A10 : 0x00000000 A11 : 0x00000000 A12 : 0x00000000 A13 : 0x00000000 A14 : 0x00000000 A15 : 0x00000000 SAR : 0x00000000 EXCCAUSE: 0x00000000 EXCVADDR: 0x00000000 LBEG : 0x00000000 LEND : 0x00000000 LCOUNT : 0x00000000 Backtrace: Version: 3.3.005-536-g20a42926/ota_1/edge (build idf v3.3.4-851-gfa4f07fb3b Dec 25 2025 16:43:35) Hardware: OVMS WIFI BLE BT cores=2 rev=ESP32/3; MODEM SIM7600 Despite all this, I’m having no such issues with V3/MQTT. I’m happy to use that - and I intend to integrate it with Home Assistant so probably would aim for that in general, but the data usage is *so* much lower on V2 - and with a Hologram SIM, that’s pretty important - that I’d have preferred to go down that path. Any ideas as to why it could be crashing? Best wishes and kind regards, Aaron *Aaron Carson** (he/him)* ✉️ : aaron(a)aaroncarson.co.uk 💻 : aaroncarson.co.uk <https://www.aaroncarson.co.uk/> 🔑 : 715E 0332 F7E1 E0F1 <https://keys.openpgp.org/vks/v1/by-fingerprint/45982EB56486CED008DAED0D715E…>

4 5

USB C (unofficial mod)
by Mark Webb-Johnson 26 Dec '25

26 Dec '25

A Boxing Day microsoldering project… Could this be the first USB-C OVMS v3? I would love for this to be official, but not at the moment. The change would invalidate our certifications, require an injection mold change, and doesn’t take advantage of USB-C PD (for higher power). But it was fun to do some micro soldering on Boxing Day morning. Mod involves one of those new USB-C diy upgrade sockets (FMC002 version available on aliexpress or taobao - about USD2 for five), some very tiny soldering, and a file to open up the hole on the case. Result is the same data and power - just no more micro-USB. I wouldn’t attempt it unless you are comfortable with a microscope and hot air rework. Merry Xmas to all!

1 0

Nissan Leaf Documentation
by Mark Webb-Johnson 23 Dec '25

23 Dec '25

For the past year, almost half the support tickets I receive are from Nissan Leaf (or variants thereof) owners saying they can’t see SOC in the app. It seems that there are various ways of setting the configurations, model year, etc, for Nissan Leaf to calculate the SOC. But the documentation seems lacking for this. At the moment, all I can do is point them to the forums, but that doesn’t seem to help much. If anybody is familiar with the Nissan Leaf support code, I would appreciate it if the documentation could be updated to better describe the configuration parameters related to vehicle model year, etc. Thanks, Mark

1 0

Vibe submissions
by Michael Balzer 21 Dec '25

21 Dec '25

Everyone, I've just added a section on "vibe" ("AI" generated) submissions to our README's developer guidelines: https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3?tab=readme… I'm really fed up with having to sort out some LLM hallucinated bullshit. This has already been causing issues in other projects, and now becomes a major problem here as well. Dear young fellow developers: know your tool's limits! When thinking about how often LLM generated nonsense may already make it into production untested at places where it really matters, and how that will be amplified by maintainers using "AI" to validate submissions, I get a very bad feeling about our future. Regards, Michael -- Michael Balzer * Am Rahmen 5 * D-58313 Herdecke Fon 02330 9104094 * Handy 0176 20698926

1 0

battery drain
by Tamás Kovács 03 Dec '25

03 Dec '25

Hi guys! I have a problem with my ioniq 28kwh car, use ovms over 2 years, and now drain my battery last day i found the following, if i set the vehicle module to none, the drain is stop. i use the edge fw. In night the auto update fw is run and after the reboot the battery drain is continue. In the picture can see, 15:15 set vehucle module to none, auto update is run at ~3:02 (vehicle module to hyundaivfl) and i woke up at ~5:20 and set the vehicle module to none I attach a log and a screenshot of battery voltage What can is do? Problem with a OBD cable? I detached the ovms from the car for a couple off hours but when is reconnect it not connect to the wi-fi network, but when i connect a computer or a powerbank, the wi-fi connection is established, after usb disconnect network works fine, but i have many can errors. On charging i get many ovms messages, charge stopped, started....... -- Thanks: Kovács Tamás

2 2