[Ovmsdev] Problems with IncomingFrameCan when registering two can buses.

Geir Øyvind Vælidalo geir at validalo.net
Sun Dec 31 01:13:36 HKT 2017


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 at 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 at expeedo.de <mailto:dexter at 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 Diag page 01
>>>>     { 0x7e4, 0x7ec, VEHICLE_POLL_TYPE_OBDIIGROUP,  	0x02, {  30,  30,  10 } }, 	// BMC Diag page 02
>>>>     { 0x7e4, 0x7ec, VEHICLE_POLL_TYPE_OBDIIGROUP,  	0x03, {  30,  30,  10 } }, 	// BMC Diag page 03
>>>>     { 0x7e4, 0x7ec, VEHICLE_POLL_TYPE_OBDIIGROUP,  	0x04, {  30,  30,  10 } }, 	// BMC Diag page 04
>>>>     { 0x7e4, 0x7ec, VEHICLE_POLL_TYPE_OBDIIGROUP,  	0x05, {  30,  30,  10 } },	// BMC Diag page 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 <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 at lists.teslaclub.hk <mailto:OvmsDev at lists.teslaclub.hk>
>>>> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev <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 at lists.teslaclub.hk <mailto:OvmsDev at lists.teslaclub.hk>
>>> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev <http://lists.teslaclub.hk/mailman/listinfo/ovmsdev>
>> 
>> 
>> 
>> _______________________________________________
>> OvmsDev mailing list
>> OvmsDev at lists.teslaclub.hk <mailto:OvmsDev at lists.teslaclub.hk>
>> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev <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 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/20171230/1ba6fefe/attachment.htm>


More information about the OvmsDev mailing list