Bricked my new AMD 7040 with the wrong BIOS update

Bummer… Probably best to see if Support can help you out then.

Thank you all for your help. I will wait for the supports advice…

I’m guessing you’re not in the US–

–and especially not in the central/midwest of the US. But even so: I’ve got the requisite tools and would be happy to help recover your machine if you do happen to be. :slight_smile:

3 Likes

@DHowett Thank you for your offer. I’m in Germany and have no recent plans to travel to the US unfortunately.. :wink: FW Support has asked for the LED Codes and I’m slightly optimistic, they have an idea how to fix the board

2 Likes

Short update: (first level?) support has no substantial idea how to fix the issue. They ask me for checking the connections and try again to update BIOS according their description from the website.

Seems to me they don’t escalate the ticket to their experts :neutral_face:

My guess is I do need to ask for a new board… :sad_but_relieved_face:

Quite frankly that’s on them if they allow you to install the wrong freaking bios without any guardrails.

1 Like

Hi @DHowett

We know how to flash the correct EC code. Do you know how to flash the correct PD code?
Fixing those would at least get battery charging working and the keyboard/trackpad working again.

It should be possible, though I’d need to do a bit of research into how exactly to do that.

Probably something to add to ectool.efi.

1 Like

@James3 I can’t find anything about the CCG5 or CYPD5225[1]’s I2C protocol outside of the docs in the EC repo itself.

However, I had a thought. I think the PD controllers in use across the Framework product line are all fairly similar. Maybe some tweaks here and there, but they all use the same protocol. They also use the same addresses on these two platforms.

There’s another chip, though–the isl9241–which is implicated as the “charger”. It looks like it is handled differently between azalea and lotus, even though it also has the same address and is on the same I2C bus.

I might recommend starting with reflashing the latest Azalea EC firmware, with either of our EC tools[2]. :slight_smile:

That may bring charging and AC power back online. We can go from there.


  1. the EC firmware mentions CYPD5525, but I think that’s a typo. No such chip appears to be documented. ↩︎

  2. with my fork, if you run ectool.efi reflash -f -f it will ignore all power constraints and board checks (!) and just power through. ↩︎

3 Likes

@DHowett appreciate your helpful hint. :+1: I think it would be a great step forward, getting back AC power.

Recently I’m strongly occupied by my job. Therefore I can’t check very quickly. I do think I can work on the BIOS thing not before tomorow afternoon… German time :wink:

@DHowett

I think maybe a good first step would be:
a “ectool version”, or similar to find out which exact EC firmware is being used.
If it says “lotus” (FW16) then maybe load a good “azalea” (FW13) version into the RW image.
Do a ectool / sysjump to running the RW image, and see if one gets AC charging back.
One can then always fall back to the existing RO image if the RW does not work at all for some reason. Note, the user has USB keyboard working, so we need to be able to role back to that point.
If the RW image gets AC charging working, we don’t have to worry about the PD firmware for a bit.
The RW image will probably get the keyboard working as well.

Well, the above is what one could try, but I am rather risk averse, so I would probably wait for FW to fix it instead.

The “ectool version” is not risky at all, so it would be interesting to know how thorough the fateful BIOS got.

Main problem there is probably that the fw13 uses smart i2c power muxes connected to the ec and the 16 uses plain mosfets for power muxing so while the negotiation may work the wrong firmware won’t be able to actually enable charging from a port. I do hope the pd-controller trying to drive a mosfet that isn’t there doesn’t cause any other problems.

The 16 has bypass mode wired and the 13 doesn’t, otherwise they are pretty similar. The 16 has the 48v buck converter in front of it though.

1 Like

We are literally in exactly the same situation right now. Brand new Framework 13 7040 we are setting up for our employee. After Windows install and BIOS update it boots into that “Expansion Bay Cable improperly connected” error message.:face_with_diagonal_mouth: We managed to boot into Windows with a quick press on power button, but once in Windows internal or external USB keyboard do not work. We’ll try usb dock next to see if we can recover it.

But it seems like there might be something wrong with Framework’s files.

I connected USB dock and was able to use external keyboard. But it’s not charging.

I extracted firmware and updated Flag=1 to 4 as discussed in Comment 13 alas it failed with “EFI Error 21” just like in Comment 19 :frowning:

I also created Please implement stronger verification of Laptop BIOS model. · Issue #127 · FrameworkComputer/SoftwareFirmwareIssueTracker · GitHub

1 Like

cat anyone who has a bricked F13 AMD, try “ectool version”.
I am curious what firmware the EC thinks it has got.
Also, maybe “ectool console” to see what is happening when one plugs in a PSU.

Has anyone heard back from FW support yet?
I was expecting them just to replace the mainboard, or provide a “fix” firmware image.

I can try. What is it and how to use it?

So far they are telling me to perform the usual motherboard cover switch reset dance. I’ll try that on Monday and will see how it goes.

Sorry, since this is not expected behavior (flashing the wrong BIOS is normally impossible), support didn’t know what to do, except provide the regular debugging steps.

We have escelated the support cases to engineering and will investigate as soon as possible.

4 Likes

@Daniel_Schaefer
If framework could provide the source code to the tool that updates the PD chip, it would then be pretty easy to get this user back to a battery charging state. They could at least work with that until FW provide a recovery bios.
We already know how to update the EC.
Updating both EC and PD firmware will restore charging.

Also, i hope FW have removed the firmware file causing this problem from their web site.

Update: Framework sends me a replacement motherboard. After installation of the new board FWL 13 loads via AC, but now there is a new issue. The Laptop wrongly detects a closed lid in very short sequences. Pressing any key will wake up the laptop from suspend then.

I’m a little bit tired be all these circumstances and efforts I’ve done for this laptop - especially with no end in sight…