1. des. 2017 kl. 01:52 skrev Mark Webb-Johnson <mark@webb-johnson.net>:

I can’t repeat the issue. Here is what I did:

1. Bring your vehicle_kiasoulev into the latest build tree for ovms v3.
   
   
2. Change
   #include “esp_log.h"
   to
   #include "ovms_log.h"
   
   
3. 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)
   
   
4. Add an ESP_LOGI diagnostic trace to Ticker1 and SetChargeMetrics
   
   
5. 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

_______________________________________________
OvmsDev mailing list
OvmsDev@lists.teslaclub.hk
http://lists.teslaclub.hk/mailman/listinfo/ovmsdev