I can’t repeat the issue. Here is what I did: Bring your vehicle_kiasoulev into the latest build tree for ovms v3. Change #include “esp_log.h" to #include "ovms_log.h" Remove: MyEvents.RegisterEvent(TAG, "ticker.1", std::bind(&OvmsVehicleKiaSoulEv::Ticker1, this, _1, _2)); and change: OvmsVehicleKiaSoulEv::Ticker1(std::string event, void* data) to OvmsVehicleKiaSoulEv::Ticker1(uint32_t ticker) Add an ESP_LOGI diagnostic trace to Ticker1 and SetChargeMetrics In the constructor, set: ks_charge_bits.ChargingJ1772 = true; ks_charge_bits.ChargingChademo = true; and removed the comment-out in SetChargeMetrics Here is the output that I get: OVMS > level info Logging level for * set to info OVMS > vehicle module KS I (9235) v-kiasoulev: Kia Soul EV v3.0 vehicle module I (10035) v-kiasoulev: Ticker1 ks_charge_bits.ChargingJ1772=1 ks_charge_bits.ChargingChademo=1 I (10035) v-kiasoulev: SetChargeMetrics V=230.000000 C=0.000000 CL=28.695652 CHADEMO=0 I (10035) v-kiasoulev: Aux Battery voltage low OVMS > metrics list v.c.mode v.c.mode standard OVMS > metrics list v.c.type v.c.type type1 OVMS > metrics list v.c.vol v.c.voltage 230V Are you sure you are running against the ‘latest’ openvehicles/esp-idf (2.1 branch) and openvehicles/ovmsv3 (master branch)? You can try to menuconfig Components -> ESP32 -> Panic Handler Behaviour -> Invoke GDBStub (to get a better stack trace and diagnostic capability). Going forward, it is probably easiest to merge in what you have with our master github, and tidy up the integration a bit (stuff like the ovms_log.h not esp_log.h, the Ticker1 event, etc); that way we keep you up-to-date with framework (in particular vehicle.{h,cpp}) changes. Shall I do that now? Based on your master or pr/5 branch? Regards, Mark.
On 27 Nov 2017, at 4:18 PM, Geir Øyvind Vælidalo <geir@validalo.net> wrote:
Ok, Mark, I've committed my latest version to https://github.com/goev/Open-Vehicle-Monitoring-System-3 Everything I've done is in vehicle_kiasoulev.
I set the charge mode in a function called SetChargeMetrics. It is called from Ticker1 when ks_charge_bits.ChargingJ1772 or ks_charge_bits.ChargingChademo is true. (Un)fortunately ks_charge_bits is uninitialized and probably contains some garbage, so it usually fires the call to SetChargeMetrics when running "vehicle module KS" even when not connected to the car. I need to set a default value to the ks_charge_bits and probab some more ks_-variables in the constructor, but I haven't come that yet.
NB! In SetChargeMetrics, I've commented out the charge mode-line, so you need to remove the comment-tag and comment.
Yesterday I also found out that ms_v_charge_state gives similar problems. It was *really* late, so I didn't look to close into it, but it seemed related. I've added a macro in vehicle_kiasoulev.h called SET_CHARGE_STATE where I've commented out the setting of the charge state, in case you find time to look into that too.
Thanks!
Geir
Really need to see the overall context of this. Where are you calling the ms_v_charge_mode->SetValue from?
Probably easiest to commit what you have to your own github clone, then let us know where that is and we can see the whole thing.
Regards, Mark.
On 26 Nov 2017, at 4:35 AM, Geir Øyvind Vælidalo <geir@validalo.net> wrote:
I’m having problems setting ms_v_charge_mode. I do it this way, but it fails at runtime:
StdMetrics.ms_v_charge_mode->SetValue( chademo ? "performance" : "standard");
This is the trace I get, so it seems to fail somewhere else:
I (6451) events: Signal(vehicle.charge.mGuru Meditation Error of type LoadProhibited occurred on core 0. Exception was unhandled. Register dump: PC : 0x400883c3 PS : 0x00060633 A0 : 0x8008708a A1 : 0x3ffc6b30 0x400883c3: vListInsertEnd at /Users/goev/esp/esp-idf/components/freertos/./list.c:130
A2 : 0x3ffc6384 A3 : 0x3ffc6c78 A4 : 0x00060620 A5 : 0x00000000 A6 : 0x00000000 A7 : 0x00000000 A8 : 0x00000038 A9 : 0x3ffb33b8 A10 : 0x3ffb131c A11 : 0x00060623 A12 : 0x00060623 A13 : 0x3ffce1ec A14 : 0x3ffce1ec A15 : 0x3ffc6a70 SAR : 0x00000010 EXCCAUSE: 0x0000001c EXCVADDR: 0x00000040 LBEG : 0x400014fd LEND : 0x4000150d LCOUNT : 0xfffffffa
Backtrace: 0x400883c3:0x3ffc6b30 0x40087087:0x3ffc6b50 0x400860f1:0x3ffc6b70 0x4008771b:0x3ffc6b90 0x40087818:0x3ffc6bc0 0x400883c3: vListInsertEnd at /Users/goev/esp/esp-idf/components/freertos/./list.c:130
0x40087087: vTaskPlaceOnEventListRestricted at /Users/goev/esp/esp-idf/components/freertos/./tasks.c:4446
0x400860f1: vQueueWaitForMessageRestricted at /Users/goev/esp/esp-idf/components/freertos/./queue.c:2392
0x4008771b: prvProcessTimerOrBlockTask at /Users/goev/esp/esp-idf/components/freertos/./timers.c:839
0x40087818: prvTimerTask at /Users/goev/esp/esp-idf/components/freertos/./timers.c:839
It looks like it has something to do with the Signal event, but I ‘m still not that good using gbd to find out what actually makes this fail. Any one got a clue?
Regards, Geir
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev