Klar - kein Problem.
Klar - kein Problem.
Ist unterwegs.
Thx.Zitat von SamWhiskey
Ist unterwegs.
Ich hatte auch schon wieder auf eBay zugeschlagen. In der kommenden Version sind wieder ein paar weitere Logik-ICs implementiert (nur ein Ausschnitt, es sind ca. 3x so viele):
ics.JPG
Geändert von 8Bit-Museum.de (26-03-2021 um 12:13 Uhr)
Hallo,
ich habe gerade die "v.17 beta 2" veröffentlicht.
Changelog:
v0.17 beta2: TTL debug shows up to 32 characters now (up to 12 in the next line), prepared for 16bit testing; ISP programming should be possible with connected SD card, chip detection implemented (configurable); added: EMM4200 (4k x 1), GTE/EMM4300 (4k x 1), GTE/EMM4801 (4k x 1), EMM8108 (1k x 8); EEPROM: 2804; fixed: 74669; added: 322, 543, 544, 569, 651, 652, 653, 654, 7266, 4034; fixed: 74299, 597, 669
v0.17 beta 1: added FIFO 40105, 74222, 222, 224, 225, 227, 228, 229, 232, 233, 234, 235, 236, 413; 2764 pin 26 set to +5V (usually „nc“ but allows to read a 2365 ROM from Apple IIe, same as 2364(28) setting); autodetection for CS/CE signals for some 23xxx ROMs added, profiles for 2364(24) and 2364(28), 6 slots for custom SRAMs, 3 slots for custom DRAMs; DRAM: 4408NLT/4408NLB (8k x 4); ROM: RO-3-2513, MCM6670/MCM6674/SCM37530, 74186; EPROM: TMS2564; NOVRAM: X20C04, X20C05, X20C16, X20C17, X2210, X2212; added: 74H71, 7497, 118, 119, 222, 224, 227, 228, 286, 575, 673, 808, 810, 832, 900(ALS), 902(ALS), 903(ALS), 9034, 9035, 9114, 9115, 9134, 9135, 9240, 9244, 9245, 8T95, 8T96, 8T97, 8T98, 4007, 40102, 40103, 4598, ULN2074, ULN282x, UDN6118, 75460, 75461, 75462, 75463, 75464, 75468, CA3081, CA3082; fixed: 74115, 173, 4055, 4056, 40105, 4514, 4515
Hab heute Nachmittag auch meinen Tester fertig aufgebaut.
Leider hat das Beschreiben der Fuses nicht geklappt.
Eigentlich wollte ich es mit meinem FTDI232 probieren, jedoch fehlt dem avrdude leider die notwendige Bibliothek.
Die beiden fehlenden dlls einfach mit ins Verzeichnis zu legen, hat leider nicht genügt. Vermutlich müsste ich die Binary neu kompilieren. Mangels akuter Zeit und Lust bin ich auf Option 2 gegangen, und zwar den Diamex NXP, der gerade leihweise hier liegt. Damit konnte ich problemlos die Fuses auslesen und gem. Handbuch beschreiben. Seitdem mag der ATmega aber leider nicht mehr mit mir kommunizieren. Bereits das Auslesen der Fuses direkt nach dem Beschreiben schlug fehl. Keine Ahnung, was da schiefgelaufen ist, vielleicht hätte ich DC-DC-Wandler und Display entfernen müssen, um den Strombedarf zu reduzieren.avrdude.exe -C"avrdude.conf" -v -patmega2560 -cft232r -PCOM12 -U lfuse:r:-:i -U hfuse:r:-:i -U efuse:r:-:i
avrdude.exe: Version 6.3-20171130
Copyright (c) 2000-2005 Brian Dean, http://www.bdmicro.com/
Copyright (c) 2007-2014 Joerg Wunsch
System wide configuration file is "avrdude.conf"
Using Port : COM12
Using Programmer : ft232r
avrdude.exe: error: no libftdi or libusb support. Install libftdi1/libusb-1.0 or libftdi/libusb and run configure/make again.
Im Handbuch ist das "Recovery"-Prozedere durch Anschließen eines Arduino als externen Taktgeber beschrieben. Da ich lediglich einen ESP8266 hier liegen hab, hoffe ich, dass der dokumentierte Code auch damit funktioniert. Heute Abend weiss ich hoffentlich mehr ...Programmer Type : STK500V2
Description : Atmel STK500
Programmer Model: STK500
Hardware Version: 10
Firmware Version Master : 2.10
avrdude: stk500v2_command(): command failed
avrdude: stk500v2_getparm(): failed to get parameter 0x9a
Topcard : Unknown
Vtarget : 4.8 V
SCK period : 8.7 us
Varef : 4.8 V
Oscillator : Off
avrdude: stk500v2_command(): command failed
avrdude: initialization failed, rc=-1
Double check connections and try again, or use -F to override
this check.
Dann hat das Schreiben der Fuses eben nicht geklappt. Vermutlich stehen die jetzt auf 0x00, d.h. übersetzt: der ATmega will einen externen Takt.
Mit dem Diamex NXP meinst du hoffentlich den Diamex PROG-S2? Nicht jeder ATmega-Programmierer kann auch den ATmega2560/1280 programmieren.
Wenn es der S2 ist, kannst du am 10-pol. Anschluss am linken mittleren Pin einen Takt abgreifen. K.A., ob der schon anliegt, ansonsten müsste der über das AVRstudio eingestellt werden. Also über den 6pol anschließen und den Takt mit dem Tester verbinden. Im Grunde kannst du jeden x-beliebigen Takt nehmen. Der muss noch nicht einmal sonderlich schnell sein, sollte aber TTL Pegel haben.
Damit sind die Fuses dann wieder korrekt setzbar und du kannst wieder normal programmieren.
Evtl. mache ich einmal ein Video dazu.
Geändert von 8Bit-Museum.de (27-03-2021 um 18:38 Uhr)
Das Teil heisst Diamex ISP-Prog-NG (nicht NXP) und hat bereits mehrere Deiner Tester erfolgreich beschrieben.
Mit AVR Studio 4 kann ich einen beliebigen Clock einstellen, jedoch schlägt das Oszi an keinem der Pins des 10-pol. Connectors aus.
Zur Arduino-Option: Mit der IDE scheitert es bereits an den Basics. Deinen dokumentierten simplen Clock-Generator kann ich nicht kompilieren, da "avr/io.h" nicht gefunden wird. Ich hab leider null Erfahrung mit der Arduino IDE. Die AVR libraries sind generell vorhanden, und ich hab die einzelnen benötigten Dateien an diverse Pfaden hinterlegt, ohne Erfolg. Möglicherweise ist die Bibliothek mit meinem nodemcu nicht kompatibel.
Da der Fehler unmittelbar nach dem Setzen der Fuses auftrat, wäre es natürlich auch denkbar, dass der Quarz-Oszillator auf dem Board nicht funktioniert. Wenn ich das Oszi an den 1MR Widerstand halte, bekomme ich keinen Puls. Allerdings kann es ja auch sein, dass die Messspitze die Schwingung stoppt.
Geändert von herr-g (28-03-2021 um 00:52 Uhr)
Zwei Möglichkeiten:
1. Die Arduino Installation ist fehlerhaft. Arduino macht es dem Anwender besonders einfach und bindet grundlegende Libraries von sich aus ein, d.h. nach avr/io.h sollte er nie fragen. Hinterlegen muss man da nichts mehr.
2. Korrektes Board (überhaupt ein Board) ausgewählt?
Du kannst aber auch einen ESP programmieren.
Hat dein Osci einen 1kHz Taktausgang? Probiere es doch einmal damit. Ist zwar sehr langsam, aber die ATmegas können grundsätzlich beliebig langsam betrieben werden und hier muss es nur reichen zum Setzen der Fuses. Ich habe aber k.A., ob 1kHz dafür ausreichen.
Die Schwingung sollte nicht gestoppt werden. Dann ist der Quarz evtl. doch hin (oder einer der 22p hat einen Kurzschluss, alles schon gehabt).
Geändert von 8Bit-Museum.de (28-03-2021 um 09:26 Uhr)
Tip vom Profi, was das Arbeiten mit dem Scope in sensiblen Schaltungen angeht:
Nimm den 100:1 Tastkopf dafür, auch wenn er eigentlich für Spannungen im hohen dreistelligen und kleinen vierstelligen Bereich konzipiert ist.
Damit ist die Belastung der Signalquelle ebenfalls um zwei Zehnerpotenzen kleiner!
Der Meßverstärker eines gängigen Scops ist ja mit 1mV / cm empfindlich genug, das nachzuverstärken.
Gruß vom Alten
Neuer Tag neues Glück - das Problem saß wie so oft an der Werkbank.
Ich hatte versehentlich einen 1k Widerstand statt 1M parallel zum Quarz eingebaut. Kein Wunder, dass ich keinen Takt sehen konnte.
Mit dem korrekten Widerstand wird nun auch munter geschwungen, und ich konnte die Firmware erfolgreich schreiben.
Das Problem mit dem externen Taktgeber ist natürlich noch offen - irgendwann wird es mir sicher wieder auf den Schoß fallen. Aber für den Moment passt es alles.
@Alter: Ich versuche grundsätzlich mit 10:1 Tastkopf zu messen. Den Sinus konnte ich hier auch (nach der "Reparatur") sauber sehen.
Puh, jetzt erstmal ein paar heile und kaputte Steinchen checken. Ahoi
EDIT: Paar heile und defekte TTLs getestet - Bislang alles top. Auch die 4116er DRAMs, die ich noch liegen hatte.
Ich hab noch leihweise einen baugleichen Chip-Tester vom Kumpel hier, der vor ein paar Monaten zusammengebraten wurde, mit 1k Widerständen am ZIF-Sockel. Hier konnte ich wunderbar den Vergleich sehen. Ein paar funktionierende 7493 wurden nur auf meinem neuen Tester mit 470R Widerständen erfolgreich getestet. Der Gast-Tester zeigt die als defekt an. Ein neuer 74LS93 wird hingegen von beiden erfolgreich getestet.
Den Gast-Tester hab ich übrigens hier, weil er Probleme mit RAM Tests haben soll. Mit meinen neuen 4116 konnte ich das direkt nachvollziehen - der Test bricht sofort nach Start mit 'failed' ab. Kann das ebenfalls mit den 1k Widerständen zusammenhängen? Oder hat der eher noch ein anderes Problem? Die Dioden und Kleintransistoren messen sich mit Multimeter unauffällig.
Geändert von herr-g (28-03-2021 um 23:37 Uhr)
Das kann damit zu tun haben, muss aber nicht. Zumindest ist der Spannungsabfall bei 470 Ohm etwas geringer.
Mögliche anderen Gründe:
Sind die Bauteile aus der selben Quelle? Ich hatte von einem Händler schon MPSA-Fakes bekommen, die einen sehr viel höheren Spannungsabfall lieferten (bei Dioden und dem MOSFET kann das auch passieren).
Es kann auch der Quarz sein, wenn der Tester im Low Power Mode betrieben wird und der Spannungshub nicht ausreichend ist (dann läuft der Tester nicht "rund"
Ich würde zunächst die Fuses auf "Full Swing Oscillator" stellen und noch einmal probieren (macht am wenigsten Arbeit) und einmal nachsehen, ob der 4.7 Ohm Widerstand wirklich 4.7 Ohm oder ggf. 4.7k Ohm sind (dann schaltet der MOSFET ggf. nicht voll durch und der Spannungsabfall wird bei höheren Strömen zu hoch).
Geändert von 8Bit-Museum.de (29-03-2021 um 09:40 Uhr)
Moin und danke für die Rückmeldung :-)
den 4,7R Widerstand hatte ich schon gecheckt. Der passt. Die Bauteile sind meines Wissens alle von Reichelt, also keine Direktimporte oder obskure eBay-Quellen.
Bleibt Deine Theorie mit dem Oszillator. Das werde ich mal ausprobieren und berichten.
Da fällt mir noch ein mögliches Problem ein. Ich hatte auch schon einmal ein defektes RECOM Modul, ein anderes Mal einen defekten Elko.
Wenn es nicht gerade ein 4116er ist, den du testen möchtest, probiere doch einmal ohne DC/DC Spannungsplatine die RAMs zu testen. Dann ist dieser Fehlerfaktor schon einmal ausgeschlossen (alle Jumper setzen und per Hohlstecker oder USB betreiben).
Das DC-DC-Modul hatte ich schon mal mit meinem getauscht. Das ist also OK. Ich teste nachher erstmal die Full-Swing-Oscillator-Einstellung.
So, Mittagspause
Änderung lfuse auf 0xf7 erhöht den den Clock von knapp 1Vss auf gut 4Vss.
Aber leider keine Veränderung beim SRAM Test. Habs daher wieder zurückgesetzt.
Ohne DC-DC Platine komme ich nicht weit, da ich aktuell nur den 4116 hier habe. Habs trotzdem probiert, aber der Test erkennt dann gar keinen Baustein im Sockel. Hmm also vielleicht doch ein Defekt im ATmega?
Berechtigungen
Zitieren