[SUCCESS] Gigabyte Designare Z390 (Thunderbolt 3) + i7-9700K + AMD RX 580

[CaseySJ]

Yeah I tried that. I cant get it to work. The pi keeps crashing on me as I wiggle it, and I can never seem to get the leds "dim".. just on or off.

I may have to wait for a different solution. :/

Try disconnecting the Vcc (power) pin -- which is the 3.3V pin on the Raspberry Pi GPIO header. Just pull that pin out. Wiggle the SOIC8 clip, try reading without the 3.3V pin connected, then connect the 3.3V pin and try again.

Also make sure PSU is turned off or power cable is unplugged from the wall.

 

[jb007]

Absolutely fantastic!!!

So, in light of the massive achievement I've finally disassembled my Z390 Gigabyte Aorus Xtreme from the case, removed the back plastic cover, proceed with trying to read my onboard THB3 chip using my CH341A reader:

View attachment 454827View attachment 454828View attachment 454829View attachment 454830View attachment 454831View attachment 454832

But, I was quite unsuccessful in all attempts...

Even had one attempt with a different message:

View attachment 454833

What am I doing wrong ?

The yellow jumper on the CH341A has to be on these pins, otherwise the USB port created by the CH341A reader doesn't get created in my MBP...

Also, when clipping the reading probe onto the TB3 It seems that I have to align the red "wire" on the cable with the blue pin on the chip, other wise the CH341A does't work again...

Surprisingly the reading probe clips very well on to the pins of the chip, even though there's a copper pipe dissipator very near...

I'm going to read your ** Mini-Guide for Flashing SPI ROM Chips using CH341A Programmer ** again!!

FYI: I'm in UK, where it seems that COVID-19 is not being tackled as per my country Portugal, or any other one in the UE...

HI, the reason you are not getting a valid read is because pin 1 which is the Chip Select /CS has to be made to go positive at the same time that pin 8 3.3V goes positive. This is documented in the Winbond PDF I attached yesterday. I only could program the chip out of circuit and by attaching a resistor between pin 8 and 1.

I suspect that pin 1 is being held low (0 Volts) by other circuitry.

This morning I discovered that I had damaged two of the circuit board pads where the chip was removed from. I used my hot air rework station to melt the lead free solder, but obviously I stuffed up. Bugger as they say here in Australia!

Even with my 46 years of professional experience in electronics, I stuffed up, so I’d strongly suggest not to do as I did!

I’d wait for the software solution to upload the modified firmware. That’s what I’m going to do when my new Designare arrives from the USA as it’s not available here in Oz.

 

[manfriday]

Try disconnecting the Vcc (power) pin -- which is the 3.3V pin on the Raspberry Pi GPIO header. Just pull that pin out. Wiggle the SOIC8 clip, try reading without the 3.3V pin connected, then connect the 3.3V pin and try again.

Also make sure PSU is turned off or power cable is unplugged from the wall.

I tried that before, but I just did it again and it read! but all three .bin files i created have differnet checksums./

 

[CaseySJ]

I tried that before, but I just did it again and it read! but all three .bin files i created have differnet checksums./

Type strings <name of file> to see if any one of the files contains meaningful data.

The chip will often read without Vcc connected, but the file will be filled with nothing.

We have to connect the Vcc pin and try again.

 

[manfriday]

Boosh

 

[CaseySJ]

@jb007

Is the board repairable? If not, sorry to hear about the damage. If it’s any consolation, I’ve spent hundreds on test benches, docks, eGPU, and even the RX 5700 XT only because these items were needed for the “general good of the community”.

If your board is truly irreparable, we respect that it went out in the line of duty...

 

[CaseySJ]

Boosh


View attachment 454844

LOL!! Is that a synonym for “hell yes it worked”??!!

If so, please try the SSDT from the same post where the modified firmware is located. Because Link Speed should be higher on the unconnected port.

 

[manfriday]

Hmm. something isnt right.
I should be using the SSDT-TBOLT3-RP05-V3.aml right?

Once I installed that, and removed the old thunderbolt.aml file the thunderbolt device I was using (MOTU 828es) is no longer seen.

It WAS seen before I installed that SSDT

LOL!! Is that a synonym for “hell yes it worked”??!!

Hah. yeah its something I picked up from my kids.

 

[CaseySJ]

Hmm. something isnt right.
I should be using the SSDT-TBOLT3-RP05-V3.aml right?

Once I installed that, and removed the old thunderbolt.aml file the thunderbolt device I was using (MOTU 828es) is no longer seen.

It WAS seen before I installed that SSDT



Hah. yeah its something I picked up from my kids.

Okay, for now let’s stay with the one that’s working.

Looks like you’re the first! Any tips for @augustopaulo when he resumes this in the morning?

 

[manfriday]

Okay, for now let’s stay with the one that’s working.

I think I spoke too soon. I shut down, and powered back on and the device appears now.

So for anyone else trying to flash the chip with a Raspberry Pi..
What worked for me was disconnecting pin 1 from the pi (easier than disconnecting from the clip once it has its tenuous grasp on the chip).

I was then able to read the chip, but the checksums werent good.. probably reading garbage, or nothing, as @CaseySJ said.

Applying wire back to pin 1 resulted in not being able to read the chip again.

So I started a read operation, then just kinda set the wire on top of the pin so that it made contact, but I didnt push it down onto the pin.
This is probably the functional equivalent of Casey's "wiggle" method.

I was able to read the chip 3 times and the checksums matched, so I went ahead and flashed the chip.
A few sphincter puckering moments later and it said the flashing was VERIFIED.