February 2021 - OvmsDev - Open Vehicles

Netmanager priority issue solved
by Michael Balzer 05 Jul '23

05 Jul '23

TL;DR: you need to pull my latest esp-idf changes. I've finally found & solved the strange priority changes for our netmanager task (i.e. being raised suddenly from origin 5 to 18/22): the bug was in the esp-idf posix threads mutex implementation. I had suspected the mutex priority inheritance for a while, so added a way to retrieve the internal mutex hold count for our task list. Using this I noticed the hold count would always & only raise by 2 whenever any kind of mongoose connection was closed. That lead me to checking the thread concurrency protection for mongoose mbufs, because every mongoose connection has two mbufs associated (rx & tx), each having a posix mutex. The bug was: posix mutexes were deleted after locking (taking) them. FreeRTOS mutexes must not be deleted while being taken, that breaks the priority inheritance (more precisely the disinheritance), with the visible effect being the mutex hold count not returning to zero. As a side effect, this may also solve the strange event task starvations (hope so…). I was investigating this as I suspected some busy loop in the netmanager context. With the netman running at prio 22, that would effectively block almost all other processing including the timer service. I've found & fixed one potential busy loop trigger in the netman that would have been caused by the netman task still running while all interfaces had been lost -- not sure if that could happen, but it would explain the effects. So please watch your crash debug info & report if the issue still turns up. Regards, Michael -- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26

5 19

IOS app reported GSM signal strength
by Craig Leres 17 Oct '22

17 Oct '22

I've noticed for awhile but never asked the question; why does the IOS app report wifi signal strength when I'm connected to wifi as gsm signal strength? I would expect gsm to always be gsm and maybe wifi would also be shown (and identified as such) when present. Note that I run my modules in wifi client-only mode. Craig

2 2

Open issues blocking release 3.2.016
by Michael Balzer 22 Jun '21

22 Jun '21

As the other thread got off-topic: I'd still like to get forward regarding release 3.2.016. We identified three open issues: 1. VW e-Up sometimes stays awake for 4-5 hours. 2. Wifi AP connection is unstable with some devices. 3. More frequent location flatbed theft false alerts. My current status on these is: 1. …is probably not a bug on the OVMS but rather a real behaviour of the e-Up performing an extended 12V trickle charge. 2. …has only been reported by Steve Davies and seems (?) to have been solved by the default scan timings – Steve? 3. …seems to be a Heisenbug, i.e. hasn't had any reports since we added extended logging. Is my status correct? If so, I think these should no longer stop us from releasing 3.2.016. Regards, Michael -- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26

6 12

Coding help
by Shane ＠ Kilve Engineering 05 Apr '21

05 Apr '21

can any one help me with a bit of code to retrieve ve some data from ecu can1/6f2 00 4c 00 00 01 97 bc 00 as i cant poll this ecu it just broadcasts when its active, ive tried polling it but does not respond, i need to choose one byte and allocate it to a PID.

3 22

ESP32 CAN controller hardware bug / interrupt issue
by Michael Balzer 03 Apr '21

03 Apr '21

Second finding & commit: TL;DR: * ESP32 CAN controller is broken, delivers trashed & duplicated RX frames * we need to optimize interrupt latency Users have been reporting occasional false BMS readings on the Twizy for more than a year. The error always trashed the reading of voltage #10 and/or temperature #8, so I initially thought that must be a variant of the SPIRAM/cache bug. But the SPIRAM fix didn't help, and the bug still occured with all BMS data in internal RAM. The issue correlated with high load situations and the SIMCOM UART issue. On testing the latest changes by Marko, my car module began showing that issue regularly, so I could take a closer look. It turned out the wrong data came from the CAN bus. Checking with a CAN logger didn't show any wrong data on the bus. So I scanned our CAN driver for potential issues, found & solved some (even a serious race condition) but that didn't fix it. I then added debug dumps of all frames read, dug into the SJA1000 spec sheet and found this: The SJA1000 RX FIFO has a capacity of 64 bytes. It's supposed to work as a ring buffer, with frames wrapping around as necessary. If no space is left in the FIFO for a new frame coming in, that frame should be discarded completely, not counted, just the overflow indicator should be set & the according interrupt be generated. Reality differs. The frame causing the overflow is added to the FIFO partially. It's also counted both in the RMC register and indicated by RBS as a valid frame when retrieving the FIFO contents. The read buffer delivers the partial frame + some trashed bytes up to the nominal frame length. In the BMS frame sequence it would normally trash bytes 7 & 8 on the sixth frame of length 8 in a sequence. A standard frame needs a 3 byte header + the data bytes in the FIFO, so 6 frames would add up to 66 bytes => 64 + 2 trash. The first trash byte normally is "08", the second "84" or "2a" or sometimes "ab", possibly some internal SJA1000 data. Better yet, if you rely on the indicators of the SJA1000 when reading the FIFO, the SJA1000 will repeat the first frame within the FIFO after the invalid frame. Mostly once or twice, and sometimes 7 times or more: inv_msg: framecnt=13, invindex=6 inv_msg: 55 01 00 00 07 98 50 54 54 20 00 6e | 4..?........U.....PTT .n inv_msg: 24 04 00 00 11 40 10 22 37 55 00 37 | 4..?........$....@."7U.7 inv_msg: 25 04 00 00 0a 1b 44 ff fe 4e 01 26 | 4..?........%.....D..N.& inv_msg: 54 05 00 00 37 37 37 37 37 37 37 00 | 4..?........T...7777777. inv_msg: 56 05 00 00 31 63 14 31 53 14 31 4a | 4..?........V...1c.1S.1J inv_msg: 57 05 00 00 31 43 14 31 53 15 *08 2a* | 4..?........W...1C.1S..* ^^^^^ trashed bytes … followed by 7 repetitions of the first frame: inv_msg: 55 01 00 00 07 98 50 54 54 20 00 6e | 4..?........U.....PTT .n inv_msg: 55 01 00 00 07 98 50 54 54 20 00 6e | 4..?........U.....PTT .n inv_msg: 55 01 00 00 07 98 50 54 54 20 00 6e | 4..?........U.....PTT .n inv_msg: 55 01 00 00 07 98 50 54 54 20 00 6e | 4..?........U.....PTT .n inv_msg: 55 01 00 00 07 98 50 54 54 20 00 6e | 4..?........U.....PTT .n inv_msg: 55 01 00 00 07 98 50 54 54 20 00 6e | 4..?........U.....PTT .n inv_msg: 55 01 00 00 07 98 50 54 54 20 00 6e | 4..?........U.....PTT .n If you had occasional strange false readings leading to strange effects, this may be the explanation. Note: the SJA1000 FIFO bug may need specific circumstance to occur in addition to the overflow, maybe the overflow happening on a specific byte position in the FIFO -- I haven't tried to determine that. I've tried clearing the overflow ASAP, looping on the IR indicator and looping on the RMC, the fault is always the same. The workaround I've now done is adding up the message lengths read during a FIFO run and discard all frames exceeding the 64 byte border. Not pretty, but functional. That keeps the trashed frames from being forwarded to the OVMS application level. As with the SIMCOM UART, these overflows wouldn't happen if the interrupt handler would react fast enough. It seems we've got a general interrupt latency issue. And just as with the SIMCOM I saw a reduction of overflows when allocating the CAN IRQ on core #0, another one with raising the IRQ level to 3, so that's also part of my commit. The esp-idf CAN driver apparently has the same issue even in the latest release, I'll contact the author about this or post another issue to Espressif. So our interrupt allocation is now: Task Run# Lvl ISR# Usage Source ---------------------------------------------------------------------------------------- - 0 1 0 RTC Core ETS_RTC_CORE_INTR_SOURCE esp_timer 0 1 0 RTOS esp_timer ETS_TIMER2_INTR_SOURCE ipc0 0 1 0 RTOS Scheduler Core0 ETS_FROM_CPU_INTR0_SOURCE ipc1 1 1 1 RTOS Scheduler Core1 ETS_FROM_CPU_INTR1_SOURCE main 0 1 0 RTOS Watchdog ETS_TG0_WDT_LEVEL_INTR_SOURCE OVMS Events 1 1 1 Peripherals (GPIO ISR) ETS_GPIO_INTR_SOURCE OVMS Events 1 1 1 MAX7317 (spi_nodma) ETS_SPI3_INTR_SOURCE *esp32can init 0 3 0 ESP32 CAN ETS_CAN_INTR_SOURCE** **OVMS SIMCOM 0 2 0 SIMCOM UART ETS_UART1_INTR_SOURCE* OVMS Events 1 1 1 USB console (UART) ETS_UART0_INTR_SOURCE OVMS Events 1 1 1 SD card ETS_SDIO_HOST_INTR_SOURCE ---------------------------------------------------------------------------------------- I think we need to find the source of the interrupt latency and/or find some better scheme to distribute the tasks & interrupts over the cores. I still don't know why core #1 already got an issue with just our 6 interrupts. This may be related to the SPIRAM fix adding overhead, but I've seen the FIFO overflows before applying the fix, and the CAN issue also has been present for over a year. My working hypothesis is some task/driver disabling interrupts for too often / too long, or non-IRAM ISRs getting delayed for too often / too long. And it seems this is an issue especially on core #1. Please verify & comment. Regards, Michael PS: a little side mystery: the netmanager task starts with priority 5, then gets raised to 22 (probably a mutex priority inheritance), but never gets lowered back to 5 afterwards. A FreeRTOS bug? -- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26

2 11

External Wifi antenna
by Michael Balzer 15 Mar '21

15 Mar '21

Some info for those in need of a better Wifi signal than achievable with the builtin ESP32-WROVER antenna: A friend of mine on the german Twizy forum had severe signal issues, using an external router antenna he saw an improvement of ~10 dB. Basics: - https://www.esp32.com/viewtopic.php?t=1635 …view on the OVMS module: Here's a video by him on the topic (in German, try automatic translation) – but sadly not showing the actual soldering process, more the afterworks: https://www.youtube.com/watch?v=4Uv71HiBPpg Regards, Michael -- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26

4 22

Re: [Ovmsdev] Time for release 3.2.016?
by sharkcow 11 Mar '21

11 Mar '21

Hi all, > Twice in the last few weeks I've gotten the "possible theft/flatbed" alert just as I was backing out of the garage. I have never received that alert before. I hadn't posted anything yet because I was waiting to drive the other car and see if has the same problem. I get this too every once in a while with my e-Up. Mostly shortly after parking, I think (and tragically, the one time I'd have needed it because I actually _did_ get towed, I had crashed OVMS into a boot loop just before :-/). sharkcow

6 26

Re: [Ovmsdev] Angelo, ipace forum
by didier＠ernotte.com 27 Feb '21

27 Feb '21

Here is a screenshot of my session with "obdii" command. Don't hesitate to post here :ovmsdev@lists.openvehicles.com You will get a quick answer from the core developement team of OVMS. Didier Le vendredi 26 février 2021 13 h 01 min 39 s UTC−5, Angelo Russo <ing.angelorusso(a)icloud.com> a écrit : No way !!! Maybe I will start over all OVMS initialing procedure. It’s a very strange issue. Can you please confirm you can use odbii command without typing ECU? ————————— This e-mail is strictly confidential. It is intended for the sole use of the individual or entity to which it is addressed and may contain information that is privileged, confidential and exempt from disclosure under applicable law. You are hereby notified that any dissemination, distribution or duplication of this message by someone else than the intended addressee or its designed agent is strictly prohibited and may breach art. 616 and ff. of the criminal code. Should you receive this e-mail by mistake please notify this firm immediately and delete the message from all locations in your computer. > Il giorno 26 feb 2021, alle ore 13:55, didier(a)ernotte.com ha scritto: > > re obdii tester start 1 7e4 5

1 0

Shell syntax to write a value
by didier＠ernotte.com 25 Feb '21

25 Feb '21

Hi, I can easily read a PID value using the shell syntax in the web browser : "obdii can1 request device 7e4 7ec 22ddd00" for example. I understand that "0x22" is used to read data by identifier, and I read that "0x2E" would be used to write data by identifier but what would be the correct syntax to write a value to a PID in the shell ? or it is not possible yet ? Didier

2 1

Time for release 3.2.016?
by Michael Balzer 24 Feb '21

24 Feb '21

Everyone, we're 624 commits away from 3.2.015, and we've got a bunch of new features & vehicle support. We've had some changes recently, but apparently no issues with these (at least none reported). I'd say it's time for 3.2.016. Objections? Anything in the works that should be included? Regards, Michael -- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26

5 27