[Ovmsdev] ESP32CAN - CAN bus interferences

[Info]

Hi Michael,
answers below:

Am 13.06.2025 um 15:18 schrieb Michael Balzer via OvmsDev:
> Christian,
>
> can you please put this in context with the discussed & implemented 
> transceiver shutdown suppression?
>
The SN65HVD233 has, according to the manual, no shutdown mode.
The so-called low-power mode is described as: a low-current, listen only 
standby mode.
So, only the write amplifier is disabled, which requires most of the power.
The mentioned TCAN330 actually has a shutdown pin, put that is separate 
from the listen only mode.
Will have a look at the discussion and comment.

> 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?
>
Yes, in case of the ESP32CAN TX pin, a transient is going straight to 
the bus and effects the CANL and CANH level. There is nothing preventing 
this except for the listen-only mode (RS pin set to high).

> Does disabling the transceiver shutdown help in your case?
>
Not sure, what you mean by this. As said above the SN65HVD233 has no 
shutdown mode.

> 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.
>
Ok, will do.
> 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
>
>
> _______________________________________________
> OvmsDev mailing list
> OvmsDev at lists.openvehicles.com
> http://lists.openvehicles.com/mailman/listinfo/ovmsdev