Re: strange 2001N fault

Den Tue, 20 Feb 2018 23:21:58 +0100 skrev Francesco Messineo
<francesco.messineo@gmail.com>:
> On Tue, Feb 20, 2018 at 10:49 PM, Mia Magnusson <mia@plea.se> wrote:
> > Den Tue, 20 Feb 2018 19:28:23 +0100 skrev Gerrit Heitsch
> > <gerrit@laosinh.s.bawue.de>:
> >> >> On 02/20/2018 11:53 AM, Francesco Messineo wrote:
> >> >>> Hi all,
> >> >>> in case someone doesn't read vcfed forums, my 3032 developed a
> >> >>> strange fault:
> >> >>>
> >> >>> http://www.vcfed.org/forum/showthread.php?62202-3032-(2001N)-strange-fault
> >> >>>
> >> >>> The thread link is just to recap what I've found and what I
> >> >>> did, so I don't have to type all again here ;-)
> >> >>> Ideas welcome, I'm just scratching my head. This is probably
> >> >>> where a logic analyzer is needed badly.
> >> >>> It seems to me there're unintended writes on some ram locations
> >> >>> (not so random, address wise) and it makes me think about VSP
> >> >>> crashes on C64.
> >> >>> Any idea where to look for a fault?
> >
> > It seems like there is a correlation between many but not all 1's in
> > the addresses and some data bits changing from 1 to 0.
> 
> I didn't look much into correlation, most of the times, all (or
> almost) locations at 128 bytes interval gets corrupted with the same
> value, so at
> the moment it seems more like a refresh or address hold time problem.
> Also I failed really to identify a place in the schematic where the
> address and data bus would "meet" in any way, unless it's a big power
> bounce, but I've searched for any power noise without success so far.
> Both +5V rails have < 1mV ripple, +12V has 2.5mV ripple (ok, that's
> big, but probably because of very low capacitance on that rail,
> compared to the tens of 100nF scattered on the +5V lines), -5V has
> about 1mV ripple.
 
This is a far call and highly unlikely, but could there be a bad joint
where both sides of the pcb connects? I.e. some power rail crossing
broken so there in fact is power rail bounce but just not visible
unless measured at the right spot on the pcb?

> > There is afaik some test programs that you can burn onto an eprom
> > and run. (I assume that you already know this, though).
> 
> the usual pettester.bin ran for hours without finding RAM errors, but
> that's not really a great test, it completely writes one bank (0),
> then reads it back. Another clue that probably refresh works fine (and
> its address counter does seem to count correctly, as far as I could
> see).

Maybe it's time to make an updated version :)

> >> But if the address bits changes too close to /RAS going low, it can
> >> happen that you get 2 or more rows selected at the same time.
> >> Meaning each read amp finds itself connected to 2 or more memory
> >> cells. If those cells don't have the same data (*) in them, you
> >> will get data corruption when the data is written back.
> >
> > In this case where AA should be everywhere, it's probably more a
> > case of only one cell getting written back after two were drained.
> 
> there're many writes in zero page and stack page even during basic
> idling at the prompt (there's the periodic keyboard scan interrupt for
> example), so if there's some address not holding enough long after
> /RAS, it could "copy" any value from zero/one pages to other
> locations.
> Only bank1 should remain full of AA, but it gets corrupted too, albeit
> less frequently.

I haven't looked at the schematics, but maybe it asserts RAS for both
banks and then only CAS for the bank that's actually addressed?



-- 
(\_/) Copy the bunny to your mails to help
(O.o) him achieve world domination.
(> <) Come join the dark side.
/_|_\ We have cookies.

       Message was sent through the cbm-hackers mailing list