That's RX buffer 0 overflow: …and the new code should have reset it automatically -- the status output shows the last error state that occurred. Maybe that's a timing issue? Are you sure about the 100 kbit? I've found 125 kbit in a forum: http://www.mykiasoulev.com/forum/viewtopic.php?t=135#p1772 Regards, Michael Am 30.12.2017 um 18:45 schrieb Geir Øyvind Vælidalo:
Looks correct now, but as you guessed, it still stops. What does error flag 0x40 mean? Is the CAN_IRQ_ARB_LOST?
Geir
30. des. 2017 kl. 18:38 skrev Michael Balzer <dexter@expeedo.de <mailto:dexter@expeedo.de>>:
OK, I found & fixed the cause for the invalid frames.
Please pull & try again -- but I doubt it's the fix for the stopping.
Am 30.12.2017 um 18:33 schrieb Michael Balzer:
Do you get valid messages with the previous version?
Regards, Michael
Am 30.12.2017 um 18:30 schrieb Geir Øyvind Vælidalo:
Ok, this is what I get. As you can see, it is the same.
OVMS >can can2 start active 100000 Can bus can2 started in mode active at speed 100000Kbps V (740558) can: rx can2 id 1fffff44 len 8: 43 02 00 00 00 00 ff ff | C....... V (740618) can: rx can2 id 000 len 8: b6 78 00 00 00 00 00 00 | .x...... V (740618) can: rx can2 id 000 len 8: ff fc 0f 03 ff 00 00 00 | ........ V (740628) can: rx can2 id 000 len 8: ff ff ff ff ff ff 00 00 | ........ V (740638) can: rx can2 id 000 len 8: 54 00 ff 00 00 00 00 00 | T....... V (740648) can: rx can2 id 1fffffbe len 8: 4d 02 00 00 00 00 ff ff | M....... V (740678) can: rx can2 id 000 len 8: 00 00 00 00 00 00 00 00 | ........ V (740748) can: rx can2 id 1fffff44 len 8: 40 02 00 00 00 00 ff ff | @....... V (740818) can: rx can2 id 000 len 8: b6 78 00 00 00 00 00 00 | .x...... V (740818) can: rx can2 id 000 len 8: ff fc 0f 03 ff 00 00 00 | ........ V (740828) can: rx can2 id 000 len 8: ff ff ff ff ff ff 00 00 | ........ V (740838) can: rx can2 id 1fffff13 len 8: 43 02 00 00 00 00 ff ff | C....... V (740848) can: rx can2 id 000 len 8: 54 00 ff 00 00 00 00 00 | T....... V (740878) can: rx can2 id 000 len 8: 00 00 00 00 00 00 00 00 | ........ V (741018) can: rx can2 id 000 len 8: b6 78 00 00 00 00 00 00 | .x...... V (741018) can: rx can2 id 000 len 8: ff fc 0f 03 ff 00 00 00 | ........ V (741028) can: rx can2 id 1fffff44 len 8: 40 02 00 00 00 00 ff ff | @....... V (741038) can: rx can2 id 000 len 8: 54 00 ff 00 00 00 00 00 | T....... V (741078) can: rx can2 id 000 len 8: 00 00 00 00 00 00 00 00 | ........ OVMS >
30. des. 2017 kl. 18:24 skrev Michael Balzer <dexter@expeedo.de <mailto:dexter@expeedo.de>>:
OK, and as your log output was from your vehicle module, please also do…
level verbose can can2 trace on
…before activating the bus.
Thanks, Michael
Am 30.12.2017 um 18:22 schrieb Geir Øyvind Vælidalo:
Can status gave this:
CAN: can2 Mode: Active Speed: 100000 Rx pkt: 104 Rx err: 0 Tx pkt: 0 Tx err: 0 Err flags: 0x40
> 30. des. 2017 kl. 18:13 skrev Geir Øyvind Vælidalo <geir@validalo.net <mailto:geir@validalo.net>>: > > Fantastic! I’m in my car right now, so I’ll test it right now 🙂 > > Geir > >> 30. des. 2017 kl. 17:59 skrev Michael Balzer <dexter@expeedo.de <mailto:dexter@expeedo.de>>: >> >> Geir, >> >> I've had a look into the mcp2515 driver and found some possible causes for your issue. Main possible cause would be there was no check or clearing of >> RX buffer overflows. >> >> There also was a chance the driver would read invalid frames, as the RX interrupts got cleared before the buffer content was fetched. >> >> I think I've solved those issues, and I also added retrieving the tx/rx error counts and flags, so "can status" can actually show you errors that occurred. >> >> I've got no simple means to check if my changes work and if they are more stable, I don't have a cable for can2/3. >> >> Can you please pull & test? >> >> Regards, >> Michael >> >> >> Am 30.12.2017 um 10:19 schrieb Geir Øyvind Vælidalo: >>> can can2 status gave me the same result. Once it stopped after receiving just 4 frames on Can2. During the few restarts I did this morning, 251 was >>> the most I got before it stopped. >>> Can1 recieved 50000 frames in no time and kept on going. It seems Can2 is the problem. Don’t know what happened yesterday when can1 stopped… >>> >>> Geir >>> >>>> 29. des. 2017 kl. 22:23 skrev Michael Balzer <dexter@expeedo.de <mailto:dexter@expeedo.de>>: >>>> >>>> Geir, >>>> >>>> can you check the output of "can … status" before and after death? Do the rx/tx counters still grow after death? >>>> >>>> Regards, >>>> Michael >>>> >>>> >>>> Am 29.12.2017 um 22:14 schrieb Geir Øyvind Vælidalo: >>>>> I’m having problems with IncomingFrameCan when reading from two can buses from the Kia Soul. One of the can buses dies prematurely, and quite fast, >>>>> with no visible errors. Most of the time it is Can2 that dies, however that is not always the case. >>>>> I tried with an almost empty IncomingFrameCan2, containing just a counter to see how many times it is called, and it varied from 15 to almost 200 >>>>> before it dies. >>>>> >>>>> This is the code: >>>>> >>>>> RegisterCanBus(1, CAN_MODE_ACTIVE, CAN_SPEED_500KBPS); >>>>> RegisterCanBus(2, CAN_MODE_ACTIVE, CAN_SPEED_100KBPS); >>>>> >>>>> … >>>>> >>>>> void OvmsVehicleKiaSoulEv::IncomingFrameCan2(CAN_frame_t* p_frame) >>>>> { >>>>> uint8_t *d = p_frame->data.u8; >>>>> m_counter->SetValue( m_counter->AsInt()+1 ); >>>>> } >>>>> >>>>> IncomingFrameCan1 is quite verbose, but should not take too long time to process. But I have a lot of Polls on Can1: >>>>> >>>>> static const OvmsVehicle::poll_pid_t vehicle_kiasoulev_polls[] = >>>>> { >>>>> { 0x7e2, 0x7ea, VEHICLE_POLL_TYPE_OBDIIVEHICLE, 0x02, { 30, 30, 30 } }, // VIN >>>>> { 0x7e4, 0x7ec, VEHICLE_POLL_TYPE_OBDIIGROUP, 0x01, { 30, 10, 10 } }, // BMC Diagpage 01 >>>>> { 0x7e4, 0x7ec, VEHICLE_POLL_TYPE_OBDIIGROUP, 0x02, { 30, 30, 10 } }, // BMC Diagpage 02 >>>>> { 0x7e4, 0x7ec, VEHICLE_POLL_TYPE_OBDIIGROUP, 0x03, { 30, 30, 10 } }, // BMC Diagpage 03 >>>>> { 0x7e4, 0x7ec, VEHICLE_POLL_TYPE_OBDIIGROUP, 0x04, { 30, 30, 10 } }, // BMC Diagpage 04 >>>>> { 0x7e4, 0x7ec, VEHICLE_POLL_TYPE_OBDIIGROUP, 0x05, { 30, 30, 10 } },// BMC Diagpage 05 >>>>> { 0x794, 0x79c, VEHICLE_POLL_TYPE_OBDIIGROUP, 0x02, { 30, 30, 10 } }, // OBC - On board charger >>>>> { 0x7e2, 0x7ea, VEHICLE_POLL_TYPE_OBDIIGROUP, 0x00, { 30, 10, 10 } }, // VMCU Shift-stick >>>>> { 0x7e2, 0x7ea, VEHICLE_POLL_TYPE_OBDIIGROUP, 0x02, { 30, 10, 0 } }, // VMCU Motor temp++ >>>>> { 0x7df, 0x7de, VEHICLE_POLL_TYPE_OBDIIGROUP, 0x06, { 30, 10, 0 } }, // TMPS >>>>> { 0x7c5, 0x7cd, VEHICLE_POLL_TYPE_OBDIIGROUP, 0x01, { 30, 10, 0 } }, // LDC - Low voltage DC-DC >>>>> { 0, 0, 0, 0, { 0, 0, 0 } } >>>>> }; >>>>> >>>>> The few times that Can2 is the one that lives on, I can’t see any metrics from Can1. >>>>> >>>>> Current source can be seen here: https://github.com/goev/Open-Vehicle-Monitoring-System-3 in case someone can take a look. >>>>> >>>>> Any pointers to where I can start looking, or tips to what I can try? >>>>> >>>>> Best regards, >>>>> Geir >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> OvmsDev mailing list >>>>> OvmsDev@lists.teslaclub.hk >>>>> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev >>>> >>>> -- >>>> Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal >>>> Fon 02333 / 833 5735 * Handy 0176 / 206 989 26 >>>> _______________________________________________ >>>> OvmsDev mailing list >>>> OvmsDev@lists.teslaclub.hk <mailto: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 >> >> -- >> Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal >> Fon 02333 / 833 5735 * Handy 0176 / 206 989 26 >> _______________________________________________ >> OvmsDev mailing list >> OvmsDev@lists.teslaclub.hk <mailto:OvmsDev@lists.teslaclub.hk> >> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev > > _______________________________________________ > OvmsDev mailing list > OvmsDev@lists.teslaclub.hk <mailto: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
-- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26 _______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk <mailto: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
-- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
-- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26 _______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk <mailto: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
-- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
