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 ?
Hello! It looks like you're interested in this conversation, but you don't have an account yet.
Getting fed up of having to scroll through the same posts each visit? When you register for an account, you'll always come back to exactly where you were before, and choose to be notified of new replies (either via email, or push notification). You'll also be able to save bookmarks and upvote posts to show your appreciation to other community members.
With your input, this post could be even better 💗
Register Login