RGH Jasper Problem

[kgasper]

I've got a problem getting a BB Jasper to glitch. I've been reading and trying different things for weeks now resisting the urge to ask for help until I'm sure I know as much as I can about the topic.

Like I said it's a 512MB Jasper with a TX Coolrunner installed. I've got good Nand dumps via a Nand-X, and with the Coolrunner installed in NORmal mode it boots to the retail Nand. I've re-written the original Nand back to verify it still boots after being unable to get XeLL to boot.

I first used J-Runner to generate and write the ECC but once powered on the Coolrunner would glitch once, maybe twice and then nothing but a black screen. I've tried rewiring the Coolrunner many times: avoiding the inductors, using a shielded wire for CPU_RST, running PLL_BYPASS under the X Clamps, etc. But nothing has helped. I've tried using 360 Multi Builder to generate the ECC and write it using NandPro directly but still no go.

The mod is for my son so it's not a big hurry, but I'm sure he's anxious to get it back. What I'm wondering is if I should be looking at the wiring more, the ECC file, or if I've just got one of those stubborn Jaspers that just won't glitch. My next thoughts are to throw together a POST monitor circuit via a CPLD & ARM combination to debug it that way.

Any help would be very much appreciated.

 

[superspeed]

I've got a problem getting a BB Jasper to glitch. I've been reading and trying different things for weeks now resisting the urge to ask for help until I'm sure I know as much as I can about the topic.

Like I said it's a 512MB Jasper with a TX Coolrunner installed. I've got good Nand dumps via a Nand-X, and with the Coolrunner installed in NORmal mode it boots to the retail Nand. I've re-written the original Nand back to verify it still boots after being unable to get XeLL to boot.

I first used J-Runner to generate and write the ECC but once powered on the Coolrunner would glitch once, maybe twice and then nothing but a black screen. I've tried rewiring the Coolrunner many times: avoiding the inductors, using a shielded wire for CPU_RST, running PLL_BYPASS under the X Clamps, etc. But nothing has helped. I've tried using 360 Multi Builder to generate the ECC and write it using NandPro directly but still no go.

The mod is for my son so it's not a big hurry, but I'm sure he's anxious to get it back. What I'm wondering is if I should be looking at the wiring more, the ECC file, or if I've just got one of those stubborn Jaspers that just won't glitch. My next thoughts are to throw together a POST monitor circuit via a CPLD & ARM combination to debug it that way.

Any help would be very much appreciated.

Have you got pictures of the install? Also are you using the cap on the CR?

 

[kgasper]

No pics, but I'll post some tonight.

I've tried bridging the CAP points on the Coolrunner Rev B but that hasn't made a difference. Also tried various size caps from 10pF up to 68nF across A (PLL_BYPASS) and GND with no luck. Also tried a cap inline with CPU_RST as read in one post.

Another strange thing... I've read people suggest trying the CR in SLIM mode but my CR won't glitch at all in that mode, or if it is the green LED's not flashing.

Does the fact that it only glitches once and then stops mean that the CR thinks the glitch worked?

 

[matt.xx]

I had almost exactly the same problem, except mine would do this when I first plugged it in to the mains and would require a power down and restart before it would glitch. But it's the same principle, sat on a black screen after the green light flash once or twice before giving up.

I resolved it by routing CPU_RST topside and redoing my connection for PLL_BYPASS. I can't stress enough how important it is to have a good connection for PLL_BYPASS.

I found the Coolrunner REV B CAP to be essential on my 256MB Jasper, but I guess that may not be the case if you're using shielded wire.

My green LED didn't flash either when set to SLIM.

EDIT: http://team-xecuter.com/forums/showthread.php?t=80589&page=5

 

[kgasper]

I had almost exactly the same problem, except mine would do this when I first plugged it in to the mains and would require a power down and restart before it would glitch. But it's the same principle, sat on a black screen after the green light flash once or twice before giving up.

I resolved it by routing CPU_RST topside and redoing my connection for PLL_BYPASS. I can't stress enough how important it is to have a good connection for PLL_BYPASS.

I found the Coolrunner REV B CAP to be essential on my 256MB Jasper, but I guess that may not be the case if you're using shielded wire.

My green LED didn't flash either when set to SLIM.

EDIT: http://team-xecuter.com/forums/showthread.php?t=80589&page=5

I remember reading your thread because it sounded similar to my issue.

I did run my CPU_RST top-side with a shielded wire puller from an old VGA monitor cable. Most VGA cables have 3 shielded wires inside for the R G B signals and seem perfect for this application.

My PLL_BYPASS is still stock unshielded wire though. I think I'll replace that with another shielded one tonight along with some pics.

 

[seanr28]

sounds to me like a bad ecc file written! try re-creating and flashing again.

 

[Martin C]

Do nothing more until you post pics.


EDIT: I've deleted the other posts. Pics are needed here, as they almost always are with RGH/JTAG help.

 

[kgasper]

Alright here are my pics...
please let me know if anything looks wrong.
I am pretty good at soldering and used a stereo microscope while soldering... too bad my scope doesn't have a camera in it :cool2:
Also, I have a top picture with the CR in it but I reached the max num of picture attachments for this post. I can post it in another reply I think?

 

[kgasper]

Here's the top picture...

 

[agt_dale_]

Looks good to me, but possible bugs:
1) R4B24. Attached directly to SMD, rather than point to the left of it. Given the timing environment, does this differential matter? Prolly not, but thought I'd throw it out there.
2) FT6U7. Something crossing a trace there....give this a good brushing off in case of random short.

Neither of these are deal breakers, really, and it's quite obvious you know what you're doing from a hardware standpoint.

As I mentioned/got deleted this morning, let's review your software work.
1) Any oddities in producing your ecc file? Let's hear how you did it...
2) Just for safety's sake, did you fc /b your dumps? As my unfortunate case points out, you can dump 64MB without errors and still get crap. Bleh. This isn't pertinent to getting the box to cough up it's keys, but will be pertinent down the line.

 

[kgasper]

Looks good to me, but possible bugs:
1) R4B24. Attached directly to SMD, rather than point to the left of it. Given the timing environment, does this differential matter? Prolly not, but thought I'd throw it out there.
2) FT6U7. Something crossing a trace there....give this a good brushing off in case of random short.

Neither of these are deal breakers, really, and it's quite obvious you know what you're doing from a hardware standpoint.

As I mentioned/got deleted this morning, let's review your software work.
1) Any oddities in producing your ecc file? Let's hear how you did it...
2) Just for safety's sake, did you fc /b your dumps? As my unfortunate case points out, you can dump 64MB without errors and still get crap. Bleh. This isn't pertinent to getting the box to cough up it's keys, but will be pertinent down the line.

Well, when I started out about a month ago I initially had a problem. I had the Nand-X hooked up and was using J-Runner to dump the nand. Well, it was really slow but I didn't exactly know how fast it should be since I hadn't dumped an Xbox nand before. I knew from reading about LPT readers that they were slow but I expected the Nand-X to be fast(er). J-Runner didn't give me any errors, but reading 64MB of the nand took several hours. I think I later generated the ECC and flashed it to the nand but got the black screen like I now have.

At a later point, I switched to using NandPro3 directly, maybe to flash the original nand back to see if it would boot that, when it began giving me all kinds of errors. It suddenly occurred to me that I'd read not to plug the Nand-X into any hubs and I had indeed plugged it into the port on my keyboard which in fact is a hub. :facepalm: DOH!!!

So, after plugging my Nand-X directly into the port on my monitor (Mac Cinema Display which is a root port) the read/write zipped along. FYI... I've also used the USB ports directly on my MacBook Pro, and the results are the same. I'm running Win 7 under Parallels.

When I generate the ECC in J-Runner here's what the log says:

===================================================
Friday, March 16, 2012 9:18:45 PM



No Updates Found


Checking Files
Finished Checking Files
Initializing Nand..
* found flash image, unpacking....
ECC'ed - will unecc.
UnECC'ed
A donor version will be used with this CB
* found decrypted CD
* found XeLL binary, must be linked to 0x1c000000
 * we found the following parts: 
SMC: 2.3
CB_A: 6750
CB_B: missing
CD (image): 8453
CD (decrypted): 8453
 * this image will be valid *only* for: jasper (CB_6751)
 * patching SMC...
Patching Jasper version 2.3 SMC at offset 0x12BA
 * zero-pairing...
 * constructing new image...
 * base size: 70000
 * encrypting CB...
7B67DFF4AE33BEEDB39398E8D6CCDE44
 * encrypting CD...
 * No separate recovery Xell available!
 * Flash Layout:
0x0..0x1FF (0x200 bytes) Header
0x200..0xFFF (0xE00 bytes) Padding
0x1000..0x3FFF (0x3000 bytes) SMC
0x4000..0x7FFF (0x4000 bytes) Keyvault
0x8000..0x11A3F (0x9A40 bytes) CB_A 6750
0x11A40..0x17A3F (0x6000 bytes) CD 8453
0x17A40..0xBFFFF (0xA85C0 bytes) Padding
0xC0000..0xFFFFF (0x40000 bytes) Xell (backup)
0x100000..0x13FFFF (0x40000 bytes) Xell (main)
 * Encoding ECC...

100%
------------- Written into output\image_00000000.ecc

I did dump the nand 2 times and they match. I also opened the nand dump in a hex editor and the original nand had the Microsoft copyright notice so it doesn't appear to be junk. Also the CB is at 0x8400 as it should be. I was concerned about the dash version and LDV values in the patch 0 & 1 sections as shown in the attached J-Runner screen capture, but I not sure if that's an issue or not?

 

[Martin C]

Why would the LDV concern you? If the console was working with this dump then it must be right.

 

[kgasper]

I just wasn't sure what the two patch sections were about and the screen shots I've seen in the J-Runner guide and other J-Runner related posts always show patch 0 with an older dash version and LDV than patch 1.

I've basically been going over everything and double checking everything trying to note any discrepancies between my mod and others successes and problems trying to figure this out.

So... it most likely a wiring/timing issue with my CR install?