MVH MV4 Backup Ram Error, Wrote 5555 Read 5540

[DCrosby]

So to try and both help others and try and solve my own issue, I wanted to A: Make sure I have my info correct B: Try and help others no matter what the code is, and share my understanding thus far.

So: First things first...
The Address Matters, as if it's failing right off the bat Address 00000000 then it's something with the lines/wires, or the chips are bad, as it can't even begin to write, if it's something later on, as each address is another page of memory... so something (anything) other than 000000 like 0004533451 or something will indicate it got that far into the ram before something bad happened.

Ok... so a 5555 would look something like this in Binary:
0101 0101 0101 0101
you can use a hex to binary converter to get that number....
5540 looks like this:
0101 0101 0100 0000

so if we put them on top of each-other we can see a pattern...

0101	0101	0101	0101
0101	0101	0100	0000
----	----	---^	-

These values with the ^ are divergent / wrong from what we expect... so what does that mean?
This is the pin-out of the memory chip, each chip has 8 data lanes, I/01 - I/08 and 2 chips = 16 bits.
The error FFFF written FF40 tells us the lower ram is affected.
if the error would have been FFFF written 40FF read it'd be the Upper Ram at fault.

So lets look at one of the ram chips (Both Upper and lower are identical in pin assignment but not what they're connected to):

I believe (reading from the back of the binary sequence) the last number being pin 1, then pin2 pin 3 etc...
So reading this lines 1,3,& 5 are not communicating properly. we can now trace where those go, and if the connection is solid.

There are other lines that can affect the chip, which then run through the HC32, which then toggles WE = Write Enable, CS = Cable Select (from the Pro-CO chip pins 8 and 16 depending which chip high or low is being selected) so other things can affect the chips function, but from the standpoint of what is the error it's telling you a bunch of which chip, and which lines. It's important to check that those lines are good, and are not damaged or pinched, as higher resistance, or intermittent connections can cause these kinds of issues.

So on to my issue, I've checked everything as far as I can, I've replaced the HC32, Both Surface Mount Backup Ram's (The two memory chips in the row 9 closest to the jamma edge. And I've not been able to clear the error, I may try tomorrow to turn on all dips to see if I can clear the backup ram, but it's pretty frustrating when you've checked and double checked things, and have no idea what's causing the error...
I'm also seeing either activity or static values on all the ram pins. I may go back tomorrow and make sure that none of the address lines in or out, are static, and it's only certain pins like GND that are static low etc...

 

[ack]

The lower byte backup ram has dead output.

The code that is re-reading the test data is doing

Assembly	OPCODE
move.w (a0), d1	3210
cmp.w d0, d1	B240

The first instruction is reading the data from backup ram and storing it in the d1 register. The 2nd instruction is comparing that to what was expected (0x5555, in the d0 register). In the event the component (backup ram in this case) doesn't put anything on the data bus when asked, it will often result in part of the next instruction's opcode being used instead. So in this case, the lower byte backup ram chip is not outputting anything which causes that lower byte to get filled with 0x40 from the cmp.w instruction and results in 0x5540 being stored in d1.

 

[DCrosby]

Interesting as I have replaced both chips. But I wonder if one of the output pins is not connected properly. I saw another post that has the CPU pins on one side and the Ram Side on the other, which has most of the outputs, but not a complete list of pins as far as the inputs goes...

This is a modified version of the Neo-Geo forums's post which is incomplete as it stops on pin 10 of the inputs. And only has 3 or so pins on the outputs, does someone had a complete list of ram pins, and where to find them on the rest of the board? Or is there a reason, for the other pins not to be represented? I think when I tested all the pins, I did see signal or activity on all the pins. Which was a bit of a missnomer, as one the the lines to the Co-Po chip was dead (No continuity), and even when I probed the pin it had a signal (static) high or low on it.. so sometimes it's not as simple as just probing a pin, because it could get a signal from someplace else.

RAM___CPU

1______43
2______41
3______36
4______35
5______34
6______33
7______32
8______31
9______30
10_____29
21_____39
23_____40
24_____38
25_____37
26_____42

etc.

There are 3 pins for each backup ram chip that are not connected to the CPU:

lower ram:

20_____74HC32 ( 13 ) located at D10
22_____PRO-C0 ( 16 )
27_____74HC32 ( 8 ) located at D10

higher ram:

20_____74HC32 ( 13 ) located at D10
22_____PRO-C0 ( 8 )
27_____74HC32 ( 6 ) located at D10

 

[ack]

You want to focus on pins 20 and 22 those are what enable the ram chip to output data. Pin 20 should be low 100% of the time. Pin 22 will be high, except when the cpu wants the read data from the chip at which point it will go low.

I would also suggest using the diag bios if you can to confirm its a dead output issue.

 

[channelmaniac]

Check around the battery for damaged traces from battery leakage. Check continuity to the CPU and each other of the Backup RAM for the address lines. Data lines are individual with one chip connected to the lower 8 bits and the other to the upper 8 bits of the 68000 CPU.

If the /CE and /OE lines aren't working right you'll have problems with data outputs from the chips, but don't discount the /WE (Write Enable) on the RAM - pin 27. If it's not going low then the CPU can't write to it. If it can't write to it then the read will be what random data is on the chip upon power up.