I have a grovepi+ that keeps crashing. I’m not entirely sure whats going on.
After 6-20h it gets semi-non-responsive, but answers on i2c. The grovepi itself can’t read i2c at this point, but it can communicate when the rpi is the master.
I’ve added watchdog reset to the grovepi code, but it doesn’t help. What is even stranger is that flashing doesn’t work until powercycling:
$ avrdude -c gpio -p m328p -U flash:w:firmware.hex
avrdude: AVR device initialized and ready to accept instructions
Reading | ################################################## | 100% 0.00s
avrdude: Device signature = 0x1e950f
avrdude: NOTE: FLASH memory has been specified, an erase cycle will be performed
To disable this feature, specify the -D option.
avrdude: erasing chip.
...
Reading | ################################################## | 100% 13.47s
avrdude: verifying ...
avrdude: verification error, first mismatch at byte 0x0000
0x0c != 0x00
avrdude: verification error; content mismatch
avrdude: safemode: lfuse changed! Was ff, and is now 0
Would you like this fuse to be changed back? [y/n]
After powercycling everything works fine again, but it seems a bit stupid to have another rpi to powercycle this one.
Should I just write this off as a faulty unit or has anyone else seen anything similar?
Actually, seems I was wrong. It worked before, but now it no longer flashes. (Not even with resetting the fuses again.)
I guess this one is garbage and can’t be rescued.
Problem is that I have another grovepi+ that also keeps crashing, but at least it comes back after a gpio pin 8 reset cycle… so far.
The only stable grovepi I have is now an old GrovePi without +. I guess I can’t get more of those?
Yes, it doesn’t flash anymore even with the fuses reset… Might experiment more on it later.
I used AVR wdt_enable/wdt_reset on a 4s timer, first in the loop() and then in actually receiving an i2c command. http://www.nongnu.org/avr-libc/user-manual/group__avr__watchdog.html
It worked fine and it reset as expected on not receiving i2c commands for four seconds. But it still hangs randomly with no recovering except on a gpio pin 8 reset. It’s very confusing and shouldn’t be possible. (Unless it hangs in a higher priority interrupt and the watchdog still needs to execute an interrupt.)
I suspect it’s because I used relays on it and the grovepi+ can’t handle the electrical shocks. The grovepi-non-plus does fine after soon a year without a single hanging, the one that is running the relay four times a day (curtains) hangs about once every one-three weeks and the one that can’t be flashed now switched relays about once a minute (driving a radiator) and hanged about 1-2 times on 24h. So the relays and grove+/non+ is the big difference. Since I right now only have three it’s not the biggest sample group.
If I have time I will check the power fluctuation when the relay is switching - I got a nice new oscilloscope that I want to learn how to use anyway. Probably not the next days though. (Time…)
Hey Mirar,
There is not a big difference b/w the GrovePi and the GrovePi+ in terms of how it handles sensors like a relay so I am not sure that why you are getting the problem. Since you are working with relays, there are 2 possibilities: 1) you somehow programmed bad fuses on the Atmega328p on the GrovePi and bricked it (we have seen this a few times) or 2) Power fluctuations might have killed the atmega.
It would be great if you could investigate this a bit more with your oscope and let us know what you find.
If you have a hot air rework station you should be able to replace the Atmega 328p with a chip from Sparkfun/Adafruit/Mouser/Digikey and try getting it to work again.
Hey,
We haven’t seen the issue before with the GrovePi. Can you use i2cdetect -y 1 instead of the i2cdetect 1 command. Can you try updating the firmware and software and see if the problem is still there.
