ESP32 Forum

PeterR: Is there an alternative to the "stock" IDF?

We also have had the impression that the ESP32 sometimes induces errors (bit shifts) in received CAN frames.

Is there a test or other version of IDF we could be using to improve CAN functionality? We are using 3.3 currently.

Thanks!

EDIT: None that resolve all errors AFAIK. Overrun has 'solutions' but the other issues I raise I have not read else where.
PPS: Am also thinking I should change my signature in the style of Cato - "& besides I believe that ESP CAN should be fixed."

Hi,
There are other project but on different OS e.g mongoose. The proposed fix is easyish. These are emperically derived 'solutions' though, IMHO the product is not performing so what do we know about fixes & what do we know about test cases? Test evidence is usually lacking. Worked for a minute? My fix was less brutal and seems ok but...
Overrun is documented but not yet fixed in the IDF. Overruns should be the 'simple' part in that you have a status register telling you 'overrun' so hopefully resolution is just about being optimum. The stock answer is nuke it which results in other frames being lost. You then need to worry about frequency. In 4.1 introducing ethernet has marked latency issues/error rate well above 4.0. Not used 3.3. So the frequency and effects become a question about your application.
I mostly display figures so missing a few is not all that bad.
EDIT: There is some fluff around CAN overruns. When you get a CAN overrun you will be told that the frame is ok and you will also likely receieve one or more corrupt frames (without any notice of fault). That is major s*it IMHO. I could add the caveat emporium in a few minutes to the readme. Would you accept a UART driver that returned partity/overrun errors without indication? Not even in the 80s. I only see one corruption btw but others report many.

It gets worse though, your main issues may be termination bus issues and (if u do) after FLASH write.
Put your termination resistor on a switch. Setup a CAN dongle with 1,2,-8 frequent TX packet. Do you see corrupt frames comming through? Of course not. Toggle the switch for a few minutes & weep.
Open to offers on that one.

Next setup a regular CAN dongle TX packet, say 1600fps. Start a FATFS write to internal flash. You will never see a correct frame again.
Also open to offers on that one.

So IMHO it is bust ATM. I have a post in General Forum & ESP are being helpful but seem slow to move past overrun. Repeat my tests & come n join us. If you can repeat/add then that helps loads.

PeterR: Thanks for the info.

Are you saying that an Overrun condition can occur and that there is no way to detect it?

Or, do you mean that we need to trap the Overrun error, and then discard a couple more frames following it?

In my situation, I can easily discard a couple frames. I just need to know WHEN to do so.

At this point, we are considering just using a PIC controller as a "CAN Gateway" between the CAN bus and the ESP...

I am not sure. There are two reports, one discusses overruns the other dealing with CAN errors. My tests/results have been based on overrun so I need to go back to looking at other errors. I was also looking at the SJA datasheet which might lead you to believe that you have tried everything. That is also wrong. The ESP is not an SJA, it is like an SJA but has more features. Some documentation would help but hey.

So I would wait a little before adding a PIC. Infact I would not add a PIC, maybe an Mn.
Having looked again at the Errata sheet then to be fair my problems might be explained by the Errata.
I think that I have tried the suggested fix. I think that I have also applied the corruption solution as posted in other forums.
Did not always work for me but I may have got my implementation wrong.
I also think that I have seen corruptions without overrun but that is a misleading ticket/forum comment. The errata does not require an overrun, just a CAN error. Anyway I may have got my implementation wrong.

So I am going to do something else for a day or two, forget what I think I know and then try again.
I have also been promised that ESP will post a CAN fix 'soon' which is really good news. It is very much over due.

If you try the errata fix yourself then I would be happy to support testing your changes. I'm on 4.1 though. Seems easier to try fixing the IDF than add a new processor & I gain

Back. Had some bad diagnostic code.

1) Corrupt frames arising from termination resistor issues fit within the ESP32 errata definiton (I was printing the wrong value). These issues should be detectable and the trash frame may then be rejected when the driver has been modified.

2) Device returning corrupt frame identifiers and/or data following FLASH write does not fit within the ESP32 errata definition. The bus error count does not increment.

The second issue has my priority. If you don't FLASH write then it may be worth you trying the ESP errata 'solution'. You will have to code yourself. <whinge_mode>I don't understand why ESP cannot point to their investigation/solution code assuming that the solution is not just a white box review claim.</whinge_mode>

ESP have an alpha here: viewtopic.php?f=2&t=15768&p=60284#p60284
Will let you know how testing goes.

This is looking like a good fix:
viewtopic.php?f=2&t=15768&p=60871#p60871

Would be great to get feedback on your tests.