RGH Problems (slim and falcon)

[Grim187]

after spending almost a month trying to get the cpld programmed (using a buffered and non buffered lpt jtag cable's on 3 different pc's) i finally did with a bus pirate.

i was able to get a 16mb jasper to glitch right away with "reset_glitch_hack_v1.1", but i still haven't gotten either of 2 slims to glitch, nor the falcon a friend loaned me.



i will start with the falcon (this is my main priority since its not mine), i dumped it 3x last night and they all matched except for the bad block @ 19 (68AC0 - 69238), i remapped it manually with nandpro 2.0b and used build.py, flashed (including 19 remaped to 3ff), wired the cpld as i did the jasper and it dident boot (just hangs), i flashed back the original (non remapped) and i get 0022 after some time, so im not sure if i have a valid original or if its just not looking to the reserve section @ 3ff for block 19 (360 flash dump tool dosent pick up the bad block), i have some spare falcon nands but they are all pre 8xxx which wouldn't help on this console (13599).



then there's the slim's, #1 i tried just about everything everyone else is/where trying, about the only thing i dident do was lower then 220pf or higher then 270pf on j6 (but would leave it on for 5mins+) for about 2 days to get this to boot and it would just hang, i uninstalled the cpld yesterday and flashed the original back (on both slims) to make sure they worked (they did) then rebuilt the ecc's for each and reflashed, after i re flashed i let it sit for a while before i installed the cpld to test agian and when i tryed to turn it back on it makes the sound but psu light stays orange, i tried flashing the original to a xenon nand and swapping them but i still get the same.



Slim #2; this one still works (afaik) i have it flashed with a fresh ecc built with build.py and i have the cpld installed, i took voltage readings when i first started and the only thing different is post_out is now 0v0 with a mild up tick (no more then 0v5) when it resets, what voltage are you guys getting on post_out?

[rf1911]

I can report my experience on two consoles, same model. Used the same generated ecc using the build_fat.py on the 2 consoles. Glitched, but the one that had the mismatched KV didnt show the DVDkey and stated that kv was not correct, but it DID print the CPUKEY.

So, yes, you can use a generic image_00000000.ecc as long as the console type is the same. Hope this helps someway.

[Pacote-san]

Grim, with the falcon one try something first

After flashing the ORIGINAL nand, take the CPU_PLL_BYPASS wire off

Just desolder it from the pad and see if it boots now

I lost 2 hours of my life on a my 9th jasper on this DAWN point... dont know WHY but when i used a wire too long of touching some parts of the mobo, the console would just boot to 0022! If i took the wire off, BAM! it booted to dash!

Give it a try

[Grim187]

@rf1911 what version where they?, i think the problem is with the cpld programming, but thats good to know for future reference, thanks.

@Pacote-san i tried removing the cpld (including wires), i still get 0022 with the original nand.


Edit: i reflashed the cpld with 1.1 falcon jed and rebuilt it on the falcon, im getting the hop on j5 (0v0 to 0v5 every 5 sec's) but j4 is staying 0.09v and i think that's the problem (on the jasper j4 hops from 0.04 to 0.15ish every 5 sec's), can someone with a working glitched confirm the behavior of j4 and j5?

Edit2: turned out the falcon's post_out had a bad connection to the cpld, after globing a bit of solder on FT6U7 it boots in 4 sec everytime.
now to try that on the slim.

[Grim187]

well i got slim #1 working (just needed to clean up the soldering on the tsop48 and it booted) but i still cant get either one to glitch.

im measuring with the multimeter and getting varying results on post_out.
sometimes its 1.74v and drops to 0.0v on reset (when cpld isent connected (sometimes when it is) and ecc is flashed)
sometimes its 0.0v and and jumps to 0.5v on reset (when cpld is connected and ecc is flashed)
and sometimes it fluctuates from 0.5v to 1.78v (during off screen boot, when cpld isent connected and original is flashed) this is what ive heard is the correct behavior from 1 person that has a working slim RGH'ed console.

also different results from stby_clk, usually its 1.34v but i have seen it be 1.78v, im not sure if this has to do with the slowing of the cpu or if its just a bug/glitch/common variation?

ive also heard the reset interval is 30 sec (pin27 stays 3.3v for 30sec then drops to 0v0 for 1 sec and repeats) where i have only observed a reset interval of 1 sec with a 2-3sec lapse (3.3v for 1 sec, 0v0 for 2-3sec).

then there is also the fact that in the description of the hack it says

Code:

We send an i2c command to the HANA to slow down the CPU at POST code D8 .
We wait for POST DA start (POST DA is the memcmp between stored hash and image hash), and start a counter.
When that counter has reached a precise value, we send a 20ns pulse on CPU_RESET.

but there is no mention of D8 or DA in the VHD.
https://github.com/gligli/tools/blob/master/reset_glitch_hack/cpld/glitchslimnodp/main.vhd
maybe just a typo or my inexperienced with VHD?

[Grim187]

i finally got a slim glitched, turned out it was just a bunch of bad luck, after i put some leds on post_out and cpu_rst i was able to see what was going on and make a better decision weather to reset or just wait for it (for the most part it helped just to know what was going on).

i made a video of the 3 state's i witnessed between resets.

http://www.youtube.com/watch?v=m8PalO1hdKE

if my theories about the error states are wrong or you have something to add i would like to hear from you.

[l_oliveira]

I only watch the CPU reset line with a voltimeter. If it's ticking, the glitch is doing it's thing

[Grim187]

That would only tell you if ecc is working or not.

watching dbg, cpu_rst and post_out gives you a complete debug; you can see the post code's change, know that the cpld is on and working and see exactly when it reset's.

i redid the video to make it easier to understand.
http://www.youtube.com/watch?v=ZrUxQH5jvCs

im in the process of building a led post bus reader, not sure what the correct pinout is for it so im just gonna hook them up in a row ft5u1-8, for debugging purposes this shouldn't be a problem but would be nice to know the post code.

[Grim187]

here is my led post reader setup.
http://i12.photobucket.com/albums/a246/Grim187/4017.jpg
showing 00100001 - 21

so here is what i have gotten from the slim i got working;

Code:

1B
1C
B8
DF
DD
D8 r
D9
F9 /r
21

1B
1C
1D
DD
D5
D8 r
D9
FB /r
F2

19
1B
1F
1C
1D
D5
D8 r
D9 /r
21

10
18
1B
1F
1C
1D
DD
DC r
D8
D9
FF /r
2E
3F
3B
19
11
12 Boot!

after swapping the cpld from the working one "fan" to the non working one #2 and vice versa this is what i got
fan

Code:

26
2F
F
1B
1F
1C
1D
9F r
97
9F
98
99
BB /r
21

r when the dbg light was on /r

#2

Code:

1B
1F (d)
1C
1D
9F
98 r
99
BB /r
21

i swapped the cpld's back and Fan is booting xell agian, i re installed the cpld to #2 makeing the post out and cpu_rst wires much shorter (installed it under the board) and im now getting this out of it.

Code:

10
1A
18
D0
D8
DA
D8
DA

so the questions i have are; what is 9F and 97-99?
what is D0 and why am i getting Dx so early? (before 1B, 1C and 1D)

[TorchMach1]

Edit2: turned out the falcon's post_out had a bad connection to the cpld, after globing a bit of solder on FT6U7 it boots in 4 sec everytime.
now to try that on the slim.

I had the exact same problem.  I was having a heck of a time getting a Matrix Glitcher to work on my Falcon.  Apparently the solder drops from the factory on FT6U lines only stuck to the copper pad, not the actual line or trace.  Imagine a tiny drop of solder with hole in it.  When I reheated the factory solder on FT6U7 and stuck my wire on it, it wasn't making a good connection to the actual line.  The fix was the same as Grims...un-solder the wire, then apply fresh solder.  My falcon boots in about 5 seconds every time!

Thanks for posting your progress Grim.  It helped me a lot!