RAM probleem: hardware of software?

Ik zit met een probleem. Ik heb hier een stukje hardware met o.a. een as7c1024b RAM chip. Nu loopt dit niet stabiel en ik heb gezien dat er tijdens het draaien af en toe (spontaan?) bytes 'omvallen'. Het betreft alleen bytes op locaties xxxFF; deze worden dan 0x00. Dus adressen eindigend op FF.

Nu is het natuurlijk de vraag: waar ligt dit aan? Zowel de hardware als software zijn zelf ontwikkeld. Het kan misschien software zijn: een pointer die verkeerd staat ofzo. Maar hoe groot is de kans dat die precies op een adres eindigend op FF staat, en dan op die manier door het hele geheugen springt?

Of toch hardware? Zijn er mensen die zoiets weleens in de praktijk hebben gezien of van gehoord hebben dat er door een of andere oorzaak 'spontaan' bits of bytes omvallen in RAM chips?

Kan natuurlijk van alles zijn. Een software fout, of hardware. Bijv. ontbrekende ontkoppel c'tjes aan Vcc, of de timing van de chip signalen klopt niet helemaal

Geef eens wat meer info. Hoe zit je bus in elkaar? (om maar eens een dwarsstraat te noemen)
Ik neem aan dat je de hardware al eens uitgewisseld hebt om een exemplarisch probleem uit te sluiten. Open deuren als stabiele voedingen ontkoppel Cs heb je neem ik aan ook al gehad.

Het systeem draait op een x86 systeem met standaard data/adresbus op 5V. Voeding loopt via 100n C en van daar naar de chip. Er is een groundvlak op de print die op 1 punt aan de GND hangt. Alle signalen werken op 5V.

We hebben 2 protoypes, en op beiden treedt het probleem op.

Maar mijn vraag is vooral: is het uberhaupt mogelijk dat er bits omvallen als er iets niet goed is?

Ja hoor, dat is heel goed mogelijk. Software kan rot doen, maar ook een glitch op een nWR line (om maar een dwarsstraat te noemen) kan hele vervelende bijeffecten hebben. Om nog maar te zwijgen van timingproblemen. Ik ken x86 hardware niet op een dergelijk niveau dat ik je een hapklaar antwoord kan geven.
Ik zou zelf een stukkie software schrijven wat in memory gaat frutten rond een address wat ellende oplevert. Eens kijken of het probleem reproduceerbaar is. Tevens heb je dan wat beter in de hand wat er op de bus gebeurt, dus je kunt ook wat meer met een logic analyser als dat niks oplevert.
Zit er nog meer op die bus wat om de een of andere reden conflicten kan veroorzaken? Wellicht is het mogelijk om dat er af te halen?

je hebt een race conditie op je onderste 8 address lijnen ...
hoe buffer je de address lijnen af ? of buffer je niet af ?

buffers zijn trager om van 1 naar 0 te springen dan omgekeerd ... ( falltime is anders dan risetime... )

schrijf eens een testprogrammatje waarbij je leest van xxff en dan schrijft naar xx00 en dan terug leest van xxxff.

schrijf een dambordpatroon ( 55 en aa hex )

ook snelhiedsverschillen tussen 8 bit brede buffers kan rottigheid geven. normaal gebruik je 74lvc16245 of 74lvc32245 om address en datalijnen te bufferen / switchen.

Op 7 oktober 2009 20:26:05 schreef free_electron:
je hebt een race conditie op je onderste 8 address lijnen ...

Ik zoiets ook eens gehad met een bussyteem. De RAM zat op een 'riser' kaart met ongeveer 10cm lange draden. Als genoeg adres lijnen een bepaalde flank hadden 'overrulden' ze een nabijgelegen lijn. het effect verdween als de riser er tussen uit werd gehaald, en het verdween ook als aan de kant van de RAM de adreslijnen wat minder hoogohmig werden afgesloten.

Ik zat ook te denken aan capacitieve koppeling tussen de datalijnen en een stuurlijn. Als er 8 in één keer van niveau wisselen, dan trekken ze misschien een CS of RD lijn mee. Pull-ups of pull-downs kunnen dan helpen. Het kan ook door koppeling via de voedingslijn komen.

Hoe zien de lijnen uit als je er met een snelle skoop op meet?

Ik ben er uit. De oorzaak bleek een 74LV4245 welke ik gebruikte om het niveau van het CS op te krikken van 3.3V naar 5V. Ik had hierbij per ongeluk van de ongebruikte poorten de uitgangen aan de gnd gelegd ipv de ingangen. blijkbaar beinvloedde dat het cs signaal. Ik kan het nog niet helemaal verklaren, maar de storing treedt tenminste niet meer op.