Hacker News Reader

Comment by glitchc | Hacker News Reader

Neat find. What could cause the calibration offset to be zero? Certainly it did not come this way from the factory. Any abuse/misuse of the controller would not cause it either.

Ah, I suspect this was a firmware update that got borked somehow. Maybe the cable was disconnected before the update could complete.

View on HN

> What could cause the calibration offset to be zero?

A possible explanation can be found on part 4 of this post:

> [...] if the checksum is not valid, there is a loop that clears out the flash [...] I suspect (but haven’t tried yet) that if the battery of the controller dies while it’s writing on the flash, at the next startup the checksum does not match and the DS4 gets totally messed up like this one.

That is, according to that theory, it was trying to write something to the flash (perhaps while pairing?), and part of the write failed because the battery died. On the next boot, it detected a wrong checksum, and erased everything.

Thanks for that, I missed it in TFA. But ouch, that feels like an extreme design choice. What's the logic here to erasing the flash on a failed checksum, or requiring a checksum in the first place? Is there a non-obvious security threat?

The issue is probably a missing A/B firmware update for the config section.

If a firmware update needs to alter the calibration data or other rather static config, and that update process is interrupted by an empty battery then it can't recover. It should of course be more conservative in killing all of the config section... Or could reset to some sane default. Or have a copy of the old known good data around and restart the procedure

A properly made device would at least keep a spare copy just in case, there's more than enough space in flash for that, but no, Sony wants to sell more controllers.

I'd wager a bad/worn NAND block, 'cosmic ray' or other electrical glitch was more likely to cause a checksum issue than anything else. It might be sudden battery disconnect caused due to the controller being dropped (per the first page), but there should be local capacitance on the NAND supply voltage size to last a page write cycle as sudden power loss is going to happen in a lot of situations.

I would generally critique the use of a checksum on this config data without a backup or ping-pong writing system specifically because in the case of a 1 bit failure on something critical like cal or configuration data, really you want the data anyway and just hope that the 1 bit wasn't that important and also be ok if the bit flips back again on the next go around.

Reply on news.ycombinator.com