Nrf52 gateway crashes
-
Perhaps it is related to the ESP. Do you have the possibility to exchange and test it with another module?
@electrik yup, switche the esp. I use esplink, and when the gateway crashes I can still reach the web-interface. So my guess is that the nrf is the problem, it somehow crashes or refuses to send/read data through the RX/TX.
It just crashed again: same node..
0;255;3;0;9;11077691 TSF:MSG:READ,114-114-0,s=0,c=3,t=16,pt=0,l=0,sg=1: -
@electrik yup, switche the esp. I use esplink, and when the gateway crashes I can still reach the web-interface. So my guess is that the nrf is the problem, it somehow crashes or refuses to send/read data through the RX/TX.
It just crashed again: same node..
0;255;3;0;9;11077691 TSF:MSG:READ,114-114-0,s=0,c=3,t=16,pt=0,l=0,sg=1: -
@omemanti adding
#define MY_DEBUG_VERBOSE_RF24to the gateway might give some insight inte what is happening.
Does this give me more information compared to the normal #MY_DEBUG?Skip that, had to change things in MyConig.. lets see what happensto be complete; I used: #define MY_DEBUG_VERBOSE_NRF5_ESB
-
i got 3 crashes, every one of them happened within the 20 minutes:
all ended like:
0;255;3;0;9;759816 TSF:MSG:READ,215-215-0,s=2,c=3,t=16,pt=0,l=0,sg=1: 0;255;3;0;9;759818 NRF5:SND:TO=215,LEN=32,PID=2,NOACK=0the strange part, its now node 215 instead of 114, both are located in a room somewhat distance from the gateway
average communication looks like:
0;255;3;0;9;750507 NRF5:RX:LEN=32,NOACK=0,PID=0,RSSI=-34,RX=0 0;255;3;0;9;750508 TSF:MSG:READ,216-216-0,s=0,c=3,t=16,pt=0,l=0,sg=1: 0;255;3;0;9;750510 NRF5:SND:TO=216,LEN=32,PID=1,NOACK=0 0;255;3;0;9;750514 NRF5:SND:END=1,ACK=1,RTRY=1,RSSI=-35,WAKE=5 0;255;3;0;9;750515 TSF:MSG:SEND,0-0-216-216,s=255,c=3,t=17,pt=6,l=25,sg=1,ft=0,st=OK:<NONCE> 0;255;3;0;9;750535 NRF5:RX:LEN=32,NOACK=0,PID=1,RSSI=-34,RX=0 0;255;3;0;9;750537 TSF:MSG:READ,216-216-0,s=0,c=1,t=1,pt=7,l=5,sg=1:60.9 -
every time it crashes, it at this line:
0;255;3;0;9;1268917 NRF5:SND:TO=216,LEN=32,PID=0,NOACK=0The "good" part, it happens to all nodes.
Could it have something to do with power? because the next line should be also an "SND"
Or can it be an encryption thing, that it happens before the SND part?
-
I've been troubleshooting for the last couple of days now;
so far:
- switches Weemos modules => both crashed
- switches Ebyte modules => both crashed
- powered the Ebyte modules separately from the ESP8266 => no luck eighter
2 things that came up "positive"
- remove: #define MY_SECURITY_SIMPLE_PASSWD => it ran all night without any errors
- FTDI + nrf52832 (serial gateway) + #define MY_SECURITY_SIMPLE_PASSWD => ran for the last couple of hours without any incident.
I don't know if it makes any sense, but when I combine the weemos with a nrf52832 (using Serial Gateway) is get bumps in the road. separate they work like charm.
-
@omemanti said in Nrf52 gateway crashes:
powered the Ebyte modules separately from the ESP8266 => no luck eighter
So you powered the Ebyte module with an external regulator?
Are your power supply and regulator powerful enough? -
It is worth to investigate the specs of the regulator of the St link. Did you try adding a capacitor on the power supply?
-
tonight, I let a node send data to the gateway, this one hangs after a couple of hours, but this time, I also hooked up an FTDI to the node, to have some readout as well from it.
It also broke down at the same stage like all the others did:
45381108 TSF:MSG:SEND,215-215-0-0,s=1,c=1,t=0,pt=7,l=5,sg=1,ft=0,st=OK:13.3
45381165 NRF5:SND:TO=0,LEN=32,PID=1,NOACK=0Why would it always hang on that this same line?
-- while operation, the node stays at a solid 3,0 V during all operations.
-
A month ago, I changed my sketch.
I replaced "MY_SECURITY_SIMPLE_PASSWD" to "MY_ENCRYPTION_SIMPLE_PASSWD" because this was most important to me. Nothing bad happened, I received everything in perfect order.
for the sake of testing, I switched back to "MY_SECURITY_SIMPLE_PASSWD" a couple of days ago, Guess what is happening since that time.
So there are to options to consider, or the implementation of MY_SECURITY_SIMPLE_PASSWD has a bug, or the Simple Signing is messing with my gateway.
-
A month ago, I changed my sketch.
I replaced "MY_SECURITY_SIMPLE_PASSWD" to "MY_ENCRYPTION_SIMPLE_PASSWD" because this was most important to me. Nothing bad happened, I received everything in perfect order.
for the sake of testing, I switched back to "MY_SECURITY_SIMPLE_PASSWD" a couple of days ago, Guess what is happening since that time.
So there are to options to consider, or the implementation of MY_SECURITY_SIMPLE_PASSWD has a bug, or the Simple Signing is messing with my gateway.
@omemanti it is not clear from your message what actually happened. Did something stop working?
Remember that you need to share the "simple" flag setting across all nodes in the network for it to work properly. You cannot have the password option on one node and the security option on another. -
@omemanti it is not clear from your message what actually happened. Did something stop working?
Remember that you need to share the "simple" flag setting across all nodes in the network for it to work properly. You cannot have the password option on one node and the security option on another.@anticimex said in Nrf52 gateway crashes:
@omemanti it is not clear from your message what actually happened. Did something stop working?
like posted a month ago; it "sometimes" stops working at the following line:
0;255;3;0;9;759816 TSF:MSG:READ,215-215-0,s=2,c=3,t=16,pt=0,l=0,sg=1: 0;255;3;0;9;759818 NRF5:SND:TO=215,LEN=32,PID=2,NOACK=0All nodes in the network are sending in data every 5 to 10 minutes (depending on the node) it all runs smoothly up until the line like above comes around. So all nodes send data and are using the same password etc.
All went oke when I changed to only encryption, when I went back to security it starts breaking again.
Average time form rebooting the gateway up until crashing averages from 30 minutes up until 15 hours. (yesterday I rebooted the gateway at 8:00 and it stopped working at 23:30) -
@anticimex said in Nrf52 gateway crashes:
@omemanti it is not clear from your message what actually happened. Did something stop working?
like posted a month ago; it "sometimes" stops working at the following line:
0;255;3;0;9;759816 TSF:MSG:READ,215-215-0,s=2,c=3,t=16,pt=0,l=0,sg=1: 0;255;3;0;9;759818 NRF5:SND:TO=215,LEN=32,PID=2,NOACK=0All nodes in the network are sending in data every 5 to 10 minutes (depending on the node) it all runs smoothly up until the line like above comes around. So all nodes send data and are using the same password etc.
All went oke when I changed to only encryption, when I went back to security it starts breaking again.
Average time form rebooting the gateway up until crashing averages from 30 minutes up until 15 hours. (yesterday I rebooted the gateway at 8:00 and it stopped working at 23:30) -
I posted a Log of the gateway from boot (around 2 hours ago) to last crash.
https://github.com/Omemanti/Paste/blob/master/Gateway_log_01-01-2019_security.txt
everything seems normal (to me) except de crash in the end.
-
FYI:
Yesterday I tried to use the MY_ENCRYPTION_SIMPLE_PASSWD and SIGNING (so not MY_SECURITY, everything separate), the gateway also crashes after a couple of hours.
So reverted all my sketches and now only have MY_ENCRYPTION_SIMPLE_PASSWD on all my nodes. Since that time I've been receiving everything and had no crashes.
-
I'm in the same situation, but with an Arduino Nano.
Did you ever get MY_SECURITY_SIMPLE_PASSWD to work ok in the end?
When I tried MY_ENCRYPTION_SIMPLE_PASSWD instead it worked straight away, so now I'm moving my network to that first. But I'd like to have optimal security if possible.
-
Please remember that the simple security flags use software implementation for signing (encryption as well unless the radio has native support), so they claim more resources. This is noticible on resource limited devices such as the atmega328p.
Nowadays, running both software encryption and softare signing on atmega328p at the same time is almost doomed to fail due to the heap and stack colliding.