March 2020 - OvmsDev - Open Vehicles

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

File logging task
by Michael Balzer 04 Jul '20

04 Jul '20

Everyone, I've pushed the long due refactoring of the file logging into a dedicated task. This removes most of the delays involved in file logging, as the fsync() and log cycling now is done in the logging task and no longer blocks overall log message processing. I stumbled upon a bad thing (tm) though we need to resolve with logging: the esp-idf logging generally involves a semaphore wait of max 10 ms (!). I wasn't aware of this because I didn't look into the source before, there also is no warning about this in the esp-idf documentation (https://docs.espressif.com/projects/esp-idf/en/latest/api-reference/system/…) so I guess I'm not the only one being taken by surprise here. // Maximum time to wait for the mutex in a logging statement. #define *MAX_MUTEX_WAIT_MS 10* #define MAX_MUTEX_WAIT_TICKS ((MAX_MUTEX_WAIT_MS + portTICK_PERIOD_MS - 1) / portTICK_PERIOD_MS) … void IRAM_ATTR *esp_log_write*(esp_log_level_t level, const char* tag, const char* format, ...) { if (!s_log_mutex) { s_log_mutex = xSemaphoreCreateMutex(); } if (*xSemaphoreTake(s_log_mutex, MAX_MUTEX_WAIT_TICKS*) == pdFALSE) { return; } … That semaphore is needed to secure the log level tag cache against parallel access, so it also affects log messages of currently disabled tags and/or levels. This means we *must not* use the standard logging from timer callbacks, at no verbosity level. But we do, partially caused by my own code serving as a bad example I assume -- sorry. But I've not only found direct log calls in most vehicle timer callbacks, there also are some hidden ones from calling the framework, for example marking a notification as read can produce a log output from Cleanup() if tracing is enabled. We need to change this short to mid term. This may be the cause of those strange timer overflow issues we've seen occasionally. It also means every debug or verbose log output currently in the code involves potentially multiple semaphore waits, that's for example the case for all hex dumps logged by the SIMCOM module. Our primary option is to remove all log calls from all low level framework functions and timer callbacks. A simple & quick workaround could be to extend the ESP_LOGx macros to check if they are executed in the timer task context, if so suppress the message or call the ESP_EARLY log function instead. That will hide these log messages from the logging framework though, if using the _EARLY_ variant they only will be sent to the USB port. For a better solution I thought about adding a dedicated queue & task for the initial log submission as well. That will need quite some rework to the esp-idf (no changes for this in the current master) but would allow to continue logging as we do now. Cons: queue submission involves some overhead & RAM, printf format expansion needs to be done before the tag/level check, messages may need to be dropped if the task starves or RAM gets tight, log output to consoles will depend on a task as well. Opinions / better ideas? Regards, Michael -- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26

2 5

Bluetooth struggle
by Chris van der Meijden 28 Mar '20

28 Mar '20

Dear all I'm struggling with the activation of the bluetooth functionality with the recent code. The sdkconfig.bluetooth.hw31 will not compile at all. I found three major problems here. 1. Mongoose SSL is needed 2. Support for the 8MB RAM version is needed (not included in sdkconfig.bluetooth.hw31!) 3. CONFIG_BTDM_CONTROLLER_BR_EDR_SCO_DATA_PATH_EFF is needed for our special esp-idf situation By doing a simple diff I could solve 1, but overlooked Nr. 2. And that was lethal. It brought my OVMS in a boot loop after I installed the fresh compiled ovms3.bin. But I got here great help from Thomas (Thanx!), who pointed to the problem and helped me out on the sdkconfig settings. For Nr. 3 I made a dirty workaround by adding config BTDM_CONTROLLER_BR_EDR_SCO_DATA_PATH_EFF int "Should be 0, can also be 1" default 0 depends on OVMS help Workaround to make bluetooth compile with our special esp-idf situation. to the KConfig. But all efforts didn't bring a postive result. The image compiles and boots now, but we can't activate bluetooth. We get the Error bt: init controller failed: ESP_ERR_NO_MEM So I would like to ask, if anybody has a working, recent, bluetooth image and if so what does it need? Any help on this is highly welcome. Here the diff of my bluetooth sdkconfig to the standard sdkconfig without bluetooth: 137,146c137,138 < CONFIG_BT_ENABLED=y < < # < # Bluetooth controller < # < CONFIG_BTDM_CONTROLLER_MODE_BLE_ONLY=y < CONFIG_BTDM_CONTROLLER_MODE_BR_EDR_ONLY= < CONFIG_BTDM_CONTROLLER_MODE_BTDM= < CONFIG_BTDM_CONTROLLER_BLE_MAX_CONN=3 < CONFIG_BTDM_CONTROLLER_BLE_MAX_CONN_EFF=3 --- > CONFIG_BT_ENABLED= > CONFIG_BTDM_CONTROLLER_BLE_MAX_CONN_EFF=0 149,150d140 < CONFIG_BTDM_CONTROLLER_PINNED_TO_CORE_0=y < CONFIG_BTDM_CONTROLLER_PINNED_TO_CORE_1= 152,365c142 < CONFIG_BTDM_CONTROLLER_HCI_MODE_VHCI=y < CONFIG_BTDM_CONTROLLER_HCI_MODE_UART_H4= < < # < # MODEM SLEEP Options < # < CONFIG_BTDM_CONTROLLER_MODEM_SLEEP= < CONFIG_BLE_SCAN_DUPLICATE=y < CONFIG_SCAN_DUPLICATE_BY_DEVICE_ADDR=y < CONFIG_SCAN_DUPLICATE_BY_ADV_DATA= < CONFIG_SCAN_DUPLICATE_BY_ADV_DATA_AND_DEVICE_ADDR= < CONFIG_SCAN_DUPLICATE_TYPE=0 < CONFIG_DUPLICATE_SCAN_CACHE_SIZE=20 < CONFIG_BLE_MESH_SCAN_DUPLICATE_EN= < CONFIG_BTDM_CONTROLLER_FULL_SCAN_SUPPORTED= < CONFIG_BLE_ADV_REPORT_FLOW_CONTROL_SUPPORTED=y < CONFIG_BLE_ADV_REPORT_FLOW_CONTROL_NUM=100 < CONFIG_BLE_ADV_REPORT_DISCARD_THRSHOLD=20 < CONFIG_BLUEDROID_ENABLED=y < CONFIG_BLUEDROID_PINNED_TO_CORE_0=y < CONFIG_BLUEDROID_PINNED_TO_CORE_1= < CONFIG_BLUEDROID_PINNED_TO_CORE=0 < CONFIG_BTC_TASK_STACK_SIZE=6144 < CONFIG_BTU_TASK_STACK_SIZE=4096 < CONFIG_BLUEDROID_MEM_DEBUG= < CONFIG_CLASSIC_BT_ENABLED= < CONFIG_GATTS_ENABLE=y < CONFIG_GATTS_SEND_SERVICE_CHANGE_MANUAL= < CONFIG_GATTS_SEND_SERVICE_CHANGE_AUTO=y < CONFIG_GATTS_SEND_SERVICE_CHANGE_MODE=0 < CONFIG_GATTC_ENABLE= < CONFIG_BLE_SMP_ENABLE=y < CONFIG_SMP_SLAVE_CON_PARAMS_UPD_ENABLE= < CONFIG_BT_STACK_NO_LOG= < < # < # BT DEBUG LOG LEVEL < # < CONFIG_HCI_TRACE_LEVEL_NONE= < CONFIG_HCI_TRACE_LEVEL_ERROR= < CONFIG_HCI_TRACE_LEVEL_WARNING=y < CONFIG_HCI_TRACE_LEVEL_API= < CONFIG_HCI_TRACE_LEVEL_EVENT= < CONFIG_HCI_TRACE_LEVEL_DEBUG= < CONFIG_HCI_TRACE_LEVEL_VERBOSE= < CONFIG_HCI_INITIAL_TRACE_LEVEL=2 < CONFIG_BTM_TRACE_LEVEL_NONE= < CONFIG_BTM_TRACE_LEVEL_ERROR= < CONFIG_BTM_TRACE_LEVEL_WARNING=y < CONFIG_BTM_TRACE_LEVEL_API= < CONFIG_BTM_TRACE_LEVEL_EVENT= < CONFIG_BTM_TRACE_LEVEL_DEBUG= < CONFIG_BTM_TRACE_LEVEL_VERBOSE= < CONFIG_BTM_INITIAL_TRACE_LEVEL=2 < CONFIG_L2CAP_TRACE_LEVEL_NONE= < CONFIG_L2CAP_TRACE_LEVEL_ERROR= < CONFIG_L2CAP_TRACE_LEVEL_WARNING=y < CONFIG_L2CAP_TRACE_LEVEL_API= < CONFIG_L2CAP_TRACE_LEVEL_EVENT= < CONFIG_L2CAP_TRACE_LEVEL_DEBUG= < CONFIG_L2CAP_TRACE_LEVEL_VERBOSE= < CONFIG_L2CAP_INITIAL_TRACE_LEVEL=2 < CONFIG_RFCOMM_TRACE_LEVEL_NONE= < CONFIG_RFCOMM_TRACE_LEVEL_ERROR= < CONFIG_RFCOMM_TRACE_LEVEL_WARNING=y < CONFIG_RFCOMM_TRACE_LEVEL_API= < CONFIG_RFCOMM_TRACE_LEVEL_EVENT= < CONFIG_RFCOMM_TRACE_LEVEL_DEBUG= < CONFIG_RFCOMM_TRACE_LEVEL_VERBOSE= < CONFIG_RFCOMM_INITIAL_TRACE_LEVEL=2 < CONFIG_SDP_TRACE_LEVEL_NONE= < CONFIG_SDP_TRACE_LEVEL_ERROR= < CONFIG_SDP_TRACE_LEVEL_WARNING=y < CONFIG_SDP_TRACE_LEVEL_API= < CONFIG_SDP_TRACE_LEVEL_EVENT= < CONFIG_SDP_TRACE_LEVEL_DEBUG= < CONFIG_SDP_TRACE_LEVEL_VERBOSE= < CONFIG_SDP_INITIAL_TRACE_LEVEL=2 < CONFIG_GAP_TRACE_LEVEL_NONE= < CONFIG_GAP_TRACE_LEVEL_ERROR= < CONFIG_GAP_TRACE_LEVEL_WARNING=y < CONFIG_GAP_TRACE_LEVEL_API= < CONFIG_GAP_TRACE_LEVEL_EVENT= < CONFIG_GAP_TRACE_LEVEL_DEBUG= < CONFIG_GAP_TRACE_LEVEL_VERBOSE= < CONFIG_GAP_INITIAL_TRACE_LEVEL=2 < CONFIG_BNEP_TRACE_LEVEL_NONE= < CONFIG_BNEP_TRACE_LEVEL_ERROR= < CONFIG_BNEP_TRACE_LEVEL_WARNING=y < CONFIG_BNEP_TRACE_LEVEL_API= < CONFIG_BNEP_TRACE_LEVEL_EVENT= < CONFIG_BNEP_TRACE_LEVEL_DEBUG= < CONFIG_BNEP_TRACE_LEVEL_VERBOSE= < CONFIG_BNEP_INITIAL_TRACE_LEVEL=2 < CONFIG_PAN_TRACE_LEVEL_NONE= < CONFIG_PAN_TRACE_LEVEL_ERROR= < CONFIG_PAN_TRACE_LEVEL_WARNING=y < CONFIG_PAN_TRACE_LEVEL_API= < CONFIG_PAN_TRACE_LEVEL_EVENT= < CONFIG_PAN_TRACE_LEVEL_DEBUG= < CONFIG_PAN_TRACE_LEVEL_VERBOSE= < CONFIG_PAN_INITIAL_TRACE_LEVEL=2 < CONFIG_A2D_TRACE_LEVEL_NONE= < CONFIG_A2D_TRACE_LEVEL_ERROR= < CONFIG_A2D_TRACE_LEVEL_WARNING=y < CONFIG_A2D_TRACE_LEVEL_API= < CONFIG_A2D_TRACE_LEVEL_EVENT= < CONFIG_A2D_TRACE_LEVEL_DEBUG= < CONFIG_A2D_TRACE_LEVEL_VERBOSE= < CONFIG_A2D_INITIAL_TRACE_LEVEL=2 < CONFIG_AVDT_TRACE_LEVEL_NONE= < CONFIG_AVDT_TRACE_LEVEL_ERROR= < CONFIG_AVDT_TRACE_LEVEL_WARNING=y < CONFIG_AVDT_TRACE_LEVEL_API= < CONFIG_AVDT_TRACE_LEVEL_EVENT= < CONFIG_AVDT_TRACE_LEVEL_DEBUG= < CONFIG_AVDT_TRACE_LEVEL_VERBOSE= < CONFIG_AVDT_INITIAL_TRACE_LEVEL=2 < CONFIG_AVCT_TRACE_LEVEL_NONE= < CONFIG_AVCT_TRACE_LEVEL_ERROR= < CONFIG_AVCT_TRACE_LEVEL_WARNING=y < CONFIG_AVCT_TRACE_LEVEL_API= < CONFIG_AVCT_TRACE_LEVEL_EVENT= < CONFIG_AVCT_TRACE_LEVEL_DEBUG= < CONFIG_AVCT_TRACE_LEVEL_VERBOSE= < CONFIG_AVCT_INITIAL_TRACE_LEVEL=2 < CONFIG_AVRC_TRACE_LEVEL_NONE= < CONFIG_AVRC_TRACE_LEVEL_ERROR= < CONFIG_AVRC_TRACE_LEVEL_WARNING=y < CONFIG_AVRC_TRACE_LEVEL_API= < CONFIG_AVRC_TRACE_LEVEL_EVENT= < CONFIG_AVRC_TRACE_LEVEL_DEBUG= < CONFIG_AVRC_TRACE_LEVEL_VERBOSE= < CONFIG_AVRC_INITIAL_TRACE_LEVEL=2 < CONFIG_MCA_TRACE_LEVEL_NONE= < CONFIG_MCA_TRACE_LEVEL_ERROR= < CONFIG_MCA_TRACE_LEVEL_WARNING=y < CONFIG_MCA_TRACE_LEVEL_API= < CONFIG_MCA_TRACE_LEVEL_EVENT= < CONFIG_MCA_TRACE_LEVEL_DEBUG= < CONFIG_MCA_TRACE_LEVEL_VERBOSE= < CONFIG_MCA_INITIAL_TRACE_LEVEL=2 < CONFIG_HID_TRACE_LEVEL_NONE= < CONFIG_HID_TRACE_LEVEL_ERROR= < CONFIG_HID_TRACE_LEVEL_WARNING=y < CONFIG_HID_TRACE_LEVEL_API= < CONFIG_HID_TRACE_LEVEL_EVENT= < CONFIG_HID_TRACE_LEVEL_DEBUG= < CONFIG_HID_TRACE_LEVEL_VERBOSE= < CONFIG_HID_INITIAL_TRACE_LEVEL=2 < CONFIG_APPL_TRACE_LEVEL_NONE= < CONFIG_APPL_TRACE_LEVEL_ERROR= < CONFIG_APPL_TRACE_LEVEL_WARNING=y < CONFIG_APPL_TRACE_LEVEL_API= < CONFIG_APPL_TRACE_LEVEL_EVENT= < CONFIG_APPL_TRACE_LEVEL_DEBUG= < CONFIG_APPL_TRACE_LEVEL_VERBOSE= < CONFIG_APPL_INITIAL_TRACE_LEVEL=2 < CONFIG_GATT_TRACE_LEVEL_NONE= < CONFIG_GATT_TRACE_LEVEL_ERROR= < CONFIG_GATT_TRACE_LEVEL_WARNING=y < CONFIG_GATT_TRACE_LEVEL_API= < CONFIG_GATT_TRACE_LEVEL_EVENT= < CONFIG_GATT_TRACE_LEVEL_DEBUG= < CONFIG_GATT_TRACE_LEVEL_VERBOSE= < CONFIG_GATT_INITIAL_TRACE_LEVEL=2 < CONFIG_SMP_TRACE_LEVEL_NONE= < CONFIG_SMP_TRACE_LEVEL_ERROR= < CONFIG_SMP_TRACE_LEVEL_WARNING=y < CONFIG_SMP_TRACE_LEVEL_API= < CONFIG_SMP_TRACE_LEVEL_EVENT= < CONFIG_SMP_TRACE_LEVEL_DEBUG= < CONFIG_SMP_TRACE_LEVEL_VERBOSE= < CONFIG_SMP_INITIAL_TRACE_LEVEL=2 < CONFIG_BTIF_TRACE_LEVEL_NONE= < CONFIG_BTIF_TRACE_LEVEL_ERROR= < CONFIG_BTIF_TRACE_LEVEL_WARNING=y < CONFIG_BTIF_TRACE_LEVEL_API= < CONFIG_BTIF_TRACE_LEVEL_EVENT= < CONFIG_BTIF_TRACE_LEVEL_DEBUG= < CONFIG_BTIF_TRACE_LEVEL_VERBOSE= < CONFIG_BTIF_INITIAL_TRACE_LEVEL=2 < CONFIG_BTC_TRACE_LEVEL_NONE= < CONFIG_BTC_TRACE_LEVEL_ERROR= < CONFIG_BTC_TRACE_LEVEL_WARNING=y < CONFIG_BTC_TRACE_LEVEL_API= < CONFIG_BTC_TRACE_LEVEL_EVENT= < CONFIG_BTC_TRACE_LEVEL_DEBUG= < CONFIG_BTC_TRACE_LEVEL_VERBOSE= < CONFIG_BTC_INITIAL_TRACE_LEVEL=2 < CONFIG_OSI_TRACE_LEVEL_NONE= < CONFIG_OSI_TRACE_LEVEL_ERROR= < CONFIG_OSI_TRACE_LEVEL_WARNING=y < CONFIG_OSI_TRACE_LEVEL_API= < CONFIG_OSI_TRACE_LEVEL_EVENT= < CONFIG_OSI_TRACE_LEVEL_DEBUG= < CONFIG_OSI_TRACE_LEVEL_VERBOSE= < CONFIG_OSI_INITIAL_TRACE_LEVEL=2 < CONFIG_BLUFI_TRACE_LEVEL_NONE= < CONFIG_BLUFI_TRACE_LEVEL_ERROR= < CONFIG_BLUFI_TRACE_LEVEL_WARNING=y < CONFIG_BLUFI_TRACE_LEVEL_API= < CONFIG_BLUFI_TRACE_LEVEL_EVENT= < CONFIG_BLUFI_TRACE_LEVEL_DEBUG= < CONFIG_BLUFI_TRACE_LEVEL_VERBOSE= < CONFIG_BLUFI_INITIAL_TRACE_LEVEL=2 < CONFIG_BT_ACL_CONNECTIONS=2 < CONFIG_BT_ALLOCATION_FROM_SPIRAM_FIRST=y < CONFIG_BT_BLE_DYNAMIC_ENV_MEMORY=y < CONFIG_BLE_HOST_QUEUE_CONGESTION_CHECK= < CONFIG_SMP_ENABLE=y < CONFIG_BLE_ACTIVE_SCAN_REPORT_ADV_SCAN_RSP_INDIVIDUALLY= < CONFIG_BLE_ESTABLISH_LINK_CONNECTION_TIMEOUT=30 < CONFIG_BT_RESERVE_DRAM=0xdb5c --- > CONFIG_BT_RESERVE_DRAM=0 506a284 > CONFIG_NO_BLOBS= 514d291 < CONFIG_SW_COEXIST_ENABLE= 642c419 < CONFIG_FATFS_ALLOC_PREFER_EXTRAM=y --- > CONFIG_FATFS_ALLOC_PREFER_EXTRAM= 673c450 < CONFIG_FREERTOS_INTERRUPT_BACKTRACE=y --- > CONFIG_FREERTOS_INTERRUPT_BACKTRACE= 683c460 < CONFIG_TIMER_TASK_PRIORITY=1 --- > CONFIG_TIMER_TASK_PRIORITY=20 688,689c465,469 < CONFIG_FREERTOS_USE_STATS_FORMATTING_FUNCTIONS= < CONFIG_FREERTOS_GENERATE_RUN_TIME_STATS= --- > CONFIG_FREERTOS_USE_STATS_FORMATTING_FUNCTIONS=y > CONFIG_FREERTOS_VTASKLIST_INCLUDE_COREID= > CONFIG_FREERTOS_GENERATE_RUN_TIME_STATS=y > CONFIG_FREERTOS_RUN_TIME_STATS_USING_ESP_TIMER=y > CONFIG_FREERTOS_RUN_TIME_STATS_USING_CPU_CLK= 775c555 < CONFIG_TCPIP_TASK_AFFINITY_NO_AFFINITY=y --- > CONFIG_TCPIP_TASK_AFFINITY_NO_AFFINITY= 777,778c557,558 < CONFIG_TCPIP_TASK_AFFINITY_CPU1= < CONFIG_TCPIP_TASK_AFFINITY=0x7FFFFFFF --- > CONFIG_TCPIP_TASK_AFFINITY_CPU1=y > CONFIG_TCPIP_TASK_AFFINITY=0x1 810c590 < CONFIG_OVMS_HW_CAN_RX_QUEUE_SIZE=30 --- > CONFIG_OVMS_HW_CAN_RX_QUEUE_SIZE=60 859,860c639,640 < CONFIG_OVMS_VEHICLE_RXTASK_STACK=6144 < CONFIG_OVMS_VEHICLE_CAN_RX_QUEUE_SIZE=40 --- > CONFIG_OVMS_VEHICLE_RXTASK_STACK=8192 > CONFIG_OVMS_VEHICLE_CAN_RX_QUEUE_SIZE=60 865d644 < CONFIG_OVMS_COMP_BLUETOOTH=y 900d678 < CONFIG_BTDM_CONTROLLER_BR_EDR_SCO_DATA_PATH_EFF=0 905,906c683,684 < CONFIG_MBEDTLS_INTERNAL_MEM_ALLOC=y < CONFIG_MBEDTLS_EXTERNAL_MEM_ALLOC= --- > CONFIG_MBEDTLS_INTERNAL_MEM_ALLOC= > CONFIG_MBEDTLS_EXTERNAL_MEM_ALLOC=y 909c687 < CONFIG_MBEDTLS_SSL_MAX_CONTENT_LEN=4096 --- > CONFIG_MBEDTLS_SSL_MAX_CONTENT_LEN=16384 929c707 < CONFIG_MBEDTLS_KEY_EXCHANGE_PSK= --- > CONFIG_MBEDTLS_KEY_EXCHANGE_PSK=y 1104a883 > # Thanx in advance for your help. Regards Chris

2 3

v.c.timerstart units
by Stephen Casner 21 Mar '20

21 Mar '20

I have just fixed a presumably quite old typo/copy-paste bug in vehicle_teslaroadster that caused CAN decoding to miss the message sent when the charge start time is selected or adjusted on the VDS. That value is stored in v.c.timerstart. Now comes the question how should v.c.timerstart be interpreted -- the user guide does not say. What the code in vehicle_teslaroadster did was to set the GMT hour in the high 8 bits of a 16-bit integer and the minutes (always 0) in the low 8 bits. The current implementation of "metrics list" shows the value as a decimal integer, so for my car set to 11pm in the -7:00 time zone the value displayed is 1792, which is not very user-friendly. The Demo and Zeva vehicles just set the value to 0. The Kia Soul sets the value to seconds after midnight UTC/GMT. The Smart ED also sets the value in seconds, but the comments don't indicate what timezone. What should be the right interpretation and display of that value? It seems that a resolution of minutes would be sufficient because it is unlikely that any vehicle would allow starting at a second other than 0 within a minute, but keeping track of a time in seconds is a pretty standard unit. -- Steve

2 2

Kia Soul wrong SOH
by Michael Balzer 19 Mar '20

19 Mar '20

Robi Škulj <robi.skulj(a)siol.net> reported to me that he's got a wrong SOH reading on his Kia Soul. He says it's displayed as 60% and should be 100%. Regards, Michael -- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26

1 0

Fwd: KIA Soul charging door
by Mark Webb-Johnson 19 Mar '20

19 Mar '20

FYI: I’ve asked this user to raise the question on the forums: https://www.openvehicles.com/forum/38 <https://www.openvehicles.com/forum/38> Perhaps a Kia Soul developer could assist when he does? Thanks, Mark. > Subject: KIA Soul charging door > Date: 19 March 2020 at 4:43:13 AM HKT > > Hello > I need your help. I set up the OVMS v3. Everything works fine, but the charging door will not open wen i push the hold button on the key fob. What can i do? > Thank you and best regards > > Sent from my iPad

1 0

Android App 3.16.1
by Michael Balzer 19 Mar '20

19 Mar '20

I've just released version 3.16.1 of the Android App to the Play Store. History: https://github.com/openvehicles/Open-Vehicle-Android/wiki/History * VW e-Up! / Seat Mii electric / Škoda CitiGOe IV * More image optimizations for vehicles & icons APK: https://github.com/openvehicles/Open-Vehicle-Android/raw/master/release/Ope… Regards, Michael -- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26

1 0

VW e-Up project
by Chris van der Meijden 19 Mar '20

19 Mar '20

Dear OVMS-devs, my name is Chris van der Meijden (devmarxx) and I just started a new project on integrating the VW e-Up into OVMS. I mailed with Michael and he provided me with usefull procedure hints. I forked OVMS V3 and the Android code into my github account https://gi thub.com/devmarxx?tab=repositories and commited my changes to the code there. I also started a pull request, but there is no hurry, because my vehicle code is just a template at the moment (like the Fiat 500 e code). The Android code is complete, but Michael is quite right that it would confuse the users to suddenly see the VW e-Up when there is still no functionality, so no hurry there too. My experience on OVMS so far is, that have been playing with the code for about 4 years. It started all because at that time I could not use the Android app on my Cyanogenmod phone due to the "google services" popup. I checked out the source code, removed the google check line and voila I could use the app with my Twizy and with my server :-) Later we bought a Nissan Leaf and I came in contact with Tom Parker. I had already set up the OVMS V2 toolchain, so it was very nice that I could use Tom's code to get the climate control of the Leaf to work. Always nice mail contact with Tom. Amazing the we can work together in New Zealand and Germany without ever have met. That where good times :- ) So now we bought a VW e-Up, that will be delivered hopefully in April. So I thought now is a good time to get started with OVMS for the VW e- Up. I decided to connect to the vehicle not over the OBD connector, but through the OCU plug of the VW e-Up. By doing so I hope to bypass the complicated VW CAN TP2.0 protocoll and I will have direct access to the the VW comfort CAN. Time will tell if that is the right decission. I started a thread at the german goingelectric forum. Here I'll post my "adventures" (in German) and I hope to find some co-coders there too ht tps://www.goingelectric.de/forum/viewtopic.php?f=50&t=54620 Well .. So far my little introduction. Looking forward to do some happy coding together. Greetinx Chris

3 10

OVMS Server 3.0.001-14-g54850ef
by Mark Webb-Johnson 16 Mar '20

16 Mar '20

A big update to the v3 OVMS Server. I re-factored the ApiV2 plugin to move all the connection information to Core, and made it shareable between modules. This includes virtualising the actions to receive and transmit data from connections. The advantage here is that vehicles and apps no longer need to use the same protocol. So for example, this should allow an HTTP API App to connect to a v2 api vehicle. The HTTP API has been held back for some time because of this, but it will also affect MQTT connections. If anyone is using ‘db’ style function callbacks, please note the new ‘Db’ standardised prefix (before some were db and others were Db - messy). A lot of little bug fixes and cleanups were made at the same time. I hope it hasn’t broken anything. The first use of #1 is to implement websockets for apiv2. The standard server now supports this as ‘ws://api.openvehicles.com:6867/apiv2' <ws://api.openvehicles.com:6867/apiv2'> and ‘wss://api.openvehicles.com:6870/apiv2' <wss://api.openvehicles.com:6870/apiv2'>. For example: % wsta -p 60 --ping-msg 'A' -I wss://api.openvehicles.com:6870/apiv2/ WebSocket upgrade request --- Host: api.openvehicles.com:6870 Connection: Upgrade Upgrade: websocket Sec-WebSocket-Version: 13 Sec-WebSocket-Key: UWfgAzvxoM/cyT35flkuIA== Origin: https://api.openvehicles.com WebSocket upgrade response --- 101 Switching Protocols Upgrade: WebSocket Connection: Upgrade Sec-WebSocket-Accept: lHNFo4fdGzWc/GfTq7bJXm7jamw= Connected to wss://api.openvehicles.com:6870/apiv2/ MP-A 1 <username> <password> DEMO MP-S 1 <username> DEMO DEMO CAR2 CAR3 CAR4 ... Z1 F1.5.0,VIN123456789012345,5,1,TRDM S31,K,220,13,charging,standard,109,98,13,1,0,0,5,1,0,0,0,1 … It works by picking up the HTTP 'GET /apiv2/ HTTP/1.1’ line as the first line of the protocol negotiation (where it was expecting MP-C, MP-A, etc). If found, it will switch to handshake a websocket connection, and from then onwards websocket messages are simply apiv2 lines (without the CRLF). When combined with SSL and crypto 0x31 authentication, it is pretty cool (as seen above). You will need to include the perl library Protocol::WebSocket (from cpan/package/etc). I also extended the crypto 0x31 mechanism to send the list of accessible vehicle IDs (as well as the selected vehicle ID). This should be very useful for Apps and Cars to be able to auto-discover the available vehicles on the account. Remember that ‘*’ can be used to auto-select the first vehicle on the account. So you can send ‘MP-A 1 <username> <password> *’, and get back a connection to the first vehicle plus a list of alternatives vehicles available. This has been a lot of work putting together the pieces for something more interesting. More on that in a subsequent mailing (but you can probably guess)... Regards, Mark.

1 0

Anyone using HTTP API?
by Mark Webb-Johnson 13 Mar '20

13 Mar '20

Is anyone here using the HTTP API at all? It seems so tied to the v2 protocol, as to not be much use. Regards, Mark.

3 18