About the CAN controller.
Re: About the CAN controller.
Mine was a faulty transceiver, but you've tried another one.
Your other CAN bus participants should ACK the CAN transmit you are doing.
I have one problem recently with dropped CAN frames when the ESP32 was busy with lots of other tasks. That turned out to be inadequate ESP32 power supply from a laptop USB even though the laptop was plugged in.
Also, if you are not, just try transmitting one CAN frame not too many at once, because otherwise you can get bus errors unless you add checks to see that the buffer is free.
Your other CAN bus participants should ACK the CAN transmit you are doing.
I have one problem recently with dropped CAN frames when the ESP32 was busy with lots of other tasks. That turned out to be inadequate ESP32 power supply from a laptop USB even though the laptop was plugged in.
Also, if you are not, just try transmitting one CAN frame not too many at once, because otherwise you can get bus errors unless you add checks to see that the buffer is free.
Re: About the CAN controller.
Entering the error passive state without having entered the bus off state is indicative of messages not being acknowledged.Gnatz_ wrote: HI there!
I am trying my luck on having a CAN connection (obviously posting here) on an ESP32 WROOM, external SN65HVD230. THis is my first ESP CAN. I do very much have the issue @jcsbanks described before. I tried 2 ESP modules and 2 transceivers...
I can only _receive_ on my test setup on a 500kB CAN (like from Thomas B. example). I have a stable CAN with 2 other participants (arduino) and want to add my ESP32 to this CAN. When I try to send, I get following error interrupts
0x80 __CAN_IRQ_BUS_ERR
0x4 __CAN_IRQ_ERR
0x20 __CAN_IRQ_ERR_PASSIVE
0x4 __CAN_IRQ_ERR .
Did anyone experience this? What could I have messed up here?
Best Regards
Bernd
To check if the connection between the ESP32 an the external transceiver is functioning correctly, try running the self test example.
If you have two ESP32s, you can try running the can network example.
Re: About the CAN controller.
Thanks a lot ESP_Dazz and jcsbanks,
your replies arrived timely and gave me the opportunity to think about the next steps. my regards~ Surely I will keep you informed~
However - so far - I did not find much time to dig into all these side branches. In addition to your mentioned root causes I thought about try the transceivers on a DUE as well (verification purpose).
Kind Regards~ and get back to you soon hopefully
your replies arrived timely and gave me the opportunity to think about the next steps. my regards~ Surely I will keep you informed~
However - so far - I did not find much time to dig into all these side branches. In addition to your mentioned root causes I thought about try the transceivers on a DUE as well (verification purpose).
Kind Regards~ and get back to you soon hopefully
Re: About the CAN controller.
Here is my update on utizlizing SN65HVD230 (or more correct a CJMCU-230 one-chip board):
After consulting a friend with an oscilloscope we found some not well formed signals (as also stated on other web-posts).
On the oscillospe the output on the CAN side was only seeing roughly 1.5V but most probematic probably was that a few high transmit (Tx) signals were not successfully mirrored back to the Rx Pin. What we tried: use a pull-up for the Rx signal. For my Esp32duino a 2.5kOhm did the job (3.3V <->2.5k<->Rx Pin). On a lolin Wroom Board it even needed have of that resistance (2 in parallel), 5kOhm were already not sufficent. The signals then had problems with some spikes but at least my test setup was starting to take off (sending and receiving CAN msgs). How stable is this pull-up approach? I would rate it a 98% for my desk setup. However will be worse with longer CAN lines and if your termination on CAN side drops below 60Ohm (accumulated). Measuring the voltage drop on the 2.5k gave me some 0.2V ...but with my cheap voltmeter it also wracked the Rx line reception again then.
Another workaround could have been to boost the SN65HVD230 to 5V (max rating 6V) and add voltage deviders / level shifter. But that was the second approach due to more efforts (I didn't yet try it).
Maybe I will retry with a SN65HVD232 chip .
After consulting a friend with an oscilloscope we found some not well formed signals (as also stated on other web-posts).
On the oscillospe the output on the CAN side was only seeing roughly 1.5V but most probematic probably was that a few high transmit (Tx) signals were not successfully mirrored back to the Rx Pin. What we tried: use a pull-up for the Rx signal. For my Esp32duino a 2.5kOhm did the job (3.3V <->2.5k<->Rx Pin). On a lolin Wroom Board it even needed have of that resistance (2 in parallel), 5kOhm were already not sufficent. The signals then had problems with some spikes but at least my test setup was starting to take off (sending and receiving CAN msgs). How stable is this pull-up approach? I would rate it a 98% for my desk setup. However will be worse with longer CAN lines and if your termination on CAN side drops below 60Ohm (accumulated). Measuring the voltage drop on the 2.5k gave me some 0.2V ...but with my cheap voltmeter it also wracked the Rx line reception again then.
Another workaround could have been to boost the SN65HVD230 to 5V (max rating 6V) and add voltage deviders / level shifter. But that was the second approach due to more efforts (I didn't yet try it).
Maybe I will retry with a SN65HVD232 chip .
Re: About the CAN controller.
I use the same board without problems as long as I do not use my Dell XPS18 USB port as power supply.
Re: About the CAN controller.
Thanks to mention it. I cross-checked on that one with a 3.1A mains adapter (rather than USB3 desktop-pc socket).
The result was a little less reliable with the mains adapter (lolin Wroom, 2.6pullup, no transmit at all (mains) vs a fail after some 25 transmits on the desktop socket supply). I also connected GND on the CAN board to rule out some influence from that side (on the elsewise differencial CAN signals). So for me no (easy) escape route in direction of pow supply. However it shows differences (influence) from the supply. I fear I do not have the proper equipment at hand to tell the detailed difference on my supplies noise or levels...
Kind Regards
The result was a little less reliable with the mains adapter (lolin Wroom, 2.6pullup, no transmit at all (mains) vs a fail after some 25 transmits on the desktop socket supply). I also connected GND on the CAN board to rule out some influence from that side (on the elsewise differencial CAN signals). So for me no (easy) escape route in direction of pow supply. However it shows differences (influence) from the supply. I fear I do not have the proper equipment at hand to tell the detailed difference on my supplies noise or levels...
Kind Regards
Re: About the CAN controller.
Hi All,
this is not a direct reply to the last post, but I think my question fits this thread well.
In my design I am short og GPIO pins. So i chose GPIO34 for the CAN Rx pin. I know, GPIO 34 is input only but since I am using it as Rx pin it should work. But it doesn't. The CAN controller does not receive anything from the CAN bus. If I use a different pin, e.g. GPIO14 everything works well, so it should not be a problem with the transceiver or so.
I am using ESP-IDF V.3.2 and the CAN driver supplied with it.
Since i need GPIO14 for another function, i' d appreciate a solution to that problem very much.
this is not a direct reply to the last post, but I think my question fits this thread well.
In my design I am short og GPIO pins. So i chose GPIO34 for the CAN Rx pin. I know, GPIO 34 is input only but since I am using it as Rx pin it should work. But it doesn't. The CAN controller does not receive anything from the CAN bus. If I use a different pin, e.g. GPIO14 everything works well, so it should not be a problem with the transceiver or so.
I am using ESP-IDF V.3.2 and the CAN driver supplied with it.
Since i need GPIO14 for another function, i' d appreciate a solution to that problem very much.
Re: About the CAN controller.
My devkit C works for CAN Rx on pin 34 - just tried it.
Re: About the CAN controller.
On my hardware it works now too. But I had to modify the can driver.
To the function in can.c
I added the line
Maybe your software sets this outside the driver. But I'd expect the driver doing that.
To the function in can.c
Code: Select all
static void can_configure_gpio(gpio_num_t tx, gpio_num_t rx, gpio_num_t clkout, gpio_num_t bus_status)
Code: Select all
gpio_set_direction(rx, GPIO_MODE_INPUT);
Who is online
Users browsing this forum: No registered users and 105 guests