Is it possible to have data corruption just after a soft restart?

[PeterR]

You must upgrade. No question, none.

The overflow issue has been there since the original driver. Understandably as the hardware API was not clear. Now IDF have moved on & fixeds lots. Invite mongoose to step up. IMHO overflow lock out is a school boy issue & unacceptable in a commercial offer. If you are GPL then you will have to offer a pull request using IDF latest
Like I said; IMHO CAN needs a bit more love.

"silicon driver patches" ?? Do you mean there are patches for the ESP32 itself?

No, its not a silicon patch (although ESP may fix this issue in later silicon). Just that after overflow you need to be aware that you might get corrupt frames. I picked up frame corruption software patches around May, had reservasions & not sure if/which branch those patches have entered. Bench testing you might not see. Field volume x1000, well.

Hopefully you have the means to bump frame rates etc and so prove to yourself that overflow is an issue (I am not mongoose so cannot say if they fixed overflow). If overflow is still a mongoose issue then I would bet that the silicon errata issues are also present. Hence my statement; you must upgrade.
In my mind overflow was a long standing issue but no one seemed to notice. I am old school reliable etc. It comes down to your own iron triangle, granted. My mentor would have shot me for delivering with CAN overflow or corruption however. So this all leaves me a little careful about the ESP CAN offer. Hence the request for more ESP CAN love.

[PeterR]

PS
I only saw the overflow issue when I upgraded to IDF 4.1 where (IMHO) someone put a 2mS block somewhere in the new Adaptor API. Maybe I just had added a lot more code. But I would bet.
I saw frame corruptions as soon as I hit field integration and had tactical cable quality issues. Unfortunately no one will change their install!
My application is mostly visual but even so the frame corruptions were significant and really needed fixing.

Check the patches ESP offer in my posts. Its mostly good & may have been taken further in an ESP branch.

[jimhelios]

Hopefully you have the means to bump frame rates etc and so prove to yourself that overflow is an issue (I am not mongoose so cannot say if they fixed overflow). If overflow is still a mongoose issue then I would bet that the silicon errata issues are also present. Hence my statement; you must upgrade.

I can reproduce the issue easily, and after I do get a fix in I'll mess with the terminators as you said in other posts.

Mongoose is not using the latest ESP-IDF, and I don't see an upgrade on the horizon real soon. It's not clear to me which they are using but TWAI/CAN is not normally supported by Mongoose. I used their config try and include TWAI support fromt he IDF but that caused the include chain to fail. It found twai.h just fine, but from twai.c there was another include that was not found.

I'm using a library that includes the Thomas Barth driver, so I think my only option is to strip that out and extract the TWAI support from ESP-IDF. That may require me to drag a lot of stuff along, and include it into that library or my own code. At first I'm just trying to issue a reset to the CAN/TWAI peripheral so the code will work at least as well after a soft reset as it does after a hard reset. From there I can then move to address the overflow issues you discussed.

Sadly this is a huge diversion, but that's the way software often goes. I'm now wishing I had used an external CAN controller.

[PeterR]

I'm using a library that includes the Thomas Barth driver, so I think my only option is to strip that out and extract the TWAI support from ESP-IDF. That may require me to drag a lot of stuff along, and include it into that library or my own code. At first I'm just trying to issue a reset to the CAN/TWAI peripheral so the code will work at least as well after a soft reset as it does after a hard reset.

Thomas was working blind (more respect). His driver has the overflow & errata issues though.
You must upgrade.

The ESP patch I received had a whole lot more code than you might expect from a simple 'reset hardware' solution. I went empirical as I had deliveries. I no longer saw errors so why not accept the fix? EDIT: But I saw lower frequency stuff. Long term I should look back but we are on initial supported runs & I have other priorities.
But I think the driver/patch has low new dependencies so worth an hour or two trial.

Check my posts. ESP offered a patch. Follow the lead & ask, maybe there is a better solution now. I had reservations but dropped the ESP conversation because my client had other priorities. Could not get ESP involvement again. IMHO there is more to learn but maybe fixed on a branch somewhere.

I would kick mongoose & especially if you paid. A driver which screws up on overflow is really not a driver (IMHO). I would go on but ... Actually I will. IMHO you cannot claim driver support with something which locks 'fail' on overflow. You could claim 'comming soon' etc. So I would kick against that.

EDIT

I can reproduce the issue easily,

Indeed you/we can - which suggests both an absence of supplier and user base support. I hate it when its just me and the guy from outer mongolia using a feature. No disrespect, love to travel!

[jimhelios]

I would kick mongoose & especially if you paid. A driver which screws up on overflow is really not a driver (IMHO). I would go on but ... Actually I will. IMHO you cannot claim driver support with something which locks 'fail' on overflow. You could claim 'comming soon' etc. So I would kick against that.

Well to be fair, Mongoose does not claim CAN / TWAI support on ESP32. They provide a way to access ESP-IDF capabilities but they are based on an older IDF. The library I'm using is an open source library that includes the older Barth driver. Mongoose offers very very pricey support, I lack budget for that

Indeed you/we can - which suggests both an absence of supplier and user base support. I hate it when its just me and the guy from outer mongolia using a feature. No disrespect, love to travel!

It's frustrating, but yes it had occurred to me that the CAN controller must get very little use on ESP32.

[PeterR]

It's frustrating, but yes it had occurred to me that the CAN controller must get very little use on ESP32.

Not sure about that. I got the impression that there were some very capable technical ppl involved in threads which suggests volume/value. What's not to love about ESP & CAN

Indeed. In summary ESP said that CAN might be fully supported. IMHO this has been a long running doubt. Is CAN supported or not?
To be fair; the latest patch is pretty good & ESP were working hard on it. Lots of code changed and in quite short time.
Still I cannot build a business on maybe.

ATM your problem seems to be support under Mongoose. I wonder why you use mongoose? The only add I can see is the MQTT server yet you loose CAN (or gain painful CAN)?

Why not go IDF?
ESP have an interest in supporting IDF yet Mongooge have many platforms and seems at least 3 years out of date on IDF (which is a lot).
I accept that CAN might not be claimed either side but then the presence of a driver would seem some what mendacious (& especially under the heading of /component (which means a part of a whole) rather than /concept).
Oh for a simple one page function support summary check sheet.

[jimhelios]

ATM your problem seems to be support under Mongoose. I wonder why you use mongoose? The only add I can see is the MQTT server yet you loose CAN (or gain painful CAN)?

Well I'm using much of what Mongoose offers as far as the OTA, the config system, the timers, network protocol drivers and so on. I don't know if IDF offers all that, I have never used IDF.

Why not go IDF?
ESP have an interest in supporting IDF yet Mongooge have many platforms and seems at least 3 years out of date on IDF (which is a lot).

I think they moved to IDF 3.3-R5 a week ago, or it least it looks that way in GitHub.

I didn't realize until just recently I had a CAN issue. At this point in my project I have a substantial base of code in Mongoose and would prefer not to have to port it all. As I said I don;t know much about IDF, perhaps it would be an easy port but I somehow doubt it, just because, despite what every software guy will tell you, nothing's ever really easy

[PeterR]

Mongoose offers as far as the OTA, the config system, the timers, network protocol drivers and so on.

IDF has all that. Mongoose gives you cross platform of course. Otherwise similar feature sets.

I think they moved to IDF 3.3-R5 a week ago, or it least it looks that way in GitHub

Not enough The update & patch needed 4.1.

. At this point in my project I have a substantial base of code in Mongoose and would prefer not to have to port it all.

Understood. Swapping OS will be tricky not least as you have become expert in Mongoose, not IDF.

Looks like you will have to port the IDF driver. Hopefully you will get some action from Mongoose. Good luck.

[jimhelios]

Mongoose offers as far as the OTA, the config system, the timers, network protocol drivers and so on.

IDF has all that. Mongoose gives you cross platform of course. Otherwise similar feature sets.

I think they moved to IDF 3.3-R5 a week ago, or it least it looks that way in GitHub

Not enough The update & patch needed 4.1.

. At this point in my project I have a substantial base of code in Mongoose and would prefer not to have to port it all.

Understood. Swapping OS will be tricky not least as you have become expert in Mongoose, not IDF.

Looks like you will have to port the IDF driver. Hopefully you will get some action from Mongoose. Good luck.

Hi Peter, I'm wondering if you saw my PM?

[baburao]

Much obliged without a doubt... I have been taking a shot at this a considerable amount and it appears that what's going on is that the CAN regulator isn't working accurately after a delicate reset. I saw something about this in the errata however didn't completely get it. The code I'm utilizing is utilizing a CAN driver by Thomas Barth. His notes state, at the time he composed it 3 years back, there was no other driver. Has Espressif delivered their own driver from that point forward?