I’m having an issue with an older GrovePi (non plus) with the RPi B+. Many sensors don’t work, including the Temp and Humidity Pro sensor, which is the main one I’m interested in. After performing some troubleshooting steps, I think I’ve localized the issue to the ATmega328p-pu (which isn’t soldered onto the board – the older ones push into a socket and are replaceable).
For example, when I try to update the firmware, I get the following error:
avrdude: initialization failed, rc=-1
Double check connections and try again, or use -F to override
this check.
This error repeats 4 times.
Does this mean the ATmega328p-pu is fried? If so, would buying a new one (eg:P here fix my issue, or would I have to flash the firmware on any new chip separately using some other method?
I’m a CS student, but not well versed in microchips, so feel free to suggest other troubleshooting steps.
Many sensors don’t work, including the Temp and Humidity Pro sensor
What do you mean they don’t work? Like you don’t get any response back on the Pi? If so, then it means the firmware is not yet flashed.
Second of all, do you have anything connected to your GrovePi (to the Grove ports or to the Pi’s headers) that might affect the flashing process? More often than not, that’s the case. And at this point, it’s quite hard to consider the GrovePi fried.
When I try to run the grove_dht_pro.py file, which is as I understand it designed to test the temp and humidity sensor, I get the following repeated infinitely:
temp = -1.00 C humidity =-1.00%
I plugged the sensor into Digital port 4 and modified from blue to white on line 53 as described.
If I understand correctly what you mean by “flash the firmware”, I executed the firmware_update.sh file and I got the following error repeated 4 times:
avrdude: AVR device not responding
avrdude: initialization failed, rc=-1
Double check connections and try again, or use -F to override
this check.
avrdude done. Thank you.
I don’t have anything connected to the GrovePi other than a USB Wifi stick, and the temp and humidity sensor.
Also, here is the log from the complete_test.shfile, in case it helps. log.txt (6.0 KB)
The test file clearly shows that the GrovePi is running just fine which means, it’s not bricked. If the GrovePi responds with an 0x04 address to i2cdetect -y 1 command just as it did in the test file then it works.
Next, I would check the version that it reports back with grovepi.version() function call and if that returns 1.2.7, then there’s something bad with the sensor or at least that’s how it looks like. We’ll go deeper into this if it’s the case. Let me know what the call returns.
Following that, I would try burning the firmware by having the GrovePi completely removed from the Raspberry Pi and instead, connected to it via jumper wires.
I think everything you need to know on how to burn it the other way can be found in this thread:
I’ll run grovepi.version() when I get home. I’ll also explore burning the firmware with jumper cables. Is that using the process you describe in the comment that begins "So let’s program the GrovePi with some jumper wires instead.” on that thread?
Also, so I can learn, why isn’t burning the firmware the normal way working? What causes this to happen?
Hi Robert, I ran grovepi.version() by creating a python file as such:
import grovepi
grovepi.version()
I run it (python test.py) and get the following error:
Traceback (most recent call last):
File "test.py", line 2, in <module>
grovepi.version()
File "/home/pi/Dexter/GrovePi/Software/Python/grovepi.py", line 266, in version
return "%s.%s.%s" % (number[1], number[2], number[3])
TypeError: 'int' object has no attribute '__getitem__'
The problem you’re facing right now is that the GrovePi is loaded with an older firmware (specifically the 1.2.2 as put in light by the log you had provided) and my guess is that there’s a cold solder joint somewhere on the board, though I’m not entirely sure, that disrupts the ISP connection that’s used for flashing the firmware.
The reason I have shown you that thread is to test and see if flashing the firmware by using different routes (with jumper wires as opposed to using the circuit on the GrovePi) solves the problem. If it does then it means there’s clearly a problem with the GrovePi’s circuitry and it needs to be replaced.
Just to be fully sure of what reply you need to follow for flashing the firmware this other way, here’s the post:
And yes, it’s that one that you have asked me about - seems like there’s a bug with our Wordpress where clicking on the shared link doesn’t take you to that post, but to the website’s index, so that’s why I have shared it again.
Speaking of which, did you succeed in flashing the firmware with jumper wires?
