RS232 decoderen

fred101

Golden Member

Peter: bedankt, ook nog in Python, mijn favoriete taal. Ik heb het opgeslagen om eens mee te spelen als ik meer tijd heb.

Eric, bedankt voor de uitgebreide info. Wees gerust, liever te veel info dan te weinig en ik ben digitaal min of meer een beginner. Maar het gaat de goede kant op. Basic logic mbv 74/40/45 ben ik nu aardig in thuis. Ik ben tussendoor een 8 bitter aan het bouwen.

Mijn natte vinger zegt: maak je verder niet zo druk om die communicatie

Dat doe ik ook nu niet meer, maar omdat ik nog nooit in dit stuk van een secutest was geweest besteed ik wat meer tijd hieraan om dit te documenteren voor toekomstig gebruik.

Deze meetdoos heeft altijd met de storages doos gewerkt.

Even wat recht zetten:, lees ik dit verkeerd ?

GuidoB: Verder heeft het ding geen ROM. Flash zal programma bevatten.

Uit de datasheet:
• 8k × 8 ROM expandable externally to 64 kbytes
• ROM code protection
• 256 × 8 RAM, expandable externally to 64 kbytes

Kan vergeetachtig RAM ervoor zorgen dat je meetresultaten stuk gaan? Ik denk het wel. Het resultaat van de laatste meting zal wel in de RAM van de controller zitten.
Het wordt ook (net als vorige metingen) in de battery-backed SRAM gefrut - zo zou ik in elk geval verwachten. Als daar ellende in zit, dan snap ik wel dat er 'niks' terug kom

Ik denk dat je dat goed hebt. Ik werk nooit met die dingen, ik repareer ze alleen. Dus ik gok ook maar wat. Zal eens in een usermanual kijken. In dit geval slaan ze alles op in de PSI welke dan terug op het bedrijf worden uitgelezen naar een PC.

-De uP heeft intern RAM dus ik denk dat het SRAM alleen voor interne opslag is (voor als men geen PSI heeft)
-hij heeft rom dus flash voor de firmware is extra kosten behalve als dat interne rom te klein is.
-Als ze dan toch 2 flash ICs hebben, lijkt het mij het meest economisch, veilig en makkelijk om daar ook de cal data in te duwen.
-ik denk dat hij alleen de inhoud van wat variabelen overzet

De /EA lijn van de uP moet laag worden als hij extern geheugen aanspreekt. De ALE lijn heeft er ook wat mee te maken.

De /S1, S2 en /W lijnen gaan naar logic ICs. Een 74HC02, een 74HC541 en een 74HC138. De eerste twee zijn goed, de 138 moet ik nog testen (in mijn BK 560 ic tester) En ik zie, statistisch totaal niet verantwoord, verdacht vaak dode 138's,

Als dat niets oplevert ga ik met logicprobe, logic current tracer en/of LA aan de gang.

Ik kijk regelmatig naar wat kanalen die Arcade kasten repareren. Die doen bijna alles met logic probes. (ik heb een HP-545 en 547)

www.pa4tim.nl, Reparatie van meet- en calibratie apparatuur, ook oud en exotisch
EricP

mét CE

Ha Fred. Uit de datasheet van Flipse:

• 83C552—8 kbytes mask programmable ROM
• 80C552—ROMless version of the 83C552
• 87C552—8 kbytes EPROM (described in a separate chapter)

Waarop ik dan toch voorzichtig van mening ben dat... Nou ja, je snapt waar ik op doel. Vooralsnog blijf ik als je het niet erg vindt bij mijn mening dat het ding geen ROM heeft :).

Die 138 kan trouwens zomaar gebruikt worden voor 'address mapping' - en dus ook zomaar in de hoek zitten waar ik op doelde. Als ze zo vaak dood zouden zijn, dan lijkt met het een goede gok om er aandacht aan te besteden (of gewoon blind vervangen als er geen duidelijke doodsoorzaak is). Dat ga je zien aan de CS lijnen. Als het chippie nooit selected wordt, zal er ook nooit in geschreven worden (of uit gelezen worden).
Bij 8051 derivaten is het heel gebruikelijk dat datalijnen op de een of andere manier pull-ups hebben. Dat zou impliceren dat de enige data die terug komt 0xff is. Ik kan me zomaar voorstellen dat 'men' besloten heeft dat dat ook iets als 'leeg' betekent.

Voor je calibration data: hoe 'field servicable' is dat? Ik kan me zomaar voorstellen dat dat deel uit maakt van de firmware als-ie daarvoor 'naar de fabriek' moet. Als je de spullen hebt, dan maakt het geen moer uit of je alleen een paar bytes naar die flash moet schrijven of de hele flash opnieuw moet schrijven. Ik heb niet naar deze specifiek gekeken, maar doorgaans doe je een chip erase bij flashes. Je kunt soms ook een page erase doen. Een paar bytes erasen, dat kunstje zit er doorgaans niet in.
Het is niet zo spannend om in die flash ook een blokje config data op te nemen (in dit geval calibration data)...

[Bericht gewijzigd door EricP op 6 februari 2018 12:47:11 (22%)]

EricP

mét CE

Nog nieuws, Ferd? Ik ben wel benieuwd of je verder gekomen bent...

fred101

Golden Member

74HC138 was goed, de rest van de IC's ook. Enige wat overblijft is de processor en het SRAM.

Ik heb in mijn aantekeningen gevonden dat ik een paar jaar geleden bij een secutest de backup batterij heb vervangen. Als daarmee de cal-data was verdwenen had ik het nog wel geweten.

Er is volop communicatie met het SRAM. Zowel op controle, data en adreslijnen. De pitch is te klein om er een LA aan te hangen.

Ik heb contact gehad met de opdrachtgever.
Ik heb van hem 3 secutests hier liggen en het verzoek was dan eerst de andere twee te repareren. Eens kijken of ik nog ergens zo'n SRAM IC kan vinden. Op de secutest sloop boarden zit er geen.

Tussendoor nog even een Citroen ECU gerepareerd (niet dat er veel stuk was). Dat is de tweede ECU al, de eerste was van een Maserati. Die zie je ook niet iedere dag.

www.pa4tim.nl, Reparatie van meet- en calibratie apparatuur, ook oud en exotisch
EricP

mét CE

Jammer. Die 138 was te makkelijke geweest blijkbaar...

Dat er op de databus en address bus leven is, verbaast me niet. Daar hangt die flash ook aan en ik vermoed ernstig dat daar de firmware in zit. Ik blijf wel benieuwd waar de ellende nou zat - als je daar achter komt. Van wat je zo vertelt, lijkt die SRAM de meest voor de hand liggende kandidaat.

Voor wat betreft die pitch: het is een bus. Als je maar *ergens* bij die lijnen kunt komen, is het goed genoeg.

fred101

Golden Member

Voor wat betreft die pitch: het is een bus. Als je maar *ergens* bij die lijnen kunt komen, is het goed genoeg.

Hmm, dat had ik eigenlijk kunnen/moeten weten van mijn ongoing 8 bitter projectje. Ik zat wel in de buurt want ik heb gemeten op de processor pinnen. Helaas zo'n vierkante en ook SMD. Ik heb voor SMD alleen maar een 16 pin wide en 8 pin normaal klem maar ik kan waarschijnlijk wel draadjes aan de processor pootjes/vias etc solderen.

Wat adviseer je ? Databus en controle lijnen ? Adresbus heeft minder zin denk ik omdat ik de memory mapping toch niet weet.

Wat me nog niet lekker zit is dat ik niet weet hoe ik een defect SRAM herken. Een short is een laag maar dan 1 waar (veel ?) stroom loopt richting het sram. En de lijn wordt nooit hoog. Dat kan ik mogelijk meten met de HP-547

Een open is, denk ik, gelijk aan de high Z state dus dat wordt lastig. En als dat allemaal klopt, kan het ding dan intern kapot zijn ?

Wat me helemaal niet lekker zit is dat het ding gelijk roept dat er geen data is. Bij defect SRAM verwacht ik eerder verminkte data.

Geen idee hoe dat werkt, ik ben geen programmeur maar ik zal eens een gooi doen:
Wat weet ik: Het initiatief komt van de PSI. De processor in de meetdoos heeft net gemeten, data staat op het scherm en de software wacht op de "terug" toets of mogelijk nog andere actie.

Dan krijgt hij de vraag naar data op zijn RS232/uart ingang vanuit de PSI. (of triggert er een interrupt ? )

De software zal dan naar een routine springen die de opdracht gaat uitvoeren. De data zal waarschijnlijk een handje vol variabelen zijn. Die staan waarschijnlijk in zijn interne RAM of hij schrijft ze direct naar SRAM.

Als het dat laatste is zal hij het SRAM laten weten zat hij een adres wil lezen, daarna de inhoud van het sram adres (via intern ram ?) naar een register copieren en dan via uart naar de psi.

Er is data, die staat immers ook op het scherm dus de variabelen hebben de een inhoud. Als de data er niet is staat er niks op het scherm, lijkt me. Variabelen zijn volgens mij niet meer dan pointers (heet dat zo ?) naar een adres en de data die daarin staat. Daarnaast, als ik na de melding terug ga naar het scherm staan daar de juiste meetwaarden weer.

Ik kan me niet voorstellen dat men die variabelen direct in SRAM zet/houdt. Daar staat dan "anonieme" data. Daarnaast zou er dan ook rare info of niks op het scherm staan. Beetje zinloos om daarvoor batterij backupped geheugen voor te plaatsen en dingen dubbel gaan opslaan.

Maar mogelijk staat er ergens in een menu iets bij een meetdoos zonder psi over opslaan in sram want ik heb wel eens een secutest gezien waar om gegevens van het dut/klant wordt gevraagd (ik test altijd de losse tests/functies een voor een op een door mij gemaakt testkastje (imiteert een te testen apparaat), ik weet maar weinig over pat testen in het wild :-) en de automatische functies. Er zijn ook nog eens tig versies met tig opties. Ik heb er nu bv ook een die geen uit stand heeft en ook geen menu met alle losse functies.

Ik denk dat er in een of andere register een vlag wordt gezet na de meting. De psi aanvraag begint met een lezing van die vlag door de processor. Is die gezet dan gaat hij door, anders de melding dat er geen data is.

En daar gaat het denk ik fout. De vlag wordt waarschijnlijk niet gezet. In dat geval is waarschijnlijk het register van de processor kapot. Als dat kan tenminste.

Zit ik in de richting ? Ik wil altijd graag beredeneren/weten/meten wat er fout is. Ik hou ook niet van spontane reparaties of ongefundeerd swappen. Ik pleeg dan ook regelmatig autopsie op onderdelen. (in mijn eigen tijd) Daar leer je veel van.

www.pa4tim.nl, Reparatie van meet- en calibratie apparatuur, ook oud en exotisch
EricP

mét CE

Ha

Ik heb niet je hele verhaal gelezen, de oogleden beginnen zwaar te worden.

Dat het ding 'geen data' roept, kan heel goed met die (potentieel) defecte RAM te maken hebben. Stel het ding trekt alles laag. Het zou zomaar kunnen dat de eerste byte die gelezen wordt het aantal records is: 0.

Stel het ding doet niks. Als ik het wel heb een 8051-clone. Dan krijg je vanwege de pull-up 0xff terug (ik ga even uit van 8051-pinnen. In het kort: die dingen zijn vanuit de controller een soort van open-drain. Pull-ups extern en formeel worden ze 1 clock 'hoog' gedreven om iets van flanken te hebben, daarna zijn ze floating (en dus hoog door de pull-ups die erop zouden moeten zitten.) Ik wiet niet of dit chippie dat ook zo doet op alle pinnen, ff spitten in de datasheet). Dat kan prima 'non initialized SRAM' voor die software betekenen.

Tenslotte zou het ook zomaar kunnen dat men nog een soort van 'integrity check' op de data loslaat. Dat kan zoiets simpels zijn als een checksum.

Ofwel: er is niet zoveel van te zeggen zonder dat je de source kent.

Verder is het SRAM. Je zou verwachten dat men niks aan wear-leveling doet. Niet interessant bij dit type RAM. Dan zou het zomaar zo kunnen zijn dat het aantal records op een vaste plaats staat.

Dan is het compleet van de software afhankelijk hoe het werkt. Je kunt alle meetwaarden achter elkaar opslaan. Is de RAM vol, nou ja, dan is dat zo.
Je kunt een ring buffer maken: is de RAM vol, dan wordt de oudste data overschreven. Hoe die boekhouding in elkaar zit, is een ander verhaal.

Voor wat je zou moeten monitoren... Nou ja, eigenlijk eh... alles. Dan kun je kijken of je een WRITE tegen komt, dan weet je het adres en de data die daar zou moeten staan. Ik verwacht dat die SRAM alleen maar actief wordt als er wat opgeslagen moet worden - na een meting dus. Je zou dan verwachten dat er opeenvolgende adressen gebruikt worden.
Als je een READ doet, dan zou je verwachten dan in elk geval een deel van die adressen weer voorbij komen (de boekhouding). En daar zou je moeten kunnen zien of de data die terug komt klopt. Dan heb je enig idee.

Over dubbel opslaan: dat hoeft niet zo raar te zijn als het klinkt. Ik kan me zomaar voorstellen dat een meting doen impliceert dat de resultaten naar SRAM moeten. Echter, je hebt niet altijd een 'print doos' er aan hangen, dus de laatste meting moet het ook op display doen. Nou ja, dat komt goed uit, die data had je toch al in RAM staan.
Komt er nou een print-doos voorbij, dan hoef je feitelijk alleen de SRAM te dumpen. Het houdt de software simpel...

Voor wat betreft je 'register kapot' theorie: ik heb het nog niet meegemaakt, maar dat wil niet zeggen dat het niet kan. Een register is doorgaans ook niks anders dan een stukkie memory wat op een andere manier aan de processor hangt. In geval van deze (interne RAM), zou dat best wel eens hetzelfde kunnen zijn als de RAM.
Ik acht het niet waarschijnlijk. Registers heb je altijd te kort, dus je zou verwachten dat er RAM voor gebruikt wordt. Ook dit is SRAM. Ik geloof er geen moer van dat daar 1 locatie stuk gaat - dan zou er een heel stuk uit moeten liggen en dan had je meer ellende moeten hebben.

Verder zou ik het zo maken dat alle relevante data in SRAM staan. Bij een 'dump' is dat simpel in software. Dat wil niet zeggen dat iemand anders het niet anders zou kunnen doen :) hahahaha.

Overigens heeft Farnell een replacement voor dat memory. 1562898. De kosten zijn het niet. En ik verdenk je er zomaar van dat ding in 10 minuten te wisselen...

[edit]Dan nog ff over die 8051... Dit is generiek en zou dus niet 100% hoeven te matchen met jouw controller. Een 8051 heeft (vanuit de processor gezien) 2 soorten RAM: intern en extern. Dat heeft met name te maken met hoe je het adreseert. 'Intern' is maar een handje vol bytes. En eigenlijk bijna altijd te weinig.
Hier begint het ingewikkeld te worden. Het 'externe' stuk (wederom, vanuit de core gezien) is bij jou zo te zien opgesplitst in 2 delen: een deel in dezelfde housing als jouw controller en een deel wat er extern aan hangt. Dat laatste deel is wat we hier steeds de SRAM noemen. Dat andere stuk is de RAM waar de datasheet het over heeft.
Vanuit de software gezien zou het zomaar kunnen dat het een aaneengesloten adres bereik is - of ook niet. De meeste compilers kun je wel vertellen waar wat zit en die regelen dan de indeling wel voor je.

En dan als laatste: het is de bekende open deur. Maar ik heb nog nergens gelezen dat de voeding van die SRAM op orde is. Het is battery-backed, zo te zien heeft het ding geen apart pin daarvoor. Dat betekent dat de voeding niet aan de voeding van de controller hangt, maar dat daat wat extra trucen voor zijn. Is de voeding goed??

[Bericht gewijzigd door EricP op 10 februari 2018 00:36:29 (18%)]

fred101

Golden Member

Over dubbel opslaan: dat hoeft niet zo raar te zijn als het klinkt. Ik kan me zomaar voorstellen dat een meting doen impliceert dat de resultaten naar SRAM moeten. Echter, je hebt niet altijd een 'print doos' er aan hangen, dus de laatste meting moet het ook op display doen. Nou ja, dat komt goed uit, die data had je toch al in RAM staan.
Komt er nou een print-doos voorbij, dan hoef je feitelijk alleen de SRAM te dumpen. Het houdt de software simpel...

Ik denk dat ik het begrijp. Het is net zo als bv een tekstverwerker. Je hebt de data op het beeldcherm (en intern ram) en je slaat het steeds automatisch op in je HD.
De Secutest die ik nu net klaar heb vraagt voor de test begint of je data van het DUT wil ingeven en of het intern of in een psi moet. Dan is batterij-backup sram wel logisch.

Ik acht het niet waarschijnlijk. Registers heb je altijd te kort, dus je zou verwachten dat er RAM voor gebruikt wordt. Ook dit is SRAM. Ik geloof er geen moer van dat daar 1 locatie stuk gaat - dan zou er een heel stuk uit moeten liggen en dan had je meer ellende moeten hebben.

Ik denk dat je daarmee wel gelijk hebt. Ik haalde wat dingen door elkaar. Ik dacht aan 1 bit, dus 1 pootje van een port maar dat is helemaal geen register. Dom, dom

Overigens heeft Farnell een replacement voor dat memory. 1562898. De kosten zijn het niet. En ik verdenk je er zomaar van dat ding in 10 minuten te wisselen...

Bedankt, scheelt me weer zoeken. Maar dan nummer: 1562899 in TSOP behuizing. Dat is een pitch van 0.5 mm. Het moeilijkste deel is meestal het schoonmaken van de pads. Die moeten compleet vlak zijn en zijn zo smal dat ze mechanisch erg kwetsbaar zijn.

En dan als laatste: het is de bekende open deur. Maar ik heb nog nergens gelezen dat de voeding van die SRAM op orde is. Het is battery-backed, zo te zien heeft het ding geen apart pin daarvoor. Dat betekent dat de voeding niet aan de voeding van de controller hangt, maar dat daat wat extra trucen voor zijn. Is de voeding goed??

Dat is een goede, ik heb de voeding gemeten, daar begin ik altijd mee ongeacht wat de klacht is. Ik heb wel met de ding uit de spanning op het SRAM gemeten maar ik heb met de meter aan niet op het SRAM zelf gemeten. Wel op de processor. De backup batterij zit een heel eind van het SRAM en de RTC af. Er zit zo te zien wat circuit aan vast. De Vcc van het SRAM hangt niet direct aan de Vcc van de rest, anders zou het batterijtje alles moeten voeden. Misschien schakelt de batterij wel af maar de Vcc niet aan. Dat zal ik controleren (als ik de andere secutests af heb)

Mbt RS232, ik heb hier nog steeds een meetontvanger staan die kapot was, (dit topic Dat ding mist nu helaas zijn cal data. Die heeft ook RS232

Ik kan die ook wel eens op de zelfde manier aan de laptop en LA hangen. Het ding zal ook wel een soort commando set hebben. Ik heb de eprom gelezen dus ik heb de firmware. Die set zal als ascii tekst daar in kunnen staan.

Is er een soort standaard protocol of syntax om via RS232 iets te bedienen. Dit is ook jaren 90 spul, de tijd van losse modems en seriële printers.
Bij de secutest werkte een "?" dat was ook maar een gok.

www.pa4tim.nl, Reparatie van meet- en calibratie apparatuur, ook oud en exotisch
PE9SMS

Special Member

Bij een meetapparaat zou dat best SCPI kunnen zijn.

Een andere bekende standaard uit de wereld van de modems zijn de AT commando's (Hayes commands).

bprosman

Golden Member

Dat is (was) maar helemaal aan de ontwerper. Heb ook veel meetinstrumenten gezien die een niet ASCII protocol hadden.

De jongere generatie loopt veel te vaak zijn PIC achterna.
EricP

mét CE

Voeding: ff kijken wat de 'backup' is. Als dat een batterij is, dan is 2 dioden niet ongebruikelijk - er loopt tenslotte 'geen' stroom, dus er is ook 'geen' spanningsval over die dioden (in elk geval niet in rust).
Als het iets is wat opgeladen kan worden (let op: die bestaan ook in lithium-2032 variant), dan kan het wat simpels met een diode & weerstandje aan de voeding zijn. Als die cel dan teveel stroom gaat trekken (sluiting, leeg, lek), dan heeft je SRAM ook niks meer.
Verder zijn er ook RTC chippies met laad-intelligentie aan boord. Dus die zouden ook nog wat kunnen betekenen. Zat varianten zeg maar :)

Pads schoon maken: ik neem aan dat ik je over solderen niet zoveel meer kan vertellen, maar... het lastigste is in mijn optiek altijd om de boel los te krijgen zonder de PCB te beschadigen. Die pads... ach, stukkie litze en dat er voorzichtig met de punt van de bout overheen trekken. Bij voorkeur in de richting die de pads hebben - geen randjes, dus je trekt moeilijker wat stuk. Volkomen vlak? Mwah... Gewoon loodhoudend tin en litze doen wonderen zeg maar :)

Voor dat protocol: ASCII kan, maar het hangt maar helemaal van de programmeur af. En van de data die overgedragen moet worden. Als je bijvoorbeeld iets hebt wat je met 'fixed length' zou kunnen doen, dan is een binair protocol vaak makkelijker te implementeren. Niet te reverse-engineeren, maar daar zal die bedenker niks van hebben - niet zijn probleem tenslotte.

[oude doos]Ik heb ooit een binair protocol van een alarmpaneel zitten reverse-engineeren voor jawel... de fabrikant. Afdeling die die dingen ontwikkeld had was opgedoekt en een paar jaar later komen ze erachter dat er nog wel een aantal gebouw beheers systemen zijn waar ze aan hangen en dat ze daar contractueel nog wel wat mee moeten. De documentatie bewaren was destijds een brug te ver. Begonnen met de bitrate terug vinden - memory scope en de kortste '1' of '0' kon dat vertellen. Een LA was natuurlijk makkelijker geweest, maar ja... 25 jaar terug he...
Als je dat eenmaal weet, dan kun je de framelength terug gaan vinden. Wederom met die scope. Dan is het ff kijken of of er een parity bit is en hoeveel stop bits er zijn. En dan heb je daarna de data. En dan kun je pas wat gaan bekijken.
Nou ja, het is een paar weken werk geweest. Ik kon daarna alles 'lezen' wat eruit kwam en alle wenselijke commando's die erin moesten geven. Gelukkig was het niet encrypted, dan had je echt je lol op gekund.
COMTAP heeft mij destijds erg geholpen. Een DOS tool die 2 streams parallel kan weergeven - zo zie je heel snel een vraag & antwoord spel. Tegenwoordig natuurlijk niet zo relevant meer, een simpele LA die dat kan kost niks meer... Maar toen was het erg handig[/oude doos]

Schimanski

Golden Member

Fred, ik heb nog een Compass Microtest liggen, naast ethernet kan deze ook inline RS-232 verkeer analyseren. Misschien kun je er wat mee. Ik zal hem voor je meenemen naar Rosmalen.

What, me worry? // Radiozendamateur - PA2HGJ // Stuff is the junk you keep -- Junk is the stuff you throw away // Tinkeo Ergo Sum
fred101

Golden Member

Het nieuwe SRAM is binnen. Maar eerst moet ik de rest van de stapel weg werken.
Desolderen is geen probleem. Zowel smd als TH. Kwestie van goed gereedschap. Hier hebben ze gelukkig de onderdelen niet ook nog vast gelijmd. Ik gebruik zelden litze, ik heb wel een speciale nozzle voor mijn Pace SX100 om pads te stofzuigen. Maar voor dit soort minipads gebruik ik meestal een heel dunne gewone nozzle. Met dit soort footprints neem ik liever geen gokjes. Ben gerust, het solderen komt wel goed.

Voor meelezers, Pace heeft een youtube kanaal met een serie heel goede video's over solderen en desolderen.

De batterij is niet oplaadbaar en ook nog goed. Er is een 0,3V spanningval als de secutest uit staat. Er zit ook een RTC in. Ik heb wel eens zo'n Dallas RTC van een nieuwe batterij voorzien. En pas geleden een Dallas IC socket gemod met externe batterij.

Leuk oude doos verhaal. (ik heb 2 LA's die ouder dan 25 jaar zijn ;-) )

Edit, mans, bedankt dat gaat zeker van pas komen.

www.pa4tim.nl, Reparatie van meet- en calibratie apparatuur, ook oud en exotisch
fred101

Golden Member

Ik heb gisteren de Compass Microtest aan de Chase meetontvanger gehad. Dat bracht heel snel aan het licht dat er geen enkele communicatie was. De cutecom commando's kwamen niet door. De oorzaak was zo ook snel gevonden. Mijn null-modem kabel was geen null modem kabel.
Bij de Secutest ging dat per ongeluk goed (door combinatie 1:1 en null-modem verloopkabeltje)

Die null-modem omgebouwd en nu was er comunicatie.

Echter, wat ik ook naar de Chase stuur, het antwoord is altijd E7 (2 ascii tekens, niet hex)

Maar dat is misschien een setup ding. De chase kan voor parity XX, OO, EE, en nog wat combinatie van die letters, bv OE.
Het ding stond op 9600, 8 bit, 2 stopbits en parity XX. Ik heb hem op 9600, 8, 1, en parity=XX gezet.

Cutcom kan mark, space, even, odd en none (even uit mijn hoofd)
Ik had hem dus op XX staan. (2x don't care, ofwel none ? )

Ik heb het rom zitten uitpluizen en geprobeerd het in regels op te maken. Er zit de nodige leesbare text in en de meest voorkomende combinatie onleesbare text is ‹å]ÃU

Ik hoop dat daar de rs232 commando's bij zitten maar ik zie het zo snel niet. Er staan wel woorden die er waarschijnlijk mee te maken hebben onder het commentaar: meldingen. Zou iemand er even een blik op willen werpen

www.pa4tim.nl, Reparatie van meet- en calibratie apparatuur, ook oud en exotisch
EricP

mét CE

Nou lijk ik te begrijpen dat je al tegen dat ding aan kunt kletsen met een ander stuk hardware. Of heb ik dat verkeerd geïnterpreteerd? Als dat zo is... dan zou ik zeggen... 'luister' mee en kijk hoe die communicatie in elkaar zit.

Als dat niet zo is... Tsja... Je kunt er eens wat van die strings naar toe sturen. Maar het zou zomaar kunnen dat elk commando een 'start' en een 'stop' heeft. Die zie je dan niet in de ASCII, maar ze moeten er wel zijn om de boel aan de gang te krijgen. Kortom: je kunt mazzel hebben dat het botweg een commando beginnen en met CR (of LF of CR/LF... daar ga je al) afsluiten genoeg is. Maar het kan ook zomaar zijn dat dat niet zo is...
Als je ff mee kunt luisteren, dan ben je daar natuurlijk in een paar minuten achter...

fred101

Golden Member

Ik heb die netwerk analyser van Mans er tussen hangen. Daar zie ik het ingetypte commando van mijn RS232 terminal programma (cutecom) langskomen op de TX lijn en direct daarna op de RX lijn dat E7 als response. En dat verschijnt ook in het RX veld van cutecom
Zonder analyser er tussen het zelfde.

De lijn nivo's uit de Chase zijn +10 en -10 en gnd. (bij open lijn)

Als ik niks stuur komt er niks terug. Je kunt hem helaas niet op het apparaat in remote mode zetten.
Het is geen ramp als het niet lukt. Hij werkt alweer maar het is best leerzaam voor die keren dat iets wel via RS232 moet. (zoals bij de secutest uit dit topic. Daar weet ik nu in ieder geval zeker dat de communicatie werkt en dat mogelijk het sram fout is.

Nu eerst uitzoeken hoe de display contrast van een secutest werkt, ik heb er nu een die totaal niet reageert en heel flets is. Lijkt een vervangingsdisplay. Geen datasheet te vinden. Ook geen potmeter waarschijnlijk. Zal wel iets met pwm zijn. Eerst eens meten wat er gebeurd

www.pa4tim.nl, Reparatie van meet- en calibratie apparatuur, ook oud en exotisch
EricP

mét CE

Ow, je hebt niks wat ermee kletst :)
Dan kan ik alleen maar zeggen: prettige wedstrijd.
Een E7 kan duiden op iets binairs. Of op een 7-bits iets waar jij 8 bits leest. Ik maak er zomaar geen chocolade van...

fred101

Golden Member

Jawel, ik kletst er tegen, maar dan via een terminal programma :-)

De originele software zal wel op een 5,25 flop hebben gestaan en onder DOS gedraaid hebben.
Het ding is uit begin jaren 90 dus heel high tech software zal het niet zijn geweest. Daarom hoopte ik dat ik het een of andere reactie kon ontfutselen.

Er was software, dat las ik in een of ander onderzoek waar dit ding werd gebruikt, en in de firmware staat in ieder geval het woord "remote" en ook "GFC,,4903,,, ,,CONNECTED,,, ,,,,," "monitor" en "echo"

www.pa4tim.nl, Reparatie van meet- en calibratie apparatuur, ook oud en exotisch
fred101

Golden Member

Voor mensen die ook een Chase hebben. REM zet de ontvanger in remote. Ik heb de volgende commandos gevonden daarnaast staat de repons en als ik weet wat ze doen zet ik het er achter. De meeste commandos lijken ook als verkortingen te werken. Zo geeft alles van FR tot FREQUENCY de frequentie.

AB AB
AS geeft -130,33992 = de gemeten power in dBm , continu (antenna signal ? )
BS geeft 0x18-130.3, dat is ook doorlopend vermogen in dBm Op de display komt: high speed display locked
CL de zelf calibratie routine
CV CV
DB DB
DX DX
DY DY Daarna "hangt" hij
FR = FREQ = Frequency in Hz maar met bv FR 10000000 zet je hem op 10 MHz en FR +100 maakte de frequentie 12,5 kHz hoger
HS HS
LT geeft ++LT
MC MC
MG MG
PV PV
RS o----- daarna verschijnt remote permanent op display ipv afwisselend met frequentie.
SG -23,3
SQ = SQUELCH en geeft -24 maar je kunt hem ook zetten door een getal tussen -25 en +60 er achter te zetten bv SQ 12
SS SS
ST = STATUS geeft 1N32NAYNN6L maar ik kreeg ook een keer 1N12UFYNN6L
VN 4403 4:00 5128, zal firmware versie en type ontvanger zijn
ZZ geeft een enorme reeks getallen aflopend van 620 tot -232 Dat zou iets met calibratie te maken kunnen hebben

3 letter commandos
VOL gaf 1 keer de respons ROL maar daarna niks meer.
ALL geeft een enorme reeks A's in de terminal eindigend op LL
LOC zet hem terug naar local
MON geeft monitor en
>(mon)
?
>

Daarna reageert hij niet meer.
Als ik mon (100) type komt er:
mon(100))
?
>

Meer heb ik nog niet gevonden. Er zijn er waarschijnlijk een paar waar iets achter moet. Sommige doen iets en een tweede keer het zelfde commando brengt hem weer terug, zoals bv bij AS

In de firmware staat twee keer de melding: INPUT SIGNALGENERATOR AT 20:0/B>V AND PRESS SOFTKEY
Dat lijkt me een calibratie instructie.

Nu in de firmware naar deze woorden zoeken.

www.pa4tim.nl, Reparatie van meet- en calibratie apparatuur, ook oud en exotisch
fred101

Golden Member

Even terug naar het originele slachtoffer. De Secutest.
Vandaag Erics opmerking nagetrokken. Na opstarten is de voedingspanning van het SRAM 4,6V. De voedingrail zelf is 5V.

Daarna het SRAM vervangen. Dit maakte echter geen verschil. Alle IC's zijn getest, nieuw SRAM, weerstanden en torren zijn goed. Enige wat overblijft is de processor. Maar een fout op de data of adreslijnen van de uP kan volgens mij niet want het apparaat werkt verder prima. Blijven de controle lijnen over.

www.pa4tim.nl, Reparatie van meet- en calibratie apparatuur, ook oud en exotisch
EricP

mét CE

Da's naar... Het was ook te simpel geweest. Die 0.4V komt waarschijnlijk door een diode waaruit de boel gevoed wordt.

Maar jij zegt... controle lijnen blijven over. Ik kan het mis hebben (heb nu geen datasheet van die controller bij de hand), maar... op de WRITE (het zal wel een nWRITE zijn) na, zit de ROM (flash in jouw geval als ik het goed onthouden heb) ook aan al die controle lijnen. Aangezien volgens het nummer eerder in dit topic (en als ik het goed onthouden heb) de controller met exact dit nummer ROM-less is, betekent dat dat als het ding inderdaad draait, er blijkbaar uit FLASH gelezen wordt - anders draaide het tenslotte niet.
Blijft nog wat address decodering over. En dat zit bij een 8051-kloon een beetje ingewikkeld. Ze hadden wat lijntjes tekort.

Ik ken dit chippie niet, dus wat hier staat heeft puur betrekking op een 'originele' 8051. Echter, zo'n beetje alles aan klonen volgt dat min of meer om compatible te blijven.
Met kwam met address wat I/O tekort en heeft dat opgelost met een losse (8-bit) latch. Wat er feitelijk gebeurt is dat er een deel van het address naar buiten wordt gespuugd. Met de Address Latch Enable (ALE, of misschien wel nALE) wordt dat stuk in een 8-bit latch gefrut. Uit m'n hoofd zijn dat de hoogste 8 bits van het address. Dan komt het 2de deel, de 8 lage bits en dan heb je per saldo een 16-bit address bus (vandaar de 64k die er origineel aan XRAM en ROM mogelijk waren, XRAM kom ik zo even op terug.
Dan komt er nog 1 'bit' naar buiten die iets vertelt over XRAM of ROM (zo uit m;n hoofd heet dat ding nPSEN). Als je de adressering lineair zou beschouwen, dus feitelijk een 17-bit address bus.

Intel heeft destijds niet voor een lineaire adressering gekozen. In de controller wordt duidelijk onderscheid gemaakt tussen ROM, RAM en XRAM (andere instructies, andere opcodes).

Dan dat RAM... Het beest heeft RAM en XRAM. RAM lijkt me duidelijk. XRAM staat voor 'external RAM'. Het geeft ook meteen aan waar oorspronkelijk de RAM zat: internal. Echter, in hun wijsheid heeft Intel dat beperkt tot 128 bytes, later uitgebreid naar 256 bytes. Meer gaat het ook niet worden, want... de core kan maar 8 bits adressering aan.
256 bytes is leuk voor wat 'book-keeping' als stack enzo, maar voor 'data' is het wat krap zeg maar. Daar komt dan de XRAM weer om de hoek kijken.

Tot zover over naamgeving bij een 8051. Het chippie zelf heeft natuurlijk niet in de gaten wat er aan hangt. Als je op basis van een address data terug krijgt, dan is het tevreden ('niks' terug krijgen kan niet, de data lijnen zullen altijd een niveau hebben). Op die manier kun je 'memory mapped I/O' maken. Ofwel: als je er bijvoorbeeld 'maar' 32k RAM aan hangt, dan heb je 32k over om andere dingen mee te doen. Als je op een specifiek address een 8-bit poortje enabled, dan heb je daarmee op dat address een 8-bit I/O poort... Moeilijker is het niet.

Dan terug naar het slachtoffer...
Op de controller na, heeft Fred alles getest. Alhoewel ik hem op zijn woord geloof, geloof ik het nog niet helemaal :) (sorry Fred, niks persoonlijks, maar het lijkt soms wel black magic wat die chippies doen :) )
Ik ga niet zeggen dat het niet kan, maar... het lijkt me niet waarschijnlijk dat er nou net de nPSEN lijn of de WRITE dood zijn. Gelukkig kun je dat vrij makkelijk testen: het ding runt normaal uit ROM. Zodra je wat met RAM gaat doen, dan moet er leven op de nPSEN zijn. De nRD (read) is minder relevant, die is alleen interessant in de context met nPSEN. Voor zover ik weer, wordt die lijn normaal ook bij ROM (in jouw geval FLASH) gebruikt, dus als de controller loopt, dan moet dat wat doen. Er moet in elk geval leven in zijn!
Dan blijft de nWR over. Als er wat in RAM geschreven wordt, dan moet daar wat gebeuren.

Voor wat betreft het al dan niet op 'interne ROM' draaien: toen dit topic ontstond, heb ik een datasheet van dat chippie bekeken. Op dat nummer, kwam alleen ROMLESS naar voren. Nou is er nog een veter die het chippie kan vertellen of-ie op interne ROM moet draaien of niet. Uit m'n hoofd een EA ofzo, waarbij ik je ff niet kan vertellen waar dat voor staat (maar de datasheet kan dat vast wel). Je zou eens kunnen kijken waar die aan hangt. Ik vermoed keihard aan voeding of ground.

Tenslotte zou er ook nog de mogelijkheid kunnen zijn (hoe smerig ook) dat men verzonnen heeft dat het RAM 'geformateerd' moet zijn. Ofwel: er moet een stuk data in staan om de boel te laten werken. Als die om welke reden dan ook 'stuk' is, dan zou de software kunnen besluiten RAM niet te gebruiken. Dat zou impliceren dat als de backup batterij er ooit mee stopt, het niet voldoende is om die te vervangen. De achterliggende gedacht is natuurlijk dat die dingen zo nu en dan nog eens terug komen en dat er dan goed aan verdiend kan worden.
Als ik het goed begrepen heb, heeft Fred bij zo'n ding al eens een backup batterij vervangen. Daarom lijkt me dat niet waarschijnlijk.

Kort samen gevat: Kijk eens of er leven is op de nPSEN lijn. Dat moet er zeker zijn op het moment dat je in de software iets met RAM doet. Een logic probe is goed genoeg, de vraag is of het lijntje 'leeft'.
Als die om welke reden dan ook niet leeft, dan kan er alleen in ROM gelezen worden. Verder kun je nog eens kijken of er leven is op de nWR lijn. Die moet klapperen als er in RAM geschreven wordt. En wellicht ook als men memory-mapped I/O geknutseld heeft. Ook hier is een logic probe genoeg: kijk of er leven in zit als je wat naar RAM schrijft.

Als in een van beiden helemaal geen leven zit, dan heb je daar in elk geval rottigheid te pakken. Let wel: het zou nog steeds zo kunnen zijn dat men alleen bij 'boot' ff kijkt of er wat zinnigs in de RAM staat en als dat niet zo is er gewoon niks meer mee doet.
Een boot kun je normaal forceren door (uiteraard terwijl de boel onder spanning staat) de reset lijn van de controller ff laag te trekken. Doorgaans is dat een pull-up weerstand met danwel een C naar GND, danwel iets met een open collector (open drain) uitgang wat 'm laag kan trekken. Alhoewel natuurlijk niet uit te sluiten, heb ik nog niet gezien dat daar iets met een totempole ofzo aan hangt. Maar zeg nooit nooit...

Tevens kun je nog eens kijken of er wat gebeurt op de diverse control lijntjes van de RAM - had ik geloof ik al eens gesuggereerd. Dan heb je ook meteen een idee of de address decodering wat doet - er zou in elk geval op een ENABLE wat moeten gebeuren, het ding deelt een databus met ROM (Flash) en moet dus 'aan/uit' gezet kunnen worden. Wederom: alleen op RAM access.

Alhoewel ik het (nog) niet met Fred eens ben dat er ellende in de controller zit (in mijn ervaring doet het ding daar nog veel te veel voor), denk ik dat alles wat interessant is in Flash zit. Dat impliceert dat je die controller zomaar zou moeten kunnen vervangen.

Tenslotte hoop ik dat ik niet al teveel onzin heb opgeschreven. Alhoewel ik destijds redelijk diep in 8051's gedoken ben, is 'destijds' wel meer dan 10 jaar terug en het meeste wat hierboven staat komt is wat ik er nog van weet. En nu maar hopen dat mijn memory beter is dan dat van die secutest :)

Ik weet niet of het al uitgesloten is. Maar zou het kunnen dat het apparaat zowel MET als ZONDER Ram uitgeleverd kon worden. Dan met/zonder de mogelijkheid om dingen op te slaan in RAM.

Dan kan het zijn dat ie bij opstarten een "memory test" doet en verder weigert om de boel te gebruiken als ie merkt dat het geheugen niet 100% ok is?

four NANDS do make a NOR . Kijk ook eens in onze shop: http://www.bitwizard.nl/shop/
fred101

Golden Member

Eric. Bedankt voor de uitgebreide uitleg. Ik zal eerst de rest nog eens goed testen. Dat digitale foutzoeken is best leuk nu ik een beetje beter weet hoe het werkt. Ik blijf nog wat onwennig met dat multiplex en bus gebeuren.

Na doorspitten datasheets kom ik wat dingen tegen die ik niet snap:

- PSEN: active low read strobe voor extern program memory, dus alleen voor het Flash ?

- ALE: bedient een externe latch voor de 8 LSB lijnen van port 0. Alleen de LSB bits gaan daar blijkbaar door.
Volgens de datasheet: Poort0 is AD0-AD7, (data en adres)
Poort2 is AD8-AD15 Dat zijn er toch 16 adresbussen ? Ze lijken ook tristate.
De databits gaan blijkbaar ook door poort0. Daarom kon ik geen aparte databus vinden.

Is die latch dan voor de data en niet voor een adres ?

Het SRAM heeft 8 data en 16 adreslijnen.
Als die latch kapot is, alleen voor data bedoeld is en alleen voor het SRAM werkt dan zou dat de fout verklaren. Of niet ? Adres komt wel aan maar data niet ?
Aan de andere kant, als de data van het flash ook door die latch gaat dan kan de latch niet fout zijn. Het defect moet iets zijn wat alleen maar door het SRAM wordt gebruikt. Dat kan lezen en schrijven zijn.

Datasheet SRAM:
- Write: CE=L, CE2=H, OE=X, WE=L
- Read: CE=L, CE2=H, OE=L, WE=H
- 8 datalijnen en 16 adreslijnen
Het moet dus iets zijn wat deze lijnen bedient. De processor zelf of een of andere logic geval er tussen.

Dan is de WR lijn de enige die alleen voor SRAM wordt gebruikt. Het SRAM heeft CE en CE2, CE moet altijd laag zijn en CE2 altijd hoog. Behalve in standby. Mogelijk blijft hij in standby staan. Dat kan ik testen. Dat zou de boel verklaren en ik dat zou buiten de processor om kunnen gaan.

Blijven over OE en WR van het SRAM. Ik denk dat de processor RD lijn dan aan OE zit en de WR lijn aan WR van het SRAM. Daar hoeft niets tussen want er is maar SRAM IC. Maar er is wel de footprint voor een tweede dus er zou iets tussen kunnen zitten

Ik zal straks eens een blokschematje maken met de bussen controle lijnen en rand IC's erop.

REW, Even korte samenvatting:
- De secutest werkt wel (als PAT tester) maar wil zijn data niet naar een externe printer/opslag doos sturen.
- Dat gaat via RS232. De opdracht komt van de opslag doos. Die opdracht komt ook aan. (als ik de lijn afluister/decodeer met Man apparaatje. De secutest reageert dan met : geen data aanwezig
- De processor (P80C552EBA) gebruikt twee flash IC's met firmware en een batterij backupped SRAM
-hele oude secutests hebben zo te zien dezelfde processor (PCB80C552-5-16WP, die heb ik twee uit gesloopte secutests liggen, helaas in onbekende staat)), 1 flash(of eprom ? zit onder stickertje) en geen backup batterij.

Eric:

www.pa4tim.nl, Reparatie van meet- en calibratie apparatuur, ook oud en exotisch
guidob

Overleden

De processor zet eerst de adreslijnen goed en daarna wordt data gelezen of geschreven op de datalijnen. Om 8 lijnen uit te sparen, worden die dubbel gebruikt.

Eerst de adresbus zetten. Dan de 8 lijnen inklokken in de latch, dan blijven die adres lijnen staan als de processor ze daarna verandert.

Dat de datalijnen ook gezet worden op dat moment maakt niets uit, er wordt geen chip aangesproken.

Dan de data lijnen goed zetten (bij schrijven) en een read of write doen.
De andere adreslijnen blijven hierbij staan. De 8 achter de latch ook; alle adreslijnen staan goed.

Is puur om 8 i/o lijnen uit te sparen. Bekijk laatste video van artifact electronics (youtube). AE#37 over een drummer sequencer. Daar zit ook zoiets in en hij heeft het er over (de latch was daar de boosdoener).

Maar die is dus voor alle communicatie met andere chips. Dus als de rest werkt, dan zou je richting SRAM adresdecodering moeten denken. Kwestie van de logic analyser eraan hangen.

Het zou kunnen dat er een specifieke chip tussen zit die de voeding en battery backup regelt. Die schakelen ook de CS naar de RAM af, zodat er niet random geschreven wordt in de RAM bij uitschakelen (de processor kan dan van alles doen). Een DS1210 bijvoorbeeld of een MAX691. Die heb ik in mijn Prema's geprutst voor dat doel.

[Bericht gewijzigd door guidob op 26 februari 2018 19:49:16 (14%)]

EricP

mét CE

Luciferhoutjes nodig, dus heel in het kort. En geen enkele garantie op correctheid :)

Ik blijf nog wat onwennig met dat multiplex en bus gebeuren.

Tsja, pootjes waren duur. Dus men heeft wat afgekl**t in het verleden. Dit is nog lang niet het ergste :)

- PSEN: active low read strobe voor extern program memory, dus alleen voor het Flash ?

Nou ja, kort door de bocht: je hebt 16 address lijnen (na de latch). Daarmee kun je 64k adresseren. Nou wil je diezelfde address lijnen gebruiken voor 'ROM' ('program store') en XRAM. Dan moet je dus wel vertellen waar het betrekking op heeft. Dat doet de nPSEN.

ff een open deur waarvan ik botweg aangenomen heb dat Fred die kende (en waarschijnlijk is dat ook zo): een n (kleine letter) voor een signaal naam is een manier van noteren dat dat ding 'actief laag' is. Ofwel geïnverteerd, zo je wilt 'negated' (daar komt die n ook vandaan denk ik). Een nPSEN is dus net zoiets als een PSEN, maar dan nagated. Ofwel: het ding is laag als de 'program store enable' bedoeld wordt. Ofwel: laag als er in ROM (in jouw geval flash) gelezen wordt.

- ALE: bedient een externe latch voor de 8 LSB lijnen van port 0. Alleen de LSB bits gaan daar blijkbaar door.
Volgens de datasheet: Poort0 is AD0-AD7, (data en adres)
Poort2 is AD8-AD15 Dat zijn er toch 16 adresbussen ? Ze lijken ook tristate.
De databits gaan blijkbaar ook door poort0. Daarom kon ik geen aparte databus vinden.

Ik vrees dat ik je een beetje op het verkeerde been gezet heb. Het is lang geleden... Nu je dit zo schrijft... Het zou zomaar kunnen dat P0 de gemultiplexte data & addresbus is.
Ofwel: er staat een deel van het address op als er iets met ALE gebeurt. En anders is het de data bus. Dus als ik dit zo lees niet zoals ik eerst schreef (nl. 'hoge' en 'lage' bit op 1 poort...). Excuses. Bijna goed (en daarmee toch fout :) ).

Even voor de terminologie: een bus is een set signalen. De complete bus bevat dus address, data en control. De address bus is dus feitelijk het deel wat het address bevat. Na de latch dus eigenlijk 16 bits, A0 t/m A15 (en, met een beetje goede wil kun je er soms ook de nPSEN nog bij rekenen, maar laat dat maar ff zitten, in de context van dit verhaal niet relevant en maakt de boel voor nu alleen maar complexer.)

Is die latch dan voor de data en niet voor een adres ?

Neen. Op die port zet je een stuk address. Dan clock je dat in de latch. Daarmee bepaal je een deel van het address - en dat staat nu 'fixed' in de latch. De actie om dus een byte uit XRAM te lezen is dus: deel van address op P0, nALE pulsen, 2de deel address op P2, P0 in 'tri state' zetten, nRD laag, P0 lezen, nRD hoog. En dat gebeurt allemaal 'vanzelf' zonder dat de programmeur er wat mee te maken heeft. De volgorde is door mijzelf verzonnen - functioneel kun je ook prima eerst A8-A15 op P2 setten en dan pas P0 en nALE doen. Je zou ook nog het hele address op P0 en P2 kunnen zetten, dan nALE pulsen, P0 tri state maken en dan lezen. Geen idee hoe de hardware het precies doet - en feitelijk ook eigenlijk nooit relevant.

Het SRAM heeft 8 data en 8 adreslijnen.

Ik denk dat die meer address lines heeft. Anders kun je maar 256 bytes in dat ding kwijt. Immers, 28=256....

Als die latch kapot is, alleen voor data bedoeld is en alleen voor het SRAM werkt dan zou dat de fout verklaren. Of niet ? Adres komt wel aan maar data niet ?

Neen, die latch maakt deel uit van de adressering. Dus dan gaat er vele meer 'stuk' (in de zin van 'bits die omvallen').

Aan de andere kant, als de data van het flash ook door die latch gaat dan kan de latch niet fout zijn. Het defect moet iets zijn wat alleen maar door het SRAM wordt gebruikt. Dat kan lezen en schrijven zijn.

Bijna goed. De adressering voor de ROM (flash) gaat ook door die latch. Vandaar dat ik zeg: aangenomen dat de firmware in die flash zit en het ding loopt, dan moet er al best veel 'bus' zijn wat werkt.

Datasheet SRAM:
- Write: CE=L, CE2=H, OE=X, WE=L
- Read: CE=L, CE2=H, OE=L, WE=H
- 8 datalijnen en 8 adreslijnen
Het moet dus iets zijn wat deze lijnen bedient. De processor zelf of een of andere logic geval er tussen.

Je hebt meer dan 8 address veters. Ik gok op minimaal 16...

Dan is de WR lijn de enige die alleen voor SRAM wordt gebruikt. Het SRAM heeft CE en CE2, CE moet altijd laag zijn en CE2 altijd hoog. Behalve in standby. Mogelijk blijft hij in standby staan. Dat kan ik testen. Dat zou de boel verklaren en ik dat zou buiten de processor om kunnen gaan.

Ja, nou, niet helemaal. Een CE is een Chip Enable. Ze hebben om interfacing makkelijk te maken een CE en een nCE veter. Als jouw ontwerp positive logic gebruikt, dan gebruik je de ene (en knoop je de andere hard vast) en als je negative logic gebruikt dan gebruik je het andersom. Idee is dat de RAM daarmee universeel voor diverse bussen is.
Verder is er ook nog een samenspel met nPSEN en eventueel address mapping.

Laat je niet in de luren leggen door het woordje 'stand by'. Het betekent niet dat het ding 'uit' gaat ofzo. Het betekent alleen dat het chippie ff nergens op reageert, niks doet.

In het kort: op de address bus kun jij niet het verschil zien tussen een READ uit XRAM en een read uit ROM (flash). Het enige wat daar verschil in maakt is de nPSEN veter. Het is niet ongebruikelijk om die - al dan niet via wat logic - aan een CE te knopen.

Verder zou je met bijvoorbeeld (niet betrekking hebbend op jouw apparaat, maar generiek) 2 32k chippies kunnen hebben die samen 64k doen. Het trucje is dat A15 (bijvoorbeeld) aan de CE van de ene chip geknoopt wordt en aan de nCE van de andere: voor de 'onderste' 32k wordt de ene gebruikt, voor de 'bovenste' 32k de andere. De firmware merkt er niks van: het is gewoon 64k.
Kortom: met die CE lijnen kun je van alles aan adresserings trucen uithalen.
Vandaar mijn opmerking van enige tijd geleden: gebeurt er uberhaupt wat op de CE lijnen? Zo nee, dan zit er rottigheid in de logic ervoor (als die er al is hoor, zoals in het voorbeeld hierboven kun je het rechtstreeks uit de controller halen.

Blijven over OE en WR van het SRAM. Ik denk dat de processor RD lijn dan aan OE zit

Daar zou je zomaar wel eens gelijk in kunnen hebben

en de WR lijn aan WR van het SRAM. Daar hoeft niets tussen want er is maar SRAM IC. Maar er is wel de footprint voor een tweede dus er zou iets tussen kunnen zitten

Neen. Dat wordt opgelost met CE en nCE (of CE en CE2 bij jou). Het is erg ongebruikelijk om in nWR en nRD te knoeien met logic - maar er is ook geen wet die het verbeidt. Dat is aan de hardware ontwerper.

Als je gaat meten: het kan prima zo zijn als rew zegt of zoals ik al eerder geopperd heb: het ding kijk bij startup ff naar RAM en als dat niet aan de verwachting voldoet, dan zou het kunnen dat de software er helemaal niks meer mee doet. Als je dus met een lopend device niks ziet gebeuren, dan is dat nog geen garantie voor 'het is stuk'.
Aan de andere kant is het ook prima mogelijk dat er pas wat met RAM gaat gebeuren als dat nodig is. Daar is weinig van te zeggen zonder dat je de firmware kent.
In het kort: als je dus op zoek gaat naar 'leven' op die lijnen, dan moet je dat dus eigenlijk zowel bij een boot als bij een meting doen.

Bij een 'dump' van de RAM (het uitlezen via RS232 ofzo) is er gene garantie dat die ook gebruikt wordt. Het zou theoretisch zo kunnen zijn dat bij boot (om welke reden dan ook) bepaald is dat RAM niet gebruikt wordt, en dat was het dan.
Waarschijnlijk vind ik dat niet. Want dat zou impliceren dat het ding volledig op z'n interne RAM (je weet wel, die 256 bytes) zou werken. Wellicht kan dat, maar het is niet erg gebruikelijk...

Verder min of meer wat guidob ook beschrijft.

Overigens verwacht ik dat die latch wel werkt. Immers, het ding zou ROMless moeten zijn. Dan komt de firmware uit de flash. Deel van die adressering MOET door die latch veroorzaakt worden, en het zijn nog de 8 'lage' bits ook. Als daar ellende in zit, dan kan het bijna niet anders dan dat het struikelt - die software is vast wel groter dan 128 bytes...

Tenslotte is mijn inschatting dat de configuratie (zo je wilt kalibratie) parameters in flash staan. Zoals gezegd: als je de spullen ervoor hebt, is het lood om oud ijzer of je er alleen een paar parameters of de complete firmware met parameters opnieuw in frut.
Zou het wellicht zo kunnen zijn dat 'memory' een optie is die 'uit' staat? Ik ken die apparaten dus niet, maar Fred heeft er meer mee gespeeld en kan daar wellicht wat meer over zeggen. In dat geval hoeft er helemaal niks stuk te zijn zeg maar :).

De reden dat ik denk dat de calibratie in flash staat, is dat - als ik het goed begrepen heb - Fred wel eens een backup batterij vervangen heeft en die 'deed het nog'. Ofwel: de RAM moet haast wel 'leeg' geweest zijn, en de calibratie data was er blijkbaar nog.

Dan nog ff een hint over die adressering: het hoeft helemaal niet zo te zijn dat wat na de latch A0 heet ook aan A0 van de RAM zit. De address lijnen kun je in willekeurige volgorde aan de RAM hangen. Immers, als je een bepaald address wilt lezen, dan zal het patroon op de address lijnen hetzelfde zijn als toen je 'm schreef. Zolagn dat uniek is, maakt het feitelijk niet uit hoe het in elkaar zit. Kortom: als het voor PCB-routering handiger uit komt om wat lijnen te husselen naar de RAM... waarom niet?
Voor de flash ligt dat iets anders. Die wordt meestal extern geprogrammeerd (maar dus weer niet in het voorbeeld hieronder :)), en dan heeft het voordelen als dat 1-op-1 mapped. Het MOET niet. Je kunt prima een stukkie software bakken wat ook daar de boel aanpast aan de PCB routering en het aangepaste image de flash in frut. Maar het is geloof ik niet zo gebruikelijk.

[off topic]Om Fred ff helemaal gek te maken met trucen met memory :): ik heb development voor een ASIC waar een (oa.) 8051 core in zit gedaan (met alle ellende die een ASIC met zich mee brengt in de zin van 'hardware bug' in de chip zelf). Daarom weet ik per ongeluk iets meer van die 8051. Maar goed... We hadden daar 64k ROM (EPROM in dit geval) en 128k RAM, waarvan natuurlijk 64k adresseerbaar. Daarnaast nog een stuk SPI flash. Het trucje van dit geheel was om zonder nog bij de EPROM te kunnen toch firmware updates te kunnen doen.

In het kort: als je het ding resette (zo je wilt aan zette), dan werd er gestart uit EPROM. Daarin zit een klein stukje firmware wat gaat bepalen of we gaan updaten of normaal gaan runnen. Als we normaal gaan runnen, dan wordt de inhoud van de SPI flash naar RAM gecopieerd - daarvoor was bijna 64k beschikbaar. Een klein stukje werd als XRAM gebruikt voor laten we het de bootloader noemen. De laatste hand vol bytes - 1 byte was beschikbaar voor een routine die uit de EPROM gecopieerd werd en die een memory mapped SR latch kon omzetten (die zat dus op die laatste ene byte). Op het moment dat dat gebeurde, werd de EPROM overbodig, de 64k RAM die nu RAM was gemapped op wat net EPROM was en de 64k RAM die niet gebruikt werd, werd nu opeens gemapped als RAM. Daarna wel een jump naar 0x0000 gedaan - het address wat de core normaal gesproken start na een hardware reset. Gevolg was dus dat een deel van de RAM nu als ROM gezien werd en een andere deel als XRAM. En dat alles door slim met nCE lijnen en 1 adres lijn van de RAM te spelen.
Het copietje van de laatste bytes van die routine van EPROM naar RAM was nodig omdat niet gespecificeerd is hoeveel pre-fetch die core deed. Een normale 8051 doet dat volgens mij helemaal niet, maar bij die ASIC implementatie bleek het nergens uit. Op deze manier maakte het allemaal niet uit: voor en na de 'swap' stond er hetzelfde.
Vanzelfsprekend was het wel ff een rondje 'compiler temmen' om ervoor te zorgen dat dat goed ging qua memory indeling.[/offtopic]