Weird persistent error 21

[mjkthirdeye]

Hi all.  I posted this question in the X-S Discord a day or two ago and haven't made any headway in resolving the issue, so I'll post here and see if anyone may be able to help.

 

A few days ago, I acquired a "non-working" 1.2/1.3 that had never been opened but externally was very clean.

When I received it, I immediately opened it up to pull the clock capacitor and clean it up.  Aside from the clock cap, the polymer caps were all leaking, as well as the caps near the CPU/GPU.  I cleaned and recapped the entire board before ever attempting to power it up.

After the initial cleaning and repair, I finally attempted to boot to be greeted with error 21.  Since I went in blind, without any idea of what was actually wrong with the system, I just assumed the dash may have possibly been wrecked from a previous softmod/user error or something, so I opted to start by installing a fresh copy of the MS Dash files via FATXplorer.

I got it back together, booted, and got error 16, which was expected.  I then installed an x2.3b lite to get around the clock check, but rather than booting to the dash as it should, it just hangs at the Xbox logo splash screen.

At this point I tossed in Doom 3 to see if it would load a disc, and it did begin to load the game, however it immediately froze as it was began to write the initial cache data to the HDD.

I decided the HDD might just be crapping out after all, so I substituted a known good working drive from another system and this is where things get weird...  The system will read the x2config.ini from the second HDD (evidenced by the fact that it can and does read, load, and apply the LED and fan settings from the INI file), but was exhibiting the same problem.  It just hangs at the Xbox logo splash screen instead of loading XBMC.  If I lock any of the drives and try to boot from the retail bios, I go right back to error 21 again...

Just to check my sanity, I tested and confirmed all the individual drives and parts work fine in another system. Also, while performing the testing in the working system, I reformatted and "factory reset" the OEM HDD using OGXbox Installer 1.5.4 just to eliminate myself and any possibility of my wrong-doing from the equation.

In the working system, MS Dash loads as it should.  If I move the HDD back to the problematic system, error 21.

After trying various combinations of 4 HDDs, 2 DVD drives, 3 different IDE cables, 2 power supplies, both with and without a modchip, I still cannot get beyond error 21 or the system freezing...

 

I think it's weird that I can boot into Xblast from the chip, format, lock, unlock, and read the S.M.A.R.T data from the drives without issue.  It's weird that it will read the x2config.ini from the drives, but based on the observed behavior, it seems like any other HDD I/O causes it to crap itself, and ultimately all roads have led to error 21.

At any rate, I am out of ideas on what else to try and any suggestions or help are, of course, greatly appreciated.

 

[Prehistoricman]

Could be RAM, GPU/northbridge, or MCPX. Or some weird hardware failure like a bad joint on the IDE connector

There's a slim chance it may be the RAM. Since I've been tinkering with the RAM for the 1.6 upgrade, I was in also a situation where normal BIOSes were unstable with some visual corruption before a freezing yet XBlast was completely stable. Is there a 64MB RAM test out there?

To eliminate the MCPX, you can modify and compile XBlast to write some files and read them back. Or maybe it even has an FTP server built in? Not sure. But watch out for v0.59 XBlast OS because it doesn't seem to be reading my HDD. 0.56 works.

[mjkthirdeye]

I too considered the IDE header or even damage to traces that lead to it, especially with as much capacitor leakage as was present on the board.  But after thoroughly cleaning and inspecting the board several times over for any remaining stray contaminants or corroded solder joints, I am fairly confident they are not the cause.

I also considered the possibility of RAM or the MCPX being the cause.  I do have some spare RAM and I had actually intended to install some on this board anyway, so I guess I could try swapping out the original to test.  Really I just wish I had a definitive culprit before exhausting more time and effort on this board.  I too am beginning to worry it's the MCPX, and if that's the case, it's dead in the water for me and I'd be better off saving the time and parts for another board.

I certainly enjoy the process of reconditioning these systems and troubleshooting these issues. That is, until they lead me down a relative dead end like this. Lol.

[KaosEngineer]

11 hours ago, Prehistoricman said:

Could be RAM, GPU/northbridge, or MCPX. Or some weird hardware failure like a bad joint on the IDE connector

There's a slim chance it may be the RAM. Since I've been tinkering with the RAM for the 1.6 upgrade, I was in also a situation where normal BIOSes were unstable with some visual corruption before a freezing yet XBlast was completely stable. Is there a 64MB RAM test out there?

To eliminate the MCPX, you can modify and compile XBlast to write some files and read them back. Or maybe it even has an FTP server built in? Not sure. But watch out for v0.59 XBlast OS because it doesn't seem to be reading my HDD. 0.56 works.

Possibly, try xbmemcheck

xbmemcheck.rar

[mjkthirdeye]

23 hours ago, KaosEngineer said:

Possibly, try xbmemcheck

xbmemcheck.rar 353.88 kB · 4 downloads

 

Thank you for posting this, KaosEngineer!  I was able to burn this to a disc and actually got it to run and complete the test successfully.  This is quite honestly the most progress I've been able to make with this system, as sad as that is. Lol.

I am not quite sure how to interpret the results though.  I am assuming the test is trying to check 128mb and the 76484 blocks it's unable to check are the non-existent upper 64mb, and whatever of the existing 64 that's currently in use by the system?  

Either way, I'm just stoked that I managed to get it to do anything besides crash.  Even if it's this much, any sign of life at this point gives me a small glimmer of hope that I may yet figure this thing out. 

 

Edited Tuesday at 12:23 AM by mjkthirdeye

[KaosEngineer]

2 hours ago, mjkthirdeye said:

 

Thank you for posting this, KaosEngineer!  I was able to burn this to a disc and actually got it to run and complete the test successfully.  This is quite honestly the most progress I've been able to make with this system, as sad as that is. Lol.

I am not quite sure how to interpret the results though.  I am assuming the test is trying to check 128mb and the 76484 blocks it's unable to check are the non-existent upper 64mb, and whatever of the existing 64 that's currently in use by the system?  

Either way, I'm just stoked that I managed to get it to do anything besides crash.  Even if it's this much, any sign of life at this point gives me a small glimmer of hope that I may yet figure this thing out. 

 

I don't understand the output of this program completely either.  There is no comprehensive memory testing application for the Xbox like for a PC (edit: e.g., memtest86).

The application itself uses some memory for itself, the Xbox's kernel is held in RAM as is the framebuffer for the screen; therefore, only 54,588 1KB blocks of the first 65,536 1KB blocks are accessible.  I'm not sure why the upper 64MBs (65,536) blocks are not being allocated.  (Edit: Hmm, most likely because Xbox app's are set to only use 64MBs of RAM out of the 128MBs that can be installed on Development and Debug Kits.)

The output when executed on my 64MB softmodded v1.6 console is slightly different:

Tested Memory :                    131072

Memoryblocks OK :                  55014

Memoryblocks ERROR :               0

Blocks not able to allocate :      76058

Number of CRC errors :             0