On paper one reset is as good as it gets, though for reasons I’ve never completely understood there have been rare occurrences when a redundant reset provokes a different response than a single one. Thinking back to ACMT training I don’t believe Apple ever specified more than one reset, but at our AASP it was something we passed around as anecdotal lore and once in a blue moon it would actually make the difference. Searching around I can’t find any theory corroborating this that isn’t similarly anecdotal (
https://www.cnet.com/news/margin-note-why-are-three-chimes-recommended-for-a-pramnvram-reset/) but I’ll throw in a couple hypotheses:
1. The PMU/SMC is frozen/erratic due to a particularly borderline battery voltage, such that the CUDA switch or SMC reset only stalls it again, however a few rapid cycles of the charging circuit bring it above the operating threshold. (In this case NVRAM wasn’t the core problem and is only needlesly reset as a byproduct.)
2. Some nearly nonexistent corrosion/residual moisture exists somewhere and is causing the PRAM reset process to intermittently fault or the NVRAM to re-corrupt. Most of the few times multiple resets worked were on machines with suspected liquid damage that we thought was probably cleaned in time not to leave long-term damage. Recycled junk laptops were useful as shop machines if they could be revived, so on a slow day I found it fun to throw a few together and see what would happen. I used a half dead USB keyboard and modified it to permanently hold the PRAM keys, so on the machines that hadn’t responded to three or four resets I’d just leave it cycling for a while. I think it worked a couple times a year, and I can’t say whether it was 10 resets or 620 resets that finally poked what needed to be poked. Despite being permanently labeled as iffy, they typically stayed revived after this (one I still make use of over a decade later.) If it was ruined to the point of trash anyways, the solution wasn’t likely to be cleanly explainable. Maybe NVRAM legitimately changed, maybe not.
3. A couple capacitors (probably PSU) are marginal enough that a cold start stalls the process of warming them up before they can drift into tolerance, but the rapidly changing load pushes them over the line and the system can begin operating (again, not actually an NVRAM issue.)
4. Weirdo undocumented behavior. E.g. the keyboard-folio that came with my TAM resets most of the variables in its NVRAM (not the device tree [sonnet patch] but yes volume/brightness/AppleTalk,) and refuses to set it to OF mode, while plugging in an AppleDesign keyboard resets all of them and happily allows OF. I think
@cheesestraws mentioned after I brought it up that his TAM keyboard behaves differently than an AppleDesign too, but also differently than mine (apologize if I’m remembering that wrong.) This isn’t a case of multiple resets mattering, but anecdotal proof that not every case is documented.
All this said, the chances that a PRAM reset will fix your problem rapidly approach absolute zero within the first three to five. Beyond that you’re probably hoping for a bandaid from heaven. All depends on how much spare time you have, I guess.
.
