[Ovmsdev] ESP32CAN - CAN bus interferences

[Michael Balzer]

Christian,

can you please put this in context with the discussed & implemented 
transceiver shutdown suppression?

E.g. in thread: Firmware release 3.3.005 / CAN SAE timing

CAN controller listen mode will be of very limited use, as most vehicles 
need to be able to at least poll.

Do the GPIO transients actually make it to the bus?

Does disabling the transceiver shutdown help in your case?

Please also share your findings in the mentioned Github discussion 
(issue 980), that's the most complete thread on this issue currently, 
and possibly Richard can do some tests as well.

Changing the transceiver is something Mark needs to comment on.

Regards,
Michael


Am 13.06.25 um 14:39 schrieb Info via OvmsDev:
> Dear all,
> I recently experienced some interferences between my OVMS module 
> (Lilygo based) and the CAN bus of the car. The car was complaining 
> once in while about problems with certain components.
> I first thought it might be related to my hardware. Checking some 
> discussions, I realized, that, at least for the Smart EQ, this seems 
> to be a common problem, independent of the used hardware.
>
> I traced this down to a crashing firmware (edge version), which leads 
> to a disturbance of CAN1 (ESP32CAN).
> Actually I emulated a car (Smart EQ) with an Arduino and two CAN 
> interfaces and recorded the bus errors and transmission problems. For 
> this I crashed the firmware intentionally once a minute. The 
> efficiency of occurring errors is pretty high, but not each crash 
> leads to transmission problems.
> It actually does not help to disable the write access to the bus, 
> since this is only implemented in software. The hardware listen-only 
> mode of the CAN transceiver SN65HVD233 is not implemented yet (see 
> below).
>
> In conclusion, CAN1 is inherently sensitive to  to a crashing firmware 
> due to the undefined GPIO transients on the ESP32CAN TX pin.
> What helps, is to switch the transceiver into the listen-only mode (RS 
> pin high). In this case two pins have to conspire to achieve a 
> dominant state on the bus.
> The MCP2515 based bus is not effected by crashes.
>
> I propose to implement the hardware based listen-only mode in case, 
> that the write access is disabled anyway. I implemented this now for 
> the ESP32CAN as well as for the MCP2515 code.
> See 
> https://github.com/zbchristian/Open-Vehicle-Monitoring-System-3-Lilygo-Support/tree/add-canbus-hw-listenonly
> This branch includes only the changes wrt to the switching of the 
> listen-only mode. I will issue a corresponding pull request.
> In the code for the cars, the can bus mode has to be specified:
>
> if (write_is_enabled) RegisterCanBus(busno,CAN_MODE_ACTIVE, speed);
> else  RegisterCanBus(busno,CAN_MODE_LISTEN, speed);
>
> In case the config changes:
>
> if (write_is_enabled) SetCanbusMode(busno,CAN_MODE_ACTIVE);
> else  SetCanbusMode(busno,CAN_MODE_LISTEN);
>
> As an example, I implemented this for vehicle_smarteq in the above repo.
>
>
> Another measure of security would be to shift for newer hardware to a 
> different CAN transceiver chip. I use now the TI TCAN330, which is pin 
> and functionally compatible with the SN65HVD233, but has a feature 
> called DOT (Dominant Time Out), which will return the bus to a 
> recessive state after a few msecs, in case the dominant state is 
> applied for a too long time.
>
> Best regards
>   Christian
>
>
> _______________________________________________
> OvmsDev mailing list
> OvmsDev at lists.openvehicles.com
> http://lists.openvehicles.com/mailman/listinfo/ovmsdev

-- 
Michael Balzer * Am Rahmen 5 * D-58313 Herdecke
Fon 02330 9104094 * Handy 0176 20698926

-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature.asc
Type: application/pgp-signature
Size: 203 bytes
Desc: OpenPGP digital signature
URL: <http://lists.openvehicles.com/pipermail/ovmsdev/attachments/20250613/3aac8cab/attachment.sig>