Note that I am inviting @cleoqc, (Nicole), to share and comment on this topic when she has the time.
I have been noticing some interesting things happening with Charlie as I have been working on him and began some investigations that resulted in some extremely startling results.
- Pi-4 4gig with latest stable firmware.
- Raspbian for Robots 2019-12-19 with current updates, but NOT the “distribution” update to the latest version of Buster.
- Power provided to the GoPiGo controller board by an external 12v 3A power adapter, (NOT a wall-cube), in place of a battery pack. Note that “dual power” via both the Raspberry Pi’s power connector and the battery connector was NOT attempted.)
While troubleshooting these issues, I attempted both a Dexter software update and a Firmware update to Charlie’s GoPiGo-3 board which is version 3.3.2.
The result was a completely inoperative 'bot and a totally un-responsive GoPiGo controller board.
(The “thunk!” you just heard was me fainting dead away thinking I had killed off Charlie. . . .)
After my wife successfully resuscitated me by applying CPR and an automatic defibrillator she “just happened” to have her pocketbook ( )
. . . .I began immediate troubleshooting steps. (I won’t detail them, just the conclusions.) However, I was seriously considering buying a 'scope and logic analyzer to help troubleshoot this issue.
Results of the investigation:
- Any attempt to update the firmware using a Raspberry Pi-4 results in a completely unresponsive GoPiGo3 controller board and a “detected robot” of “None” on reboot.
- “Unresponsive” means that no LED’s were active at all, including the power LED, the servos were unresponsive, and the /home/pi/Dexter/detected_robot.txt file shows “None”. (i.e. NO robot controller detected.)
- This is true even if the Pi-4 board is completely disconnected from everything else except video, mouse/keyboard, and power through the GoPiGo3’s battery connector when the firmware update is attempted.
- Attempts to update the firmware using a Raspberry Pi-3 always succeeded.
- Note that this was done with a Pi-3 that was completely disconnected from everything else except the controller board, mouse, keyboard, video, and power as noted above.
- Also note that prior to upgrading Charlie to a Pi-4, I had attempted firmware updates using a Pi-3 while fully installed and connected without problems.
- Rebooting after an unsuccessful flash using a Pi-4 requires the power button to be held down until the system completely boots up. Letting it go earlier causes the Pi to loose power as if it had been unplugged.
- Removing the GoPiGo3 controller board from the Pi-4 and installing it on a stand-alone Pi-3, (using the same SD card), results in the same unresponsive behavior on reboot , including the need to hold down the power button to fully restart the Pi.
- Re-flashing an unresponsive GoPiGo3 controller board’s firmware from the software updater, while attached to a Pi-3 board, appears to return the board to full functional status.
- If it works like a 'bot, walks like a 'bot, swims like a 'bot and quacks like a 'bot, I’m assuming that it IS a fully functional 'bot.
- After re-flashing the firmware using a Pi-3, reattaching it to a Pi-4 works as expected.
- The only difference visible to me is that the updater uses a "rpi-2.cfg file after identifying the Raspberry Pi board as a Pi-3 and it uses a rpi-4.cfg file when it identifies the board as a Pi-4.
I have not done any further troubleshooting or investigation yet.