ESP8266 gateway and sensor node not talking - noobie
-
@hek said:
Ok, great. We need to increase timeout then.
Better add a yield() call in those blocking wait loops.
When quiclkly looking over the code of the RF69 driver, the RFM69::initialize call could in theory block for 1.5 sec...
That's a watchdog reset waiting to happen! -
I am seeing something similar with RFM69 (specifically RFM69CW) and ESP8266. I have build an ESP8266 gateway based on the GatewayESP8266 sketch and this is what I changed
#define MY_RADIO_RFM69 #define MY_GATEWAY_ESP8266 #define MY_RFM69_FREQUENCY RF69_868MHZ #define MY_RF69_IRQ_PIN 4 #define MY_RF69_SPI_CS 15 #define MY_RF69_IRQ_NUM 4I build a sensor node with the DallasTemperatureSensor sketch on an Arduino Mini Pro and defined
#define MY_RADIO_RFM69 #define MY_RFM69_FREQUENCY RF69_868MHZWhen I start up the gateway I see
0;255;3;0;9;Starting gateway (RRNGE-, 2.0.0-beta) 0;255;3;0;9;Radio init successful. ....scandone state: 0 -> 2 (b0) state: 2 -> 3 (0) state: 3 -> 5 (10) add 0 aid 8 cnt connected with AP, channel 1 ip:62.x.x.x,mask:255.255.255.128,gw:62.x.x.x .IP: 62.x.x.x 0;255;3;0;9;Init complete, id=0, parent=0, distance=0So far so good - I assume all the radio wiring is OK, since the radio init is successful
On the sensor node I see
Starting sensor (RRNNA-, 2.0.0-beta) Radio init successful. find parent send: 255-255-255-255 s=255,c=3,t=7,pt=0,l=0,sg=0,st=bc: find parent send: 255-255-255-255 s=255,c=3,t=7,pt=0,l=0,sg=0,st=bc: find parent send: 255-255-255-255 s=255,c=3,t=7,pt=0,l=0,sg=0,st=bc: Init complete, id=255, parent=255, distance=255As soon as the sensor node is started the ESP8266 crashes with a WDT reset
Soft WDT reset ctx: cont sp: 3ffef370 end: 3ffef630 offset: 01b0 >>>stack>>> 3ffef520: 00000001 3ffef6d4 3ffef964 00000000 3ffef530: 00000024 3ffef6d4 3ffef964 40202436 3ffef540: 3ffe8432 00000000 3ffef6d4 402024bc 3ffef550: 3ffe8432 00000000 3ffef6d4 402026a7 3ffef560: 3ffef6f2 00000001 3ffef6d4 40202b87 3ffef570: 3fffdae0 00000000 3ffee600 3ffef6ac 3ffef580: 3fffdae0 3ffef6f1 3ffef6d4 40202cf4 3ffef590: 3fff1210 00000000 3ffee600 402042b4 3ffef5a0: 00000000 00000002 3ffef82c 40203d20 3ffef5b0: 00000000 3ffef6d4 3ffef964 4020247c 3ffef5c0: 401057ff 00000400 00000103 3ffef5f0 3ffef5d0: 3ffef5e0 00000004 3ffef6cd 4020249c 3ffef5e0: 3ffe8920 00000000 00000000 3ffee608 3ffef5f0: 3fffdae0 00000000 3ffee600 3ffee608 3ffef600: 3fffdae0 00000000 3ffee600 40203e6c 3ffef610: feefeffe feefeffe 3ffee600 402045b4 3ffef620: feefeffe feefeffe 3ffee610 40100114 <<<stack<<<The libraries are 2.0 beta as from a few days ago. I consider the power to the ESP8266 to be OK, since I use the same for en NRF24 based gateway and also for several other ESP modules.
From the thread I understand that known issues should be fixed in the current beta. Any ideas on how to move on?
-
I am seeing something similar with RFM69 (specifically RFM69CW) and ESP8266. I have build an ESP8266 gateway based on the GatewayESP8266 sketch and this is what I changed
#define MY_RADIO_RFM69 #define MY_GATEWAY_ESP8266 #define MY_RFM69_FREQUENCY RF69_868MHZ #define MY_RF69_IRQ_PIN 4 #define MY_RF69_SPI_CS 15 #define MY_RF69_IRQ_NUM 4I build a sensor node with the DallasTemperatureSensor sketch on an Arduino Mini Pro and defined
#define MY_RADIO_RFM69 #define MY_RFM69_FREQUENCY RF69_868MHZWhen I start up the gateway I see
0;255;3;0;9;Starting gateway (RRNGE-, 2.0.0-beta) 0;255;3;0;9;Radio init successful. ....scandone state: 0 -> 2 (b0) state: 2 -> 3 (0) state: 3 -> 5 (10) add 0 aid 8 cnt connected with AP, channel 1 ip:62.x.x.x,mask:255.255.255.128,gw:62.x.x.x .IP: 62.x.x.x 0;255;3;0;9;Init complete, id=0, parent=0, distance=0So far so good - I assume all the radio wiring is OK, since the radio init is successful
On the sensor node I see
Starting sensor (RRNNA-, 2.0.0-beta) Radio init successful. find parent send: 255-255-255-255 s=255,c=3,t=7,pt=0,l=0,sg=0,st=bc: find parent send: 255-255-255-255 s=255,c=3,t=7,pt=0,l=0,sg=0,st=bc: find parent send: 255-255-255-255 s=255,c=3,t=7,pt=0,l=0,sg=0,st=bc: Init complete, id=255, parent=255, distance=255As soon as the sensor node is started the ESP8266 crashes with a WDT reset
Soft WDT reset ctx: cont sp: 3ffef370 end: 3ffef630 offset: 01b0 >>>stack>>> 3ffef520: 00000001 3ffef6d4 3ffef964 00000000 3ffef530: 00000024 3ffef6d4 3ffef964 40202436 3ffef540: 3ffe8432 00000000 3ffef6d4 402024bc 3ffef550: 3ffe8432 00000000 3ffef6d4 402026a7 3ffef560: 3ffef6f2 00000001 3ffef6d4 40202b87 3ffef570: 3fffdae0 00000000 3ffee600 3ffef6ac 3ffef580: 3fffdae0 3ffef6f1 3ffef6d4 40202cf4 3ffef590: 3fff1210 00000000 3ffee600 402042b4 3ffef5a0: 00000000 00000002 3ffef82c 40203d20 3ffef5b0: 00000000 3ffef6d4 3ffef964 4020247c 3ffef5c0: 401057ff 00000400 00000103 3ffef5f0 3ffef5d0: 3ffef5e0 00000004 3ffef6cd 4020249c 3ffef5e0: 3ffe8920 00000000 00000000 3ffee608 3ffef5f0: 3fffdae0 00000000 3ffee600 3ffee608 3ffef600: 3fffdae0 00000000 3ffee600 40203e6c 3ffef610: feefeffe feefeffe 3ffee600 402045b4 3ffef620: feefeffe feefeffe 3ffee610 40100114 <<<stack<<<The libraries are 2.0 beta as from a few days ago. I consider the power to the ESP8266 to be OK, since I use the same for en NRF24 based gateway and also for several other ESP modules.
From the thread I understand that known issues should be fixed in the current beta. Any ideas on how to move on?
-
@chrille Try adding the following line to your setup() function:
ESP.wdtDisable();It should disable the (software) watchdog on ESP. See if it continues, or if it will now just hang.
-
@Yveaux Just tried that. The change removed the watchdog message and the stack trace, but the module still reboots
-
@Yveaux Just tried that. The change removed the watchdog message and the stack trace, but the module still reboots
-
@Yveaux I did some further tests and it may be related to the inclusion mode feature. At least disabling this makes things more stable - but I still haven't got the radio side working reliable. When this is working I will go back to the gateway and see if I can find out what triggers the crash
-
@Yveaux I think I have narrowed down the issue now to this code in RFM69.cpp
void RFM69::sendACK(const void* buffer, byte bufferSize) { debug(PSTR("RFM69: void sendACK\n")); byte sender = SENDERID; debug(PSTR("RFM69: sendACK - entering while()\n")); while (!canSend()) receiveDone(); sendFrame(sender, buffer, bufferSize, false, true); }(The debug lines are added by me)
Most of the time the WDT kicks in, after logging "entering while()" - occasionally it will reach sendFrame() and log a "read: " line but then the WDT kicks in when it gets to the while() loop again.
sendAck is called from sendFrame, that disables interrupts, by calling select()With a bunch of additional debug turned on, this is what I get on the console
0;255;3;0;9;Init complete, id=0, parent=0, distance=0 chg_B:-60 chg_B:-120 0;255;3;0;9;RFM69: interruptHandler 0;255;3;0;9;RFM69: IRQ handler - select chip 0;255;3;0;9;RFM69: IRQ handler - release chip 0;255;3;0;9;RFM69: IRQ handler - read RSSI 0;255;3;0;9;RFM69: receiveDone() - payload 0;255;3;0;9;RFM69: void sendACK chg_B:-60 0;255;3;0;9;RFM69: sendACK - entering while() 0;255;3;0;9;RFM69: sendFrame() 0;255;3;0;9;RFM69: interruptHandler 0;255;3;0;9;RFM69: IRQ handler - read RSSI 0;255;3;0;9;read: 255-255-0 s=255,c=3,t=3,pt=0,l=0,sg=0: 0;255;3;0;9;RFM69: interruptHandler 0;255;3;0;9;RFM69: IRQ handler - select chip 0;255;3;0;9;RFM69: IRQ handler - release chip 0;255;3;0;9;RFM69: IRQ handler - read RSSI 0;255;3;0;9;RFM69: receiveDone() - payload 0;255;3;0;9;RFM69: void sendACK 0;255;3;0;9;RFM69: sendACK - entering while() Soft WDT reset ctx: cont sp: 3ffefa70 end: 3ffefd30 offset: 01b0 >>>stack>>> 3ffefc20: 00000001 3ffefdd4 3ffeffdc 000000ff 3ffefc30: 00000024 3ffefdd4 3ffeffdc 402022da 3ffefc40: 3ffe8496 00000000 3ffefdd4 40202360 3ffefc50: 00000000 00000000 3ffefdd4 4020254b 3ffefc60: 3ffefdf2 00000000 3ffefdd4 402037f9 3ffefc70: 3fffdc20 00000000 3ffefdd4 3ffefdac 3ffefc80: 3fffdc20 3ffefdf1 3ffefdd4 4020385c 3ffefc90: 00000003 00000000 3ffeecf8 40204035 3ffefca0: 00000003 00000000 00000000 00000000 3ffefcb0: 3ffefd58 3ffefdd4 3ffeffdc 3ffeed00 3ffefcc0: 3ffefe00 00000000 3ffefe98 40203aec 3ffefcd0: 00000003 00000000 000000ff 00000000 3ffefce0: 000000ff 00000002 00000000 00000000 3ffefcf0: 3fffdc20 00000000 3ffeecf8 3ffeed00 3ffefd00: 3fffdc20 00000000 3ffeecf8 40203c06 3ffefd10: 00000000 00000000 3ffeecf8 4020432c 3ffefd20: 00000000 00000000 3ffeed10 40100114 <<<stack<<<Any ideas on how to fix this, would be greatly appreciated!
-
@Yveaux I think I have narrowed down the issue now to this code in RFM69.cpp
void RFM69::sendACK(const void* buffer, byte bufferSize) { debug(PSTR("RFM69: void sendACK\n")); byte sender = SENDERID; debug(PSTR("RFM69: sendACK - entering while()\n")); while (!canSend()) receiveDone(); sendFrame(sender, buffer, bufferSize, false, true); }(The debug lines are added by me)
Most of the time the WDT kicks in, after logging "entering while()" - occasionally it will reach sendFrame() and log a "read: " line but then the WDT kicks in when it gets to the while() loop again.
sendAck is called from sendFrame, that disables interrupts, by calling select()With a bunch of additional debug turned on, this is what I get on the console
0;255;3;0;9;Init complete, id=0, parent=0, distance=0 chg_B:-60 chg_B:-120 0;255;3;0;9;RFM69: interruptHandler 0;255;3;0;9;RFM69: IRQ handler - select chip 0;255;3;0;9;RFM69: IRQ handler - release chip 0;255;3;0;9;RFM69: IRQ handler - read RSSI 0;255;3;0;9;RFM69: receiveDone() - payload 0;255;3;0;9;RFM69: void sendACK chg_B:-60 0;255;3;0;9;RFM69: sendACK - entering while() 0;255;3;0;9;RFM69: sendFrame() 0;255;3;0;9;RFM69: interruptHandler 0;255;3;0;9;RFM69: IRQ handler - read RSSI 0;255;3;0;9;read: 255-255-0 s=255,c=3,t=3,pt=0,l=0,sg=0: 0;255;3;0;9;RFM69: interruptHandler 0;255;3;0;9;RFM69: IRQ handler - select chip 0;255;3;0;9;RFM69: IRQ handler - release chip 0;255;3;0;9;RFM69: IRQ handler - read RSSI 0;255;3;0;9;RFM69: receiveDone() - payload 0;255;3;0;9;RFM69: void sendACK 0;255;3;0;9;RFM69: sendACK - entering while() Soft WDT reset ctx: cont sp: 3ffefa70 end: 3ffefd30 offset: 01b0 >>>stack>>> 3ffefc20: 00000001 3ffefdd4 3ffeffdc 000000ff 3ffefc30: 00000024 3ffefdd4 3ffeffdc 402022da 3ffefc40: 3ffe8496 00000000 3ffefdd4 40202360 3ffefc50: 00000000 00000000 3ffefdd4 4020254b 3ffefc60: 3ffefdf2 00000000 3ffefdd4 402037f9 3ffefc70: 3fffdc20 00000000 3ffefdd4 3ffefdac 3ffefc80: 3fffdc20 3ffefdf1 3ffefdd4 4020385c 3ffefc90: 00000003 00000000 3ffeecf8 40204035 3ffefca0: 00000003 00000000 00000000 00000000 3ffefcb0: 3ffefd58 3ffefdd4 3ffeffdc 3ffeed00 3ffefcc0: 3ffefe00 00000000 3ffefe98 40203aec 3ffefcd0: 00000003 00000000 000000ff 00000000 3ffefce0: 000000ff 00000002 00000000 00000000 3ffefcf0: 3fffdc20 00000000 3ffeecf8 3ffeed00 3ffefd00: 3fffdc20 00000000 3ffeecf8 40203c06 3ffefd10: 00000000 00000000 3ffeecf8 4020432c 3ffefd20: 00000000 00000000 3ffeed10 40100114 <<<stack<<<Any ideas on how to fix this, would be greatly appreciated!
-
@chrille I'm not familiar with rfm implementation, but you could try adding a call to yield() inside the while loop.
-
@chrille Could you create a pull-request (or a bug report) for this fix in MySensors' github repo ?
