[Ovmsdev] Problems ms_v_charge_mode
Mark Webb-Johnson
mark at webb-johnson.net
Fri Dec 1 08:52:43 HKT 2017
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 at 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 at 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 at lists.teslaclub.hk
>>> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
>>
>> _______________________________________________
>> OvmsDev mailing list
>> OvmsDev at lists.teslaclub.hk
>> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
>>
>
>
> _______________________________________________
> OvmsDev mailing list
> OvmsDev at lists.teslaclub.hk
> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openvehicles.com/pipermail/ovmsdev/attachments/20171201/b33e5104/attachment.htm>
More information about the OvmsDev
mailing list