Hmm, the web page says SOIC-8 (and some other things, I guess), and my WSON-8 test clip doesn’t fit. Is it because it’s a WSON-8 6x5 instead of a WSON-8 6x8?
That’s just a list of the packages that the chip is available in. It can be bought is any one of those listed.
I have a mixed update. It took a few weeks for the WSON-8 6x5 test probe to arrive, but it came yesterday. I was able to use it to pull the contents of the flash closest to the EC on the bottom side of the mainboard, and the first 0x80000 bytes exactly match what ECTool pulled in its backup, so that looks good.
The other two flash chips on the bottom have what appears to be other firmware for some other components. Both have very different contents and none of them match the ECTool backup, so I’m just going to leave them alone. If someone wants, I can post the contents of those chips somewhere.
So, feeling confident I have an escape hatch, I reassembled my laptop, and… it wouldn’t charge or boot. It had been disconnected from battery for like 3 weeks. I was pretty careful handling the mainboard, so I’m not sure what the issue could have been.
I saw some suggestions that I should pop out and in the CMOS battery and try trickle charging it. Unfortunately, I cracked the CMOS receptacle, so Framework is luckily replacing the mainboard for me. When I get that replaced I guess I will get new flash backups and then finally try the flashing.
2 Likes
While I’m waiting for my replacement mainboard, I had a question. Is there any reason why touching the test probe and doing “read” and “verify” operations from the flash programmer could mess up the mainboard? I still don’t know why the first one wouldn’t charge and want to make sure it wasn’t because of my read and verify to create the backup. I didn’t do any erase or write operations.
I can’t think of a reason that would cause a lasting problem. However, if you are using an 11th gen laptop you’re probably seeing the fairly well-known RTC battery bug. Sometimes it requires trickle charging the entire machine (not just the RTC battery) from a 5V source rather than a PD source.
I’m really glad you were able to verify the flash! Sorry that you ended up getting held up by unexpected tech trouble 
1 Like
Mine is 12th gen, so I didn’t think that was the problem. I wasn’t able to trickle charge it with a non-PD charger (or I didn’t wait long enough before I took matters into my own hands and broke the part, oops). Thanks for the response. New board is on the way, so I’ll see how that goes soon.
Well, everything is good now. I received the new mainboard and it works. I was able to use ECTool to reflash the modified EC firmware… had a bug there, was able to restore from backup and fix the bug and reflash again, and now my laptop is working like I always wanted. I ended up not needing to use my backup, but I’m glad I had it just in case, and I’m pretty confident it would have worked.
At some point soon I will write a blog from this because I don’t go through this much angst without producing something out of it, haha. Thank you to all who helped with various information and advice.
4 Likes
I’ve written up the entire process, including the bug fix and some debugging. I link to pictures and flash chip dumps that I uploaded, too.
Thanks again to everyone who helped out on this thread. For @DHowett, I link to a proposed minor feature for ECTool. For the Framework team I list a few recommendations at the end.
6 Likes
This is amazing! Thanks for writing it up, and I’m glad we were all able to be part of the journey!
Ah, and if you submit a pull request for ECTool.efi I’d be happy to give it a look 
2 Likes
Thank you for the effort of writing up this interesting journey!
Concerning the original behaviour that prompted your investigations: oddly, under linux with the 3.17 (11th gen) BIOS I am not seeing the keyboard behaviour you report. Instead I see:
- press “A” – key starts repeating after a short delay
- press “B” - a single “b” appears; starts repeating after (same) short delay
- release “A” – repeating stops, but after (same) short delay, repeating of “b” resumes
- release “B” – repeating of “b” stops (as one would expect)
So either the keyboard behaviour changed somewhere prior to 3.17 or linux handles the key press/release messages differently to produce repeating behaviour from it.
I guess I hope it’s linux; otherwise it’s rather tragic to go on a wild firmware goose chase only to have a firmware update void the work – although it does make for a better story if that were the case; and you (and the community) learned a lot along the way.
Huh, weird. I don’t see the EC firmware having any related updates recently, so I don’t really have an explanation there. It’s possible some of the “typematic” functionality is being handled in OS code, I suppose, so it could have linux-only behavior. I’m okay with how things turned out for me, though. I’m quite happy with my fixed laptop, it’s a good feeling to put a little “sweat equity” into it, and yanno, journey before destination, right?