[help]820-01700 "mistery problem"

[phantomEVO]

I repeat: macbook switching after chaning all 4 usb controller and flashing only one tbt rom . u7650 changed before by another technician with a wrong one. re changed by me with the right one. from that moment, macbook works like this
Dropbox

www.dropbox.com
then i've tried to reflash t2 rom and from that moment only 5v and direclty to dfu mode even with original backup

[phantomEVO]

i've discovered something (maybe) interesting... PP2V5_NAND_SSD1 and PP2V5_NAND_SSD10 have good diode values, but if i connect the power supply, and i disconnect it, diode values go down to 0,060...is it normal?

[phantomEVO]

i',m going crazy

[phantomEVO]

ppbus g3h and pp3v3 g3h sns ssd0/1 present (12,3 and 3,3)
1,8slprs present

[reformatt]

Review https://logi.wiki/index.php/CD3217_a...er_on_Sequence

If you have 12.3V for PPBUS, this means the T2 isn't starting (this chip replaces the SMC in previous versions - it's much more complex but performs the same basic functions). As per the Wiki page, you need to have all 4 CD3217's communicating AND have the correct I2C programming for the left side CD3217's (as they have one time programmable I2C address burnt in). Best is to source from a donor board that has not been reworked.

T2 also has it's own PMU IC, so the Wiki page also resistances for each power rail. The T2 has to boot from it's own internal ROM, before switching on SSD power rails and loading BridgeOS. DFU revive or restore or messing with T2 ROM is a bad idea if you have a pre-existing hardware fault as it will not complete and now you have 2 faults. If you have restored the original T2 ROM and it's still in DFU, review your programming setup or your soldering. The original boot rom should at least allow the T2 to internally start before proceeding to switch on SSD's and load BridgeOS.

As the board has been reworked, and you have also done your own rework, the likelihood is additional faults have been introduced, further muddying the waters. My experience is to review every bit of rework on the board, and I'd start by comparing diode values for each reworked section against openboardview data. Do you trust the previous tech's work? I had once a 'repair' where a tech had replaced a cap only to find what he fitted was wrong or defective. You end up going around in circles if you don't check their work.

The bulk of the issues on these 16" MAC's are corrosion on either wing of the board where the fan intakes are, or shorted NAND's from a shorted TPS62180. Unfortunately, most people dive straight into replacing CD3217's, use the wrong ones, or a defective one from a donor board, adding an additional layer of issues.

[phantomEVO]

thank you for your awesome reply!

like i said before, at the beginning i had only 5 v.

so i have installed 2 controller from an identical donor board (same place), then the other two.

then i flashed ONLY one tbt rom and i had had 20v! so i'm pretty sure that controller and t2 was ok! but no boot! no short around each nand and no short around its power supply.

after t2 rom flash, it goes DIRECTLY in dfu mode and obviously i have only 5v.

i have used my minipro to read t2 eeprom.. schematic says it is "MX25U3235F" so i have select it... but i have had some warning about "DEVICE ID" (like different from what expected). i've done the backup and tried to write it with error! so i have seen this video

https://www.youtube.com/watch?v=8x15Ye406uY

he select model "at25sl321: this is not present on my progrm....so searching on the website i've found that the programmer ch431 support this eeprom

bought the programmer and used the sofwtare to write a dump from internet and my backup without luck!!! always in dfu directly

are you 100% sure that erasing eeprom and reprogramming it, it will work without problem?

because if it is like this, i'm 100% sure that the eeprom is solder good and i have 50% of change of a writing problem 50% of backup problem.

in the meantime i've bough a new programmer (t48) that native supports this eeprom...

[mon2]

It is normal to expect the DFU mode after the T2 reflashing.

Watch this video:

https://youtu.be/n164YwaI4cQ

[phantomEVO]

yes i know, but is it normale that flashing my ioriginal backup is still in dfu?

[mon2]

Can you confirm if you had a valid known good T2 flash dump at the start of this repair? Perhaps consider to test a T2 rom from a donor board onto your target board. Do not do anything but remove and replace as-is.

[phantomEVO]

i repeat! is it sure that erasing and reflashing MY T2 ROM BACKUP, IT WILL GO TO DFU? MAYBE I'VE FOUND THE PROBLEM

i have used a dump from the tool t2 unlock mina

https://www.youtube.com/watch?v=EMnkSZSDb8c

in this video, as soon as you flash the file, it goes directly in dfu mode .


but in this video, when he flash is own t2 rom backup simply changing serial number

https://www.youtube.com/watch?v=-6ndWqQ7PW0&t=177s

it doesnt go directly to dfu!!

even in this video!

https://www.youtube.com/watch?v=-lYn5gnK_Es&t=139s

so just because i'm not sure about the health of my t2 rom backup, what do you think if i flash one of this?

https://www.badcaps.net/forum/troubl...2-soc-rom-dump

[phantomEVO]

other question: is it sure that ppbus_g3h MUST be @12,6? because i have 12,3v since the beginning

[mon2]

When T2 boots, you will have 12v6.

[phantomEVO]

i think it would be better to assure that main voltages (for example) are all presents!

i have no short anywhere diodes readings are all good, but at the same time, main vltages for nand ar not present. i dont think that both pm for nands are dead TOGETHER.

Maybe i miss something that power on them????