PJON icon indicating copy to clipboard operation
PJON copied to clipboard

ESP32 <-> ESP8266 softwarebitbang communication failure

Open MArimont3 opened this issue 2 years ago • 5 comments

Hi, I did some first trials with this library with 2 Arduino Nano boards communicating to each other using the softwarebitbang strategy. the examples did run fine.

Then I moved to the environment I would like to use: an ESP32 (Espressif ESP32-WROOM) communicating to one or more ESP8266 (NodeMCU V3) boards. I did start with an ESP32 and a single ESP8266 board. I used pin 12 on the ESP32 and pin 5 (D1) on the ESP8266, and pulled down the softwarebitbang data line with a 1M ohm resistor.

I tested with the NetworkAnalysis Transmitter and Receiver example sketches (under PJON/Arduino/local/SoftwareBitBang). Uncommented "SWBB_MODE 1" in both scripts. And adapted the pin numbers. I made first the ESP32 the transmitter , and ESP8266 the receiver. Works fine. No fails nor busy's. Then I switched both roles: made the ESP¨8266 the transmitter and the ESP32 the receiver (and of course adapted the pins in both scripts). Was not able to send a single packet: all return PJON_FAIL.

How to explain ? I understand that in the first configuration (ESP32 = transmitter , ESP8266 = receiver), "communication" goes in both directions as the ESP8266 has to "acknowledge" the reception of each package to the ESP32. Why is it then impossible to send something when switching the roles ?

I tried several other examples, and always was blocked at the same point. No issue to send something from the ESP32 to the ESP8266 (sent was acknowledged). But impossible to reply or send from the ESP8266 to the ESP32...

Any idea ? Why is this protocol so device dependent ? Why is it also so pin dependent (why does it only work on some very specific pins ? I can't find any special for these pins in the data sheets ?)

Thanks for any help (or experience)

MArimont3 avatar Jan 31 '22 16:01 MArimont3

I also added the error_handling (see PJON doc) to both transmitter and receiver scripts. No errors are raised... Both boards of course also share a common ground... Also repeated all tests with pin 25 on ESP32, same results...

MArimont3 avatar Jan 31 '22 17:01 MArimont3

Maybe the same issue I'm facing in issue #404 😕

SunboX avatar Mar 18 '22 14:03 SunboX

@SunboX @MArimont3 I think the problem was identified here https://github.com/gioblu/PJON/issues/398 by @X-Ryl669

GPIO12 is a bit painful to use since if you have it pulled high (for whatever reason) while booting, the ESP32 will likely fail to boot (it's used to change the voltage of the flash chip from 3.3V to 1.8V). It can be pulled high if the other side of the communication link is trying to communicate while the ESP32 is rebooting. In that case, the system will never resume in a working condition, unless manually reboot while GPIO12 is low.

When the ESP32 used as a receiver will likely fail to boot because the transmitter is pulling HIGH the GPIO12 while attempting to transmit a packet.

I think the solution is to use other pins to avoid this issue, this is probably easily solved with just testing. Try other available pins (even if not in the list of compatible pins) and see if works.

If doesn't work I will need to recover my oscilloscope and my stuff (now more than 1k kilometers from where I am now) and make some tests :)

gioblu avatar Mar 19 '22 13:03 gioblu

@MArimont3 Can you please check if this timing config on the ESP32 (using pin 25) also works for you?

See timing config here: https://github.com/gioblu/PJON/issues/404#issuecomment-1077405057

SunboX avatar Mar 24 '22 09:03 SunboX

It might be unrelated, but I came across this issue (and #404) while searching for solutions to a somewhat similar problem I'm facing with using PJON on ESP32, except I'm using the ESPNow strategy (after applying fix in #419). Using the "PingPongArduinoIDE" example, I can send from/to either of two ESP32 devices, but don't ever receive any packets from a reply sent in the receiver function. Obviously ESPNow doesn't require a GPIO pin to be set high/low, but I'm wondering if there's some wider related timing/contention issue here affecting the ESP32 core?

alastaira avatar Nov 04 '22 12:11 alastaira