Very hot components with External Power Supply / Power over Raspberry Pi

Is that the “new” new board or the “old” new board?

Totally agree. And the “magic sauce” usually ends up being something so insanely trivial that it escapes notice. Or something any sane person would consider totally unrelated.

Case in point:
Remember the gentleman with a Pi-2 who couldn’t get his 'bot to run properly on WiFi?

He just received a Pi-3, installed it, and tried to use Etcher on the Mac to burn it. It fails miserably with an apparent blown flash. Consistent and repeatable.

He was eventually able to execute a “raw” dd on his Mac to get the SD card working.

I have seen the exact same thing using Etcher on Linux Mint 19.3.

Any attempts to flash a Dexter/Modular Robotics image file containing a truncated file system image using Etcher within Linux Mint also fail, producing a SD card with an unusable system.

“normal” un-truncated images usually work well.

I think part of the fact is that Etcher, (when run on anything else but Windows), is less comprehensively tested and/or supported, and the non-windows Etcher versions appear to trash file images that have a truncated or damaged filesystem image. (At least this is true for M.R. images.)

Why this should be true is beyond my understanding.

“In theory” Etcher is simply a manifestly civilized “dd”.

Then again, “theoretically” it is impossible for bees and wasps to fly. :roll_eyes:

N.B.  Actually no longer true.
I just had several ideas that might be the reason why, and they may have absolutely nothing to do with either Etcher or the Modular Robotics images. More research is needed.

I am planning to continue researching this when I get out.

I might try to get myself an inexpensive Mac system to test with. However that’s as much of an oxymoron as an “inexpensive Ferrari to teach Driver’s Education”

1 Like

Note:
I am updating this topic with the latest findings so that anyone who finds it while searching will get the best and latest information.

Ref:  My post at:

The actual issue appears to be the fact that the original poster was feeding the GoPiGo through both the GoPiGo’s 12v connector AND the Raspberry Pi’s 5v input.

This can cause a condition where the Raspberry Pi is “overdriving” the GoPiGo controller board by providing a higher +5 voltage than the board was programmed to provide.

When you do that, the IC that generates the +5v from the +12v works “backwards” and sucks current instead of providing it.

This can cause components on the GoPiGo board to overheat and/or cause the 12 voltage to rise dramatically.

I discuss the solution to this problem over at the thread referenced above.