Misbehaving hardware? Try swapping cabling or clearing settings

-September 11, 2017

Apple, I think I owe you an apology (longstanding readers can imagine how hard it is for me to write those words ;-) ). Back in May, I told you about a Thunderbolt interface failure with my mid-2011 model Mac mini, which at the time I believed to be the result of an operating system migration to Mac OS 10.9 "Mavericks." I've subsequently migrated that same system to Mac OS 10.10 "Yosemite" in order to dodge even more applications' support deprecations (AgileBits' 1Password, to be specific, along with an eye to a pending migration from Microsoft Office 2008 for Mac to Office 2016 for Mac, the latter requiring "Yosemite" at minimum).

The O/S upgrade went smoothly, at least on this particular system (keep reading) as well as the other two sitting in my office (a mid-2011 13" MacBook Air and a mid-2010 13" MacBook Pro). And after it was concluded, on a hunch I decided to try out Thunderbolt again. As I documented in that earlier writeup, I'd been forced to retire the Western Digital Thunderbolt Duo, replacing it with two Seagate GoFlex Desk for Mac devices paired to each other (and to the Mac mini) over Firewire 800 cabling. After disconnecting the Seagate drives and disconnecting them from their Firewire docks, I mated them to their Thunderbolt dock alternatives and tethered the first one to the Mac mini.

The GoFlex Desk for Mac fired up just fine, and survived multiple sleep-and-wake and reboot cycles with aplomb, as did the LCD connected to its second Thunderbolt connector via a DisplayPort-to-HDMI adapter. So I re-added the second Seagate drive in series: same positive result. Feeling bullish, I then swapped out both Seagate drives for the Western Digital Thunderbolt Duo ... and everything still remained stable through sleep and restart cycles alike. Obviously, whatever Apple broke in "Mavericks" it had subsequently fixed in "Yosemite," right?

Maybe not. Three decades' worth of engineering has, if nothing else, given me a healthy dose of skepticism regarding things that seem too good to be true. Looking closely at my setup, I realized that I was now using an Apple 0.5m Thunderbolt cable to connect the computer to the drive(s), versus the 2m cable I'd previously been employing. When I swapped out the 0.5m cable for its 2m precursor, all the previous issues re-emerged. I can't say for sure what the root cause of the problems is; this 2m cable had served me ably for many years. It still works fine when I hot-plug it, so the failure isn't "hard;" it only fails to continue to function after the system undergoes a sleep or reboot cycle. And since copper Thunderbolt cabling is spec'd to work to 3m, length likely isn't the culprit, either. While writing this post, I've just remembered that copper Thunderbolt cables contain active circuitry in the connectors; perhaps this is what's going bad.

Now for the "clearing settings" portion of this post. My wife currently runs a combination of Mac OS 10.7 "Lion" and 10.8 "Mountain Lion" on her two laptops, and she's also interested in getting Office 2016 for Mac installed on them, specifically for its native Google calendar and contacts support. I first tackled her mid-2013 11" MacBook Air, at the time running "Mountain Lion." I ran the "Yosemite" upgrade installer, which rebooted the system and began doing its thing ... until about halfway through the update process, when I saw this (I've obscured the system's reported serial number for privacy purposes):



Rebooting the system only led to an auto-launch of the O/S update attempt, with the same incomplete end result; the system's HFS+ partition was no longer usable as normal. Fortunately, by instead launching into Recovery Mode, I was able to restore full system functionality by restoring from Time Machine backup, but that still left me stuck on "Mountain Lion." Googling the PPM002 reference code led to discussions from lots of other folks who'd also encountered the issue during O/S upgrades. Apparently, beginning with "Yosemite," Apple had instituted more stringent hardware checks as part of the update process ... unfortunately, however, in the middle of the process, rendering the system DOA if the tests failed.

Many folks who'd seen a PPM002 error had previously done system memory upgrades using third-party modules; they'd subsequently been able to eliminate the error, thereby enabling the update to complete successfully, by temporarily swapping back in the original Apple-branded DRAM. That fix didn't apply in my case, unfortunately; the MacBook Air was running its original memory, which to make matters worse was soldered down on the motherboard, versus being in removable/replaceable module form. And the system was nearly a year beyond its extended warranty coverage period, so I was looking at a pricey repair bill.

While on the phone with Apple Support, preparing to plead for an out-of-warranty exception, I had an idea; what would happen if I tried resetting the SMC (system management controller) and NVRAM (nonvolatile random-access memory, formerly referred to as PRAM for parameter RAM)? I'd done so in the past on other systems to alleviate various wonky behaviors; I hadn't ever come across references to it fixing this particular problem, nor had the Apple rep on the other end of the phone, but she agreed that it was worth a try and regardless of the outcome, wouldn't make things any worse. So I did both reset sequences in sequential order, then ran hardware diagnostics ... and the formerly reported memory error was no more. Re-running the "Yosemite" upgrade once more produced a successful outcome this time, as well.

The seminal (at least for engineers) TV series IT Crowd frequently featured a staff member asking someone on the other end of the phone, "Have you tried turning it off and on again?":



While that particular bit of wisdom didn't apply in either of these cases (although it certainly has worked for me plenty of times in the past), its simplistic equivalents "Have you tried swapping out cables?" and "Have you tried clearing the error codes?" came through with aplomb in these situations. Before concluding that an intensive (and expensive) solution is your only option, make sure you exhaust all of the more elementary alternatives first. You might be surprised, as I was!


Brian Dipert is Editor-in-Chief of the Embedded Vision Alliance, and a Senior Analyst at BDTI and Editor-in-Chief of InsideDSP, the company's online newsletter.


Also see:

Loading comments...

Write a Comment

To comment please Log In

FEATURED RESOURCES