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-Suppo... 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@lists.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev
_______________________________________________ OvmsDev mailing list OvmsDev@lists.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev