Enter/exit CAN reset mode

[PeterR]

Hi,
I am trying to work around some CAN issues.
I have not been able to recover the CAN issue using

Code: Select all

can_initiate_recovery(void)

The device no longer provides valid frames.
Instead I am trying to disable the CAN device whilst the problem conditions occurs and then reenable. I hope that the CAN issue will then be avoided.
I could try

Code: Select all

can_driver_uninstall(void)

and reinstall hoping for a harder reset but that approach leaks into the application which is registered for events, waiting on receive() etc.

I have tried removing the device from the bus:

Code: Select all

int can_set_reset(int reset)
{
    if(reset)
        can_ll_enter_reset_mode(can_context.dev);
    else
        can_ll_exit_reset_mode(can_context.dev);
    
    return 0;
}

but once I call with values 1 then 0 then I no longer receive CAN frames.

Dumping registers before I reset/enable:

Code: Select all

I (31438) CAN: mode: 0x0008
I (31438) CAN: status: 0x001c, interrupt: 0x0000, error_capture: 0x0000

and after:

Code: Select all

I (122018) CAN: mode: 0x0008
I (122018) CAN: status: 0x001c, interrupt: 0x0000, error_capture: 0x007b

and then no more frames. can_initiate_recovery() will not recover (I know its not designed to recover from my hacks)
What am I doing wrong?
How may I perform a hard device reset without creating a new driver context?

[ESP_Dazz]

Hi,
I am trying to work around some CAN issues.
I have not been able to recover the CAN issue using

• can_initiate_recovery() is supposed to recover from Bus-Off, it won't help recover from corrupt frames

• Entering and Exiting reset mode doesn't really reset the peripheral. It's more of a start/stop bit. So any corrupt frames in the RX FIFO will stay there

.

• You can use periph_module_reset(PERIPH_CAN_MODULE) to do a hardware reset of the entire peripheral.

[PeterR]

Thanks.

Entering and Exiting reset mode doesn't really reset the peripheral. It's more of a start/stop bit. So any corrupt frames in the RX FIFO will stay there

Indeed. My thinking though was to prevent the error in the first place.

You can use periph_module_reset(PERIPH_CAN_MODULE) to do a hardware reset of the entire peripheral.

Will I need to re-initialise & re-program the device?
Guess I will find out soon.

Do you know when the IDF CAN driver will be updated to address the errata issues?
The device also produces corrupt frames following FLASH write but without bus errors. This fault mode locks where when bus error the corrupt frames disappear after a while.

[ESP_Dazz]

Will I need to re-initialise & re-program the device?

Yes. The registers will reset to their default power-on values.

Do you know when the IDF CAN driver will be updated to address the errata issues?

We are currently reviewing the bugfix and will be merged into master shortly, after which we will backported to v4.1. Like I've mentioned in our private correspondence, if you cannot afford to wait for the backport, I can send you the bug fix immediately as a git patch.

[ESP_Dazz]

@PeterR
I've attached the patch. Please run git apply fifo_overrun.patch on a branch based off release/v4.1. Note that because these changes are still under review, the final changes on master branch may be different.

[PeterR]

Great, will test, EAOE understood, guess it will be worth more than I paid for

[PeterR]

@ESP_Dazz
Thanks. The patch seems to resolve the locked into corrupt mode following FLASH write issue. Seems logical given that FLASH write would cause overruns.
The patch does not seem to fix termination resitor issues. I think termination resistor issues are more likely to cause the error discussed in 3.13.5 errata.

I am aware that early CAN issues were reported as overrun faults & that overrun was not processed in the IDF. The errata talks about bit errors however. Did you attempt both solutions?

Feel free to send me update patches for test.
The failing test condition is to place the termination resistor in circuit with a switch. I run at 1600 fps @250Kbps. Toggle the switch like your playing 'track & field'. Corrupt frames will get through very quickly. The frame ID seems good but the contents contain trash. The condition resolves once termination is restored.

[ESP_Dazz]

@Peter R,
I suspect it could due to 3.13.5 as well. I'll send you another patch with the 3.13.5 workaround shortly.

[PeterR]

Cool, happy to test.

[ESP_Dazz]

@PeterR
Here is the patch that includes a fix for errata 3.13.5.