[SOLVED] latest git-snapshot causes freezes
-
I forgot to mention that the node is battery powered @ 2x AA-Alkaline-Battery @ ~2,5volt .. no LDO involved .. and an NRF24+LNA+PA version of the NRF24 ..
I got like 4-5 boards with this exact same setup and they run totally fine with the latest stable release ..
.. investigating the root cause might be difficulty as my code is a little bit customized with a little wrapper .. will try out a fresh sketch tomorrow ..
-
Okay ... I switched back between snapshot from yesterday and stable 2.0.0 and all I can say is that the stable is perfectly fine and the snapshot freezes.
prepare to sleep 17416 MCO:SLP:MS=16,SMS=0,I1=1,M1=3,I2=255,M2=255 17481 MCO:SLP:TPD 17498 MCO:SLP:WUP=1 .18Nothing on the code has been changed. Only difference is that I had to modifie latest stable to include a few delays for my slow 1mhz node ..
PS: I currently don't have the time to debug this issue further .. last time it took me some days to figure out the delay-issue of slow nodes ...
-
Okay ... I switched back between snapshot from yesterday and stable 2.0.0 and all I can say is that the stable is perfectly fine and the snapshot freezes.
prepare to sleep 17416 MCO:SLP:MS=16,SMS=0,I1=1,M1=3,I2=255,M2=255 17481 MCO:SLP:TPD 17498 MCO:SLP:WUP=1 .18Nothing on the code has been changed. Only difference is that I had to modifie latest stable to include a few delays for my slow 1mhz node ..
PS: I currently don't have the time to debug this issue further .. last time it took me some days to figure out the delay-issue of slow nodes ...
-
// http://www.earth.org.uk/OpenTRV/Arduino/bootloader/ATmega328P-1MHz/README.txt #define MY_NODE_ID 14 #define MY_BAUD_RATE 9600 // DONT GO HIGHER AS 57600 !!! 115200 might cause DEADLOCKS!!! // Enable debug prints to serial monitor #define MY_DEBUG #define MY_DEBUG_LIGHT #define MY_RF24_PA_LEVEL RF24_PA_HIGH // Enable and select radio type attached #define MY_RADIO_NRF24 //#define MY_RADIO_RFM69 #include <SPI.h> #include <MySensors.h> //#include "helper.h" //MySensorChild motionSensor = MySensorChild(0, S_MOTION, V_TRIPPED, ""); void before() { //wdt_enable(WDTO_8S); } void presentation() { // Send the sketch version information to the gateway and Controller char datetime[30]; // 22 + 1 should ben enough snprintf(datetime, 30, "%s | %s", __DATE__, __TIME__); #ifdef MY_DEBUG_LIGHT Serial.print(F("SketchInfo: ")); Serial.println(datetime); #endif sendSketchInfo("adxl345", datetime); } #include <Wire.h> #include <FaBo3Axis_ADXL345.h> FaBo3Axis fabo3axis; //void ADXL_ISR() //{ // //} void setup() { Serial.begin(9600); // シリアルの開始デバック用 Serial.println("Checking I2C device..."); //if(fabo3axis.searchDevice()){ // Serial.println("I am ADXL345"); //} Serial.println("Init..."); fabo3axis.configuration(); fabo3axis.powerOn(); //fabo3axis.enableTap(); fabo3axis.enableActivity(); //attachInterrupt(digitalPinToInterrupt(3), ADXL_ISR, RISING); fabo3axis.readIntStatus(); // http://www.avrfreaks.net/forum/wire-library-increasing-i2c-speed //TWBR = ((F_CPU / 400000) - 16) / 2; TWBR = 0; Serial.print("i2c @ "); Serial.print(TWBR); Serial.println(); } void loop() { //wdt_reset(); MyMessage msg(0, V_TRIPPED); //motionSensor.set(1); motionSensor.waitsend(50); //send(msg,true); //uint8_t s = fabo3axis.readIntStatus(); uint8_t s = 1; if(false){ Serial.print("activity "); //Serial.println(millis()); msg.set(1); send(msg,true); //motionSensor.set(1); motionSensor.waitsend(50,60000); } else { Serial.print(s,HEX); msg.set(0); send(msg,true); //motionSensor.set(0); motionSensor.waitsend(50,60000); } //Serial.println("prepare to sleep"); Serial.flush(); // Pending Int-Stati might prevent interrupt! fabo3axis.readIntStatus(); sleep(digitalPinToInterrupt(3),RISING,16); //millis_offset += 16; Serial.print(" | "); Serial.println(hwMillis()); } bool my_ack_received; void receive(const MyMessage &message) { if (message.isAck()) my_ack_received = true; }I suspect the sleep/interrupt combination.
Could not remove the accelerometer cause it is the source of the interrupts
-
I hope you catch it, as I believe I'm hit by the same bug. It the happens similar way on Sensebender Micro & NRF24L01+. I have a thread on troubleshooting forum with topic of interrupt mystery. I'm arduino newbie, so I'm not much help. I'm just about to try it on Arduino Pro mini just for comparison.
Somehow the enbling of interrupts lock it within a minute or so. If no interrupt enabled, no locking.
BR,
Ikke -
I hope you catch it, as I believe I'm hit by the same bug. It the happens similar way on Sensebender Micro & NRF24L01+. I have a thread on troubleshooting forum with topic of interrupt mystery. I'm arduino newbie, so I'm not much help. I'm just about to try it on Arduino Pro mini just for comparison.
Somehow the enbling of interrupts lock it within a minute or so. If no interrupt enabled, no locking.
BR,
Ikke -
@cimba007
just an idea..i don't know if it can help at all..but it looks there is a while loop in FaBo3Axis::readI2c
do you think if adding some debug here you get something??
i was just thinking..a freeze that's weird..no wdt? -
@tekka Arduiono 1.6.12
############################################################## # Add the new board to boards.txt (normally located at "C:\Program Files\Arduino\hardware\arduino\avr" # The *.bootloader.* etries only matters if you want to program bootloader (and fuses) from Arduino IDE. # See http://www.engbedded.com/fusecalc (select Atmega328p) for interpretation of fuse values and how # extended fuses are written in different applications (07h in Arduino IDE = FFh in Atmel studio). ############################################################## apm96.name=APM Optiboot internal 1MHz noBOD 9600baud apm96.upload.tool=avrdude apm96.upload.protocol=arduino apm96.upload.maximum_size=32256 apm96.upload.speed=9600 apm96.bootloader.tool=avrdude apm96.bootloader.low_fuses=0x62 apm96.bootloader.high_fuses=0xde apm96.bootloader.extended_fuses=0x06 apm96.bootloader.path=optiboot_v50 apm96.bootloader.file=atmega328_1a.hex apm96.bootloader.unlock_bits=0x3F apm96.bootloader.lock_bits=0x2F apm96.build.board=AVR_APM96 apm96.build.mcu=atmega328p apm96.build.f_cpu=1000000L apm96.build.core=arduino apm96.build.variant=standard ##############################################################I changed the fuses to include BDOUT @ 1,8Volt
VCC of my setup is 2-3Volt -
@cimba007
just an idea..i don't know if it can help at all..but it looks there is a while loop in FaBo3Axis::readI2c
do you think if adding some debug here you get something??
i was just thinking..a freeze that's weird..no wdt?@scalz Thanks for the hint with the while-loop. I changed the i2c-read the following way:
void FaBo3Axis::readI2c(uint8_t register_addr, uint8_t num, uint8_t buffer[]) { Wire.beginTransmission(_i2caddr); Wire.write(register_addr); Wire.endTransmission(); Wire.requestFrom(_i2caddr, num); int i = 0; uint8_t limit = num; while(Wire.available() && limit--) { Serial.print("r"); buffer[i] = Wire.read(); i++; } }Now it should under no circumstanced read more then the number given. Sadly this had no impact:
| 34291 34291 TSF:MSG:READ,0-0-14,s=0,c=1,t=16,pt=2,l=2,sg=0:0 34357 TSF:MSG:ACK 134390 TSF:MSG:SEND,14-14-0-0,s=0,c=1,t=16,pt=2,l=2,sg=0,ft=0,st=OK:0 r34471 MCO:SLP:MS=16,SMS=0,I1=1,M1=3,I2=255,M2=255 34537 MCO:SLP:TPD 34553 MCO:SLP:WUP=1 | 34553 34553 TSF:MSG:READ,0-0-14,s=0,c=1,t=16,pt=2,l=2,sg=0:0 34553 TSF:MSG:ACK 134553 TSF:MSG:SEND,14-14-0-0,s=0,c=1,t=16,pt=2,l=2,sg=0,ft=0,st=OK:0Just before the sleep ..
I then added a Serial.flush() to the "r"-output ..
void FaBo3Axis::readI2c(uint8_t register_addr, uint8_t num, uint8_t buffer[]) { Serial.print("readI2c"); Serial.flush(); Wire.beginTransmission(_i2caddr); Wire.write(register_addr); Wire.endTransmission(); Wire.requestFrom(_i2caddr, num); int i = 0; uint8_t limit = num; while(Wire.available() && limit--) { Serial.print("r"); Serial.flush(); buffer[i] = Wire.read(); i++; } }54706 MCO:SLP:WUP=1 | 54706 54706 TSF:MSG:READ,0-0-14,s=0,c=1,t=16,pt=2,l=2,sg=0:0 54706 TSF:MSG:ACK 154706 TSF:MSG:SEND,14-14-0-0,s=0,c=1,t=16,pt=2,l=2,sg=0,ft=0,st=OK:0Now the freeze is clearly before entering the sleep function ..
but then .. on another round ..
| 56623 56623 TSF:MSG:READ,0-0-14,s=0,c=1,t=16,pt=2,l=2,sg=0:0 56623 TSF:MSG:ACK 156623 TSF:MSG:SEND,14-14-0-0,s=0,c=1,t=16,pt=2,l=2,sg=0,ft=0,st=OK:0 readI2creadI2cgot # from slave: 1 r78987 MCO:SLP:MS=16,SMS=0,I1=1,M1=3,I2=255,M2=255 79052 MCO:SLP:TPD 79069 MCO:SLP:WUP=1 | 79069 79069 TSF:MSG:READ,0-0-14,s=0,c=1,t=16,pt=2,l=2,sg=0:0 79069 TSF:MSG:ACK 179069 TSF:MSG:SEND,14-14-0-0,s=0,c=1,t=16,pt=2,l=2,sg=0,ft=0,st=OK:0 readI2cSo .. your tip was very good .. it seems to be related to the
Wire.beginTransmission(_i2caddr); Wire.write(register_addr); Wire.endTransmission();-call .. only one questions remains .. why was it working perfectly on the stable library?
Just to be sure I will run exactly the same code in a non-stop loop with the stable library ..
-
@scalz Thanks for the hint with the while-loop. I changed the i2c-read the following way:
void FaBo3Axis::readI2c(uint8_t register_addr, uint8_t num, uint8_t buffer[]) { Wire.beginTransmission(_i2caddr); Wire.write(register_addr); Wire.endTransmission(); Wire.requestFrom(_i2caddr, num); int i = 0; uint8_t limit = num; while(Wire.available() && limit--) { Serial.print("r"); buffer[i] = Wire.read(); i++; } }Now it should under no circumstanced read more then the number given. Sadly this had no impact:
| 34291 34291 TSF:MSG:READ,0-0-14,s=0,c=1,t=16,pt=2,l=2,sg=0:0 34357 TSF:MSG:ACK 134390 TSF:MSG:SEND,14-14-0-0,s=0,c=1,t=16,pt=2,l=2,sg=0,ft=0,st=OK:0 r34471 MCO:SLP:MS=16,SMS=0,I1=1,M1=3,I2=255,M2=255 34537 MCO:SLP:TPD 34553 MCO:SLP:WUP=1 | 34553 34553 TSF:MSG:READ,0-0-14,s=0,c=1,t=16,pt=2,l=2,sg=0:0 34553 TSF:MSG:ACK 134553 TSF:MSG:SEND,14-14-0-0,s=0,c=1,t=16,pt=2,l=2,sg=0,ft=0,st=OK:0Just before the sleep ..
I then added a Serial.flush() to the "r"-output ..
void FaBo3Axis::readI2c(uint8_t register_addr, uint8_t num, uint8_t buffer[]) { Serial.print("readI2c"); Serial.flush(); Wire.beginTransmission(_i2caddr); Wire.write(register_addr); Wire.endTransmission(); Wire.requestFrom(_i2caddr, num); int i = 0; uint8_t limit = num; while(Wire.available() && limit--) { Serial.print("r"); Serial.flush(); buffer[i] = Wire.read(); i++; } }54706 MCO:SLP:WUP=1 | 54706 54706 TSF:MSG:READ,0-0-14,s=0,c=1,t=16,pt=2,l=2,sg=0:0 54706 TSF:MSG:ACK 154706 TSF:MSG:SEND,14-14-0-0,s=0,c=1,t=16,pt=2,l=2,sg=0,ft=0,st=OK:0Now the freeze is clearly before entering the sleep function ..
but then .. on another round ..
| 56623 56623 TSF:MSG:READ,0-0-14,s=0,c=1,t=16,pt=2,l=2,sg=0:0 56623 TSF:MSG:ACK 156623 TSF:MSG:SEND,14-14-0-0,s=0,c=1,t=16,pt=2,l=2,sg=0,ft=0,st=OK:0 readI2creadI2cgot # from slave: 1 r78987 MCO:SLP:MS=16,SMS=0,I1=1,M1=3,I2=255,M2=255 79052 MCO:SLP:TPD 79069 MCO:SLP:WUP=1 | 79069 79069 TSF:MSG:READ,0-0-14,s=0,c=1,t=16,pt=2,l=2,sg=0:0 79069 TSF:MSG:ACK 179069 TSF:MSG:SEND,14-14-0-0,s=0,c=1,t=16,pt=2,l=2,sg=0,ft=0,st=OK:0 readI2cSo .. your tip was very good .. it seems to be related to the
Wire.beginTransmission(_i2caddr); Wire.write(register_addr); Wire.endTransmission();-call .. only one questions remains .. why was it working perfectly on the stable library?
Just to be sure I will run exactly the same code in a non-stop loop with the stable library ..
-
@tekka said:
AVR board def
What do you mean with AVR board def?
https://forum.mysensors.org/topic/4999/latest-git-snapshot-causes-freezes/17
I am using an arduino pro-mini china clone (328p) with 8mhz internal oscillator and DIV_8 fuse.
The bootloader is an "APM Optiboot 1Mhz" .. cant find the link right now.
-
@tekka said:
AVR board def
What do you mean with AVR board def?
https://forum.mysensors.org/topic/4999/latest-git-snapshot-causes-freezes/17
I am using an arduino pro-mini china clone (328p) with 8mhz internal oscillator and DIV_8 fuse.
The bootloader is an "APM Optiboot 1Mhz" .. cant find the link right now.
-
btw .. the "old" library is running happy for 6 minutes now ... still continuing
TSP:MSG:READ 0-0-14 s=0,c=1,t=16,pt=2,l=2,sg=0:0
1TSP:MSG:SEND 14-14-0-0 s=0,c=1,t=16,pt=2,l=2,sg=0,ft=0,st=ok:0
readI2cgot # from slave: 1
r | 373997
TSP:MSG:READ 0-0-14 s=0,c=1,t=16,pt=2,l=2,sg=0:0
1TSP:MSG:SEND 14-14-0-0 s=0,c=1,t=16,pt=2,l=2,sg=0,ft=0,st=ok:0
readI2cgot # from slave: 1
r | 374177@tekka: I will try the "new snapshot" with the board defs you mentioned .. standby
-
@1.6.12 board defs
r68550 MCO:SLP:MS=16,SMS=0,I1=1,M1=3,I2=255,M2=255 68599 MCO:SLP:TPD 68632 MCO:SLP:WUP=1 | 68632 68632 TSF:MSG:READ,0-0-14,s=0,c=1,t=16,pt=2,l=2,sg=0:0 68632 TSF:MSG:ACK 168632 TSF:MSG:SEND,14-14-0-0,s=0,c=1,t=16,pt=2,l=2,sg=0,ft=0,st=OK:0 readI2c@1.6.13 board defs
readI2cgot # from slave: 1 r62914 MCO:SLP:MS=16,SMS=0,I1=1,M1=3,I2=255,M2=255 62980 MCO:SLP:TPD 62996 MCO:SLP:WUP=1 | 62996 62996 TSF:MSG:READ,0-0-14,s=0,c=1,t=16,pt=2,l=2,sg=0:0 62996 TSF:MSG:ACK 162996 TSF:MSG:SEND,14-14-0-0,s=0,c=1,t=16,pt=2,l=2,sg=0,ft=0,st=OK:0 readI2c -
hmm..too bad that didn't do the trick..but there was something (and that's an issue which can appear easily when using other libs, "hidden" while) and difficult to reproduce exactly the same case on my side as i'm not using the same radio.
i've dl the latest snpashot. so i will check on my side if one of my sketch is still running fine (with 4ints) and if i get the problem i'll try to debug it too. but i hope to not get it lol :)