search

kmpelectronics / ProDinoESP32

1 stars 1 forks source link

SPI bus conflicts between Ethernet and MCP23S08 #2

Open wildstray opened 2 years ago

wildstray commented 2 years ago

Hello, I'm an embedded developer for a company that made an industrial protocol bridges based on ESP32. We used you ProDinos but we're experiencing issues with SPI. With base Ethernet library (cannot compile the embedded one, moreover I cannot found what changes are justifying the embedded one) we had to disuse digital I/O and comment out all reference and initialization of MCP23S08 also in you library. This is the only way we found to have a stable behaviour of W5500. Otherwise, if we try to use digital I/O or simply leave this library to init MCP23S08, we cannot read digital inputs (they are random), there are sporadic network errors (eg. corrupted web pages with EthernetWebServer) and the worst thing is that maybe the firmware crashes after Ethernet.begin() due to task watchdog when we power on the ProDino. If this issue happens, there is no way other than power off and power on. ESP.restart() don't reset W5500. I notice we can use in stable manner only MCP23S08 OR Ethernet. I tried to lower SPI clock modifying w5100.h SPI_ETHERNET_SETTINGS define, to use your standalone KMP_MCP23S08 library into ProDinoESP32 library instead of embedded MCP23S08 one... no way...

wildstray commented 2 years ago

PS: The power up lock of W5500 happens only with ProDino ESP32 EX and not with the old model.

wildstray commented 2 years ago

PPS: Take a look on this issue... other developers are noticing issues with Ethernet and SPI and is seems likely an issue of ESP32 SPI library... https://github.com/PaulStoffregen/Ethernet/issues/39 Anyway, it must possibile to use all hardware features of your devices... so have you some tips to manage shared SPI? I have seen some changes in the commits history just about MCP23S08, I noticed you tried to use a mutex and then you backtrack... Might be actually the ESP32 board platform (and how to address the issue?), maybe both Ethernet and MCP23S08 need mutex and/or transactions, maybe the management of timings (but there are already right delays and introducing other delays doesn't help, already tried) and CS lines?