I2C corruption when using ESP CAN (IDFGH-3307)

PeterR
Posts: 370
Joined: Mon Jun 04, 2018 2:47 pm

Re: I2C corruption when using ESP CAN (IDFGH-3307)

Postby PeterR » Tue May 19, 2020 6:07 pm

Moving i2c_driver_install() to core 1 seems to resolve/reduce the spurious GPIO issue. I cleaned core 1 of other stuff, would normally have SPI there.
I am going to clean build and confirm then see what I can add back onto core 1.

1) CAN overrun is a moderate issue. Disabling Ethernet improves/may even fix. I drop overrun frames ATM. My fix may not be perfect but (2) is much worse.
2) CAN frame corruption on termination resistor change is a major issue. Not found a way to detect this yet.
3) CAN RX locked after FATFS write is a major issue. Only noted when I have high frame rate. Following I always receive the same frame content. can_initiate_recovery() does not recover. Power off/on needed.
& I also believe that IDF CAN should be fixed.

PeterR
Posts: 370
Joined: Mon Jun 04, 2018 2:47 pm

Re: I2C corruption when using ESP CAN (IDFGH-3307)

Postby PeterR » Wed May 20, 2020 6:03 pm

Hi,
The I2C/GPIO button issue seems resolved by moving I2C ISR to core 1. I have also reenabled a GPIO interrupt (around 2KHz) on core 1 and the I2C GPIO readings stayed solid. The ISR is light weight though, just wakes a thread.
It is not clear if the I2C issue is an ESP or GPIO chip fault. One would imagine that with all the bit bashers out there that its not likely to be the GPIO and that this might be worth further investigation.
Another suggestion is that it may be an idea to look at the 4.1 Ethernet driver. I am clear that Ethernet is a cause of CAN overflows and allows the I2C issue to happen. As you say the ISR lock out time must be around 2mS to explain which seems excessive.

This leaves the IDF CAN corrections open. I did quickly try the Errata changes but to no effect. I will double check my code. May I ask when the CAN errata fixes will be made available?
Presently I cannot recover the CAN driver following a FLASH write. I also might stop receiving valid frames when CPU has been heavily loaded. The two sound similar and related to the Erratta .
& I also believe that IDF CAN should be fixed.

PeterR
Posts: 370
Joined: Mon Jun 04, 2018 2:47 pm

Re: I2C corruption when using ESP CAN (IDFGH-3307)

Postby PeterR » Thu May 21, 2020 11:58 pm

Hi,
Weak github force runs in me.
Please add links to the CAN driver ticket and repo branch such that I may follow the update. Would also be cool to understand the timetable.
I am attempting the errata hint but am hitting SJA amature issues (errors between screen & keyboard). If I can see where you are going then that would help me get the CAN driver of the floor.
For a production fix I'm sure that you might want to place can_ in front of hal_ then hal_ll. I just need a short term hack ;) So your register insights etc would help a lot. We only have one ESP CAN after all & I have my own high level abstraction for cross platform.
I can use your structured/finessed solution latter.
PM if you need. Just needing some love ATM.
EDIT:
1) Termination resistor issues fit within the errata definition. My counter report logic was wrong. So your errata fix should help
2) FLASH writes cause frame id & data corruptions. Some CAN issue posts discusse overruns (the errata discusses bit errors). So perhaps the overrun solution resolves but errata documentation is not clear. I would expect overruns when FLASHing as I am not sure that all driver logic is IRAM. so lets hope.
& I also believe that IDF CAN should be fixed.

Who is online

Users browsing this forum: burtrum and 28 guests