Jazeker, ook de eMMC krijgt de benodigde spanningen, namelijk +3V3-EMMC en +1V8-EMMC-IO.
Vandaag een hele tijd aan het uitpluizen geweest hoe ik de eMMC met mijn RT809H "in-circuit" kan uitlezen. En inmiddels met heel dun geëmailleerd koperdraad aansluitingen gemaakt voor:
1. EMMC-CMD
2. EMMC-CLK
3. EMMC-D0
4. GND
5. +1V8-EMMC-IO
6. +3V3-EMMC
Nu nog het (minuscule) XTAL van de standby-processor aan GND zien te leggen om te voorkomen dat de standby-processor gaat "lopen" en het eMMC benadert terwijl ik van buitenaf met de RT809H de eMMC poog uit te lezen. Maar jemig - wat is het allemaal klein?! Afgelopen week mijn nieuwe bril opgehaald en dat is maar goed ook...
Heeft er iemand trouwens nog suggesties hoe/waar ik aan een eMMC-dump voor dit toestel (55PUS8305/12 / chassis TPM18.1E_LA) kan komen?
UPDATE
Alvorens te pogen om de eMMC in-circuit uit te lezen, wilde ik eerst weten of het niet de standby-processor is die "dood" is. CPU-problemen schijnen bij dit chassis namelijk nogal eens voor te komen.
Om te kijken of de standby-processor okay is (lijkt) heb ik mijn oscilloscoop aangesloten op de "EMMC-CLK" lijn (zie foto). Als de standby-processor okay is, dan verwacht ik hier leven te zien als de TV wordt aangezet, de standby-processor probeert dan immers de eMMC uit te lezen. En jawel; kort na het aanzetten van het toestel is hier activiteit te zien (video).
Mijn voorlopige/voorzichtige conclusie: de standby-processor is okay, het probleem zit hem in de eMMC.
Volgende stap: het XTAL van de standby-processor kortsluiten (zodat de standby-processor stilligt) om vervolgens de eMMC in-circuit uit te lezen. Wordt vervolgd.
P.S. Heeft er iemand trouwens nog suggesties hoe/waar ik aan een eMMC-dump voor dit toestel (55PUS8305/12 / chassis TPM18.1E_LA) kan komen?
Update
Omdat ik toch ook al draadjes had liggen naar eMMC-CMD en eMMC-D0 toch ook even naar de signalen op die lijnen gekeken. En tot mijn verbazing leeft bij het booten óók eMMC-D0 wat erop duidt dat er data uit de eMMC gelezen wordt. En toch start de TV niet op?! Is het dan toch wat anders dan de eMMC?
Op suggestie van "een professional uit de reparatietechniek" een laptop met terminal-programma (Putty) en voorzien van een geschikte USB-RS232-adapter aangesloten op de 3-pins SERV-U port van de TV. Op die port wordt tijdens het booten (normaalgesproken) allerlei relevante informatie getoond. Ook ERRORS, zo is het idee.
En jawel; er verschijnt iets op het scherm (foto 1). Een klein deel is leesbare tekst. Misschien is er nog iets mis met de instellingen van de seriele verbinding (115200bps, 8 databits, 1 stopbit, geen pariteitsbit, geen flow-control)?
Heeft iemand op dit punt nog tips/aanwijzingen wellicht?
Wordt vervolgd...
N.B. Voor info over het uitlezen van de Serv-U poort:
https://toengel.net/philipsblog/2020/12/09/philips-logs-am-tv-service-…
Als je de TV langere tijd aan laat staan, meer dan 30 min, gaat er dan geen LED knipperen?? Anders is de Main CPU de boosdoener of de spanningsregelaars daarheen worden niet geschakeld vanuit standby processor of defect..
Update
Vanavond heb ik de PC via een andere USB-serial interface op de TV aangesloten. Deze interface wordt aanbevolen in het blog van Toengel (zie mijn eerdere bericht).
En met deze interface (1e foto) kun je de interface aanpassen aan verschillende spanningsnivo's. Ingesteld op 3.3V komt er nu leesbare tekst tevoorschijn bij het aanzetten van de TV (2e foto).
De conclusie lijkt voor de hand te liggen: de eMMC is defect?!
En daarmee kom ik terug op de vraag: heeft er iemand een suggestie hoe/waar ik aan een eMMC-dump voor dit toestel (55PUS8503/12 / chassis TPM18.1E_LA / mainboard 715G8465-M0D-B01-005T) kan komen?
Update
@smd: En nu dan toch aan de slag gegaan met het in-circuit uitlezen van de eMMC.
BOOT1, BOOT2, EXT_CSD en USER kunnen zonder probleem worden uitgelezen; checksum/verify okay. Het enige dat daarbij opvalt is dat de gerapporteerde grootte van de USER-file niet okay lijkt: 14190MB?! Oftewel ruim 14GB. Dat lijkt mij wat veel voor een 16Gb (Gigabit) KLMAG1JENB B041. Is er dan toch iets aan de hand met de eMMC, ondanks dat het (serieel) in-circuit uitlezen wel lijkt te lukken?
Ik kan de eMMC natuurlijk uitsolderen en de inhoud kopieeren naar een nieuwe chip, maar daarbij verlies ik sleutelmateriaal en verliest de TV bepaalde functionaliteit (toegang CI+-module o.a.).
Heeft er iemand nog een suggestie?
Nee je leest het verkeerd: van de 16 GB is 14,190 GB bruikbaar, Boot Files zijn 4 MB groot, dat vind ik juist vreemd...
Dag smd (e.a.).
De eMMC-chip heeft een totale grootte van 16GBit. Oftewel 2 GigaByte.
Daar past geen USER-file in van 14.190GByte, want dat is meer dan 7x zo veel. Dus ofwel a) de chip is corrupt en rapporteert verkeerde file-groottes ofwel b) de RT809H-tool maakt er een rommeltje van. Ik zie geen andere uitleg.
De enige andere ervaring met eMMC-dumps die ik buiten dit project heb is met een 55PFS8109/12 waar ik laatst een nieuwe eMMC in heb gezet. En ook die eMMC heeft BOOT1- en BOOT2-files van 4.096KB. Zo gek lijkt die filesize van 4MB dan ook niet.
Wat ik na jouw opmerking gedaan heb, is de inhoud van BOOT1 en BOOT2 bekijken met een HEX-editor. De file BOOT1 is op grond van wat ik zie volledig gevuld met (naar ik aanneem) machinecode en een aantal leesbare karakters. De file BOOT2 is op 32 karakters na gevuld met alleen maar "00". En dat vind ik vreemd.
En nog even terugkomend op het in-circuit uitlezen; ik meldde eerder dat het uitlezen prima ging, met "check/verify okay". Bij nader inzien zegt dat laatste waarschijnlijk helemaal niets. Het zegt dat het uitlezen gelukt is, maar niet of de data die in BOOT1 en BOOT2 staat de juiste data is. Als de chip corrupt is, dan lezen we corrupte data uit. En als dat lukt, dan is "check/verify" ook okay. Alleen indien de check/verify plaatsvindt tegen een checksum die ook in de eMMC-file staat (zou staan) dan stelt het wat voor. Maar of dit het geval is, dat weet ik niet..
Ik ga nu eerst maar eens een eMMC-dump maken & bestuderen van een TV die het nog wél doet. To be continued dus...
Toch ook een foto van BOOT2 gemaakt, zie bijlage. Vanaf de 5e regel "00 FF 00 FF" et cetera tot einde file.
Ik heb inmiddels ook gekeken naar de eMMC-dump van de 55PFS8109/12, het toestel dat met een nieuwe eMMC geladen met die betreffende eMMC-dump weer tot leven is gekomen. Ik heb vastgesteld dat bij die dump de files BOOT1 en BOOT2 geheel identiek zijn. En vermoed dat BOOT1 en BOOT2 bewust identiek zijn met het oog op redundantie/betrouwbaarheid. Maar dat is maar een slag in de lucht. Één ding staat vast: bij de 55PUS8503/12 die niet op wil starten zijn BOOT1 en BOOT2 beslist niet identiek.
Heeft er wellicht nog iemand ideeën over / ervaring met dit onderwerp?
Voor zover ik weet is de EMMC 16GB ( gigabyte) en geen gigabit wat ook overeenkomt het de file van ruim 14GB. De meeste Sony backups die ik heb van EMMC's zijn 13-14GB. groot.
Een lege BOOT wil niet zeggen, soms staat de loader in een andere file.
@William1967: ik heb n.a.v. je reactie de spec van de eMMC opgezocht op de site van Samsung, en je hebt gelijk: het is een 16GB chip. Ik ben de fout ingegaan door te varen op wat ik las op AliExpress, daar staat bij de chips die ik besteld heb 16Gb. Leermoment. Een eMMC-dump heb ik tot nu toe nergens kunnen vinden; het lijkt erop dat ik niet ontkom aan het op de kop tikken van een vervangend mainboard.
Ik denk ook een ander mainboard helaas. Soms op Russische sites vond je wel wat, maar op EEA manier lijkt dat steeds meer geblockt.
@RAAF12: tnx,gelijk een berichtje naar de verkoper gestuurd.
Overigens ben ik ondertussen wat verder gegaan met research betreffende de foutmelding die via de Serv-U interface wordt uitgegeven:
Secure boot failed:3
Trying 2nd bank…2nd bank boot failed: 3
System Halts.
Bovenstaande LOG-OUTPUT is alles wat er na het aanzetten van het toestel op de Serv-U poort wordt uitgegeven.
De gerapporteerde fout kom ik vaker tegen als ik Google maar niet specifiek voor TVs. De fout heeft volgens wat ik lees te maken met een probleem tijdens de eerste bootfase van de processor, waarbij de processor (interne) code laadt om met de omgeving buiten de (processor)chip te kunnen communiceren. Deze melding lijkt daarmee een indicatie te zijn dat er met de (standby)processor (Mediatek MTK5596) iets mis is.
Wordt vervolgd.
Update
Op advies van derden ben ik alle spanningen maar eens nagelopen die voor de MT5596 van belang zijn:
+12V: OK
+3V5-SB: OK
+1V0-AVDD: OK
+3V3-STANDBY: OK
+5V_SW: OK
+1V5-DDR: OK
+1V0-VCCK: OK
+3V3: OK
+1V8-EMMC: OK
Alle benodigde spanningen zijn aanwezig én okay. Getuige de via de Serv-U poort vastgelegde bootlog komt de CPU echter niet door zijn eerste bootcyclus heen. En in die fase wordt er (volgens dit artikel) uitsluitend code vanuit een (MT5596-interne) ROM in (MT5596-intern) SRAM geladen. Er gebeurt op dat moment nog helemaal niets met (bijvoorbeeld) de eMMC.
Al met al lijkt er dus toch op dat de CPU zelf defect is en dat ik die MT5596 zal moeten vervangen. Kan iemand mij vertellen waar/hoe ik aan zo'n chip kan komen?
Aanvulling
1. kan iemand mij vertellen waar ik zo'n Mediatek MT5596 kan verkrijgen?
2. op het schema staat "MT5596". Als ik een beetje Google, dan kom ik tegen "MT5596HGOJ", "MT5596UGIJ". Kan iemand mij vertellen wat die vierletterige suffix inhoudt en of de "UGIJ" en "HGOJ" varianten uitwisselbaar zijn?
3. ik heb slechts één SSB beschikbaar bij dit toestel. Met dus n.a.w. een defecte CPU. Ik heb meerdere SSB's van andere toestellen met diezelfde "Mediatek MT5596". Kan ik zo'n chip (afgezien van de desoldeer-/reball-/soldeer-problematiek) transplanteren of is dat (bijvoorbeeld vanwege "vergrendeling" aan de eMMC) kansloos?
Ik verwacht niet dat een Standby processor aan een EMMC gekoppeld is zoals in vergelijkwaardige datasheets ziet. Maar volgletters zou toch deels er op moeten staan?? Of versie verschillen door pinlayout?? Ik denk niet dat je verschillende versies door elkaar heen kan gebruiken, dat zal wel een conflict opleveren tussen EMMC standbyprocessor
Bart64
*hier heb ik geen app voor nodig
Zou toch eens de processor een gecontroleerde reflow geven met flux, deze problemen lijken op de boot problemen van de eerdere QFu series en losse processor of een defect daarvan. Of het flash geheugen dat corrupt is. Als vervangen processor en flash geheugen ook niet heeft geholpen is misschien het ram geheugen niet goed, gezien de foutmeldingen. DEfect ramgeheugen doet ook hele vervelende dingen zoals niet goed opstarten, geen video, vastlopers enz. (Dat laatste had ik met een ASUS pc moederbord nl)
@Bart64: de bootlog laat zien dat het de standby-processor (onderdeel van de MT5596 SOC) er niet in slaagt de eerste fase van het bootproces succesvol af te ronden. In die eerste fase laadt de standby-processor normaalgesproken een minimale hoeveelheid code (die al in de MT5596 staat) in SRAM (ook intern MT5596). Er is in die fase nog geen interactie met geheugen in de "buitenwereld". En in die zin kan falend (extern) flash-geheugen niet de oorzaak zijn. Een losse processor is inderdaad nog wel een mogelijkheid; alle spanningen die de MT5596 nodig heeft zijn weliswaar op de PCB aanwezig, maar het is natuurlijk mogelijk dat t.g.v. losse BGA-verbindingen bepaalde spanningen niet de MT5596 binnenkomen. Ik ga een reflow down; veel te verliezen is er niet.
Voor het overige kijk ik nog steeds met belangstelling uit naar een antwoord op de in mijn vorige posting gestelde vragen 
.
En @smd: ik ben er inmiddels achter dat er op het 18.1E_LA chassis een MT5596UGIJ wordt toegepast, op het 17.1E_LA chassis een MT5596HGOJ. Het lijken dus twee varianten van de MT5596 en daarmee lijkt onderlinge uitwisselbaarheid niet mogelijk.
[Bericht gewijzigd door ChristiaanR op (12%)]
Nee, ik zou die moeite zeker niet doen, ervaring leert dat de volgletters identiek moeten wezen..
Oepsie...
Helemaal vergeten te posten hoe deze reparatie - inmiddels bijna anderhalf jaar geleden - is afgelopen. Maar bij deze: ik heb het SSB uiteindelijk vervangen door een identiek exemplaar afkomstig uit een 49PUS8503/12. Geïmporteerd vanuit de UK, dichter bij huis was er op dat moment niet aan te komen.
Ik heb mijn postings over deze reparatie gelijk nog eens goed bestudeerd. Het is grappig om te zien dat ik met mijn kennis van nu al eerder zou hebben geweten wat er feitelijk mis was met het originele SSB: de eMMC was defect. Niet alleen de USER-file was defect (dit bleek tijdens het uitlezen gelet op de vreemde file-grootte), ook de BOOT1- en BOOT2-file waren corrupt. Dit bleek achteraf gezien vanuit de log-file, waar het booten vanuit BANK1 én vanuit BANK2 niet lukte. En dát ben ik nog niet vaker tegengekomen?! Dat een eMMC na verloop van tijd problemen heeft ten gevolge van een versleten USER-file komt vaker voor, omdat die file niet alleen gelezen maar ook geschreven wordt tijdens bedrijf. Maar de BOOT1- en BOOT2-files worden alleen maar gelezen, en daar slijt zon eMMC normaal gesproken niet van?!
Anyhow: de consequentie van corrupte BOOT1- en BOOT2-file is dat het SSB niet reparabel is omdat in die files cryptografisch sleutelmateriaal staat dat gekoppeld is aan bepaalde componenten op datzelfde SSB. Deze files kopiëren vanuit een ander SSB is daarmee zinloos, omdat die "vreemde" files dan niet matchen met de hardware van dít SSB.
Dus - een ander SSB geplaatst en de TV kan weer een tijdje mee.
Lijkt meer dat de TV statische vonk heeft gehad en daardoor de alleen leesbare files beschadigd zijn…