Hi Chris

Here are the required changes, as I understand them, to be compiled into a new firmware from this thread: https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/pull/1102/files

Cheers

Derek

On Tue, 21 Jan 2025 at 10:48, Michael Balzer via OvmsDev <ovmsdev@lists.openvehicles.com> wrote:

Chris,

there is no prepared branch for these changes, as we still try to determine the best (most compatible) configuration.

You need to apply the suggested changes manually to the current master.

Regards,
Michael

Am 20.01.25 um 19:56 schrieb Chris Box via OvmsDev:
I'm happy to try some new code on my Leaf. Which code should I use? The current master, or a different branch? It wasn't clear to me from the thread below.

Chris

On 2025-01-19 19:47, Derek Caudwell via OvmsDev wrote:

I can't recall testing a later version but I think Chris can confirm he was on a later version when his Leaf had a similar problem.

The Leaf is now my wife's daily drive so I won't be able to take a look at making the suggested changes for a couple of weeks at least.

On Mon, 20 Jan 2025, 8:31 am Michael Balzer via OvmsDev, <ovmsdev@lists.openvehicles.com> wrote:

Derek,

Am 03.05.24 um 12:53 schrieb Derek Caudwell via OvmsDev:

When running firmware 3.3.004-74-gbd4e7196 on my Nissan Leaf I suspect (but can't be 100% sure as it's only been 24h without fault) the new poller caused the car to throw the attached faults from overloading the can bus whilst driving. The fault was sufficient to send the car into limp mode and could not be driven until cleared with LeafSpy.

Build 3.3.004-74 (released 2024-04-30) did not yet include the poller tracing control, i.e. it did lots of logging for frames, significantly affecting overall performance.

Poller tracing control was introduced in https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/commit/7e4046042a99339d0212aac8f874cc8f780e634e on May 12.

That commit was first included in build 3.3.004-103-g11fddbf6 released 2024-05-25. Do you remember testing that build or a later one?

But as I still don't understand how a software queue overflow could cause a bus crash, I've also checked the 500 kbit timing for the MCP2515 and found that may have the same issue as the 125 kbit timing:

Our timing is:
case CAN_SPEED_500KBPS:
    cnf1=0x00; cnf2=0xf0; cnf3=0x86;
= PROP=1, PS1=7, PS2=7, SJW=1, Sample 3x @56.3%

Remember, the SAE/CiA recommendation is SJW=2, Sample 1x @87.5%. That would translate to:
PROP=5, PS1=8, PS2=2, SJW=2, Sample 1x @87.5% =
    cnf1=0x40; cnf2=0xbc; cnf3=0x81;

I also checked the Arduino MCP_CAN lib, and that uses:
    cnf1=0x40; cnf2=0xe5; cnf3=0x83;
= PROP=6, PS1=5, PS2=4, SJW=2, Sample 3x @75%

So our timing for 500 kbit/s on the MCP buses also isn't as recommended.

Derek, could you test the SAE/CiA recommendation and the MCP_CAN config as shown? Or anyone else with a live can2/can3 bus at 500 kbit?

If these work, the question is which is the more general setup we should adopt. Apparently the MCP_CAN lib also does not follow the CiA recommendation, I wonder if the MCP_CAN config is a compromise for compatibility.

Regards,
Michael
_______________________________________________
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