www.mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik AVR-Clock-Out


Autor: Nicolas Dorwig (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

ich hätte mal eine Frage: Ich bin echt gerade am verzweifeln: Habe ein
Board nach folgenden Vorgaben aufgebaut
[http://www.linuxfocus.org/Deutsch/March2002/article231.shtml] und
unter Linux versucht das Ding zu programmieren. Ich habe jetzt schon
stundenlang versucht den Fehler (ein fehlener Draht oder falsche
Pinbelegung??) zu finden, aber kein Erfolg. Die Schaltung und das Kabel
sind 100%ig richtig. Deswegen vermute ich den Fehler beim AVR selbst.

Ich meine mich zu errinern, dass es bei den Motorola
MC68HC11-Controllern einen Pin "E" gab, an dem die Clock anlag und
man ganz banal mit einem Multimeter testen konnte ob die MCU überhaupt
läuft. (Multimeter zeigt bei laufendem Chip ca 1/2 VCC an) Ich habe
leider kein Oszi zur Hand und kann somit auch schlecht mit einem Oszi
testen. Das Programm was ich verwende (avrprog) meldet mir halt immer
das kein Gerät gefunden wäre und dass die Signature-Bytes alle jeweils
ff sind und nicht wie für den verwendeten MC: 0x01 0x92 0x03

Hier ist die Ausgabe von avrprog:
Befehl: avrprog -d AT90S4433 -p 0x378 -v -w < avrledtest.hex

Chip signature bytes: 0xff 0xff 0xff 0xff
Warning: chip autodetection not done due to '-d' option.
Chip identification: AT90S4433 - 4096 bytes program; 256 bytes eeprom
Writing program memory
 offset reclen success
 0x0000  0x08   -fail-
 0x0008  0x08   -fail-
 0x0010  0x08   -fail-
 0x0018  0x08   -fail-
 0x0020  0x08   -fail-
 0x0028  0x08   -fail-
 0x0030  0x08   -fail-
 0x0038  0x08   -fail-
 0x0040  0x06   -fail-
ERROR: Writing failure.

Abschließend zur Info: Ja, ich habe schreib/leserechte für das
parport-device (alle Versuche geschahen als root) Habe es auch
alternativ noch einmal mit PonyProg versucht, aber dass kann auch
keinen angeschlossenen Controller finden.


Zusammenfassed: Ich suche eine Methode messtechnisch zu ermitteln ob
der Controller überhaupt läuft.

Danke für eure Hilfe.

Nico

Autor: Dominic Thomé (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Vorschlag von mir :

nimm doch mal den uisp (www.openavr.org) und tipp dann in der Shell :
uisp -dprog=dapa
Als Ausgabe sollte sowas kommen wie AT90S4433 found.

Danach dann beschreiben probieren.

Wenn Fehlermeldung :
Spannungsversorgung OK ?, Quarz OK?,( Oszilloskop vorhanden
nachmessen)

Wenn alles nichts fruchtet : Meldung von uisp hier posten.

Autor: Nicolas Dorwig (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Okay, danke erst einmal für den Hinweis. Habe es mal ausprobiert, wie du
es vorgeschlagen hast.

Uisp meldet, dass /dev/parport0 nicht da ist, ooooookay, ist ein Grund.
;-) Ich glaube ich habe fälschlicherweise immer nach /dev/lp0 geschaut,
aber das ist ja ein anderes Paar Stiefel. Werde mich ersteinmal darum
kümmern, dass das Parport-Device funktioniert. Ausserdem habe ich mal
alle Programme deaktiviert, die in irgendeinem Zusammenhang mit dem
Paralellport stehen (cups, lpr etc.)

Ich melde mich nochmal, sobald ich was neues rausgefunden habe, aber
das hat mir jetzt immerhin schonmal gemeldet, dass etwas schon mit dem
Paralellport net stimmt.

Trotzdem suche ich allgemein mal nach einer Möglichkeit, den Chip OHNE
Oszi zu testen. Ein Gedanke von mir war vielleicht die Stromaufnahme,
aber ob das aussagekräftig genug ist, um mir zu sagen, das der Quarz
auch schwingt?

Fragen über fragen, danke für eure Hilfe!

Gruß Nico

Autor: Dominic Thomé (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Bei der Stromaufnahme dürftestDu nichts rausfinden.

Hast Du die Module parport_pc und ppdev geladen ?

Autor: Matthias Weißer (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi

am Pin2 des AVR (XTAL2) solltest du mit einem hochohmigen
Spannungsmessgerät (Digitalmultimeter) etwa Ub/2 messen können. Ist es
nicht hochohmig bleibt wahrscheinlich der Oszillator stehen und du mist
0V oder Ub.

Matthias

Autor: Nicolas Dorwig (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Dominic: Ja, die Module sind geladen, ich werde es heute abend nochmal
in aller Ruhe kontrollieren. Aber trotzdem danke für den Hinweis.

@Matthias: Genau das wäre der Hinweis, den ich erwartet hatte, werde
auch dies heute Abend noch mal in Ruhe eruieren. Vielen Dank!

Autor: Nicolas Dorwig (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Fogender Zwischenstand hat sich ergeben:
Die Module sind alle geladen.
Ich habe in der Zwischenzeit ein wenig nach dem Problem gegoogelt und
herausgefunden, dass man das Problem mit dem Fehlenden parport0-Device
so lösen kann:

Als root "mknod /dev/parport0 c 99 0"

uisp meldet nun folgendes:

------------ Befehl: uisp -dprog=dapa
An error has occurred during the AVR initialization.
 * Target status:
   Vendor Code = 0xff, Part Family = 0xff, Part Number = 0xff

Probably the wiring is incorrect or target might be `damaged'.
--------------

Ich fand ausserdem noch heraus, dass unter Debian parport0 = par0 ist,
der Befehl

uisp -dprog=dapa -dlpt=/dev/par0

brachte mir die gleiche Fehlermeldung wie oben genannt.

Nun kann es wohl nur noch am System selber liegen. (Wenn man der
Fehlermeldung Glauben schenken darf!)

Hat es eigentlich einen Einfluss, wie der Paralellport im BIOS
konfiguriert ist? Als EPP, EPC, SPP oder whatever?

Naja, es ist jetzt spät, ich mache morgen weiter, vielleicht nochmal
die 1/2 Ub- an-XTAL2-Messung durchführen.

Gähn Vielleicht hat hier ja noch jemand ne Idee.

Gruß Nico

Autor: Nicolas Dorwig (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ergänzung:
Gelegentlich bekomme ioctl PPCLAIM: Invalid argument
------- Befehl: uisp -dprog=dapa -dplt=/dev/par0
Failed to claim ppdev.
ich bei der Verwendung von /dev/par0 auch das hier:
----------

Also noch was zum Grübeln ;-)

Autor: Tom 'Carp' Neidl (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi,

was für eine Kernel-Version hast Du?
ppdev gibts erst ab Kernel 2.4.x

<Zitat aus uisp/INSTALL>
Parallel port access should still work if you have the Linux ppdev
driver (patch for 2.2.17 is in the kernel directory, ppdev is standard
in 2.4 kernels).  Please lobby Alan Cox to include this tiny little
driver in 2.2.x too :)
</Zitat>

Ähm, das mit Alan Cox ist nur ein Witz :-)

Ultimativer Test: Drucker an lpt1: und "echo Testing >/dev/lp0" in
der Console eingeben, wenn was rauskommt sollte es gehen.

Cya
Tom

Autor: Nicolas Dorwig (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hey Tom!

Danke für deinen Hinweis. Ich habe einen 2.4.20-k6 Kernel. Die Testidee
mit dem Drucker ist mir auch noch gekommen, nur habe ich gerade keinen
Drucker zur Hand, den ich mal eben dranklemmen könnte. Meine Frage wäre
allerdings: Ist /dev/lp0 nicht ein spezielles Drucker-Device, dass
irgendwie über den lpd bearbeitet wird und nur zum Ansprechen von
Druckern verwendet wird und parport0 bzw. par0 die eigentliche
Schnittstelle? Ich meine damit: Wenn ein Drucker über ein spezielles
Druckerdevice funktioniert sagt mir das zwar, ob ich mit der
Schnittstelle drucken kann, aber doch noch nicht, ob ich mit uisp
direkt auf die Schnittstelle zugreifen kann, oder sehe ich das
falsch..?

Naja, werd mal noch ein bischen weiterfummeln. Vielleicht ergit sich ja
noch was aus den Manpages oder so. Ist halt immer das tolle an Linux,
man will nur mal eben was ausprobieren und schon muss man sich damit
auseinandersetzen, was das Betriebssystem im innersten zusammenhält.

Gruß Nico

Autor: Tom \\\'Carp\\\' Neidl (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi Nico,

NP.
Ich hab noch ne Idee. Mach mal "lsdev", dann solltest Du
sehen auf welche I/O-Ports parport0 verweist. Alternativ
(Wenn Du "lsdev" nicht hast) kannst Du auch "cat /proc/ioports"
verwenden.

Sollte so aussehen:
...
keyboard                  1  0060-006f
parport0                     0378-037a
PCI                          0cf8-0cff
...

Wenn nicht, dann ZUERST "modprobe parport_pc", dann
"modprobe parport". Dann nochmal guggen.

btw: parport0 hält Linux nicht zusammen :-)

Cya
Tom

Autor: Nicolas Dorwig (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hey Tom!

Hier das Resultat meine all-abendlichen Bastelei:
Bin nach deinem Posting vorgegangen:

--------- Ausgabe von cat /proc/ioports ----------
...
02f8-02ff : serial(set)
0376-0376 : ide1
0378-037a : parport0
037b-037f : parport0
03c0-03df : vga+
03f6-03f6 : ide0
...
----------------------------------
Okay, soweit sogut! Aber warum 2 mal parport0? verwundertsei

Ich habe immer mehr den Eindruck, dass es mehr ein Hardware-Defekt an
meinem AVR-Board ist, ich glaube auf Sofware-Ebene auf meinem
Linux-System scheint mir alles im grünen Bereich zu sein. Also doch
nochmal testen.

Ich melde mich bei Erfolg. Werde diesen ganzen Krempel der hier jetzt
schon zum Thema Linux und AVR gepostet wurde wohl mal als FAQ
zusammenfassen und ein Mini-Howto für Debian schreiben. Gibt sicher
noch andere, die diese oder ähnliche Probleme haben.

Greetz Nico

Autor: Nicolas Dorwig (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Nachtrag für heute: Eben dachte ich, ich hätte es: Fand beim genauen
überprüfen der Platine noch eine Nicht-Verbindung zwischen GND vom AVR
und des Parport-Steckers. Aber war leider nicht ausschlaggebend für den
weiteren Verlauf.

XTAL2 gibt überigens bei Ub=5V ca. 2,4V ab, sollte wohl soweit auch
stimmen. An RESET liegen 5V an, somit ist der AVR wohl nicht in einem
Dauer-Reset, wie ich anfangs mal vermutete. Also weitersuchen....

Autor: Tom 'Carp' Neidl (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi,

Du hast nur einen parport0, weil 37f - 378 = 8 Byte :-)

Von der Linux-Seite aus scheint es ok zu sein.
Ich denke das Problem muss woanders liegen.
Halt mich bitte auf dem laufenden, wenns geht, würd
mich interessieren.

Cya
Tom

Autor: Nicolas Dorwig (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Servus!

Ich mach einfach mal kurzen Prozess. Kleiner Ausflug in die
Windows-Welt. Werde heute das Board mal bei einem bekannten an den PC
hängen und dann testen ob es da programmierbar ist. Der Bekannte hat
auch glaube ich ein Osziloskop da, was die Diagnostik wohl ein bischen
einfacher gestalten sollte. Vielleicht brutzel ich hier ja auch schon
eine Woche lang mit einem defektem Chip rum...

Gruß Nico

Autor: Nicolas Dorwig (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Servus!

Wollte blos bescheid geben, dass sich das Problem von selber gelöst
hat: Das Board geht und das erste Testprogramm, dass eine LED am Port D
blinken lässt funktioniert! blinkblink

Messungen mit Oszi ergaben, dass alles so funktioniert wie es soll.
Habe eine Lötstelle nochmal erneuert und TADA, es ging!!!!

Trotzdem vielen Dank an alle die mir hier geholfen haben. Ich werde das
angesammelte Wissen zum Thema Linux und AVR mal wenn ich Zeit habe zu
einem HowTo zusammenschreiben.

Viele Grüße und nochmal Danke

Nico

Autor: Dominic Thomé (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>>Die Schaltung und das Kabel
>>sind 100%ig richtig. Deswegen vermute ich den Fehler beim AVR
selbst.

Hmmm, da fällt mir nur eines ein.
Sauber arbeiten sollte man schon.

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.