MV1FZ Bram error......help

alessandro

n00b
Joined
Jul 24, 2015
Posts
15
Hi, this is my first post....i have a MV1FZ that Until a few days ago it worked, suddenly not working and i have a message (with neo diag bios) "bram error". Attachment file.
I have change RAM3, RAM4, 74HC32 and D0 but i have not resolved.......can you help me???? Sorry for my english....
 

Attachments

  • IMG_3254[1] (1).JPG
    IMG_3254[1] (1).JPG
    73.7 KB · Views: 140
  • IMG_3255[1] (1).JPG
    IMG_3255[1] (1).JPG
    78.9 KB · Views: 138
  • IMG_3256[1].JPG
    IMG_3256[1].JPG
    155.5 KB · Views: 139

GadgetUK

Ace Ghost Pilot
Joined
Sep 27, 2013
Posts
1,323
TBH - looking at the BRAM error, it looks like a faulty SRAM. The fact its not the first address, and the actual is nothing like the 0000 expected. Did you use new chips when you swapped out the BRAM? It would be useful to see some closeups of the BRAM and battery area of the board.
 

alessandro

n00b
Joined
Jul 24, 2015
Posts
15
Many thanks Gadget for the reply, I sincerely do not remember if the SRAM was new or not, but the error is identical with both old SRAM and new SRAM.



 

GadgetUK

Ace Ghost Pilot
Joined
Sep 27, 2013
Posts
1,323
Did you replace them since the fault appeared? Because its hard to tell if RAM 3 has been replaced or not - ie. the solder looks quite old on there, not like it has been recently replaced. I see corrosion on pin 20 of RAM 4 as well - you wouldn't expect that on a new IC. The error does suggest that the RAM is the fault, but maybe you've got some problem where two chips trying to output to the databus at the same time or something. TBH, I would start by removing the BRAM again, and test WITHOUT BRAM connected - just to see how the system behaves with diag bios at that point. In theory you should get a dead BRAM error or something similar, if it comes back with incorrect values at a certain address, that will then be a clue that the problem is not related to the SRAMs, but perhaps CS or something.
 

GadgetUK

Ace Ghost Pilot
Joined
Sep 27, 2013
Posts
1,323
I would also remove that battery because it looks like it has never been replaced! Although that type of cell don't tend to leak I don't think.
 

alessandro

n00b
Joined
Jul 24, 2015
Posts
15
RAM3 and RAM4 are already been replaced, now remove Ram3 and i have "BRAM DEAD OUTPUT LOWER".......If you like I can also remove the battery



 

GadgetUK

Ace Ghost Pilot
Joined
Sep 27, 2013
Posts
1,323
Could be connectivity between the C1 and BRAM circuit / SRAM. Not clear on the diagram where the CS signals for BRAM come from, possibly C1. Have you checked the VCC level on the BRAM just to make sure something hasn't gone strange with its VCC due to perhaps a failed charging circuit? It doesnt look to be databus related as I don't think the system would boot if there was something miss-behaving on any of the datalines, and you wouldn't see the fault at a specific address like you do.

It feels like faulty RAM, perhaps bad BRAM_VCC rail or something chip select or write enable related. I would certainly do connectivity checks on all the pins on the SRAM to make sure you can write to it and enable it correctly.

Beyond that maybe an address line has a fault somewhere, or some problem with what ever generates the write enable? Maybe CS is OK, but it cannot be written to or something? Do you get the same value coming back each time at the same address?

EDIT: You might want to ignore all that stuff above and just look at this bit for now:-
Since BRAM range is $D00000 to $D0FFFF, and you get an error at $D00002, that means $D00000 and $D00001 seem to be read OK, that might point to maybe address bit 2 (3rd address line on SRAM) being questionable? Have you checked the address line connectivity between BRAM and CPU?

EDIT2: And looking at schematics, it appears that both BRAM and WRAM address lines are all connected the same. ie. A0 on RAM3, should be connected to A0 on RAM1, RAM2, RAM4. So you can quickly test address line connectivity there.
 
Last edited:

alessandro

n00b
Joined
Jul 24, 2015
Posts
15
i have tested Vcc on RAM3 and is 4.3v. On pin 20 i have a L signal; on the pin 22 and 27 i have H signal. Now i have a different error, ADDRESS D00002 and ACTUAL B97B. All address A0 are tested and connected....
 

GadgetUK

Ace Ghost Pilot
Joined
Sep 27, 2013
Posts
1,323
i have tested Vcc on RAM3 and is 4.3v. On pin 20 i have a L signal; on the pin 22 and 27 i have H signal. Now i have a different error, ADDRESS D00002 and ACTUAL B97B. All address A0 are tested and connected....
Don't just test A0 - A0 was an example, you need to test A2! But just test them all whilst you're there, A0 to A15
 

alessandro

n00b
Joined
Jul 24, 2015
Posts
15
I have tested all connection A0-A14 between Ram3 and Ram1/2/4......are all ok
 
Last edited:

GadgetUK

Ace Ghost Pilot
Joined
Sep 27, 2013
Posts
1,323
The clue is there I think in terms of the address that is reported. Your next step imo is to look at the address lines on a scope or logic probe, just to make sure logic levels are OK. Beyond that, something must be responding when it shouldn't be doing - perhaps a databus conflict when reading that address. It could also be that the CS is not correct at the time the BRAM is read at address D00002, but I might expect random values returning rather than just 11AE. I think if something was wrong with the CPU address line it would cause problems on the WRAM test. Have you tested the HC32 with a logic probe, just to make sure you see correct activity there (just incase a trace is damaged on the HC32)?
 

alessandro

n00b
Joined
Jul 24, 2015
Posts
15
Tested 74HC32, have this value:
1. H
2. L
3. H
4. H
5. H
6. H
7. GND
8. H
9. H
10. H
11. H
12. H
13. H
14. Vcc + 4.3v

Now "actual" is FFFB.....address always D00002
74HC32 is a new componet (changed)
 

GadgetUK

Ace Ghost Pilot
Joined
Sep 27, 2013
Posts
1,323
It looks to me like the WE and OE for the BRAM comes from the Neo C1. So if there's no address line problems, and everything else on the address bus is OK, maybe there's a problem with the C1? It really is just a case of looking at the schematics for the 1FZ, test connectivity between the C1 and 74HC32 chips (something like 4 at least that I see - BRAMOEU BRAMOEL BRAMWEU and BRAMWEL. Scope them, probe them, check they are doing something. But when all is said and done its still strange that its always address D00002. The only way I can see that issue happening is if there was an addressing, CS / OE problem, faulty SRAM, or something else interfering with either the address or databus.

Are you sure you aren't just using bad SRAM chips here?
 

alessandro

n00b
Joined
Jul 24, 2015
Posts
15
News of day....i verified the connection between 74HC32 and C1.
74HC32 pin 5 ---> pin 14 C1 =OK
74HC32 pin 6 ---> pin 27 RAM4 =OK
74HC32 pin 8 ---> pin 27 RAM3 =OK
74HC32 pin 10 ---> pin 98 C1 =OK

I replaced yet RAM3 and RAM4 with another RAM (SONY as RAM1/2 before was SHARP), and now ADDRESS D00002 (as before) and ACTUAL 21E2 (is changed).
 

Jarryson

New Challenger
Joined
May 30, 2016
Posts
54
I have one with a similar problem, read 5555 write 0000 or 0002...all lines checked and all ok, but i wasnt able to repair it, I replaced a lot of chips for nothing. I hope you can repair your board.
 

alessandro

n00b
Joined
Jul 24, 2015
Posts
15
I hope I can fix it, I have at least two others with the same problem.
Do you have any other idea ???
 

GadgetUK

Ace Ghost Pilot
Joined
Sep 27, 2013
Posts
1,323
It does sound like some wierd bus conflict somewhere - maybe when the BRAM is being addressed (CS) something else tries to drive the databus, that's the only thing I can think is occuring, or the CS isn't being driven properly at the point when its reading or writing from the BRAM. Could be the Neo C1 - you really need to get a scope and logic analyser on it at this stage to try and work out what's going on.
 

GadgetUK

Ace Ghost Pilot
Joined
Sep 27, 2013
Posts
1,323
I suspect you've got a WE fault. Take a look at this from SMK Dans page:-

Pins used from the 74xx32 chip vary with board type. Each reference to the '32 refers to the same single chip on the board. The /WE circuit has many points of possible failure.

NEO-C1 SRAMWEL (98) → 74xx32 (5 on MV1F; may vary) (lower only)
74xx32 (6 on MV1F) → 62256 /WE (27) (lower only)
NEO-C1 SRAMWEU (14) → 74xx32 (10 on MV1F) (upper only)
74xx32 (8 on MV1F) → 62256 /WE (27) (upper only)
74xx259 Q6 (11) → 74xx04 (5 on MV1F)
74xx04 (6 on MV1F) → 74xx32 (1 on MV1F)
74xx32 (3 on MV1F) → 74xx32 (4 on MV1F)
Collector from battery circuit transistor → 74xx32 (2 on MV1F)

Edit: my other thought is maybe the WRAM is enabled when it shouldn't be? CS on WRAM is always low. So if the WE or OE go low on WRAM, WRAM might respond, and you may have a bus conflict.
 
Last edited:

alessandro

n00b
Joined
Jul 24, 2015
Posts
15
I don't understand......
I tested all 74HC32 pin on a board while working, and i have this result:
1. H
2. L
3. H
4. H
5. H
6. H
7. GND
8. H
9. H
10. H
11. H
12. H
13. H
14. +V

On the non-working board I have the same identical results, as you can ??

Today the error is only "BRAM UNWRITEABLE"...
 
Last edited:

GadgetUK

Ace Ghost Pilot
Joined
Sep 27, 2013
Posts
1,323
The problem is, there will be a point in time when those logic levels will change in order that access to the BRAM is enabled or disabled, depending on what the processor wants access to. What I suspect is happening (I could be wrong), is that possibly the Neo-C1 is enabling (or not) the BRAM at the wrong time. ie. The outputs there on that 74HC32 all look high at the point you are checking with the logic probe, but they should actually go low at some point, and maybe they aren't. That's where a logic probe doesn't help - it's showing that the HC32 seems OK, but the input to the HC32 might not be correct.

There are limited things at play here, consider it like this:-

1) BRAM and WRAM address and data lines are connected to the 68K CPU (you've checked those and apparently all OK, so you can rule that out).
2) You've replaced the SRAM, so you can rule that out.
3) You've checked VCC and ground connections to SRAM.
4) Write enable (WE) for the lower and upper BRAM banks goes through the HC32, which you've swapped out.
5) CS and OE look to come from the Neo-C1 (I could be wrong here, hard to read on the diagram)

I think your problem relates to 4 or 5. Either the BRAM is not enabled at the correct time (perhaps no OE or CS - guessing they should be active low), and similarly, maybe if those are OK maybe the WE is not correct, so maybe the chip can be enabled and read, but not written to. If I was to hazard a guess I would suspect the C1, or a bad connection from C1 with relation to OE, CS, or WE.

I guess the other possibility here is something else on the databus is enabled at the same time as the BRAM is accessed (bus conflict) - maybe the WRAM is not disabled when it should be or something?
 
Last edited:

GadgetUK

Ace Ghost Pilot
Joined
Sep 27, 2013
Posts
1,323
You might be able to better diagnose it using a unibios. Maybe if you skip the BRAM error with unibios, and use the debug side of the unibios to try read from BRAM, then WRITE to BRAM, and then read back from BRAM address again to see if your write did anything, and also to see what the read is showing. Maybe also read from WRAM to see what's at the same address in WRAM vs the address read in BRAM. You might also be able to narrow it down that way in that if you can read and write to the upper or lower bank then that's a clue as to which bank has a problem. But I've not done that before - you might need to ask others for help using that feature of the unibios.
 

alessandro

n00b
Joined
Jul 24, 2015
Posts
15
Many thanks to GADGET UK, you have been very clear. So I should try to replace the C1, which is not easy given its size and especially because they are not found ........
Before I try to replace it, can I do some other test?
 

GadgetUK

Ace Ghost Pilot
Joined
Sep 27, 2013
Posts
1,323
Many thanks to GADGET UK, you have been very clear. So I should try to replace the C1, which is not easy given its size and especially because they are not found ........
Before I try to replace it, can I do some other test?
Before you rush to replace the C1 I would be tempted to check that OE, CS, and WE on both BRAM chips are connected properly. Search for the MV1FZ schematics if you don't already have them, and look at page 1. On that page you will see the CPU up top, connected to WRAM and BRAM, and at the bottom of that page is the Neo-C1 - it's really hard to read but you should see the BRAM connections there that which connect to the BRAM, and the 74HC32 I think. I would check that the connections coming from the Neo-C1 are going where they are supposed to. If you wanted to be absolutely sure of what's going on, it would be a case of connecting a logic analyser and working out from there what is going on with regards to CS,OE, and WE.

Logically it sounds like the C1, but it might be a connection issue, and I am not sure if there's a transistor on the BRAM circuit there that feeds the 74HC32 - maybe its something as simple as that transitor. "Collector from battery circuit transistor → 74xx32 (2 on MV1F)" <- from SMK dans page. Maybe see if you can find that transitor by following the HC32 connections and just check that transistor too. Other than that, I think you've exhausted all options and then maybe consider the C1.
 
Top