Intermittent B240 Backup Ram Error (MV2)

[Hansuke]

I get this strange backup ram B240 error on an MV2.
Write 5555, Read B240.
I'm aware that it's a common error, but it seems to be intermittent and can be induced.

I noticed that whenever I play a multicart, (161 in 1, 100 in 1, etc.) after playing some games for a while, sometimes the physical coin counter meter in the cabinet would go haywire and start counting up credits nonstop rapidly for seemingly no reason. The text on the bottom of the screen where it would usually display the "Level" and "Credit" of the current game would become all garbled and illegible. Sometimes when this error happens, the current game shuts off and then the displays the error screen with the screen filling red text saying that this cartridge is counterfeit and such.

Upon hard resetting after this error happens, even without any cartridges inserted, I am greeted with the B240 error, trying to force AES mode through the unibios just gives me a green screen error, similar to the "Exception Error Handling" error with dirty cartridge contacts.
I tried flipping all dip switches to on to clear the backup ram, but the B240 error persists and I'm unable to clear the backup ram.

I have found that removing the coin cell battery from the battery holder and waiting for a bit allows the MV2 to boot normally again without errors and plays legit cartridges normally.

I wanted to test my theory that the multicarts were causing this issue and I've noticed something new. Now when the error occurs after playing with multicarts, coin meter goes awry, Level and Credit displays get corrupted like before. However, after a hard reboot the error doesn't display a B240 anymore but instead goes into watchdog reset constantly. Even removing the battery doesn't seem to help at first, but after a longer time of being just left alone without the battery, the error goes away like before.
Now when I flip all the dip switches to on, I get the same B240 error screen as before and I can actually force AES mode now. Also, I now noticed that when gong to set the system clock after these "resets" to working order, the system clock would start counting forward rapidly fast from the default reset date/time, but would seem normal after having set the time.

I don't have this issue with my four or single slot machines when dealing with multicarts.
I've tried replacing the C1815 and A1015 transistors and the capacitor in the backup section of the MV2, but it doesn't seem to have any effect. Unsure if this is just a common issue on MV2 hardware and it doesn't do well with multicarts or maybe something else could be faulty...

I've noticed that the corruption of the Level and Credit Text along with the coin counter meter going nuts coincides when the game switches if using Pick n Mix with the 161 in 1 multicart. It doesn't happen everytime, but only sometimes it seems.
Could corroded traces cause this issue with multicarts?

I'm aware that the multicarts clear backup game data when powered on. Could that cause the issue and is there a way to prevent the B240 error from happening?

 

[ack]

You have a dead output issue with the backup ram. The cpu is trying to read from the backup ram and its not putting anything on the data bus. What normally happens in that situation is the register the data was going to be put in will get filled with the next cpu instruction.

This is the code doing the read and compare for the backup ram test

     Assembly       | Byte code
--------------------------------
 move.w  (A0), D1   | 0x3210
 cmp.w   D0, D1     | 0xB240

The first instruction is trying to read a word in from backup and store it in D1 register. This read is not happening causing D1 register to get filled with 0xB240 and triggering to error.

I would start by seeing if there are any issues around the backup ram with the OE signal, which I think is coming from the 74HC32 to the top-left of the backup ram.

 

[Hansuke]

I would start by seeing if there are any issues around the backup ram with the OE signal, which I think is coming from the 74HC32 to the top-left of the backup ram.

I'm a complete amateur on these matters so if it's not too much to ask, could you please explain how to examine the OE signal and what it is?

I'm unsure what an "OE" signal is, but am aware that the 74HC32 is an "OR" gate. Is that what you meant? To check to see if the OR gate is functioning properly?

If so, then would I need to induce the error again to see if the 74HC32 is actually faulty? Would testing it when games seem to being working normally actually show any faults?

 

[HeavyMachineGoob]

Look at this picture:

Note the notch at the top and the little circle in the upper right corner, those denote the orientation so you know what pin 1 is. /OE is pin 22 and it means Output Enable. It along with /WE (write enable) and /CS (chip select) is used by surrounding control circuits in the Neo Geo to control this Static RAM chip, when it's time to read or write or not.

Now where on the board to be looking? You need to find the battery, it has an area marked off with thick white lines. Inside that white square is two of these 62256 Static RAM chips, one or both could be malfunctioning, or the 74HC32 nearby which handles the Output Enable (/OE).

So your list of things that could be the fault is as follows:

- A bad Static RAM 62256 chip in the battery area (one or both)
- a bad 74HC32 (near by)
- a corroded trace connecting pin 22 of the SRAM chips to the 74HC32 (can't remember which pin, might be pin 7 but I'd have to check)

Edit: write enable, not chip enable

 

[Hansuke]

So your list of things that could be the fault is as follows:

- A bad Static RAM 62256 chip in the battery area (one or both)
- a bad 74HC32 (near by)
- a corroded trace connecting pin 22 of the SRAM chips to the 74HC32 (can't remember which pin, might be pin 7 but I'd have to check)

Thanks for the detailed write up.

There aren't any marked off areas with thick white lines on an MV2. Here's a picture of an MV2 from mvs-scans. There seem to be two 74HC32's in the top left section of the board. I'm assuming that I should just look at the 74HC32 closest to the battery?

 

[channelmaniac]

Generally it's related to corroded traces around the HC32 and components next to it, like the 22K ohm resistor or the transistors.

 

[Hansuke]

Generally it's related to corroded traces around the HC32 and components next to it, like the 22K ohm resistor or the transistors.

Would a corroded trace explain why the ram error seems to be intermittent? Like sometimes it works and sometimes it doesn't. Seems random.

 

[channelmaniac]

Would a corroded trace explain why the ram error seems to be intermittent? Like sometimes it works and sometimes it doesn't. Seems random.

Yes.

 

[maki]

Multicarts pull more power than normal carts, did you measure if the 5V are actually 5V?
Measure that on the power rail, but also on the ICs.
At 4.7V things go weird.

 

[Hansuke]

Finally got around to actually fixing this. It's been busy for a bit, but feels nice to actually find out what was wrong.

This fault has been iffy because all the traces had continuity and the ICs seemed to work fine. It only seems to act up if I placed a battery in there to keep backup ram saved. If I were to just not have a battery installed, no faults would happen.

With a battery installed, after the initial boot with freshly cleared backup ram, on the next bootup the machine would now go into watchdog restart and wouldn't get out of the loop until I removed the battery and left it unpowered for a few minutes. When I first made this thread, the watchdog issue didn't happen at first and the errors seemed to happen at random.
While the watchdog restart was happening with battery installed, restarting with all the dip switches in the on position put the board in ram test mode and it gave the typical B240 error like before.

Removing the battery would of course alleviate the issue. Since all the traces had continuity I thought that maybe the backup ram chips were bad and just switched them out for new replacements; same error happens.

Since I now know for sure that it isn't the backup ram chips, I looked at the HC32 gates as suggested by the helpful members above. The traces all seemed good, so I decided to remove the closest HC32 to the battery since I thought that one is most likely to have battery acid damage. However, the legs on the IC looked fine and shiny, so I had doubts about this HC32 actually being bad.

After removing the HC32, I tested continuity with the traces that were underneath and they checked out fine. I then cleaned the area with some IPA so I could install a socket. I then checked continuity with the trace that's connected to the C1815 and it was now not connected anymore.

Here's a picture of the area after that IPA wipedown with the location of the breakpoint of the trace:

Spoiler:

I installed a socket and ran a patch wire underneath from the middle leg of the C1815 to pin 2 of the HC32:

Spoiler:

I then put back the original HC32 that was there in the new socket:

Spoiler:

I even removed the new backup ram chips and put back in the original ones.
I then reinstalled the battery and left the machine on in picknmix for an hour and turned off the cabinet and turned it back on the next day, no more watchdog.

Repair complete!

Before the removal, even though the trace underneath the HC32 was still able to hold continuity, I'm assuming the trace was very fragile and wasn't able to carry a signal properly which caused the watchdog panic while the backup ram was active. After the patch wire was installed, I noticed that I don't get a watchdog click more than once after holding P1 start to get into picknmix anymore. Before the patch job, the watchdog click would happen at least 2-3 times before the machine would boot properly into picknmix.

I previously cleaned the battery acid using a mixture of baking soda + distilled water and gave it a pretty good rinse and a brush down with a toothbrush. The ZMC2 still looks pretty rough, but those traces work fine. I was thinking about desoldering it to get a more thorough cleaning underneath, but the oxidized legs and pads spooked me about whether or not if I would be able to solder it back into place.

It works fine for now, and hopefully the baking soda+distilled water shower the area got will be good enough.

A heartfelt thanks goes out to all the helpful people above that helped me figure out this annoying issue!

The ZMC2 does bother me slightly, but "if it ain't broke"...
Has anyone else dealt with a oxidized/corroded ZMC2 chip? Would it be worth trying to desolder it and cleaning up the legs and pads somehow?

 

[channelmaniac]

If the ZMC2 is working, don't touch it. Clean up the area the best you can to degrease it and get the corrosive oils off that leaked out of the NiCd. You can tell how far that sh*t has traveled looking at the "wet looking" dust & dirt area surrounding the battery.

I've had luck cleaning up the pads with some Multicore solder with the SAVBIT formula and a careful scrubbing of the pads. Not for the faint of heart.

When I had the B240 error, it was an open transistor in the battery backup section. The corrosion went up the leg of the transistor and killed it. Had a chat with Nightmare Tony about it BITD.

 

[Hansuke]

Thanks for the tips channelmaniac!

I still have nightmares from cleaning corroded pads from leaked SMD electrolytics in Game Gears and a Turbo Duo. What I found to work the best is using a lot of flux, solder, and desolder braid to clean the pads. Unsure if there's a better way to do it.
I'm assuming battery corrosion would be harder to clean especially on an SMD chip like the ZMC2.
It's working fine for now and I will indeed leave well enough alone.

When I gave the area that baking soda + distilled water rinse, after everything dried I still noticed some super tiny wet droplets in the area with the resistors and diodes in between the components. I'm assuming that's the left over badness from the leaked battery that was drawn up from the PCB's surface after the solution dried. Gave it another clean until there were no more wet droplets left over after drying.