Leaf AZE1 Can1 stuck after poll 7BB group 61
Using Leafspy I can see that it's using the following poll and response to get the SOH of the batteries 1742706668.884315 1R11 79B 02 21 61 00 00 00 00 00 1742706668.892602 1R11 7BB 11 4b 61 61 1a cc 23 70 However, when try to do the same poll with OVMS using the following code... static const OvmsPoller::poll_pid_t obdii_polls[] = { // BUS 2 { CHARGER_TXID, CHARGER_RXID, VEHICLE_POLL_TYPE_OBDIIGROUP, VIN_PID, { 0, 900, 0, 0 }, 2, ISOTP_STD }, // VIN [19] { CHARGER_TXID, CHARGER_RXID, VEHICLE_POLL_TYPE_OBDIIEXTENDED, QC_COUNT_PID, { 0, 900, 0, 0 }, 2, ISOTP_STD }, // QC [2] { CHARGER_TXID, CHARGER_RXID, VEHICLE_POLL_TYPE_OBDIIEXTENDED, L1L2_COUNT_PID, { 0, 900, 0, 0 }, 2, ISOTP_STD }, // L0/L1/L2 [2] // BUS 1 { BMS_TXID, BMS_RXID, VEHICLE_POLL_TYPE_OBDIIGROUP, 0x01, { 0, 60, 0, 60 }, 1, ISOTP_STD }, // bat [39/41] { BMS_TXID, BMS_RXID, VEHICLE_POLL_TYPE_OBDIIGROUP, 0x02, { 0, 60, 0, 60 }, 1, ISOTP_STD }, // battery voltages [196] { BMS_TXID, BMS_RXID, VEHICLE_POLL_TYPE_OBDIIGROUP, 0x06, { 0, 60, 0, 60 }, 1, ISOTP_STD }, // battery shunts [96] { BMS_TXID, BMS_RXID, VEHICLE_POLL_TYPE_OBDIIGROUP, 0x04, { 0, 300, 0, 300 }, 1, ISOTP_STD }, // battery temperatures [14] { BMS_TXID, BMS_RXID, VEHICLE_POLL_TYPE_OBDIIGROUP, 0x61, { 0, 300, 0, 300 }, 1, ISOTP_STD }, // SOH for AZE1 POLL_LIST_END }; It results a CAN bus error 2025-03-23 13:48:10.648 AEDT E (11528) esp32can: can1 stuck bus-off error state (errflags=0x00040cab) detected - resetting bus I'm new to this but from what I can work out what I am doing should work. Any suggestions? Thanks Wayne
Wayne,
do you currently apply my CAN timing patch? If not, please try that first.
Also, a general question to all Leaf developers: did anyone yet test
fixing that random bytes write in OvmsVehicleNissanLeaf::CommandWakeup()?
Regards, Michael
Am 23.03.25 um 06:59 schrieb Wayne Love via OvmsDev:
Using Leafspy I can see that it's using the following poll and response to get the SOH of the batteries
1742706668.884315 1R11 79B 02 21 61 00 00 00 00 00 1742706668.892602 1R11 7BB 11 4b 61 61 1a cc 23 70 However, when try to do the same poll with OVMS using the following code...
static const OvmsPoller::poll_pid_t obdii_polls[] = { // BUS 2 { CHARGER_TXID, CHARGER_RXID, VEHICLE_POLL_TYPE_OBDIIGROUP, VIN_PID, { 0, 900, 0, 0 }, 2, ISOTP_STD }, // VIN [19] { CHARGER_TXID, CHARGER_RXID, VEHICLE_POLL_TYPE_OBDIIEXTENDED, QC_COUNT_PID, { 0, 900, 0, 0 }, 2, ISOTP_STD }, // QC [2] { CHARGER_TXID, CHARGER_RXID, VEHICLE_POLL_TYPE_OBDIIEXTENDED, L1L2_COUNT_PID, { 0, 900, 0, 0 }, 2, ISOTP_STD }, // L0/L1/L2 [2] // BUS 1 { BMS_TXID, BMS_RXID, VEHICLE_POLL_TYPE_OBDIIGROUP, 0x01, { 0, 60, 0, 60 }, 1, ISOTP_STD }, // bat [39/41] { BMS_TXID, BMS_RXID, VEHICLE_POLL_TYPE_OBDIIGROUP, 0x02, { 0, 60, 0, 60 }, 1, ISOTP_STD }, // battery voltages [196] { BMS_TXID, BMS_RXID, VEHICLE_POLL_TYPE_OBDIIGROUP, 0x06, { 0, 60, 0, 60 }, 1, ISOTP_STD }, // battery shunts [96] { BMS_TXID, BMS_RXID, VEHICLE_POLL_TYPE_OBDIIGROUP, 0x04, { 0, 300, 0, 300 }, 1, ISOTP_STD }, // battery temperatures [14] { BMS_TXID, BMS_RXID, VEHICLE_POLL_TYPE_OBDIIGROUP, 0x61, { 0, 300, 0, 300 }, 1, ISOTP_STD }, // SOH for AZE1 POLL_LIST_END };
It results a CAN bus error 2025-03-23 13:48:10.648 AEDT E (11528) esp32can: can1 stuck bus-off error state (errflags=0x00040cab) detected - resetting bus I'm new to this but from what I can work out what I am doing should work. Any suggestions?
Thanks Wayne
OvmsDev mailing list OvmsDev@lists.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev
-- Michael Balzer * Am Rahmen 5 * D-58313 Herdecke Fon 02330 9104094 * Handy 0176 20698926
Hi Michael, Adding your patch did not make noticeable difference. I noted that Leafspy pads the poll request with 0x00, whereas ovms pads with 0x55. I've also modified vehicle_poller_isotp.cpp to pad with 0x00 but again this made no difference. Thanks Wayne On Mar 23, 2025, at 9:23 PM, Michael Balzer via OvmsDev <ovmsdev@lists.openvehicles.com> wrote: Wayne, do you currently apply my CAN timing patch? If not, please try that first. Also, a general question to all Leaf developers: did anyone yet test fixing that random bytes write in OvmsVehicleNissanLeaf::CommandWakeup()? Regards, Michael
Wayne,
payload cannot cause bus errors.
2025-03-23 13:48:10.648 AEDT E (11528) esp32can: can1 stuck bus-off error state (errflags=0x00040cab) detected - resetting bus
OVMS# can can1 explain 0x00040cab Bus error flags 0x00040cab: | IR.2 Error-warning state | SR.3 TX done | SR.2 TX buffer free | ECC Stuff error in RX, segment data length code
If not by false timing, stuff errors can be caused by noise on the bus, some component flooding the bus with transmissions, or by hardware issues with the cabling.
Regarding Leaf CAN problems there ist a running investigation here: https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/issues/980
Adding the termination resistor would have been my next guess, but Richard already tried that, didn't help.
Are you absolutely sure the issue only (!) and reproducably (!) exists with that additional SOH poll entry?
Assuming that's the case: could it be this is a bus overload caused by the Leaf module itself when requesting all response frames without delay?
OvmsVehicleNissanLeaf::OvmsVehicleNissanLeaf() … *PollSetResponseSeparationTime(0);*
The framework default is 25 ms, so you could try commenting out that call.
Regards, Michael
Am 24.03.25 um 07:48 schrieb Wayne Love:
Hi Michael,
Adding your patch did not make noticeable difference.
I noted that Leafspy pads the poll request with 0x00, whereas ovms pads with 0x55. I've also modified vehicle_poller_isotp.cpp to pad with 0x00 but again this made no difference.
Thanks Wayne
On Mar 23, 2025, at 9:23 PM, Michael Balzer via OvmsDev <ovmsdev@lists.openvehicles.com> wrote:
Wayne,
do you currently apply my CAN timing patch? If not, please try that first.
Also, a general question to all Leaf developers: did anyone yet test fixing that random bytes write in
OvmsVehicleNissanLeaf::CommandWakeup()?Regards, Michael
-- Michael Balzer * Am Rahmen 5 * D-58313 Herdecke Fon 02330 9104094 * Handy 0176 20698926
Hi Micheal, Your comment... Regarding Leaf CAN problems there ist a running investigation here: https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/issues/980 Is dead on the money. Polling group 61 returns an abnormally large response, 329 bytes. This causes a buffer overrun in OvmsVehicleNissanLeaf::IncomingPollReply with an unguarded memcpy that causes the module to crash. Once the module crashes, I get the exact symptoms in issue 980. Appreciate your help with this. Thanks Wayne
Wayne,
uh, yes, that's a typical buffer overflow pattern there, unguarded copying of a string contents to a fixed size buffer:
static uint8_t buf[MAX_POLL_DATA_LEN]; memcpy(buf, rxbuf.c_str(), rxbuf.size());
Not sure why/if the handlers need an uint8_t array in the first place, but a quick first fix should be to adjust MAX_POLL_DATA_LEN:
#define MAX_POLL_DATA_LEN 196
Add some spare room to the 329 bytes needed, just in case.
Regards, Michael
Am 25.03.25 um 09:31 schrieb Wayne Love:
Hi Micheal,
Your comment...
Regarding Leaf CAN problems there ist a running investigation here: https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/issues/980
Is dead on the money.
Polling group 61 returns an abnormally large response, 329 bytes. This causes a buffer overrun in OvmsVehicleNissanLeaf::IncomingPollReply with an unguarded memcpy that causes the module to crash. Once the module crashes, I get the exact symptoms in issue 980.
Appreciate your help with this.
Thanks Wayne
-- Michael Balzer * Am Rahmen 5 * D-58313 Herdecke Fon 02330 9104094 * Handy 0176 20698926
Why don't we just std:max() the reserve() on the string and cast c_str() to uint8_t * !? That way we know the array access in the code won't fumble into uncharted space and we get rid of the unchecked copy into the static memory space?
//.ichael
On Tue, 25 Mar 2025 at 16:38, Michael Balzer via OvmsDev < ovmsdev@lists.openvehicles.com> wrote:
Wayne,
uh, yes, that's a typical buffer overflow pattern there, unguarded copying of a string contents to a fixed size buffer:
static uint8_t buf[MAX_POLL_DATA_LEN]; memcpy(buf, rxbuf.c_str(), rxbuf.size());
Not sure why/if the handlers need an uint8_t array in the first place, but a quick first fix should be to adjust MAX_POLL_DATA_LEN:
#define MAX_POLL_DATA_LEN 196
Add some spare room to the 329 bytes needed, just in case.
Regards, Michael
Am 25.03.25 um 09:31 schrieb Wayne Love:
Hi Micheal,
Your comment...
Regarding Leaf CAN problems there ist a running investigation here:
https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/issues/980
Is dead on the money.
Polling group 61 returns an abnormally large response, 329 bytes. This causes a buffer overrun in OvmsVehicleNissanLeaf::IncomingPollReply with an unguarded memcpy that causes the module to crash. Once the module crashes, I get the exact symptoms in issue 980.
Appreciate your help with this.
Thanks Wayne
-- Michael Balzer * Am Rahmen 5 * D-58313 Herdecke Fon 02330 9104094 * Handy 0176 20698926
OvmsDev mailing list OvmsDev@lists.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev
I see you already checked the poll handlers don't write to the buffer, so that's a possible & better option.
But why do you limit the reserve() call? Clearly, the MAX_POLL_DATA_LEN isn't sufficient for the new poll, Wayne wants to add. Doing rxbuf.reserve(length + job.mlremain) should be perfectly OK, as it adapts to any reply size? After all, it's just a reservation, append will need to reallocate if it's too small. I think the module can get rid off MAX_POLL_DATA_LEN altogether when using the string memory directly.
Regards, Michael
Am 25.03.25 um 09:54 schrieb Michael Geddes via OvmsDev:
Why don't we just std:max() the reserve() on the string and cast c_str() to uint8_t * !? That way we know the array access in the code won't fumble into uncharted space and we get rid of the unchecked copy into the static memory space?
//.ichael
On Tue, 25 Mar 2025 at 16:38, Michael Balzer via OvmsDev <ovmsdev@lists.openvehicles.com> wrote:
Wayne, uh, yes, that's a typical buffer overflow pattern there, unguarded copying of a string contents to a fixed size buffer: > static uint8_t buf[MAX_POLL_DATA_LEN]; > memcpy(buf, rxbuf.c_str(), rxbuf.size()); Not sure why/if the handlers need an uint8_t array in the first place, but a quick first fix should be to adjust MAX_POLL_DATA_LEN: > #define MAX_POLL_DATA_LEN 196 Add some spare room to the 329 bytes needed, just in case. Regards, Michael Am 25.03.25 um 09:31 schrieb Wayne Love: > Hi Micheal, > > Your comment... > >> Regarding Leaf CAN problems there ist a running investigation here: >> https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/issues/980 > > Is dead on the money. > > Polling group 61 returns an abnormally large response, 329 bytes. > This causes a buffer overrun in > OvmsVehicleNissanLeaf::IncomingPollReply with an unguarded memcpy that > causes the module to crash. Once the module crashes, I get the exact > symptoms in issue 980. > > Appreciate your help with this. > > Thanks > Wayne > > > -- Michael Balzer * Am Rahmen 5 * D-58313 Herdecke Fon 02330 9104094 * Handy 0176 20698926 _______________________________________________ OvmsDev mailing list OvmsDev@lists.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev
OvmsDev mailing list OvmsDev@lists.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev
-- Michael Balzer * Am Rahmen 5 * D-58313 Herdecke Fon 02330 9104094 * Handy 0176 20698926
I think to prevent the buffer being too small, this should rather be std::min()?
Am 25.03.25 um 10:49 schrieb Michael Balzer via OvmsDev:
I see you already checked the poll handlers don't write to the buffer, so that's a possible & better option.
But why do you limit the reserve() call? Clearly, the MAX_POLL_DATA_LEN isn't sufficient for the new poll, Wayne wants to add. Doing rxbuf.reserve(length + job.mlremain) should be perfectly OK, as it adapts to any reply size? After all, it's just a reservation, append will need to reallocate if it's too small. I think the module can get rid off MAX_POLL_DATA_LEN altogether when using the string memory directly.
Regards, Michael
Am 25.03.25 um 09:54 schrieb Michael Geddes via OvmsDev:
Why don't we just std:max() the reserve() on the string and cast c_str() to uint8_t * !? That way we know the array access in the code won't fumble into uncharted space and we get rid of the unchecked copy into the static memory space?
//.ichael
On Tue, 25 Mar 2025 at 16:38, Michael Balzer via OvmsDev <ovmsdev@lists.openvehicles.com> wrote:
Wayne, uh, yes, that's a typical buffer overflow pattern there, unguarded copying of a string contents to a fixed size buffer: > static uint8_t buf[MAX_POLL_DATA_LEN]; > memcpy(buf, rxbuf.c_str(), rxbuf.size()); Not sure why/if the handlers need an uint8_t array in the first place, but a quick first fix should be to adjust MAX_POLL_DATA_LEN: > #define MAX_POLL_DATA_LEN 196 Add some spare room to the 329 bytes needed, just in case. Regards, Michael Am 25.03.25 um 09:31 schrieb Wayne Love: > Hi Micheal, > > Your comment... > >> Regarding Leaf CAN problems there ist a running investigation here: >> https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/issues/980 > > Is dead on the money. > > Polling group 61 returns an abnormally large response, 329 bytes. > This causes a buffer overrun in > OvmsVehicleNissanLeaf::IncomingPollReply with an unguarded memcpy that > causes the module to crash. Once the module crashes, I get the exact > symptoms in issue 980. > > Appreciate your help with this. > > Thanks > Wayne > > > -- Michael Balzer * Am Rahmen 5 * D-58313 Herdecke Fon 02330 9104094 * Handy 0176 20698926 _______________________________________________ OvmsDev mailing list OvmsDev@lists.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev
OvmsDev mailing list OvmsDev@lists.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev
-- Michael Balzer * Am Rahmen 5 * D-58313 Herdecke Fon 02330 9104094 * Handy 0176 20698926
OvmsDev mailing list OvmsDev@lists.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev
-- Michael Balzer * Am Rahmen 5 * D-58313 Herdecke Fon 02330 9104094 * Handy 0176 20698926
That's to make sure a minimum width so that packages shorter than expected dont have issues with the functions accessing it beyond the buffer.
Oversize will just adapt anyway.
On Tue, 25 Mar 2025, 17:49 Michael Balzer via OvmsDev, < ovmsdev@lists.openvehicles.com> wrote:
I see you already checked the poll handlers don't write to the buffer, so that's a possible & better option.
But why do you limit the reserve() call? Clearly, the MAX_POLL_DATA_LEN isn't sufficient for the new poll, Wayne wants to add. Doing rxbuf.reserve(length + job.mlremain) should be perfectly OK, as it adapts to any reply size? After all, it's just a reservation, append will need to reallocate if it's too small. I think the module can get rid off MAX_POLL_DATA_LEN altogether when using the string memory directly.
Regards, Michael
Am 25.03.25 um 09:54 schrieb Michael Geddes via OvmsDev:
Why don't we just std:max() the reserve() on the string and cast c_str() to uint8_t * !? That way we know the array access in the code won't fumble into uncharted space and we get rid of the unchecked copy into the static memory space?
//.ichael
On Tue, 25 Mar 2025 at 16:38, Michael Balzer via OvmsDev < ovmsdev@lists.openvehicles.com> wrote:
Wayne,
uh, yes, that's a typical buffer overflow pattern there, unguarded copying of a string contents to a fixed size buffer:
static uint8_t buf[MAX_POLL_DATA_LEN]; memcpy(buf, rxbuf.c_str(), rxbuf.size());
Not sure why/if the handlers need an uint8_t array in the first place, but a quick first fix should be to adjust MAX_POLL_DATA_LEN:
#define MAX_POLL_DATA_LEN 196
Add some spare room to the 329 bytes needed, just in case.
Regards, Michael
Am 25.03.25 um 09:31 schrieb Wayne Love:
Hi Micheal,
Your comment...
Regarding Leaf CAN problems there ist a running investigation here:
https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/issues/980
Is dead on the money.
Polling group 61 returns an abnormally large response, 329 bytes. This causes a buffer overrun in OvmsVehicleNissanLeaf::IncomingPollReply with an unguarded memcpy that causes the module to crash. Once the module crashes, I get the exact symptoms in issue 980.
Appreciate your help with this.
Thanks Wayne
-- Michael Balzer * Am Rahmen 5 * D-58313 Herdecke <https://www.google.com/maps/search/Am+Rahmen+5+*+D-58313+Herdecke?entry=gmail&source=g> Fon 02330 9104094 * Handy 0176 20698926
OvmsDev mailing list OvmsDev@lists.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev
OvmsDev mailing listOvmsDev@lists.openvehicles.comhttp://lists.openvehicles.com/mailman/listinfo/ovmsdev
-- Michael Balzer * Am Rahmen 5 * D-58313 Herdecke <https://www.google.com/maps/search/Am+Rahmen+5+*+D-58313+Herdecke?entry=gmail&source=g> Fon 02330 9104094 * Handy 0176 20698926
OvmsDev mailing list OvmsDev@lists.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev
Sorry, you're of course right, guess I didn't get enough sleep last night… 9_9
Am 25.03.25 um 13:09 schrieb Michael Geddes:
That's to make sure a minimum width so that packages shorter than expected dont have issues with the functions accessing it beyond the buffer.
Oversize will just adapt anyway.
On Tue, 25 Mar 2025, 17:49 Michael Balzer via OvmsDev, <ovmsdev@lists.openvehicles.com> wrote:
I see you already checked the poll handlers don't write to the buffer, so that's a possible & better option. But why do you limit the reserve() call? Clearly, the MAX_POLL_DATA_LEN isn't sufficient for the new poll, Wayne wants to add. Doing rxbuf.reserve(length + job.mlremain) should be perfectly OK, as it adapts to any reply size? After all, it's just a reservation, append will need to reallocate if it's too small. I think the module can get rid off MAX_POLL_DATA_LEN altogether when using the string memory directly. Regards, Michael Am 25.03.25 um 09:54 schrieb Michael Geddes via OvmsDev:Why don't we just std:max() the reserve() on the string and cast c_str() to uint8_t * !? That way we know the array access in the code won't fumble into uncharted space and we get rid of the unchecked copy into the static memory space? //.ichael On Tue, 25 Mar 2025 at 16:38, Michael Balzer via OvmsDev <ovmsdev@lists.openvehicles.com> wrote: Wayne, uh, yes, that's a typical buffer overflow pattern there, unguarded copying of a string contents to a fixed size buffer: > static uint8_t buf[MAX_POLL_DATA_LEN]; > memcpy(buf, rxbuf.c_str(), rxbuf.size()); Not sure why/if the handlers need an uint8_t array in the first place, but a quick first fix should be to adjust MAX_POLL_DATA_LEN: > #define MAX_POLL_DATA_LEN 196 Add some spare room to the 329 bytes needed, just in case. Regards, Michael Am 25.03.25 um 09:31 schrieb Wayne Love: > Hi Micheal, > > Your comment... > >> Regarding Leaf CAN problems there ist a running investigation here: >> https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/issues/980 > > Is dead on the money. > > Polling group 61 returns an abnormally large response, 329 bytes. > This causes a buffer overrun in > OvmsVehicleNissanLeaf::IncomingPollReply with an unguarded memcpy that > causes the module to crash. Once the module crashes, I get the exact > symptoms in issue 980. > > Appreciate your help with this. > > Thanks > Wayne > > > -- Michael Balzer * Am Rahmen 5 * D-58313 Herdecke <https://www.google.com/maps/search/Am+Rahmen+5+*+D-58313+Herdecke?entry=gmail&source=g> Fon 02330 9104094 * Handy 0176 20698926 _______________________________________________ OvmsDev mailing list OvmsDev@lists.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev _______________________________________________ OvmsDev mailing list OvmsDev@lists.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev-- Michael Balzer *Am Rahmen 5 * D-58313 Herdecke <https://www.google.com/maps/search/Am+Rahmen+5+*+D-58313+Herdecke?entry=gmail&source=g> Fon 02330 9104094 * Handy 0176 20698926 _______________________________________________ OvmsDev mailing list OvmsDev@lists.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev
-- Michael Balzer * Am Rahmen 5 * D-58313 Herdecke Fon 02330 9104094 * Handy 0176 20698926
participants (3)
-
Michael Balzer -
Michael Geddes -
Wayne Love