Problems with IncomingFrameCan when registering two can buses.
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
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
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
- des. 2017 kl. 22:23 skrev Michael Balzer <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 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@lists.teslaclub.hk <mailto:OvmsDev@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@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
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
- 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
Fantastic! I’m in my car right now, so I’ll test it right now 🙂
Geir
- des. 2017 kl. 17:59 skrev Michael Balzer <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
- 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 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@lists.teslaclub.hk <mailto:OvmsDev@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@lists.teslaclub.hk <mailto:OvmsDev@lists.teslaclub.hk> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev <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 <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
Hm… It didn’t fix the issues. Also, the MsgId looks messed up:
OVMS > can can2 start active 100000 Can bus can2 started in mode active at speed 100000Kbps D (80978) v-kiasoulev: M-CAN2 000 8 3c 00 f0 00 00 00 00 00 D (80988) v-kiasoulev: M-CAN2 1fffff13 8 03 00 0c 1f 47 c0 ff f3 D (80998) v-kiasoulev: M-CAN2 000 8 ff fc 0f 03 ff 00 00 00 D (80998) v-kiasoulev: M-CAN2 1fffffbe 8 06 00 ff ff ff ff ff ff D (81118) v-kiasoulev: M-CAN2 000 8 54 00 ff 00 00 00 00 00 D (81178) v-kiasoulev: M-CAN2 000 8 3c 00 f0 00 00 00 00 00 D (81188) v-kiasoulev: M-CAN2 000 8 00 00 00 c0 ff ff 0f 00 D (81208) v-kiasoulev: M-CAN2 000 8 ff ff ff ff ff ff 00 00 D (81318) v-kiasoulev: M-CAN2 000 8 54 00 ff 00 00 00 00 00 D (81378) v-kiasoulev: M-CAN2 000 8 3c 00 f0 00 00 00 00 00 D (81398) v-kiasoulev: M-CAN2 000 8 00 00 00 c0 ff ff 0f 00 D (81398) v-kiasoulev: M-CAN2 000 8 ff fc 0f 03 ff 00 00 00 D (81518) v-kiasoulev: M-CAN2 000 8 54 00 ff 00 00 00 00 00 D (81578) v-kiasoulev: M-CAN2 000 8 3c 00 f0 00 00 00 00 00 D (81588) v-kiasoulev: M-CAN2 1fffffbe 8 4d 02 00 00 00 00 ff ff OVMS >
As you can see, it still stops after few messages. Anything particular I should look into/test?
Best regards, Geir
- des. 2017 kl. 18:13 skrev Geir Øyvind Vælidalo <geir@validalo.net>:
Fantastic! I’m in my car right now, so I’ll test it right now 🙂
Geir
- 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
- 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 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@lists.teslaclub.hk <mailto:OvmsDev@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@lists.teslaclub.hk <mailto:OvmsDev@lists.teslaclub.hk> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev <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 <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
Please send me:
can can2 status
Regards, Michael
Am 30.12.2017 um 18:20 schrieb Geir Øyvind Vælidalo:
Hm… It didn’t fix the issues. Also, the MsgId looks messed up:
OVMS >can can2 start active 100000 Can bus can2 started in mode active at speed 100000Kbps D (80978) v-kiasoulev: M-CAN2 000 8 3c 00 f0 00 00 00 00 00 D (80988) v-kiasoulev: M-CAN2 1fffff13 8 03 00 0c 1f 47 c0 ff f3 D (80998) v-kiasoulev: M-CAN2 000 8 ff fc 0f 03 ff 00 00 00 D (80998) v-kiasoulev: M-CAN2 1fffffbe 8 06 00 ff ff ff ff ff ff D (81118) v-kiasoulev: M-CAN2 000 8 54 00 ff 00 00 00 00 00 D (81178) v-kiasoulev: M-CAN2 000 8 3c 00 f0 00 00 00 00 00 D (81188) v-kiasoulev: M-CAN2 000 8 00 00 00 c0 ff ff 0f 00 D (81208) v-kiasoulev: M-CAN2 000 8 ff ff ff ff ff ff 00 00 D (81318) v-kiasoulev: M-CAN2 000 8 54 00 ff 00 00 00 00 00 D (81378) v-kiasoulev: M-CAN2 000 8 3c 00 f0 00 00 00 00 00 D (81398) v-kiasoulev: M-CAN2 000 8 00 00 00 c0 ff ff 0f 00 D (81398) v-kiasoulev: M-CAN2 000 8 ff fc 0f 03 ff 00 00 00 D (81518) v-kiasoulev: M-CAN2 000 8 54 00 ff 00 00 00 00 00 D (81578) v-kiasoulev: M-CAN2 000 8 3c 00 f0 00 00 00 00 00 D (81588) v-kiasoulev: M-CAN2 1fffffbe 8 4d 02 00 00 00 00 ff ff OVMS >
As you can see, it still stops after few messages. Anything particular I should look into/test?
Best regards, Geir
- 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
- 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
- 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
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
- des. 2017 kl. 18:13 skrev Geir Øyvind Vælidalo <geir@validalo.net>:
Fantastic! I’m in my car right now, so I’ll test it right now 🙂
Geir
- 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
- 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 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@lists.teslaclub.hk <mailto:OvmsDev@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@lists.teslaclub.hk <mailto:OvmsDev@lists.teslaclub.hk> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev <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 <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
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
- 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
- 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
- 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
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 >
- des. 2017 kl. 18:24 skrev Michael Balzer <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
- 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
- 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
- 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 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@lists.teslaclub.hk <mailto:OvmsDev@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@lists.teslaclub.hk <mailto:OvmsDev@lists.teslaclub.hk> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev <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 <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 <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 <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 <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
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 >
- 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
- 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
- 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
Yes. They where valid in previous version.
Geir
- des. 2017 kl. 18:33 skrev Michael Balzer <dexter@expeedo.de>:
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 >
- 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
- 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
- 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 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@lists.teslaclub.hk <mailto:OvmsDev@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@lists.teslaclub.hk <mailto:OvmsDev@lists.teslaclub.hk> >> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev <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 <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 <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 <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 <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 <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 <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
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 >
- 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
- 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
- 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
Looks correct now, but as you guessed, it still stops. What does error flag 0x40 mean? Is the CAN_IRQ_ARB_LOST?
Geir
- des. 2017 kl. 18:38 skrev Michael Balzer <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 >
- 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
- 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 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@lists.teslaclub.hk <mailto:OvmsDev@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@lists.teslaclub.hk <mailto:OvmsDev@lists.teslaclub.hk> >>> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev <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 <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 <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 <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 <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 <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 <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 <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
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
- 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 >
- 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
I’m pretty sure it’s 100kbit. I’ve decoded a lot of data with another can-logger. I’ve been restarting the can-bus some times now and there’s two «special» PIDs that aren’t among the ones the trace have printed out. On of these messages can look like this: 49bh 10 31 f0 32 00 30 00 31 49bh 21 00 2c 00 20 00 46 00 49bh 22 72 00 69 00 64 00 74 49bh 23 00 6a 00 6f 00 66 00 49bh 24 20 00 4e 00 61 00 6e 49bh 25 00 73 00 65 00 6e 00 49bh 26 73 00 20 00 76 00 2e 49bh 27 00 aa aa aa aa aa aa
It is a «multiframe» response containing text. Don’t know if that might be a problem?
Geir
- des. 2017 kl. 18:52 skrev Michael Balzer <dexter@expeedo.de>:
That's RX buffer 0 overflow:
<epbaejkifcjkiahk.png>
…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 <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
- 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 >
- 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 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@lists.teslaclub.hk <mailto:OvmsDev@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@lists.teslaclub.hk <mailto:OvmsDev@lists.teslaclub.hk> >>>>> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev <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 <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 <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 <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 <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 <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 <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 <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 <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 <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
Please try 125000, just to be sure.
At these rates many transceivers should be able to silently correct the timing, maybe the MCP2515 gives up on this after some frames.
Multiframe responses are just plain frames to the CAN driver, if there's a bug it would be in the application, the can trace logging would continue to work.
Am 30.12.2017 um 19:01 schrieb Geir Øyvind Vælidalo:
I’m pretty sure it’s 100kbit. I’ve decoded a lot of data with another can-logger. I’ve been restarting the can-bus some times now and there’s two «special» PIDs that aren’t among the ones the trace have printed out. On of these messages can look like this: 49bh 10 31 f0 32 00 30 00 31 49bh 21 00 2c 00 20 00 46 00 49bh 22 72 00 69 00 64 00 74 49bh 23 00 6a 00 6f 00 66 00 49bh 24 20 00 4e 00 61 00 6e 49bh 25 00 73 00 65 00 6e 00 49bh 26 73 00 20 00 76 00 2e 49bh 27 00 aa aa aa aa aa aa
It is a «multiframe» response containing text. Don’t know if that might be a problem?
Geir
- des. 2017 kl. 18:52 skrev Michael Balzer <dexter@expeedo.de <mailto:dexter@expeedo.de>>:
That's RX buffer 0 overflow:
<epbaejkifcjkiahk.png>
…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
- 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
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
OVMS > can can2 start active 100000 Can bus can2 started in mode active at speed 100000Kbps V (1616109) can: rx can2 id 114 len 8: b6 78 ff ff 00 00 00 00 | .x...... V (1616109) can: rx can2 id 1e7 len 8: ff ff ff ff ff ff 00 00 | ........ V (1616109) can: rx can2 id 123 len 8: 00 00 00 c0 ff ff 0f 00 | ........ OVMS > can can2 start active 100000 Can bus can2 started in mode active at speed 100000Kbps V (1618439) can: rx can2 id 130 len 8: 02 0d 09 ff ff ff ff 00 | ........ V (1618509) can: rx can2 id 114 len 8: b6 78 ff ff 00 00 00 00 | .x...... V (1618509) can: rx can2 id 123 len 8: 00 00 00 c0 ff ff 0f 00 | ........ V (1618509) can: rx can2 id 1e7 len 8: ff ff ff ff ff ff 00 00 | ........ V (1618569) can: rx can2 id 443 len 8: 4d 02 00 00 00 00 ff ff | M....... V (1618709) can: rx can2 id 114 len 8: b6 78 ff ff 00 00 00 00 | .x...... V (1618709) can: rx can2 id 123 len 8: 00 00 00 c0 ff ff 0f 00 | ........ V (1618709) can: rx can2 id 1e7 len 8: ff ff ff ff ff ff 00 00 | ........ V (1618749) can: rx can2 id 531 len 8: 54 00 ff 00 00 00 00 00 | T....... V (1618849) can: rx can2 id 443 len 8: 4d 02 00 00 00 00 ff ff | M....... V (1618909) can: rx can2 id 114 len 8: b6 78 ff ff 00 00 00 00 | .x...... V (1618909) can: rx can2 id 123 len 8: 00 00 00 c0 ff ff 0f 00 | ........ V (1618909) can: rx can2 id 1e7 len 8: ff ff ff ff ff ff 00 00 | ........ OVMS > can can2 start active 125000 Can bus can2 started in mode active at speed 125000Kbps OVMS > can can2 start active 125000 Can bus can2 started in mode active at speed 125000Kbps OVMS > can can2 start active 125000 Can bus can2 started in mode active at speed 125000Kbps OVMS > can can2 start active 125000 Can bus can2 started in mode active at speed 125000Kbps OVMS > can can2 start active 125000 Can bus can2 started in mode active at speed 125000Kbps OVMS > can can2 start active 125000 Can bus can2 started in mode active at speed 125000Kbps OVMS >
I’m pretty sure 100kbit is correct. I get no response on 125kbit, but 100kbit always give a few lines at least.
It is strange that these two IDs are missing… Although, when I think of it, they aren’t transmitted as often as the rest, so that can explain why they aren’t in the traces.
Geir
- des. 2017 kl. 19:07 skrev Michael Balzer <dexter@expeedo.de>:
Please try 125000, just to be sure.
At these rates many transceivers should be able to silently correct the timing, maybe the MCP2515 gives up on this after some frames.
Multiframe responses are just plain frames to the CAN driver, if there's a bug it would be in the application, the can trace logging would continue to work.
Am 30.12.2017 um 19:01 schrieb Geir Øyvind Vælidalo:
I’m pretty sure it’s 100kbit. I’ve decoded a lot of data with another can-logger. I’ve been restarting the can-bus some times now and there’s two «special» PIDs that aren’t among the ones the trace have printed out. On of these messages can look like this: 49bh 10 31 f0 32 00 30 00 31 49bh 21 00 2c 00 20 00 46 00 49bh 22 72 00 69 00 64 00 74 49bh 23 00 6a 00 6f 00 66 00 49bh 24 20 00 4e 00 61 00 6e 49bh 25 00 73 00 65 00 6e 00 49bh 26 73 00 20 00 76 00 2e 49bh 27 00 aa aa aa aa aa aa
It is a «multiframe» response containing text. Don’t know if that might be a problem?
Geir
- des. 2017 kl. 18:52 skrev Michael Balzer <dexter@expeedo.de <mailto:dexter@expeedo.de>>:
That's RX buffer 0 overflow:
<epbaejkifcjkiahk.png>
…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 <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
- 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 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@lists.teslaclub.hk <mailto:OvmsDev@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@lists.teslaclub.hk <mailto:OvmsDev@lists.teslaclub.hk> >>>>>>> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev <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 <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 <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 <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 <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 <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 <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 <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 <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 <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 <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 <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
Thanks Greg. This can-bus is only 100kbit and uses less than 10% of the available capacity. It is a low speed, low traffic bus. And currently I don’t do any transmitting on it.
I don’t see why it shouldn’t work for me, then.
Geir
- des. 2017 kl. 19:07 skrev Greg D. <gregd2350@gmail.com>:
For what it's worth, I've been using CAN3 for a long time with no lockups, running the OBDII ECU code. What is different, perhaps, is that all the interactions are at 500k speed (vs 1000), and generally alternate one frame receive, followed by one frame transmit. So, overflow should never occur unless the OBD2ECU code stops, at which point I probably didn't care. Standard vs extended has not been a factor, in case that's a question.
The only issue we had was that if you try to transmit several frames back-to-back, the third and subsequent frame sent were all duplicates of the second frame. That was fixed by adding a delay in the code, hoping that it would be sufficient for the prior frame to actually get sent. Seems to work, though those frames are typically only sent at startup (request of VIN or ECU Name), not hammered on.
Greg
Geir Øyvind Vælidalo wrote:
Looks correct now, but as you guessed, it still stops. What does error flag 0x40 mean? Is the CAN_IRQ_ARB_LOST?
Geir
- 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 >
- 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 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@lists.teslaclub.hk <mailto:OvmsDev@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@lists.teslaclub.hk <mailto:OvmsDev@lists.teslaclub.hk> >>>>> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev <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 <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 <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 <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 <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 <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 <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 <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 <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 <http://lists.teslaclub.hk/mailman/listinfo/ovmsdev>
OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
I don’t have anything connected to CAN3. I could try to use CAN3 instead of CAN2. It’s a long shot, but worth a try… I’ll look into it tomorrow.
Geir
- des. 2017 kl. 19:29 skrev Greg D. <gregd2350@gmail.com>:
Ha, I thought 100k was a typo for 1000, sorry... Yeah, high speed overflow shouldn't be an issue. On the other hand, low speed means that the time to receive a frame increases 10x, so that opens up a larger window if the chip doesn't like being talked to when actively receiving a frame. Perhaps there is some interaction between the two sides of the chip? For example, are there any registers that pertain to both busses? I only use CAN3, with nothing connected to CAN2.
Greg
Geir Øyvind Vælidalo wrote:
Thanks Greg. This can-bus is only 100kbit and uses less than 10% of the available capacity. It is a low speed, low traffic bus. And currently I don’t do any transmitting on it.
I don’t see why it shouldn’t work for me, then.
Geir
- des. 2017 kl. 19:07 skrev Greg D. <gregd2350@gmail.com <mailto:gregd2350@gmail.com>>:
For what it's worth, I've been using CAN3 for a long time with no lockups, running the OBDII ECU code. What is different, perhaps, is that all the interactions are at 500k speed (vs 1000), and generally alternate one frame receive, followed by one frame transmit. So, overflow should never occur unless the OBD2ECU code stops, at which point I probably didn't care. Standard vs extended has not been a factor, in case that's a question.
The only issue we had was that if you try to transmit several frames back-to-back, the third and subsequent frame sent were all duplicates of the second frame. That was fixed by adding a delay in the code, hoping that it would be sufficient for the prior frame to actually get sent. Seems to work, though those frames are typically only sent at startup (request of VIN or ECU Name), not hammered on.
Greg
OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
Geir,
can you please try this: locate the speed setup in mcp2515.cpp, it's around line 115. Replace the setup for 100 KBPS by this:
case CAN_SPEED_100KBPS:
//cnf1=0x03; cnf2=0xfa; cnf3=0x87;
cnf1=0x44; cnf2=0xe5; cnf3=0x83;
break;Then try again.
Am 30.12.2017 um 20:25 schrieb Geir Øyvind Vælidalo:
I don’t have anything connected to CAN3. I could try to use CAN3 instead of CAN2. It’s a long shot, but worth a try… I’ll look into it tomorrow.
Geir
- des. 2017 kl. 19:29 skrev Greg D. <gregd2350@gmail.com <mailto:gregd2350@gmail.com>>:
Ha, I thought 100k was a typo for 1000, sorry... Yeah, high speed overflow shouldn't be an issue. On the other hand, low speed means that the time to receive a frame increases 10x, so that opens up a larger window if the chip doesn't like being talked to when actively receiving a frame. Perhaps there is some interaction between the two sides of the chip? For example, are there any registers that pertain to both busses? I only use CAN3, with nothing connected to CAN2.
Greg
Geir Øyvind Vælidalo wrote:
Thanks Greg. This can-bus is only 100kbit and uses less than 10% of the available capacity. It is a low speed, low traffic bus. And currently I don’t do any transmitting on it.
I don’t see why it shouldn’t work for me, then.
Geir
- des. 2017 kl. 19:07 skrev Greg D. <gregd2350@gmail.com <mailto:gregd2350@gmail.com>>:
For what it's worth, I've been using CAN3 for a long time with no lockups, running the OBDII ECU code. What is different, perhaps, is that all the interactions are at 500k speed (vs 1000), and generally alternate one frame receive, followed by one frame transmit. So, overflow should never occur unless the OBD2ECU code stops, at which point I probably didn't care. Standard vs extended has not been a factor, in case that's a question.
The only issue we had was that if you try to transmit several frames back-to-back, the third and subsequent frame sent were all duplicates of the second frame. That was fixed by adding a delay in the code, hoping that it would be sufficient for the prior frame to actually get sent. Seems to work, though those frames are typically only sent at startup (request of VIN or ECU Name), not hammered on.
Greg
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
Hm. One more try?
cnf1=0x43; cnf2=0xe5; cnf3=0x83;Am 30.12.2017 um 20:44 schrieb Geir Øyvind Vælidalo:
To me, it looks to give the same result. No difference :-(
Geir
- des. 2017 kl. 20:30 skrev Michael Balzer <dexter@expeedo.de <mailto:dexter@expeedo.de>>:
cnf1=0x44; cnf2=0xe5; cnf3=0x83;
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
Got this now:
OVMS > can can2 status CAN: can2 Mode: Active Speed: 100000 Rx pkt: 0 Rx err: 135 Tx pkt: 0 Tx err: 0 Err flags: 0xb
No packets at all.
Geir
- des. 2017 kl. 20:50 skrev Michael Balzer <dexter@expeedo.de>:
Hm. One more try?
cnf1=0x43; cnf2=0xe5; cnf3=0x83;Am 30.12.2017 um 20:44 schrieb Geir Øyvind Vælidalo:
To me, it looks to give the same result. No difference :-(
Geir
- des. 2017 kl. 20:30 skrev Michael Balzer <dexter@expeedo.de <mailto:dexter@expeedo.de>>:
cnf1=0x44; cnf2=0xe5; cnf3=0x83;
OvmsDev mailing list OvmsDev@lists.teslaclub.hk <mailto:OvmsDev@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@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
I guess we can rule out timing issues then. Those are the values used by the MCP2515 Arduino lib by Cory Fowler.
The second set is used for 125 kbit, so I guess 100 kbit is confirmed.
I've got no more ideas at the moment. You can check the driver yourself, see doc for MCP2515. Maybe a comparison with Corys implementation makes sense.
Regards, Michael
Am 30.12.2017 um 20:55 schrieb Geir Øyvind Vælidalo:
Got this now:
OVMS >can can2 status CAN: can2 Mode: Active Speed: 100000 Rx pkt: 0 Rx err: 135 Tx pkt: 0 Tx err: 0 Err flags: 0xb
No packets at all.
Geir
- des. 2017 kl. 20:50 skrev Michael Balzer <dexter@expeedo.de <mailto:dexter@expeedo.de>>:
Hm. One more try?
cnf1=0x43; cnf2=0xe5; cnf3=0x83;Am 30.12.2017 um 20:44 schrieb Geir Øyvind Vælidalo:
To me, it looks to give the same result. No difference :-(
Geir
- des. 2017 kl. 20:30 skrev Michael Balzer <dexter@expeedo.de <mailto:dexter@expeedo.de>>:
cnf1=0x44; cnf2=0xe5; cnf3=0x83;
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
Ok. Thanks for your help so far, Michael!
I’ll dig deeper into this.
Geir
- des. 2017 kl. 21:24 skrev Michael Balzer <dexter@expeedo.de>:
I guess we can rule out timing issues then. Those are the values used by the MCP2515 Arduino lib by Cory Fowler.
The second set is used for 125 kbit, so I guess 100 kbit is confirmed.
I've got no more ideas at the moment. You can check the driver yourself, see doc for MCP2515. Maybe a comparison with Corys implementation makes sense.
Regards, Michael
Am 30.12.2017 um 20:55 schrieb Geir Øyvind Vælidalo:
Got this now:
OVMS > can can2 status CAN: can2 Mode: Active Speed: 100000 Rx pkt: 0 Rx err: 135 Tx pkt: 0 Tx err: 0 Err flags: 0xb
No packets at all.
Geir
- des. 2017 kl. 20:50 skrev Michael Balzer <dexter@expeedo.de <mailto:dexter@expeedo.de>>:
Hm. One more try?
cnf1=0x43; cnf2=0xe5; cnf3=0x83;Am 30.12.2017 um 20:44 schrieb Geir Øyvind Vælidalo:
To me, it looks to give the same result. No difference :-(
Geir
- des. 2017 kl. 20:30 skrev Michael Balzer <dexter@expeedo.de <mailto:dexter@expeedo.de>>:
cnf1=0x44; cnf2=0xe5; cnf3=0x83;
OvmsDev mailing list OvmsDev@lists.teslaclub.hk <mailto:OvmsDev@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@lists.teslaclub.hk <mailto:OvmsDev@lists.teslaclub.hk> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev <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 <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
I did a test where I created three counters. One went into MCP2515_isr and counts every interrupt. One was added as the first code line in mcp2515::RxCallback. And the third one was added to RxCallBack, but right before we read the CAN frame via SPI that will end up in IncomingFrame. I.e. should be a count of every CAN frame.
This is what I got:
OVMS > can can2 status CAN: can2 Mode: Active Speed: 100000 Rx pkt: 82 MCP2515_isr: 239 RxCallback1: 320 RxCallback2: 295 Rx err: 0 Tx pkt: 0 Tx err: 0 Err flags: 0x2040
These numbers puzzles me. Shouldn’t RxCallback1 and RxCallback2 be less or equal to MCP2515_isr? Where does these extra 81 calls come from? I’m missing something here...
Also, RxCallback2 is much bigger than Rx pkt, which means not all frames are sent to IncomingFrame. I Believe the reason is this code in can.cpp CAN_rxtask:
case CAN_rxcallback:
while (msg.body.bus->RxCallback(&msg.body.frame))
{
me->IncomingFrame(&msg.body.frame);
}
break;Is this correct? Wouldn’t it skip calling IncomingFrame it there are only one interrupt? I would think this is would be more appropriate:
case CAN_rxcallback:
{
bool keepOn=true;
do
{
keepOn = msg.body.bus->RxCallback(&msg.body.frame);
me->IncomingFrame(&msg.body.frame);
}while(keepOn);
}
break;Do you agree?
But, the interrupts still stops :-( What does the 0x2040 means? And where do that number comes from?
Best regards, Geir
- des. 2017 kl. 21:24 skrev Michael Balzer <dexter@expeedo.de>:
MCP2515 Arduino
Geir & Greg,
first of all, I did an over-optimization mistake in the RxCallback: the return after fetching the frame must always be true -- fix is pushed.
That has caused frames to get lost so you should apply this fix first.
Am 31.12.2017 um 01:00 schrieb Geir Øyvind Vælidalo:
I did a test where I created three counters. One went into MCP2515_isr and counts every interrupt. One was added as the first code line in mcp2515::RxCallback. And the third one was added to RxCallBack, but right before we read the CAN frame via SPI that will end up in IncomingFrame. I.e. should be a count of every CAN frame.
This is what I got:
OVMS >can can2 status CAN: can2 Mode: Active Speed: 100000 Rx pkt: 82 MCP2515_isr: 239 RxCallback1: 320 RxCallback2: 295 Rx err: 0 Tx pkt: 0 Tx err: 0 Err flags: 0x2040
These numbers puzzles me. Shouldn’t *RxCallback1* and *RxCallback2* be less or equal to *MCP2515_isr*? Where does these extra 81 calls come from? I’m missing something here...
No, that's expected behaviour. The MCP2515 has two RX buffers plus error conditions. The framework is designed to loop RxCallback over an IRQ event until all buffers and error conditions have been processed, so RxCallback counters should always be >= ISR count.
Also*, RxCallback2* is much bigger than *Rx pkt, *which means not all frames are sent to IncomingFrame.
That's in part due to my bug, but it also can happen under normal conditions, as an error IRQ will also trigger the RxCallback but not return a frame to be processed.
What does the 0x2040 means? And where do that number comes from?
That's constructed in line 293 from the error interrupt flags and the error register. The lower 8 bits are in the image I sent, the upper 8 bits are
// MERRF 0x80 = message tx/rx error
// ERRIF 0x20 = overflow / error state changeRegards, Michael
-- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
I’ve been looking into what’s happening with the interrupt/queue this morning and your fix makes more sense than my suggestion. It could potentially fix the problem with the buffer filling up. Unfortunately my wife is using the car so I can’t test this yet,
Geir
- des. 2017 kl. 10:54 skrev Michael Balzer <dexter@expeedo.de>:
Geir & Greg,
first of all, I did an over-optimization mistake in the RxCallback: the return after fetching the frame must always be true -- fix is pushed.
That has caused frames to get lost so you should apply this fix first.
Am 31.12.2017 um 01:00 schrieb Geir Øyvind Vælidalo:
I did a test where I created three counters. One went into MCP2515_isr and counts every interrupt. One was added as the first code line in mcp2515::RxCallback. And the third one was added to RxCallBack, but right before we read the CAN frame via SPI that will end up in IncomingFrame. I.e. should be a count of every CAN frame.
This is what I got:
OVMS > can can2 status CAN: can2 Mode: Active Speed: 100000 Rx pkt: 82 MCP2515_isr: 239 RxCallback1: 320 RxCallback2: 295 Rx err: 0 Tx pkt: 0 Tx err: 0 Err flags: 0x2040
These numbers puzzles me. Shouldn’t RxCallback1 and RxCallback2 be less or equal to MCP2515_isr? Where does these extra 81 calls come from? I’m missing something here...
No, that's expected behaviour. The MCP2515 has two RX buffers plus error conditions. The framework is designed to loop RxCallback over an IRQ event until all buffers and error conditions have been processed, so RxCallback counters should always be >= ISR count.
Also, RxCallback2 is much bigger than Rx pkt, which means not all frames are sent to IncomingFrame.
That's in part due to my bug, but it also can happen under normal conditions, as an error IRQ will also trigger the RxCallback but not return a frame to be processed.
What does the 0x2040 means? And where do that number comes from?
That's constructed in line 293 from the error interrupt flags and the error register. The lower 8 bits are in the image I sent, the upper 8 bits are
// MERRF 0x80 = message tx/rx error // ERRIF 0x20 = overflow / error state changeRegards, Michael
-- 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
I've added another minor change to avoid TX lockups if the bus is lost (i.e. disconnected). Also CMD_READ_RXBUF actually clears the interrupt flag itself, so we can skip the additional BITMODIFY call.
The internal ESP32 CAN controller (SJA1000) unfortunately only has one TX buffer. I'm having performance issues with the TX speed on that, it's not consistently sufficient high to get the Twizy charge control working reliably. Not sure yet if that's caused by the CAN controller, the driver or the RTOS.
Regards, Michael
Am 31.12.2017 um 14:33 schrieb Geir Øyvind Vælidalo:
I’ve been looking into what’s happening with the interrupt/queue this morning and your fix makes more sense than my suggestion. It could potentially fix the problem with the buffer filling up. Unfortunately my wife is using the car so I can’t test this yet,
Geir
- des. 2017 kl. 10:54 skrev Michael Balzer <dexter@expeedo.de <mailto:dexter@expeedo.de>>:
Geir & Greg,
first of all, I did an over-optimization mistake in the RxCallback: the return after fetching the frame must always be true -- fix is pushed.
That has caused frames to get lost so you should apply this fix first.
Am 31.12.2017 um 01:00 schrieb Geir Øyvind Vælidalo:
I did a test where I created three counters. One went into MCP2515_isr and counts every interrupt. One was added as the first code line in mcp2515::RxCallback. And the third one was added to RxCallBack, but right before we read the CAN frame via SPI that will end up in IncomingFrame. I.e. should be a count of every CAN frame.
This is what I got:
OVMS >can can2 status CAN: can2 Mode: Active Speed: 100000 Rx pkt: 82 MCP2515_isr: 239 RxCallback1: 320 RxCallback2: 295 Rx err: 0 Tx pkt: 0 Tx err: 0 Err flags: 0x2040
These numbers puzzles me. Shouldn’t *RxCallback1* and *RxCallback2* be less or equal to *MCP2515_isr*? Where does these extra 81 calls come from? I’m missing something here...
No, that's expected behaviour. The MCP2515 has two RX buffers plus error conditions. The framework is designed to loop RxCallback over an IRQ event until all buffers and error conditions have been processed, so RxCallback counters should always be >= ISR count.
Also*, RxCallback2* is much bigger than *Rx pkt, *which means not all frames are sent to IncomingFrame.
That's in part due to my bug, but it also can happen under normal conditions, as an error IRQ will also trigger the RxCallback but not return a frame to be processed.
What does the 0x2040 means? And where do that number comes from?
That's constructed in line 293 from the error interrupt flags and the error register. The lower 8 bits are in the image I sent, the upper 8 bits are
// MERRF 0x80 = message tx/rx error // ERRIF 0x20 = overflow / error state changeRegards, Michael
-- 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
Greg,
you should now also be able to see TX overflows in the can status output.
I removed the delay loop because delays and retries should not be done by the driver, the driver should just tell the application about a fail, which it does now. Also, the minimum delay with vTaskDelay() is 1 "tick" = currently 10 ms, which is already far too much time to be spent on this level.
The previous esp32can implementation did no checking of the TX buffer at all, resulting in silent losses or possibly corruptions of frames on TX overflows.
And TX overflows actually do occur quite often, without a plausible cause:
OVMS > can can1 status CAN: can1 Mode: Active Speed: 500000 Rx pkt: 133146 Rx err: 0 Rx ovrflw: 0 Tx pkt: 53238 Tx err: 95 Tx ovrflw: *498* Err flags: 0x12c00
In this case, a TX occurs every 10 ms on a 500 kbit bus -- plenty of time for the buffer to get sent. I'm looking into that.
Regards, Michael
Am 31.12.2017 um 19:37 schrieb Greg D.:
Ok, MUCH better. CAN3 is back to working again! No evidence of the transmit overrun problem, and the frames are about 50ms apart, so I think your transmit changes are working. I'm running 500k BAUD.
I'll let it run for a while, just to check stability. But so far, Yea!
Greg
Michael Balzer wrote:
I've added another minor change to avoid TX lockups if the bus is lost (i.e. disconnected). Also CMD_READ_RXBUF actually clears the interrupt flag itself, so we can skip the additional BITMODIFY call.
The internal ESP32 CAN controller (SJA1000) unfortunately only has one TX buffer. I'm having performance issues with the TX speed on that, it's not consistently sufficient high to get the Twizy charge control working reliably. Not sure yet if that's caused by the CAN controller, the driver or the RTOS.
Regards, Michael
Am 31.12.2017 um 14:33 schrieb Geir Øyvind Vælidalo:
I’ve been looking into what’s happening with the interrupt/queue this morning and your fix makes more sense than my suggestion. It could potentially fix the problem with the buffer filling up. Unfortunately my wife is using the car so I can’t test this yet,
Geir
- des. 2017 kl. 10:54 skrev Michael Balzer <dexter@expeedo.de <mailto:dexter@expeedo.de>>:
Geir & Greg,
first of all, I did an over-optimization mistake in the RxCallback: the return after fetching the frame must always be true -- fix is pushed.
That has caused frames to get lost so you should apply this fix first.
Am 31.12.2017 um 01:00 schrieb Geir Øyvind Vælidalo:
I did a test where I created three counters. One went into MCP2515_isr and counts every interrupt. One was added as the first code line in mcp2515::RxCallback. And the third one was added to RxCallBack, but right before we read the CAN frame via SPI that will end up in IncomingFrame. I.e. should be a count of every CAN frame.
This is what I got:
OVMS >can can2 status CAN: can2 Mode: Active Speed: 100000 Rx pkt: 82 MCP2515_isr: 239 RxCallback1: 320 RxCallback2: 295 Rx err: 0 Tx pkt: 0 Tx err: 0 Err flags: 0x2040
These numbers puzzles me. Shouldn’t *RxCallback1* and *RxCallback2* be less or equal to *MCP2515_isr*? Where does these extra 81 calls come from? I’m missing something here...
No, that's expected behaviour. The MCP2515 has two RX buffers plus error conditions. The framework is designed to loop RxCallback over an IRQ event until all buffers and error conditions have been processed, so RxCallback counters should always be >= ISR count.
Also*, RxCallback2* is much bigger than *Rx pkt, *which means not all frames are sent to IncomingFrame.
That's in part due to my bug, but it also can happen under normal conditions, as an error IRQ will also trigger the RxCallback but not return a frame to be processed.
What does the 0x2040 means? And where do that number comes from?
That's constructed in line 293 from the error interrupt flags and the error register. The lower 8 bits are in the image I sent, the upper 8 bits are
// MERRF 0x80 = message tx/rx error // ERRIF 0x20 = overflow / error state changeRegards, Michael
-- 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
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
Turned out this was no hardware issue but a scheduler problem: the CAN rx and vehicle rx tasks were not scheduled often & fast enough to consistently keep up with the 10 ms period.
After assigning the CAN RX task to core 0 and raising the vehicle task priority to 10, there are no more TX overflows, and my charge control override works perfectly.
Geir, I don't know if that helps with your can2 issue, but it's worth a try.
Regards, Michael
Am 31.12.2017 um 19:59 schrieb Michael Balzer:
And TX overflows actually do occur quite often, without a plausible cause:
OVMS > can can1 status CAN: can1 Mode: Active Speed: 500000 Rx pkt: 133146 Rx err: 0 Rx ovrflw: 0 Tx pkt: 53238 Tx err: 95 Tx ovrflw: *498* Err flags: 0x12c00
In this case, a TX occurs every 10 ms on a 500 kbit bus -- plenty of time for the buffer to get sent. I'm looking into that.
-- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
Great Michael! I’ll test that as soon as I have the time.
The previous version made me come a little bit further, however it will still stop, but for another reason. Maybe the last change will fix that?
I seems my problem now has to do with the queue. The queue is shared between both CAN-busses: Can1 (500kbit) and can2 (100kbit). The RxCallback sometimes handles multiple can-frames from can2 in one «queue»-entry. Which means it can take quite a long time to finish. At that time the much faster can1 fills the rest of the queue. At the next interrupt, the queue is full and the RxCallback on can2 won’t be called. The flags on mcp2515 won’t be cleared and no more interrupts will occur.
I wonder if we should have one queue per can and in CAN_rxtask we could check m_rxqueue1, m_rxqueue2 and m_rxqueue in a round robin fashion.
I think it is quick to test, so if your latest changes won’t fix this, I will try with separate queues.
Geir
- des. 2017 kl. 21:38 skrev Michael Balzer <dexter@expeedo.de>:
Turned out this was no hardware issue but a scheduler problem: the CAN rx and vehicle rx tasks were not scheduled often & fast enough to consistently keep up with the 10 ms period.
After assigning the CAN RX task to core 0 and raising the vehicle task priority to 10, there are no more TX overflows, and my charge control override works perfectly.
Geir, I don't know if that helps with your can2 issue, but it's worth a try.
Regards, Michael
Am 31.12.2017 um 19:59 schrieb Michael Balzer:
And TX overflows actually do occur quite often, without a plausible cause:
OVMS > can can1 status CAN: can1 Mode: Active Speed: 500000 Rx pkt: 133146 Rx err: 0 Rx ovrflw: 0 Tx pkt: 53238 Tx err: 95 Tx ovrflw: 498 Err flags: 0x12c00
In this case, a TX occurs every 10 ms on a 500 kbit bus -- plenty of time for the buffer to get sent. I'm looking into that.
-- 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
YESSS! Both can-buses are working now! Was stable for at least a few minutes (that was what I got time for), so I think we can say problem solve. Thanks guys!
Happy new year to all!
Geir
- des. 2017 kl. 23:07 skrev Greg D. <gregd2350@gmail.com>:
Right. I verified the Tx with Wireshark, but the counters are zero as well. Good cross-check.
Fully agree with not putting delays in the driver. My understanding from others was that it was a temporary hack to get things to work, pending a better solution. We now have that, thanks!
Greg
Michael Balzer wrote:
Greg,
you should now also be able to see TX overflows in the can status output.
I removed the delay loop because delays and retries should not be done by the driver, the driver should just tell the application about a fail, which it does now. Also, the minimum delay with vTaskDelay() is 1 "tick" = currently 10 ms, which is already far too much time to be spent on this level.
The previous esp32can implementation did no checking of the TX buffer at all, resulting in silent losses or possibly corruptions of frames on TX overflows.
And TX overflows actually do occur quite often, without a plausible cause:
OVMS > can can1 status CAN: can1 Mode: Active Speed: 500000 Rx pkt: 133146 Rx err: 0 Rx ovrflw: 0 Tx pkt: 53238 Tx err: 95 Tx ovrflw: 498 Err flags: 0x12c00
In this case, a TX occurs every 10 ms on a 500 kbit bus -- plenty of time for the buffer to get sent. I'm looking into that.
Regards, Michael
Am 31.12.2017 um 19:37 schrieb Greg D.:
Ok, MUCH better. CAN3 is back to working again! No evidence of the transmit overrun problem, and the frames are about 50ms apart, so I think your transmit changes are working. I'm running 500k BAUD.
I'll let it run for a while, just to check stability. But so far, Yea!
Greg
Michael Balzer wrote:
I've added another minor change to avoid TX lockups if the bus is lost (i.e. disconnected). Also CMD_READ_RXBUF actually clears the interrupt flag itself, so we can skip the additional BITMODIFY call.
The internal ESP32 CAN controller (SJA1000) unfortunately only has one TX buffer. I'm having performance issues with the TX speed on that, it's not consistently sufficient high to get the Twizy charge control working reliably. Not sure yet if that's caused by the CAN controller, the driver or the RTOS.
Regards, Michael
Am 31.12.2017 um 14:33 schrieb Geir Øyvind Vælidalo:
I’ve been looking into what’s happening with the interrupt/queue this morning and your fix makes more sense than my suggestion. It could potentially fix the problem with the buffer filling up. Unfortunately my wife is using the car so I can’t test this yet,
Geir
- des. 2017 kl. 10:54 skrev Michael Balzer <dexter@expeedo.de <mailto:dexter@expeedo.de>>:
Geir & Greg,
first of all, I did an over-optimization mistake in the RxCallback: the return after fetching the frame must always be true -- fix is pushed.
That has caused frames to get lost so you should apply this fix first.
Am 31.12.2017 um 01:00 schrieb Geir Øyvind Vælidalo: > I did a test where I created three counters. > One went into MCP2515_isr and counts every interrupt. > One was added as the first code line in mcp2515::RxCallback. > And the third one was added to RxCallBack, but right before we read the CAN frame via SPI that will end up in IncomingFrame. I.e. should be a count of every CAN frame.
> > This is what I got: > > OVMS > can can2 status > CAN: can2 > Mode: Active > Speed: 100000 > Rx pkt: 82 > MCP2515_isr: 239 > RxCallback1: 320 > RxCallback2: 295 > Rx err: 0 > Tx pkt: 0 > Tx err: 0 > Err flags: 0x2040 > > These numbers puzzles me. Shouldn’t RxCallback1 and RxCallback2 be less or equal to MCP2515_isr? Where does these extra 81 calls come from? I’m missing something here...No, that's expected behaviour. The MCP2515 has two RX buffers plus error conditions. The framework is designed to loop RxCallback over an IRQ event until all buffers and error conditions have been processed, so RxCallback counters should always be >= ISR count.
> Also, RxCallback2 is much bigger than Rx pkt, which means not all frames are sent to IncomingFrame.
That's in part due to my bug, but it also can happen under normal conditions, as an error IRQ will also trigger the RxCallback but not return a frame to be processed.
> > What does the 0x2040 means? And where do that number comes from? >
That's constructed in line 293 from the error interrupt flags and the error register. The lower 8 bits are in the image I sent, the upper 8 bits are
// MERRF 0x80 = message tx/rx error // ERRIF 0x20 = overflow / error state changeRegards, Michael
-- 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 <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 <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 <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 <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 <http://lists.teslaclub.hk/mailman/listinfo/ovmsdev>
OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
Great work done here. Thanks to all contributors.
I’ve been away for the past few days, spending some quality time with my wife and kids. I left OVMS v3 running on my desk, connected via the cellular network here in Malaysia. It saw a bunch of connection drops, but overall managed to reconnect each time and be stable for 10 days. I think we’re close… Just need to deal with the edge case of modem rebooting and losing MUX connection.
Regards, Mark.
On 1 Jan 2018, at 7:00 PM, Geir Øyvind Vælidalo <geir@validalo.net> wrote:
YESSS! Both can-buses are working now! Was stable for at least a few minutes (that was what I got time for), so I think we can say problem solve. Thanks guys!
Happy new year to all!
Geir
- des. 2017 kl. 23:07 skrev Greg D. <gregd2350@gmail.com <mailto:gregd2350@gmail.com>>:
Right. I verified the Tx with Wireshark, but the counters are zero as well. Good cross-check.
Fully agree with not putting delays in the driver. My understanding from others was that it was a temporary hack to get things to work, pending a better solution. We now have that, thanks!
Greg
Michael Balzer wrote:
Greg,
you should now also be able to see TX overflows in the can status output.
I removed the delay loop because delays and retries should not be done by the driver, the driver should just tell the application about a fail, which it does now. Also, the minimum delay with vTaskDelay() is 1 "tick" = currently 10 ms, which is already far too much time to be spent on this level.
The previous esp32can implementation did no checking of the TX buffer at all, resulting in silent losses or possibly corruptions of frames on TX overflows.
And TX overflows actually do occur quite often, without a plausible cause:
OVMS > can can1 status CAN: can1 Mode: Active Speed: 500000 Rx pkt: 133146 Rx err: 0 Rx ovrflw: 0 Tx pkt: 53238 Tx err: 95 Tx ovrflw: 498 Err flags: 0x12c00
In this case, a TX occurs every 10 ms on a 500 kbit bus -- plenty of time for the buffer to get sent. I'm looking into that.
Regards, Michael
Am 31.12.2017 um 19:37 schrieb Greg D.:
Ok, MUCH better. CAN3 is back to working again! No evidence of the transmit overrun problem, and the frames are about 50ms apart, so I think your transmit changes are working. I'm running 500k BAUD.
I'll let it run for a while, just to check stability. But so far, Yea!
Greg
Michael Balzer wrote:
I've added another minor change to avoid TX lockups if the bus is lost (i.e. disconnected). Also CMD_READ_RXBUF actually clears the interrupt flag itself, so we can skip the additional BITMODIFY call.
The internal ESP32 CAN controller (SJA1000) unfortunately only has one TX buffer. I'm having performance issues with the TX speed on that, it's not consistently sufficient high to get the Twizy charge control working reliably. Not sure yet if that's caused by the CAN controller, the driver or the RTOS.
Regards, Michael
Am 31.12.2017 um 14:33 schrieb Geir Øyvind Vælidalo:
I’ve been looking into what’s happening with the interrupt/queue this morning and your fix makes more sense than my suggestion. It could potentially fix the problem with the buffer filling up. Unfortunately my wife is using the car so I can’t test this yet,
Geir
> 31. des. 2017 kl. 10:54 skrev Michael Balzer <dexter@expeedo.de <mailto:dexter@expeedo.de>>: > > Geir & Greg, > > first of all, I did an over-optimization mistake in the RxCallback: the return after fetching the frame must always be true -- fix is pushed. > > That has caused frames to get lost so you should apply this fix first. > > > Am 31.12.2017 um 01:00 schrieb Geir Øyvind Vælidalo: >> I did a test where I created three counters. >> One went into MCP2515_isr and counts every interrupt. >> One was added as the first code line in mcp2515::RxCallback. >> And the third one was added to RxCallBack, but right before we read the CAN frame via SPI that will end up in IncomingFrame. I.e. should be a count of every CAN frame.
>> >> This is what I got: >> >> OVMS > can can2 status >> CAN: can2 >> Mode: Active >> Speed: 100000 >> Rx pkt: 82 >> MCP2515_isr: 239 >> RxCallback1: 320 >> RxCallback2: 295 >> Rx err: 0 >> Tx pkt: 0 >> Tx err: 0 >> Err flags: 0x2040 >> >> These numbers puzzles me. Shouldn’t RxCallback1 and RxCallback2 be less or equal to MCP2515_isr? Where does these extra 81 calls come from? I’m missing something here... > > No, that's expected behaviour. The MCP2515 has two RX buffers plus error conditions. The framework is designed to loop RxCallback over an IRQ event until all buffers and error conditions have been processed, so RxCallback counters should always be >= ISR count. > >> Also, RxCallback2 is much bigger than Rx pkt, which means not all frames are sent to IncomingFrame. > > That's in part due to my bug, but it also can happen under normal conditions, as an error IRQ will also trigger the RxCallback but not return a frame to be processed. > >> >> What does the 0x2040 means? And where do that number comes from? >> > > That's constructed in line 293 from the error interrupt flags and the error register. The lower 8 bits are in the image I sent, the upper 8 bits are > > // MERRF 0x80 = message tx/rx error > // ERRIF 0x20 = overflow / error state change > > Regards, > Michael > > -- > 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 <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 <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 <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 <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 <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
Mark,
Am 03.01.2018 um 13:35 schrieb Mark Webb-Johnson:
I left OVMS v3 running on my desk, connected via the cellular network here in Malaysia. It saw a bunch of connection drops, but overall managed to reconnect each time and be stable for 10 days. I think we’re close… Just need to deal with the edge case of modem rebooting and losing MUX connection.
Not sure if this is the edge case: if the connection is running over Wifi and the modem is idling, it will lose the ppp connection after some time. When it does, the v2 server will also disconnect, although it's still connected via Wifi. When the ppp link then gets back up, occasionally the server reconnect will fail continously with a DNS error:
… I (21780828) ovms-server-v2: Send MP-0 h394,0,RT-GPS-Log,293916,86400,51.30231476,7.39006519,326,197,0,1,119,-105,0,0,0,0,0,0,40,19000,-2000,1.000,1.000,0,0 I (21780868) ovms-server-v2: Incoming Msg: MP-0 h394 I (21780868) notify: Cleanup type data id 394 I (21782818) simcom: PPP Connection disconnected I (21782818) simcom: PPP Connection disconnected I (21783008) simcom: Lost network connection (+PPP disconnect in NetMode) I (21783008) simcom: State: Enter NetLoss state I (21783008) gsm-ppp: Shutting down (hard)... I (21783008) events: Signal(system.modem.down) I (21783008) events: Signal(network.modem.down) I (21783008) events: Signal(network.reconfigured) I (21783008) ovms-server-v2: Network is down, so disconnect network connection E (21783008) ovms-server-v2: Status: Error: Disconnected from OVMS Server V2 I (21788578) gsm-ppp: StatusCallBack: User Interrupt I (21788578) gsm-ppp: PPP connection has been closed I (21788578) events: Signal(system.modem.down) I (21792008) simcom: State timeout, transition to 5 I (21792008) simcom: State: Enter NetWait state I (21792008) gsm-nmea: Startup I (21793018) ovms-server-v2: Connection is ovms.dexters-web.de:6867 TEST1/aeL1aN9j W (21793018) net: DNS lookup on ovms.dexters-web.de failed err=202 E (21793028) ovms-server-v2: Status: Error: Cannot establish tcp/ip connection to server I (21796008) simcom: State: Enter NetStart state I (21797028) simcom: PPP Connection is ready to start I (21798008) simcom: State: Enter NetMode state I (21798008) gsm-ppp: Initialising... I (21800268) gsm-ppp: StatusCallBack: None I (21800268) gsm-ppp: status_cb: Connected I (21800268) gsm-ppp: our_ipaddr = 10.170.195.13 I (21800268) gsm-ppp: his_ipaddr = 10.64.64.64 I (21800268) gsm-ppp: netmask = 255.255.255.255 I (21800268) gsm-ppp: our6_ipaddr = :: I (21800268) events: Signal(system.modem.gotip) I (21800268) events: Signal(network.modem.up) I (21800268) events: Signal(network.up) I (21803028) ovms-server-v2: Connection is ovms.dexters-web.de:6867 TEST1/aeL1aN9j W (21816078) net: DNS lookup on ovms.dexters-web.de failed err=202 E (21816078) ovms-server-v2: Status: Error: Cannot establish tcp/ip connection to server I (21826078) ovms-server-v2: Connection is ovms.dexters-web.de:6867 TEST1/aeL1aN9j W (21839118) net: DNS lookup on ovms.dexters-web.de failed err=202 E (21839118) ovms-server-v2: Status: Error: Cannot establish tcp/ip connection to server I (21840008) notify: Raise text data: RT-GPS-Log,293916,86400,51.30231476,7.39006567,326,197,0,1,119,-101,0,0,0,0,0,0,40,19000,-2000,1.000,1.000,0,0 I (21840008) events: Signal(notify.data) I (21849118) ovms-server-v2: Connection is ovms.dexters-web.de:6867 TEST1/aeL1aN9j W (21862138) net: DNS lookup on ovms.dexters-web.de failed err=202 E (21862138) ovms-server-v2: Status: Error: Cannot establish tcp/ip connection to server
… and so on until manually restarting the Wifi or modem link.
Regards, Michael
-- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
I think this is a different case, and somewhat nasty. Most likely the DNS server is being set by the ppp stack, then overwritten by the wifi stack, then when wifi goes away the wifi dns servers are no longer available.
Perhaps easiest to disable DNS for both wifi and ppp, and then set manually to 8.8.8.8, 8.8.4.4 after each stack comes up? Or, try to retrieve the DHCP/PPP dns servers for each, store them, and allow them to be controlled by network manager?
I think this is in the category for network manager to handle. I will have a look at it.
Regards, Mark.
On 4 Jan 2018, at 12:10 AM, Michael Balzer <dexter@expeedo.de> wrote:
Mark,
Am 03.01.2018 um 13:35 schrieb Mark Webb-Johnson:
I left OVMS v3 running on my desk, connected via the cellular network here in Malaysia. It saw a bunch of connection drops, but overall managed to reconnect each time and be stable for 10 days. I think we’re close… Just need to deal with the edge case of modem rebooting and losing MUX connection.
Not sure if this is the edge case: if the connection is running over Wifi and the modem is idling, it will lose the ppp connection after some time. When it does, the v2 server will also disconnect, although it's still connected via Wifi. When the ppp link then gets back up, occasionally the server reconnect will fail continously with a DNS error:
… I (21780828) ovms-server-v2: Send MP-0 h394,0,RT-GPS-Log,293916,86400,51.30231476,7.39006519,326,197,0,1,119,-105,0,0,0,0,0,0,40,19000,-2000,1.000,1.000,0,0 I (21780868) ovms-server-v2: Incoming Msg: MP-0 h394 I (21780868) notify: Cleanup type data id 394 I (21782818) simcom: PPP Connection disconnected I (21782818) simcom: PPP Connection disconnected I (21783008) simcom: Lost network connection (+PPP disconnect in NetMode) I (21783008) simcom: State: Enter NetLoss state I (21783008) gsm-ppp: Shutting down (hard)... I (21783008) events: Signal(system.modem.down) I (21783008) events: Signal(network.modem.down) I (21783008) events: Signal(network.reconfigured) I (21783008) ovms-server-v2: Network is down, so disconnect network connection E (21783008) ovms-server-v2: Status: Error: Disconnected from OVMS Server V2 I (21788578) gsm-ppp: StatusCallBack: User Interrupt I (21788578) gsm-ppp: PPP connection has been closed I (21788578) events: Signal(system.modem.down) I (21792008) simcom: State timeout, transition to 5 I (21792008) simcom: State: Enter NetWait state I (21792008) gsm-nmea: Startup I (21793018) ovms-server-v2: Connection is ovms.dexters-web.de:6867 TEST1/aeL1aN9j W (21793018) net: DNS lookup on ovms.dexters-web.de failed err=202 E (21793028) ovms-server-v2: Status: Error: Cannot establish tcp/ip connection to server I (21796008) simcom: State: Enter NetStart state I (21797028) simcom: PPP Connection is ready to start I (21798008) simcom: State: Enter NetMode state I (21798008) gsm-ppp: Initialising... I (21800268) gsm-ppp: StatusCallBack: None I (21800268) gsm-ppp: status_cb: Connected I (21800268) gsm-ppp: our_ipaddr = 10.170.195.13 I (21800268) gsm-ppp: his_ipaddr = 10.64.64.64 I (21800268) gsm-ppp: netmask = 255.255.255.255 I (21800268) gsm-ppp: our6_ipaddr = :: I (21800268) events: Signal(system.modem.gotip) I (21800268) events: Signal(network.modem.up) I (21800268) events: Signal(network.up) I (21803028) ovms-server-v2: Connection is ovms.dexters-web.de:6867 TEST1/aeL1aN9j W (21816078) net: DNS lookup on ovms.dexters-web.de failed err=202 E (21816078) ovms-server-v2: Status: Error: Cannot establish tcp/ip connection to server I (21826078) ovms-server-v2: Connection is ovms.dexters-web.de:6867 TEST1/aeL1aN9j W (21839118) net: DNS lookup on ovms.dexters-web.de failed err=202 E (21839118) ovms-server-v2: Status: Error: Cannot establish tcp/ip connection to server I (21840008) notify: Raise text data: RT-GPS-Log,293916,86400,51.30231476,7.39006567,326,197,0,1,119,-101,0,0,0,0,0,0,40,19000,-2000,1.000,1.000,0,0 I (21840008) events: Signal(notify.data) I (21849118) ovms-server-v2: Connection is ovms.dexters-web.de:6867 TEST1/aeL1aN9j W (21862138) net: DNS lookup on ovms.dexters-web.de failed err=202 E (21862138) ovms-server-v2: Status: Error: Cannot establish tcp/ip connection to server
… and so on until manually restarting the Wifi or modem link.
Regards, Michael
-- 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
Am 30.12.2017 um 19:07 schrieb Greg D.:
The only issue we had was that if you try to transmit several frames back-to-back, the third and subsequent frame sent were all duplicates of the second frame. That was fixed by adding a delay in the code, hoping that it would be sufficient for the prior frame to actually get sent.
I've replaced that "nasty hack" by a TX buffer status check polling all three buffers, so TX speed on the MCP2515 buses is no longer limited to 100 frames per second.
Please test.
Regards, Michael
-- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
Greg,
thanks for testing.
Please check your "can can3 status" output and also check if "level verbose can" + "can can3 trace on" will show frames. Trace output is now done at the "verbose" level.
To go back in the commit history, use "git log" and "git checkout":
"git log" shows the latest commits. You can checkout any commit by referencing its hash value, i.e. "git checkout 1c833dbcbddd4efdbb7ed765cc3ed96be31c820f" will set your working tree back to the commit before I started working on the MCP2515 code.
Then you can advance commit by commit to see where the error was introduced.
If you've open changes conflicting with the checkout, git will detect that and tell you. You can then use "git stash" to put them aside, and later on "git stash pop" to get them back.
Regards, Michael
Am 31.12.2017 um 07:43 schrieb Greg D.:
Michael Balzer wrote:
Am 30.12.2017 um 19:07 schrieb Greg D.:
The only issue we had was that if you try to transmit several frames back-to-back, the third and subsequent frame sent were all duplicates of the second frame. That was fixed by adding a delay in the code, hoping that it would be sufficient for the prior frame to actually get sent. I've replaced that "nasty hack" by a TX buffer status check polling all three buffers, so TX speed on the MCP2515 buses is no longer limited to 100 frames per second.
Please test.
Regards, Michael I haven't used the ECU code in the last few merges (maybe a couple of weeks), as I've been playing with the modem, but I just merged and now I'm not seeing /any/ frames receive on CAN3. So, I can't tell exactly when, but it's broken now.
I forget... Is there a way to force boot the module from the other flash partition? I could try that to see if it was just the latest merge.
Greg
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
participants (4)
-
Geir Øyvind Vælidalo -
Greg D. -
Mark Webb-Johnson -
Michael Balzer