V18 PS2 fan stuck at 100% after modchip

installed a modchip in a V18, chip works 100%
however the fan is stuck at 100%

 

Don't worry found the problem


RIP: MECHACON EEPROM

 

And what was the problem?

 

The eeprom inside the Mechanics controller got corrupted somehow..

 

And the fan controller stores some settings in EEPROM? Is this verified?

 

At the very last resort, you can try to connect the PS2's MECHACON to your PC's serial port via a 3.3V UART and to enter commands via a terminal. Baud is 57600, no parity, one stop bit.

The commands for loading defaults are standardized, but I don't know how you're really going to adjust this thing after loading the defaults (not sure if SONY changed the way things work). But there is a chance that you can get away with the auto-gain commands, since any board-specific, weird juju seems to be to compensate for some deficiency in the auto-gain process.

The MECHACON prints a 0 if there is no error, non-zero for an error code. Each command is entered in a line.

Default Fixed Data: c8d02
Default Val Data: c8d03
Default Tray Data: c8d04

If loading the defaults helped, you may want to consider adjusting the gain to fit the console.
Auto-gain adjustment (again, if you dare to, since this is without any error checking and may be without any required workarounds):
CD 12cm mode: c11
Focus up/down end: c2200
Sled home position: c44
Tray Close: c6000
Tray Open: c6001

(Insert a PlayStation 2 CD-ROM here)
Tray Close: c6000
Sled home position: c44
CD Detect Adjustment: c9700
CD 8cm mode: c10
CD Auto-adjustment (phase 1+2): ca301
Focus up/down end: c2200
Sled home position: c44
Tray Open: c6001

(Insert a PlayStation 2 DVD-SL here)
Tray Close: c6000
Sled home position: c44
DVD-SL Detect Adjustment: c9701
Disc Detect Data to EEPROM Write: c9703
DVD-SL 12cm mode: c14
DVD-SL Auto-adjustment (phase 1+2): ca301
Focus up/down end: c2200
Sled home position: c44
Tray Open: c6001

(Insert a PlayStation 2 DVD-DL here)
Tray Close: c6000
Sled home position: c44
DVD-DL 12cm mode: c15
DVD-DL Auto-adjustment (phase 1+2): ca301
Focus up/down end: c2200

EEPROM Checksum Write: c9900
Sled home position: c44
Tray Open: c6001

There is a pattern here. Other than the odd addition of the disc detect data to EEPROM write, it is usually something like this:
1. Retract tray.
2. Move sled to the home position (close to spindle).
3. Set disc mode.
4. Perform auto-gain adjustment.
5. End any activity.
6. Move sled to the home position (close to spindle).
7. Eject tray.

 

One valid thing you could try is find another PS2 which is identical to yours, save it's eeprom using Dampro's lenschanger then try restoring it into yours. If the fan speed control is on a area which are allowed for writes from the PS2 side it will be able to overwrite.

Also, before you screw with the eeprom, verify if you didn't ruin the PWM pin of the fan. PWM enabled fans will run at maximum unrestrained speed if one keeps the PWM control pin at logic level 1. A short circuit could be the cause instead of eeprom corruption. I suggest you investigate the fan before tampering with the EEPROM. Also comes without saying, keep a copy of the EEPROM as it is currently so you can return to the previous state.

 

yep one of the first things I checked for was a short on all pins in the fan header.

this was 100% an eeprom issue, console is pal but video mode changed back to NTSC-J

Ill post in a few minutes what happened but the fault has cleared somehow????>

 

Uhuh?
That would be awesome! I would use this to have the console boot in NTSC mode.

 

IMO it is not an EEPROM problem if it went back to being normal on its own - if the EEPROM's contents are lost, they can't "come back".
Perhaps something you did caused the MECHACON to enter an undefined state, which led to it not allowing access to the EEPROM.

@rama: SCPH-75000 and later have a universal ROM. The region-specific parameters are retrieved from the EEPROM. This includes which letter for DECKARD to change the ROMVER region letter to, which affects the default video mode for OSDSYS.
FMCB can also change the video mode.

But his boot certification seems to be failing too (so it is quite an unusable console).

 

Thanks for explaining how it works.
I suppose the mechacon is still region specific though? I can't just change the region byte in the EEPROM and have the console boot NTSC games? Or can I?

 

I believe it is a generic device for all regions, at the point of manufacture because the leaked service manuals show the same Dragon model for all regions. Earlier devices had region-specific codes (i.e. 003R for Japan, 403R for Asia).

But that is the thing..... There is no known way to edit the whole EEPROM anymore.

Back on topic, @LeHaM wrote that he cannot get the RTC working.

 

Sorry for straying off topic again
So let me throw this in: The battery isn't flat, is it?

 

By shorting the BCDEFGHI wires, which are actually a 8-bit GPIO port the mechacon uses to communicate with the DVP (CD/DVD DSP), you will "corrupt" what the IOP sees at the DVP registers when it tries to talk with the mechacon. Since the mechacon owns the eeprom and RTC serial bus, the IOP will not get reliable information on the EEPROM contents if these modchip points are shorted out. Also disc auth will fail.

Should a user try to store settings on the eeprom (change OSD settings) with those lines shorted, the mechacon may perform invalid writes and overwrite the eeprom at unexpected regions, causing the eeprom to become corrupt beyond repair. That may cause the console to "switch into" a different region. Considering it's a Japanese design it wouldn't be unfair if the mechacon defaults to JAPAN region in case of a severely corrupted eeprom.

 

He'll have to confirm this, but he didn't say it was when I asked him.

Ah, that makes sense. I was wondering how it would be possible for things to go so badly, when the EEPROM is now within the MECAHCON. Thanks!

Given that reading/writing of the EEPROM is done via N-commands, shouldn't this be rather difficult since the commands provide a layer of abstraction over the EEPROM? I mean, the config region is not directly read/written to.

Also because his console has started working normally (with the exception of the RTC), this should mean that it wasn't the EEPROM that got corrupted?

(But, thanks for explaining what may happen if the EEPROM gets corrupted)

 

Very likely the EEPROM didn't get corrupted because no writes were attempted.

Btw apparently the mechacon is a SPC970 series (SONY proprietary MCU) micro controller.

EEPROM corrupting might be proving that there's new obscure N commands that may actually cause EEPROM to be fully writable. Unfortunately shorts on the communication bus would be random, making it difficult for one to discover what exactly the mechacon reacted to.

 

Adding: mechacon always owned the EEPROM and RTC subsystem, even when it wasn't embedded within itself (early models with CXP101064/102064/103049) and eeprom corruption may happen to any PS2 with a botched modchip install if any writes are attempted.

 

I've had a really strange experience with a modded slim once when the RTC stopped working after being modded.

If the RTC is stuck and there is only 1 orb not spinning, go to change the time, press down and hold it which will keep reverting it back to 00:00 but press circle to go back on the menu whilst continuing to hold down. This releases it and then RTC starts again.

It was some time ago with a ghost 2 where it failed to boot properly while the RTC was stuck. Really odd.

 

That's by design. You disconnected the battery. When you connected the battery again the RTC was in a special mode designed for extending shelf life of products which are expected to spend long times sitting on the shelf before being put into use. At that state the RTC is stopped and doesn't draw any power from the battery. Attempting to set the time will start the clock up. And actually, that has nothing to do with the EEPROM issue I was commenting, but indeed a interesting observation from your part.