I mentioned in the last post that occasionally the SqueezePi would not boot up. The behaviour seemed very random, so I initially suspected my soldering, or power supply issues. But after a morning spent checking and cross-checking both thoroughly, I found nothing of concern.
Then while digging into GPIO information for another project (more to come in a future post on this) I learnt that some versions of the firmware will boot into ‘safe mode’ if GPIO3 is held low on startup. Hmmm… one of my rotary encoders (for volume) in the control panel connects to that pin…
After some careful positioning of the rotary encoder and gentle probing with a multimeter to achieve GPIO3 held low, I was able to replicate the bootup failure every time. Plugging in an HDMI cable showed the Pi was booting partway, and the video output signal was low resolution (640×480). Further adjusting the encoder to ensure GPIO3 was connected high allowed perfectly stable boot every time. Culprit found!
The random behaviour of this issue was purely because of what position the volume control was in on boot. This meant that you could on one day have the SqueezePi working fine and turn the volume up or down while listening, then on the next boot it wouldn’t start. Accidentally knock the volume control while trying to sort it out, and it would ‘magically’ start booting again.
PiTFT and Upgrading Firmware Challenges
So to resolve this, I decided to see about upgrading the Pi firmware and Raspbian version in the SqueezePi. But because I’m using the prebuilt kernel modules for the Adafruit PiTFT touchscreen, options are limited as Adafruit package up the modules with an entire kernel. Fortunately the latest version at the time of writing is new enough not to have the safe mode boot check, so I went for that.
Lo and behold… booting became reliable, no matter the volume control position. However there was a not-so-nice and very obvious side effect – every time the screen updated, very audible noise was emitted from the speakers. And the screen update speed was visibly slower.
Rolling back to the previous firmware and kernel I was using fixed both of these issues (see here on Adafruit) – but means exposure to the safe mode boot scenario.
What to do?
Well, the situation still stands – I haven’t gone into this further, and both Adafruit and notro (who did the PiTFT work) don’t currently have an answer. I’m sticking with the older firmware, and have just found out that there’s a config.txt option to force safe mode to be ignored so I’m going to try that for now.
EDIT: I’ve tried the above ‘ignore safe mode’ option, and it works. So I’m going with that and the earlier firmware for now.
(c) 2014 Nicholas Tuckett