ESP32-EVB different revisions; CAN problems?

[KeesZagers]

I developed a nice universal CAN product based on the ESP32-EVB. Everything works on my first module which was of revision D. Recently I bought a second module which is of revision K. The same program seemed to work without any problems. Only when I connected it to a real CANbus no communication is detected. Looking into the differences between the 2 revisions I saw a replacement of the CAN transceiver from MCP2551 into MCP2562 and later on a new replacement of the MCP2562 into SIT1042T/3. As far as I know these transceivers are powered by 3.3 Volts in stead of 5 Volts, which I don't like because the 2.5 Volt treshold which is common on traditional CANbusses cannot be achieved. So I like to know if these new designs are tested on a traditional CANbus anyway?

[LubOlimex]

No, it is the other way around - some of these transceivers can be powered and operate at 3.3V, while others are 5V only. And while some allow for 3.3V operation while others are 5V-only, all of the CAN transceivers that we used were routed for 5V operation by default. Even the 3.3V-capable chips that we used operated at 5V due to the default jumper setting of 5.0V/3.3V1 jumper (set to 5.0V position).

So the issue is probably something else. Did you close CAN_T1 jumper? By default the terminating resistor is disconnected and might affect CAN connection if only two devices are used (both need to have terminating resistor).

There are some differences between the two controllers - SIT1050T has resistor divider on the RX line (while MCP2560 had VREF and no need of resistors). This might affect the maximum speed. Also the timeout time is different - the 1050T is 450uS (called "Bus dominant time-out time") with MCP2562 being much bigger so the timings in your software might be incompatible with the new CAN chip. The datasheets used are these ones:

https://semic-boutique.com/wp-content/uploads/2016/05/SIT1050-V1.6_en.pdf

https://ww1.microchip.com/downloads/en/devicedoc/20005167c.pdf

Maybe also check our demo and notes about speed:

https://github.com/OLIMEX/ESP32-EVB/tree/master/SOFTWARE/Arduino%20IDE%20examples/CAN_library_and_examples

[KeesZagers]

Hi Lub,
Thank you for the quick answer. First of all I'm glad you powered the devices with 5 Volts.
I'm testing on an existing CANbus, with 2 termination resistors of 120 ohms on both sides, so no CAN-T1 resistor should be used.
If I read the revision notes correctly, the rev.-K is built with the SIT1050T. Unfortunately I cannot read any text on the chip itself, it is completely blank. Google helped me with finding the SIT1050T, a cheap Chinese alternative for the TJA1050 of NXP. I'm not very chauvinistic but I trust the Dutch (my native country) product more than the Chinese alternative.
I know there is one specification in the SJA1000 (the internally CAN controller in the ESP32) which is of influence of the connection between CAN controller and transceiver. I will check that, however this specification has nothing to do with timing, only with the way the inputs and outputs of the transceiver are specified.

[LubOlimex]

It is just matter of availability, we don't want to change original designs but we are sometimes forced to. In last few years it had been very hard to find components from original designs, hence why we have to purchase replacements and there are many CAN chips listed in the schematic ("Options: MCP2562-E/SN, MCP2551-I/SN, SIT1050T , SIT1042T/3, SIT1051T/3 or SN65HVD232D!").

This had been described in the README with the hardware changes:

https://github.com/OLIMEX/ESP32-EVB/blob/master/HARDWARE/README.md

[KeesZagers]

Checked SJA1000 software for the TJA1050; same as for the MCP2551. So no software problem.
SIT1050T is second source for NXP TJA1050T. At Mouser 58000 on stock of the TJA1050. SIT1050T unknown at Mouser.
I'm going to bypass the transceiver chip and see if I can communicate on the CANbus.
Anyway I suggest that Olimex does a real test of the CANbus connection with the new versions of the ESP32-EVB.

[LubOlimex]

What qualifies as a real CAN bus test?

During the production tests we usually connect two boards over CAN and check whether they communicate.

Also ESP32-EVB is one of our top sellers. Of course, I can't be sure how many of the customers use the CAN, but we haven't received many complaints. I'd expect more negative feedback if things with CAN were that bad.

Can you analyze a bit where the communication fails so we can compare?

[KeesZagers]

Hi Lub,
A CANbus system should work with all kind of CAN modules with all kind of transceivers. If you let 2 Bulgarian people talk with each other they will communicate quite well I suppose. If you put them in a group with people of the rest of the EU, I'm quite sure the communication will not succeed if they still speak Bulgarian in stead of English 

I don't believe many of the ESP32-EVB users are using CAN. I like to hear them on this platform and ofcourse specially those ones that are working with recent modules and not the old ones with the MCP2551, because I did not have any problems with the old one.

I have not got the time to install the test equipment to see where it goes wrong. As the CAN-controller is built within the ESP32 and is linked to GPIO5 and GPIO35 I don't suspect problems on CAN-Tx or CAN-Rx. The CAN transceiver should shift the levels to CAN-Hi and CAN-Lo (both 2.5 Volt in recessive situation; 3.5 resp. 1.5 Volt in dominant situation). As far as I can see with just a multimeter the first situation (2.5 Volt both) is correct. I have not set up a test system with an oscilloscope to see what happens if the communication is running. I will try to do that today and will report later on.

[KeesZagers]

In Dutch we have a proverb which says: "Meten is weten". In English: "Measuring is knowing".

My conclusion: Never blame the Bulgarian people; blame the Chinese ones.

After measurement I saw communication on the CANbus, however not at the right speed. Based on the original software it had to be running on 125 kb/sec, however it was running on 62.5 kb/sec. The CAN software on which my application is based (Thomas Barth, barth-dev.de) used an ESP32 constant APB_CLK_FREQ (frequency used for the peripherals) of 80 MHz. However Espressif seems to have lowered this APB_CLK_FREQ to 40 MHz within the ESP-WROOM-32 module. Now all bitrates are half the original ones.

For the CANbus applications the 40 MHz frequency has a big advantage, because now it should be possible to communicate also on 10 and 20 kb/sec. With 80 MHz it was not possible to have a lower bitrate than 25 kb/sec.

So problem solved.

[LubOlimex]

Thanks for the update and glad issue was resolved. Interesting that it came down to differences in ESP32 versions, but there it is.

[KeesZagers]

Just for others, struggling with the same problem as I did:

https://www.espressif.com/sites/default/files/documentation/esp32_datasheet_en.pdf

page 38:

bit rates:
– from 25 Kbit/s to 1 Mbit/s in chip revision v0.0/v1.0/v1.1
– from 12.5 Kbit/s to 1 Mbit/s in chip revision v3.0/v3.1

This means older libraries for CAN use APB_CLK_FREQ (which is 80 MHz) as basic frequency for the CAN bitrate calculation. However for newer devices this constant should be replaced by a value of 40000 (40 MHz). Or what I did is storing a variable in EEPROM, which can be set to 1 or 2. ABP_CLK_FREQ is divided by this variable.