I’m using a Grove Pi+ to run some grove sensors (temperature, light sensor, that sort of thing).
We are having an issue when something causes the RST light to turn on. I can trigger the light turning of and off by connecting/disconnecting sensors when the Pi is powered up.
The issue we are having is that once the RST light turns on, we are then unable to read an data. We have the same issue if we then trigger the RST light to turn off. Rebooting the Pi does not seem to work, is there a way to reset the Grove Pi+ so that we can resume reading data?
I have the same problem with GrovePi0 (basically GrovePi+ for Raspberry Zero).
It mostly works fine, but on random times it goes into some kind of error state and only poweroff helps.
This is a huge problem though, because my board is located far from me.
Any help is much appreciated!
A quick and dirty fix is to basically reset the GrovePi with avrdude. You can do this by issuing this command:
avrdude -c gpio -p m328p
Second of all, we know the v1.2.7 has some bugs, so we suggest you give a shot to our beta version, the v1.3.0. It has a lot of things fixed, so maybe this is your ticket to an error-free environment. If not, please let us know about it and we’ll have it fixed.
To find out about the documentation on this beta version and to see how to install it, follow this post here:
Which by the way, can you tell us how often that happens for you?
Hi @RobertLucian, thank you for the tips!
Now after an extremely long time I can finally get back to you on this matter.
I have one Raspberry running with GrovePi+ that also occasionally goes into an error state (only twice this year, although it is reporting sensor data 24/7) and there the avrdude fix works perfectly.
The other Raspberry is running with GrovePi0. It has also been reporting temperature and humidity data 24/7 for months now.
And now it happened again. I can not get it to work with the avrdude command line, although the output of the command says that it was successful:
avrdude: AVR device initialized and ready to accept instructions
Reading | ################################################## | 100% 0.00s
avrdude: Device signature = 0x1e950f
avrdude: safemode: Fuses OK
avrdude done. Thank you.
But my program (crazy, I know, but I’m using java with Pi4j) can’t connect to Grove board. I tried to see whether the operating system sees the board with
I must admin I was unable to update the software on GrovePi0 board, but would it help against the board not being detected at all?
Previously the problem happened has happened couple of times in a row and I thought it was caused by the Raspberry not having enough power to feed 3G modem, GrovePi0, DHT22 and SHT31 sensors.
But now the problem happened after months of stable running.
Thanks for the advice!
Are you still having issues with the GrovePi0 when flashing the firmware? I gotta be honest, I still haven’t tested the 1.3.0 on the GrovePi0 as I had so much on my plate recently, but the firmware should work on it as it does on the GrovePi+.
Also, are you absolutely sure the I2C/SPI interfaces were enabled? There’s a small chance of this, yes, but still, it’s better to be safe than sorry. If you’re encountering this, can you reset the GrovePi? You can easily do this by issuing avrdude -c gpio -p m328p and then try reflashing the firmware again.
And also, do you happen to have a logic analyzer by your side? It would be interesting to see what’s going on these lines.
I’m interested in hearing more about your problem so that we can make the GrovePi more stable in the long run.
Thanks for the reply!
I double checked that I2C/SPI interfaces are enabled via raspi-config - yep, both are still enabled, as the system was stable for at least a couple of months.
My only wild guess is that maybe RPI Zero is not able to provide enough power to feed GrovePi0, DHT22 and SHT31 sensors, 1.12" OLED and a 3G modem stick (Huawei-E173s). What do you think - would it be worth to try feeding 3G stick directly from the PSU?
Unfortunately I do not have a logic analyzer, but I will try to update the firmware and let you know!
I did not tag you in my previous reply .
I tried to do a software update now as described in the 1.3.0 pre-release forum post. Updating itself seemed to go well (at least avrdude was showing progress of writing the new firmware), but checking the version failed:
>>> import grovepi
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File "build/bdist.linux-armv6l/egg/grovepi.py", line 291, in version
File "build/bdist.linux-armv6l/egg/grovepi.py", line 198, in write_i2c_block
IOError: GrovePi is unreachable
Is there any other way to reset the GrovePi0 board besides avrdude -c gpio -p m328p. Powering off did work last couple of times, but as my setup should work out of reach in the future, I desperately need to get it working without physically going there powering off the system
Okay, this is something new: having that many devices could theoretically make the Raspberry Pi Zero (W) behave in a weird manner.
If you don’t happen to see the GrovePi device when issuing i2cdetect -y 0 command, which can be found at 0x40 address, then that means there’s a problem with the Raspberry Pi or there’s a connection problem between the GrovePi 0 and the Pi i.e. bad electrical contacts.
Are you implying that you have added these devices recently after letting it run successfully for months? If so, can you disconnect them (I’m mainly referring to the OLED screen and the 3G modem) and see if the GrovePi shows up after a power cycle? I know for a fact that cellular modems are power hungry and this could take away power from the GrovePi. The target here is to come up with the minimal setup that has a working GrovePi0 and then gradually add in other devices/components.
Furthermore, you can run avrdude -c gpio -p m328p from far away, provided you have a remote connection to the said Raspberry Pi. You don’t need to be there - still, I’m pretty sure you don’t have to resort to this method. And to answer your question, there’s no other method I can think of that would reset your GrovePi remotely.