--- JTAG just stopped working - any advice appreciated! ---

[makks]

Whats your soldering like?

EDIT: Sorry, dont have a decent camera now (tested phone camera - far too blurry), to be honest soldering is barely average.

Regardless, nothing was touched or flashed between the time it last worked and hours later when it boots black screen.

Since its not likely for the NAND to alter itself, all AUD_clamp soldering has been redone, remelted solder on QSBs but still black screen : /

 

[makks]

Flashed original 7371 (original dump 3) back to NAND, booted fine, then dumped this working NAND (re dump).

This is a Big block Jasper, the non-matching block at 72 is blocks 390 to 397 (the nandpro ERROR at 392 seems to correlate with this)

nandpro ERROR 678 - 67f

Theis is Bad block ID 00x00CF shown in 360 Flash tool (which uses 16mb block numbering). No relocation address, but seems to be relocated to 1FF (big block: FF8 to FFF)



nandpro ERROR BD0

This is Bad Block ID 00x17A. Relocated to bad block sector at 1FE (FF0 - FF7 in big blocks). Since earlier bad blocks gets remapped to the *end* of the bad block sector first, and 678 is *earlier* than BD0, its likely that the FFFF FFFFs in blocks FF8 to FFF is infact the remapped 00CF (678-67f)

The problem with this is that upon inspection of 16mb NANDs, block CF contains much data, as opposed to FFFF FFFFs - I don't know what to think : /


nandpro ERROR 1418, 3358-335F

These are in MU section and shouldn't matter.



I've looked around blocks 390 and 678 on untouched XBR3 image, its all FFFF FFFFs, no data, can bad blocks really be causing the black screen boot issue?


Hoping to get the simpler XBR3 working first. Thx in advance for any insight

 

[manwithoutname]

Just to clarify this, you wrote back the original dump then turned the console on and then turned it off and re-dumped the NAND again? My understanding is that the NAND will always alter it self once a console is booted.

 

[makks]

Just to clarify this, you wrote back the original dump then turned the console on and then turned it off and re-dumped the NAND again? My understanding is that the NAND will always alter it self once a console is booted.

Correct yes.

 

[manwithoutname]

No wonder your re-dump didn't match the original dump you flashed. Everytime the console is turned on the NAND changes. Try this, flash your original NAND dump onto the console again, then without turning it on re-dump the NAND and compare again. I bet they will match.

Have you tried flashing xell on it's own and see if that boots?

 

[makks]

Have you tried flashing xell on it's own and see if that boots?

Tried and Xell also boots to black screen. Does a correctly flashed Xell(AUD_clamp patched) get a e79 when AUD_clamp wire connection is bad?


Is this correct way to flash Xell onto Jasper256-audclamp?


1. Extract SMC from "jasper_6723_hack_256MB_512MB.bin" (1.3mb Xell)
2. Update SMC to (TMS:AUD_clamp, TDI:Tray open) like M AzeeM K's tut
3. Flash updated Xell (16mb) to beginning of NAND

Does it matter if the rest of NAND is not erased?





Also tried some manual NAND repair
:

Bad blocks 678 - 67F are filled with "FFFF"s, while their nearby neightbour blocks (677..., 680... ect) are also all "FFFF", so how the heck does 360 flash tool know
678-67F are bad block and the rest are not?

Anywho, overwriting 678-67F with "0000"s (telling 360 flash tool to look in slot 1 in bad block area) makes the 678-67F bad block ID dissapear : /

Blocks BD0 - BD7 are alrerady filled with "0000", simply moving blocks FF0-FF7 (slot 2 in bad block area) to BD0-BD7 makes that bad block and bad block reloated messages dissapear.

I doubt this will help solve the mystery.. since none of this was done the 1st time round and Freeboot still worked for weeks : /

 

[manwithoutname]

Yes, a patched xell will give E79 when any of the alternate points has got a bad a connection.

Are you using just the AUDIO_CLAMP or both AUDIO_CLAMP and OPEN_TRAY? If it's the later just flash the jasper xell from signature below. Alternatively if you want to make your own, then copy the jasper.bin file from xbins folder within jtag tool and update it as in Azeem's tutorial.

It shouldn't make a difference to erase the NAND or not as xell takes only the 1st 50 blocks. But if it doesn't work one way then it's always worth trying earasing it and trying again.

 

[makks]

Are you using just the AUDIO_CLAMP or both AUDIO_CLAMP and OPEN_TRAY? If it's the later just flash the jasper xell from signature below.

Yellow jtag diode = Q2N1 AUD_clamp
Red jtag diode = Tray Open

Does Xell not need rawkv.bin injection?



EDIT:

Yes, a patched xell will give E79 when any of the alternate points has got a bad a connection.

Just flashed jasper.bin from your sig (nandpro usb: -w256 jasper.bin 0). Tried both power & eject button, Jtag QSB switch in all 3 positions:

all boot black screen.. this is really wierd : /

EDIT2: using Component cable

 

[manwithoutname]

No, xell doesn't require any kv's. Try nandpro usb: -w16 jasper.bin and see what that gives you. Also do you have any spare diodes you can test?

 

[makks]

No, xell doesn't require any kv's. Try nandpro usb: -w16 jasper.bin and see what that gives you. Also do you have any spare diodes you can test?

just did nandpro usb: -w16 jasper.bin, still same result, no boot.

I don't have any spare diodes atm, but surely if the jtag switch is set to off, then 360 should e79?
Or else e79 is not guranteeded when Xell is flashed correct but without jtag wires...

-Just unplugged DVD power cable (with tray_open wire spliced in) from mobo - same black screen upon boot(although ROL center light flashes as opposed to being solid green)



Even if this is looking hopeless, I'm still ever so greateful for everyone's help. manwithname's post here is most inspirational:

http://www.team-xecuter.com/forums/showpost.php?p=281864&postcount=35

1. Never give up and try every possible and impossible way

 

[manwithoutname]

I'd say the next logical thing to do is replace the diodes and test them. Just get standard switching didoes 1N4148 and see what's the outcome.

 

[makks]

Replacing the diodes is fine if its *certain* to be the wiring. However, this just happened:

Flashed stock XBR3 w/ unaltered SMC - *without* injecting kv & config

Flashed XBR3 w/ unaltered SMC - with injected kv & config

Flashed Xell w/ unaltered SMC (1.3mb)

​

All boot to same black screen.
Even without jtag(DB1F1, ROL) wiring, Xell / XBR configured to use those normal points still boot to black screen.

Surely Xell & XBR with unaltered SMC should E79 when normal JTAG wiring is not present? : /

What could possibly be going on here :?

 

[manwithoutname]

So the conclusion so far is that anything else apart from the original standard dash is flashed to the console you end up with a black screen regardless if the Jtag connections are there or not. Right?

I don't know if you tried this but compile a freeboot image from the original NAND dump then remap the freeboot before flashing it back!!

Important, if you still using the alternate Jtag points to make sure you got an altered smc file for use during the making of freeboot (this should be already included the file you downloaded in my signature).

 

[makks]

So the conclusion so far is that anything else apart from the original standard dash is flashed to the console you end up with a black screen regardless if the Jtag connections are there or not. Right?

right

as a separate test: replaced config of original 7371 dash with config from freeboot image

(nandpro usb: -w256 ef7-ef8_from_freeboot.bin ef7 2)

Still booted just fine

I don't know if you tried this but compile a freeboot image from the original NAND dump then remap the freeboot before flashing it back!!

yup tried that as follows:

Created new Freeboot from original NAND dump, flashed to NAND, then *without* powering on, dumped the (just flashed) NAND system area (-r256 0 1000) into verify file:

Only difference was:

Freeboot.bin:.................................all "FFFF"s in blocks 678-67F
Freeboot_read_from_NAND.bin:.......all "0000"s in blocks 678-67F

Since 678-67F is bad, those 8 blocks should be remapped to FF8-FFF(end of system area on big block NAND), Hex editor shows blocks FF8-FFF on both files to be "FFFF". -So if 678-67F were remapped to FF8-FFF, it would overwrite the same data. This is confirmed by dumping "-r256 badblock 678 8", and "-r256 remap_block FF8 8", badblock & remap_block has same md5.

Important, if you still using the alternate Jtag points to make sure you got an altered smc file for use during the making of freeboot (this should be already included the file you downloaded in my signature).

Of course the altered smc file is used.

jasper.bin (renmamed to SMC.bin) from your sig has md5: DEF87030E22E4A7C387C90193620A931, manually altering the SMC(extract from XBR3, patch with SMC_io) gives same md5. SMC is definately patched for AUD_CLAMP & TRAY OPEN

 

[makks]

After multimeter testing, conclusion is: Black boot screen caused by Bad diode or Overheated Q2N1.


J2D2.1 to TRAY_OPEN diode

RED probe on J2D2.1: measured 0.368 (forward current is fine?)
BLACK probe on J2D2.1: Display does not change, stays at "1 . " -meaning no current and diode is good right?
​

J2D2.2 to AUD_CLAMP diode

RED probe on J2D2.2, measured 0.368 (is that like, 368mV?)

BLACK probe on J2D2.2: a reading of 1.23434

-definately not the "non changing" reading from other diode. Does this mean this diode is not blocking current in the other direction?
​

Overheated AUD_CLAMP (Q2N1) transistor (dear god lord not this please...)

Does anyone know the B,C,E points on Q2N1, and if it can be tested like any normal transistor?
​