Svenska ElektronikForumet

För ett litet tag sen fick jag i min hand en HP3478A multimeter. (Inte mitt ex. Lånad bild)

Jag anade att det var något fel på den eftersom den skrotades, och det visade sig att displayen var helt blank när den slogs på. Bara ett litet blink just vid spänningstillslaget. Bra nyheter att det inte rök, men dåliga nyheter att det inte "bara" var en säkring. Å andra sidan brukar ju inte säkringar gå av sig själv...

Alla manualer finns på nätet så det var ingen brist på schema och funktionsbeskrivningar. Det blev ändå inte mycket till felsökning direkt i både brist på utrustning och tid. Första felsökningen begränsade sig till att kolla att matningsspänningarna var ok. Det var dom, så inget sånt fel. Nästa tanke var om backup-batteriet var tomt så att den inte kunde starta p.g.a. det. Men batteriet verkade ok och att ta ur det var inte aktuellt eftersom det skulle göra att kalibreringskonstanterna var borta.

Min logikanalysator är tyvärr trasig så jag hade bara multimeter och oscilloskop att mäta med. Med oscilloskopet konstaterades att klocksignalerna till displayen saknades. Dessa genereras av CPUn så där verkade det finnas något problem. Upptäckte snart att det gjordes reset på CPUn stup i ett. Åter fokus på batteriet som är inblandat i reset, men det visade sig finnas en watchdog som kollar att tangentmatrisen scannas
och resetar om den inte gör det. Jag kunde se att PSEN och ALE var aktiva. Alltså gjorde CPUn något och I hopp om att den bara väntade på något och kunde komma vidare om det inte gjordes reset i tid och otid så disablade jag watchdogen. Men det gjorde ingen skillnad.

Därefter var idéerna slut och apparaten åkte på hyllan igen. Utan batteribyte vilket jag ångrar nu...

Under tiden som följt har jag haft många idéer och googlat lite ibland. Ingen annan verkar ha exakt samma problem. Det finns många 3478or bland hobbyister och många har gjort fina/användbara/snygga/lustiga/tokiga modifieringar. Ex.vis bytt displayen mot nixie-rör, adderat backlight och rent av lagt till nya mätfunktioner!

CPUn är en 8039 som hör till MCS48 familjen som jag har viss tidigare erfarenhet av. Den klockas med 5,8MHz som ger ca 390k instruktioner per sekund. Inget fartmonster alltså. En rom-dump hade jag hittat på interwebsen.
http://www.ko4bb.com/getsimple/index.ph ... nd_Drivers

Någon har till och med disassemblerat denna för att förstå hur den jobbar.
https://github.com/fenugrec/hp3478a_uti ... ROM_disasm
Det är också denna disassembly som gjort införandet av nya funktioner möjlig.

Det här med kalibreringskonstanterna är ett bekymmer. Dör batteriet krävs en komplicerad och omfattande justering för att få korrekta mätvärden igen. Men det har visat sig att via GPIB kan man läsa och skriva kalibreringskonstanterna genom (tidigare) odokumenterade kommandon. Innan det var känt var enda sättet att rädda sina kalibreringskonstanter att byta batteri med spänningen på med allt vad det innebär i att använda isolerade verktyg et.c.

Ibland har jag verkligen kännt att jag behövt den här multimetern. GPIB-möjligheten med loggning via AndersGs konstruktion är något jag varit ute efter. Senast för någon vecka sen. Löste problemet då men tyckte att nu var det verkligen dags för ett ryck igen.

Tog fram 3478an igen och öppnade locket. Katatrof. Batteriet 0V och hade börjat läcka. Som tur var inte ner på PCBt utan bara runt polerna än så länge. Försökte inte ens löda bort det. Tog bara avbitaren. Så nu blir det nån slags kalibrering också om jag får liv i den. Lämnade det tyvärr till återvinning innan jag hann ta någon bild.

HAR DU EN 3478A. BYT BATTERI! Men se till att du läser på först för det måste göras med spänningen på alternativt läsa ut kalibreringkonstanterna via GPIB och skriva tillbaka efteråt om du är vågad.

Fortsättning följer.

P.g.a. katastrofen med batteriet kunde jag nu vara säker på att det inte var läsning från RAM som var problemet. Nu var det garanterat blankt, eller iaf oinitierat, och displayen blinkade fortfarande bara till vid tillslag.

Så nu lånade jag en logikanalysator för att bättre kunna se vad som händer. Finns det något bättre sätt att spendera en jul-ledighet än att hänga i labbet? Bortsett från skinka på julafton då? (Retorisk fråga. Naturligtvis är svaret nej)

Jag försökte koppla in probarna på data och adress-bussen utan att mer än ta av locket. Det hade kanske gått om jag haft test-clips för kresar med rätt ben-antal men det slutade med att jag rev hela apparaten.

Det var alltså en sån jag inte hade. Så det blev så här Det ser mer brutalt ut än det är. Det sitter en plexi-skiva som täcker lödsidan i högspänningsdelen så risken för större eldsvådor är liten.

Redan vid första datainsamlingen kunde jag konstatera att bara efter några hundra instruktioner exekverats hamnade den i en loop som den inte kom ur. Jämförde med disassembly-listan från nätet.
I min lista har jag fått adressbussen till höger eftersom jag ännu inte begripit logikanalysatorns inställningar när jag gjorde detta. Men man kan se att det börjar med "8a 01" i båda fallen. Sätter bit 0 i port 2 till 1. Det är ena klocksignalen till displayen. Men sen kör det ihop sig. "9a fe" i romdumpen från internet och "ba fe" i min multimeter. "9a fe" skulle inneburit att klocksignalen gått låg igen men vad betyder ba? Jo mov r2,data. Nästa instruktion är lika "8a 20" vilket sätter den andra klocksignalen hög, men sen är det olika igen. Ny mov r2,data. Sen lika igen med "ea 02". Och det är nu man förstår att något gått väldigt fel. För här gör man djnz r2 och hoppar tillbaka.

djnz är "decrement jump if not zero". D.v.s angivet register (r2) räkas ner och man hoppar till angiven adress om r2 inte blivit 0. Men r2 laddas ju om inuti loopen inte mindre än två gånger om min hand-disassembly är rätt. So loopen kommer aldrig att terminera!


Jämför man bitvis mellan 9a och ba ser man att
9A = 1001 1010
BA = 1011 1010

Alltså ett enda bitfel som gör rätt stor skillnad i funktion (eller avsaknad av).

Men nu var det ju inte bara ett enda bitfel... bit 5 är ju ändrad både på adress 1A04 och 1A08. Men inte på ex.vis 1A03 där 01 borde blivit 21 om bit 5 flippat där också. I det här läget var jag fortfarande osäker på om min tolkning var rätt trots att det kändes så uppenbart. Är hand disassemblyn rätt? Troligen, jag har kollat flera gånger. En slump att det just blivit r2 man laddar?

Nu ville jag verkligen läsa ur ROMet, men hur gör man det när alla komponenter är lödda på plats?

Fortsättning följer...

Kan du inte mäta och spara värdena från allt som läses från ROM:et? Sen kan du sortera på adress och jämföra med en ROM dump (för jag antar att man kan hitta sådana till instrumentet) det borde ju ge svar på om det som exekveras är "rätt".

Jag har i något fall lyckats dumpa ett EPROM på plats i kopplingen med brännaren, men det styrs ju hur kringkomponenterna är kopplade...

Om 8039:an är kass kan det finnas i mina gömmor, PM:a i så fall.

Jag har ett gäng 8748 som borde gå att ersätta med om det kniper, men just nu är hypotesen att bara ROMet gått snett. Jag håller på att skriva på fortsättningen där jag faktiskt dumpat ROMet.

Jag har egentligen ingen erfarenhet av hur ROM beter sig när de börjar få bitfel. Därför kunde jag utan problem svalt ett slumpmässigt fel någonstans. Om det varit flera spridda runt om hade jag också svalt det, men än så länge kände mig orolig för att det var mitt sätt att tolka koderna som var fel och inte romet. Placeringen kändes inte så slumpmässig även om vi människor har svårt att förstå riktig slump. (Egentligen trodde jag inte att mask-ROM kunde få bitfel. Mönstret skall ju vara inpräntat i den litografiska processen under tillverkningen. Eller?)

Jag skulle gärna vilja ha ROMet i min 3478 utläst för att se om det matchar det som finns på internet. En match så när som på lite bitfel skulle göra mig mer säker på att ROMet var fel och att jag hade hittat felet. Men ROMet och alla andra komponenter också för den delen är som sagt lödda direkt på kortet. Lödda komponenter brukar inte vara ett problem för endera är jag ute efter att rädda PCBt och då klipper man benen och löder bort ett i taget. Exakt så gör ju anders_bzn på sina PDP-er. Vill man rädda en komponent sågar man ur den och löder bort PCBt bitvis. Nu vill jag i min möjligtvis felriktade försiktighet rädda båda och jag har ingen superfin avlödningsstation. Bara en Weller lödpenna. Anledningen att rädda båda är naturligtvis att kunna läsa ROMet och, om det visar sig inte vara fel, kunna använda det.

Min första idé för att rädda ROM-innehållet utan själva kretsen var naturligtvis att nöja mig med vad jag kunde fånga från logikanalys
med apparaten igång och lite klickande på olika knappar och annan input. Tyvärr sket ju det sig rätt kraftig när allt fastnar med bara
några hundra byte fångade av 8k.

När jag studerade schemat såg jag att där fanns en helt annan lösning för att dumpa hela innehållet in-situ. Där är möjligt att bryta upp data-bussen genom att ta ur RP527 som är socklad. Det är inlagt för att möjliggöra signaturanalys så vitt jag förstår. En teknik utvecklad för att felsöka digitala system.
http://hpmemoryproject.org/an/pdf/an_222.pdf
Nu har jag ingen signaturanalystor. Ingen jag känner har en och jag har aldrig sett en i verkligheten.

I servicemanualen finns signaturer angivna för olika strappningar i ett felsökningsträd där det också står vilken krets som skall bytas.
Det verkar onekligen varit ett smidigt sätt när reservdelar fanns... Bryter man bussen så här kommer CPUn att se "ff" hela tiden pga de pull-up motstånd som sitter på CPU-sidan av bus-break. FF är en en-bytes register till register-instruktion (mov a,r7) och CPUn kommer alltså stega igenom allt program-minne den kommer åt. MCS-48 har bankat minne så det blir bara 2k man stegar utan bankswitch-instruktioner. Dessutom är romet dubbelt så stort som totala adressutrymmet vilket man löst med lite specialtrick. Men det finns fler strappningar så man kan i praktiken cycla igenom hela minnet även om det får göras i fyra delar.

Med lite tricksande kunde jag alltså få min ROM-dump. Fyra olika avläsningar som sen dumpades från logikanalysatorn över GPIB till fil och
slutligen klipptes dumparna ihop och konverterades till Intel-hex med ett specialskrivet program. Lätt som en plätt I alla fall troligen
enklare än min första tanke.

Nu visade det sig på allvar att min 3478a inte har samma programvara som den jag laddat ner. Och det var inte bara
lite bitröta som skiljde. Uppenbarligen är min en annan, troligen tidigare, version. Mitt serienummer hör till den absolut
första revisionen vilket snart skall visa sig relevant på fler sätt.

Men så till mina bit-fel. ROMarna är åtminstone delvis lika och en jämförelse var mycket intressant.

Där finns stora partier som är identiska. I stort sett hela första halvan är lika och de skillnader som finns får jag
titta närmare på senare. Andra delar är radikalt olika. Troligen handlar det om extra kod som tillkommit i den version som finns på nätet. Men så finns dom här delarna där jag såg att CPUn fastnade. Och titta noga på denna jämföreslse.
Jag har lagt in "orginal-dump" och min bit-ruttnade version på varannan rad. Man kan tydligt se att på var fjärde byte har bit 5 (eller 6 beroende på hur man räknar) ändrats från 0 till 1 där den inte redan var satt till 1. Jag kan inte förklara detta. Om någon har en förklaring vore den intressant.

Det här är inte det enda blocket där detta hänt. Och blandat med detta är alltså helt legetima skillnader. Jag tror det blir en utmaning att få till rätt bitar överallt. Så stor att jag tänker prova med romet från nätet istället. Jag har jämfört scheman på äldre och nyare serienummer på multimetern och kan inte se några relevanta skillnader. Men i serivcemanualen finns ett eget kapitel "backdating" där ändringar i hårdvaran mellan olika versioner finns listade. Och dessutom skall ju denna CPU prata med en annan som sitter i själva mät-delen av multimetern. Har man ändrat i protokollet kan jag inte byta programvara.

Stay tuned...

Försök hitta en 8048 disassembler på nätet så kan du se vad skillnaderna "gör". Det kan ju vara att man använder ett annat register tex som förklarar ändringarna. Det går ju att göra för hand med är tråkigt och lätt att göra fel.
Den här har jag använt både för Z80 och 8048. http://www.atastro.com/software/prog/dasmx.html
Det finns flera om du söker på "8048 disassembler".

Ett stalltips är att använda WinMerge för att diffa hex-dumparna.
Det är gratis och open source:
https://winmerge.org/
Den markerar enskilda poster som skiljer sig mellan filerna, så det passar ypperligt till att lysa upp enskilda hexvärden som är olika.
Du kan diffa filer från kommandoraden som med Windiff med WinMergeU file1 file2.

@castor: Jag har disassembler för 8048. Mer än en tror jag faktiskt. Eventuellt till och med en jag skrivit själv, fast i så fall är den i fortran för VAX... Vill helst använda den som fenugrec använt och som jag hänvisar till i första inlägget. Problemet är bara att man byggt ut adressutrymmet med en extra bit genom att använda en ut-port. Det finns inte många som klarar (0). fenugrec har patchat d48 lite för att ge något bättre stöd. Har dock inte lyckats kompilera den än eftersom jag aldrig tidigare haft behov av en C-kompilator hemma och den som verkade följa med Bridgepoint (mingw) inte riktigt sväljer koden.

Jag har en simulator också men den kräks när man försöker ladda filer större än 4k. Möjligen kan simulatorn i MAME fungera men då är det en produkt till att lära sig....

Vad man vill ha är nog en macro-disassembler men någon sån har jag aldrig sett. För någon processor...

@Maalobs: Jag skall testa winmerge igen. Förkastade den för några år sen av nån anledning jag inte minns. Men då var det inte hex-dumpar jag jämförde. Jag är inte främmande för att skriva ihop något specifikt för detta själv heller.

En sak till malde i huvudet:
Om det enda verktyg man har är en hammare ser alla problem ut som en spik. Eller elektronikvärldens motsvarande:
Om det enda verktyg man har är en logikanalysator ser alla problem ut som ett timingproblem....

Jag ville därför se om det kanske möjligen var så att ROMet gav dåliga utsignaler som kunde feltolkas ibland. Ja jag medger att det borde vara mer slumpmässigt och svårt att upprepa då men jag ville kolla.

Lyckades få oscilloskopet att trigga på signal från logikanalysatorn så jag kunde se exakt vad spänningen på bit 5 var när den läste just 1A04. Men det visade sig inte vara problemet. Självklart har ROMet buffrar på utgången. CH1 är databit 5. CH2 är PSEN. När den går hög läser CPUn (och min logikanalysator) värdet. 10ggr probar utan avläsning i skopet så det är rätt nivåer oavsett vad skalorna säger. Att spänningen faller efter triggpunkten beror på att bussen flyter och kapacitansen i ledare/probar/et.c. håller kvar spänningen tills den läcker bort. 4V är kanske lite dåligt men det ser lika dant ut på alla läsningar. Ettan som är rätt strax efter är ju lika dan.

Det finns idéer på nätet om att med annan matningsspänning kanske den interna läsförstärkaren i ROMet ger ett annat resultat. Intressant men går inte att testa där det sitter. Kanske en övning när ROMet är urlött.

Så till mitt låga serienummer igen...
Hela tiden när jag probat runt i min 3478 har jag utgått från ett utskrivet schema jag har. Data-pinnarna har suttit på traditionella ställen från vad jag haft i huvudet så jag har inte funderat mer på saken. Rotade runt i lådorna och hittade en del 2764-chip jag tänkte prova med. Det var då jag upptäckte skillnaden. ROMet i min 3478 har 24 pinnar. En vanlig 2764 har 28 pinnar!!!!! I instrument med serienummer som efter 2619A32988 har man bytt till en 28-pinnarskrets. Första två siffrorna i serienummret säger för övrigt vilket år den är tillverkad
om man adderar 1960. Så min är tillverkad 1981 och 1986 bytte man till andra kretsar.

Google google google. Och jo visst, det är ett speciellt mostek-rom med latchar på adress-ingångarna, naturligtvis inga programmeringsspännar och adressledningarna lite annorlunda. Facepalm. Men hade inte någon på forumet nyligen en adapter ute till försäljning?...... Jo visst, anders_bzn, så det är beställt.

Jag har också googlat ännu mer och konstaterat att dom här MOSTEK-rommarna är kända för att tappa minnet efter så där 40 år. Min enhet är 38 år. Bland annat drabbar det ägare av HP3468. Så har du en apparat med MOSTEK-rommar som du är rädd om:
Se till att dumpa innehållet så du kan ersätta dom den dag bitrötan sätter in.
https://www.eevblog.com/forum/testgear/ ... s-coming!/

Att det är latchar på ingången och andra saker som skiljer skall inte spela någon roll. Det är nästan 1uS från det att PSEN går låg till data läses in i MCUn. De låga adressledningarna multiplexas förvisso på processorn men latchas i en egen '373. Övriga adressledningar är inte hanterade på samma sätt och skall inte vara ett problem. Och vad gäller access-tid så har man som sagt 1uS på sig vilket är en evighet även för långsamma EPROM.

Så vart står jag idag?
- ROMet måste ur. Får ske efter nyår för det är stängt och tomt på jobbet.
- Adapter är beställd. Skall kontrollmätas och bestyckas. Bedöms enkelt.
- EPROM skall brännas. Mycket enkelt med pgv från nätet. Jag har brännare.
- Skillnader mellan dumpar måste undersökas mer noga. Stort jobb.
- Nytt backup-batteri måste fixas. Satsar nog på en annan modell och hållare. Idéer?
- Justering. Har idag ingen aning om hur detta skall lösas, men den dagen den sorgen.

Ser framtiden an med tillförsikt ändå.

Här är svaret om vilket batteri som ska användas, 3V Litium: http://mrmodemhead.com/blog/hp-3468a-ba ... placement/ Batteriet håller länge, så varför krångla till det?

Om Postnord gör det dom ska så borde du ha adaptrarna i brevlådan i morgon! Frågan är, har du EPROM:ar? Annars kunde jag stoppat ner några i brevet...

För övrigt så gillar jag tråden, kudos för att du dokumenterar och delar!

Tydligen kan det sitta minst en RIFA kondensator i nätdelen, ganska nära transformatorn. Gamla äckliga PME. Byt dessa med en gång.

Jag har sett att det sitter minst tre RIFA-kondingar i. Två alldeles vid nätbrunnen och en PÅ strömbrytaren. Trots att jag rivit hela multimetern verkar dom svåra att komma åt och ser inte spruckna ut. Skall kolla dom närmare. Tack för påminnelsen.

Och jo, jag har 2764 men säkert bara 20 stycken..

Jag är mycket tacksam över insatserna i detta projekt. Jag har en containerfyndad 3648A som tydligen också löper samma risk att tappa minnet. Det blir att byta batteri (och i görligaste mån) eventuella kondensatorer i riskzonen efter nyår.

Idag var det full fart på jobbet igen vilket innebar att jag kunde löda loss den där ROM-kretsen som jag haft som hypotes att den är trasig. Ja, jag har väl varit ganska säker men det skulle ju teoretiskt kunna vara något annat. Nåja, det var inte helt utan problem att få loss den trots bra grejor men till slut var den loss och alla paddar var kvar där dom skulle vara. Väl hemma igen var det bara att löda dit en sockel och plugga i adaptern jag köpt av Anders_bzn med ett ny-bränt 2764 EPROM. Jag hade tänkt tvätta rent från flussmedel och junk men jag var så spänd på om det skulle bli liv eller inte nu så det får anstå en stund. Det blir en hög mojäng med två socklar, stiftlister och ett pcb. Det är inga problem att få plats men det känns lite känsligt för g-krafter åt fel håll som skulle kunna få den att trilla ur. Något att fundera på.

I ungefär 2 mikrosekunder funderade jag på om jag skulle koppla in logikanalysatorn igen för att se vad som hände eller om jag istället skulle plugga i displayen och helt enkelt koppla in nätspänningen. Det blev det senare. Vet inte om jag skall kalla det annat än succe. Ja, den är okalibrerad men verkar inte visa nonsens. Eftersom kortet är utanför skalet kunde jag inte testa GPIB-kommunikationen men jag har bläddrat mellan funktionerna och displayen uppdaterar som förväntat.

Sen rev jag instrumentet ännu mer

För att byta dom där RIFA-kondingarna måste man komma åt själva nätströmbrytaren. Hälften av dom är monterade direkt på den och allt ihop är sen "kapslat" i en krympslang. Men brytaren satt på en plåtvinkel som satt på transformatorn som är lödd på kortet. Och för att få loss vinkeln måste man ta loss fronten för att få ut den långa förlängningen som knappen sitter på. Inte Design for service direkt.

Och nu när jag ser att den lever igen är det dags att fixa nya kondingar och ett backup-batteri. Det visade sig att batteriexperten hade "nästan" rätt batteri. Inte med ben utan med lödfanor men jag har ju delar av benen från det gamla kvar så det skall nog gå att få ihop.

Ikväll är kodar-holger mycket glad.