In my last post I had just discovered a version of the Gertduino manual that includes a schematic diagram. It turns out that that version of the manual ( is "version 1.3 Dated 6th Nov 2013", whereas the version without the schematic, pointed to by the element14 Gertduino page at is "version 1.4 Dated 6th Nov 2013" ( I'm not going to speculate about how that may have happened or what differences there may be between version 1.3 and version 1.4 (other than the missing schematic). Rather, I'm just going to be content with having found the schematic and leave it at that.


But also in my last post there was an unsolved mystery, namely why did one of the LEDs remain lit after I had successfully uploaded the Blink example program via the Arduino IDE. Strangely (and discomfortingly), that problem somehow solved itself overnight. I swear that I did not touch anything, change anything, or fix anything. It simply stopped being lit up all by itself. I hate when that happens. If something unexplained has happened, then in the future something else unexplainable is bound to happen.


Having the schematic at hand has not shed any light on the mystery of the errant LED (sorry for the bad pun) - or has it?


The good news is that I can reproduce the problem (sort of). The Blink example program makes it easy to change the Arduino output pin number of the LED to be blinked, recompile, then upload and test the changed program. So I've tried blinking each of the LEDs one at a time. In fact, I've become quite adept at using the IDE's Ctrl-Shift-U shortcut for uploading the sketch via the GPIO programmer interface. What I've discovered so far is that, depending on the timing of the blinking of LED5/diode D9/pin 5 and the upload of a revised program to blink LED0/diode D5/pin 13, I can sometimes get into a state where LED0 is blinking while LED5 is solidly on.


So, what could cause that to happen? Do I have a bad solder joint? Some stray capacitance on the board? A not-quite-in-spec ATmega328P pin?


Referring to the schematic, it turns out that the LED buffer chip is none other than a M74HC14TTR (, a Hex Schmitt inverter. And LED5 turns out to be connected to ATmega328P pin PD6/OC0A/AIN0. So at least I have a clue as to where to look, if I should want to get my hands dirty, that is. Alas, my oscilloscope is sitting patiently on a bench at my local makerspace (, while my Pi and the Gertduino are hanging out on a desk at my home, and the scope probes are simply not long enough to reach across that distance.


My best guess is that it will turn out to be something to do with the voltage coming off of the ATmega328P pin somehow sitting on the hairy edge of the 74HC14's hysteresis band and not quite having the oomph to drag it down far enough to have the inverter output a logic high to turn the LED off. Maybe there's something special about pin PD6/OC0A/AIN0 that warrants a close examination of all 660 pages of the ATmega328P's datasheet ( to understand.

But (he wondered, wonderingly), wait just one minute - shouldn't the unused ATmega328P pins be floating in a high-impedance state, rather than being pulled down to ground? Unless I missed them, I don't see any pulldown resistors on those pins. So I guess that I shouldn't be surprised that one of the pins is floating high. Rather, I should be surprised that some or all of those pins are not floating high.


Whatever the proximate cause of the problem may be, at least the schematic has provided some useful clues, but I'm going to ignore them for now and move on. OK, arguably that's prima facie evidence of a serious character flaw, no doubt related to the one where, if I happen to hear a strange noise coming from my car while I'm driving it, my typical response is to turn up the radio volume so that I no longer hear the noise. I can usually get away with that with the car, and hope to get away with it when working with the Gertduino, but I'm absolutely certain that I should have no business getting involved with, say, airplane piloting.


But, speaking of mysteries, with all of the compiling and uploading and LED blinking that I've been doing, occasionally I'll run across an evil error message such as the following:


avrdude: verification error, first mismatch at byte 0x0054 0x0c != 0x06

avrdude: verification error: content mismatch


I'm not the first one to run into that problem (for example, see and - the usual recommendation being to upload via the "Upload Using Programmer" command from the file menu and not the normal upload button, however that's what I've been doing. The message is clearly evidence that some sort of problem has been encountered while doing the upload.

I'll keep an eye on it. But right now my plan is to turn up the radio volume and keep driving.