Schönen Guten Morgen, folgende Schwierigkeit: Ich habe einen Atmega32_16PU im roten Sockel vom STK500. Das Programm lief bis vergangene Woche sehr gut. Es wurde vom yC abgearbeitet und die Ein- und Ausgänge entsprechend angesteuert. Nach einer Neuprogrammierung habe ich nun folgendes Phenomen: der Microcontroller kann Programmiert werden, jedoch Muxt er sich nach aussen nicht. Anfangs ist er sporadisch noch gelaufen, doch nach einem Neustart ist er nun Ausgeblieben. Er ist mit Spannung versort. Ich kann ihn über die JTAG - Schittstelle Programmieren und Auslesen. Die Fusebits lassen sich ebenfalls schreiben und lesen. Auch die alte Programmversion welche ich nochmals aufgespeilt habe läuft nicht mehr. Beim Auslesen des Microcontrollers ist mir aufgefallen, dass das erzeugte Hexfile vom zu Programierenden File Abweichungen zeigt. Ich weiß allerdings nicht wo hier an welcher Stelle etwas zu finden ist, wo z.B die Prozessorgeschwindigkeit oder Teilungsfaktoren der Timer oder auch die Startadresse ... zu finden ist. Es kann natürlich auch sein dass die Abweichungen im File von Variablendeklarationen innerhalb des Programmes kommen sofern dieses denn bearbeitet wird. Wie kann ich das herausfinden. Hat hier jemand eine Idee bzw. die Erfahrung den Prozessor ins laufen zu bekommen? Danke euch, Michael
Der STK500 verstellt gern mal die Betriebsspannung. Wenn dann BOD aktiviert ist, steht alles still.
Georg G. schrieb: > Der STK500 verstellt gern mal die Betriebsspannung. Wenn dann BOD > aktiviert ist, steht alles still. Hallo Georg, als Betriebsspannung wird 5,1 V Angezeigt. Meinst du mit BOD das BODEN Fuse-bit? dieses ist deaktiviert.
was hast du denn an den AVR angeschlossen? villeicht sind deine Ausgänge durchgebrannt?
Marc S. schrieb: > was hast du denn an den AVR angeschlossen? villeicht sind deine > Ausgänge durchgebrannt? Hallo Marc, Er ist im STK 500 an der dortigen Pherepherie. Wie beschrieben hat er funktioniert. Er hat die Ausgänge aktiviert und über UART kommuniziert. Nach einem Neustart dann nichts. Bzw. ist er noch ein oder zweimal gelaufen. Dies alles ohne an der Pherepherie etwas zu ändern. Ein Neuer ist aber bestellt. Dann wird sich dieses Kriterium ausschliessen lassen. Mich wunder nur, dass das Hex File nicht übereinstimmt. Wo stehen denn die wichtigen Einträge wie Startadresse und CPU Frequenz?
Was auch noch interessant sein dürfte ist, ob das JTAGMKII richtig eingestellt ist und ob das übertragungsprotokoll stimmt. Gibt es hier etwas zu verstellen von dem ich vielleicht nichts weiß?
Gast
#4220540
Hi >Mich wünder nur, dass das Hex File nicht übereinstimmt. Das ist normal. >WO stehen denn die wichtigen Einträge wie Startadresse Das Programm startet immer bei 0x0000 > und CPU Frequenz? Was soll die im Hexfile? MfG spess
spess53 schrieb: > Das Programm startet immer bei 0x0000 Hallo Spess53 das ist in soweit richtig wenn du nicht mit einem Bootloader arbeitest. spess53 schrieb: > Das ist normal. Kannst du mir erkären warum sich das so verhält? Nachtrag: MarcS gibt es eine Möglichkeit die druchgebrannten Ports durch Messungen herraus zu finden? Danke euch
Hallo, ein kleiner Zwischenversuch: Ich habe ein kleines Testprogramm geschrieben in welchem nur die PORTS als Ausgänge deklariert werden. Hier wollte ich die PORTS manuell setzen. Das Übertragen funktioniert abermals ohne Schwirigkeiten. Beim Versuch zu Debuggen gibt mir das ATMEL STUDIO eine Fehlermeldung aus:"...debugger command leaveProgMode failed". Ich denke ich warte auf den neuen Processor. Und versuche es hiermit abermals.
Gast
#4220584
Hi
>Kannst du mir erkären warum sich das so verhält?
Beim Auslesen wird der komplette ROM stur Byte für Byte ausgelesen. Also
auch Bereiche, die kein Programm oder Daten enthalten.
Wird das Hex-File generiert werden solch Teile durch entsprechende
Adressrecords ersetzt.
MfG spess
Gast
#4220601
spess53 schrieb: > Beim Auslesen wird der komplette ROM stur Byte für Byte ausgelesen. Also > auch Bereiche, die kein Programm oder Daten enthalten. > > Wird das Hex-File generiert werden solch Teile durch entsprechende > Adressrecords ersetzt. Hallo, ja das ist richtig. Der Speicher wird vor dem schreiben mit FF gefüllt(beschrieben). Dann wird Byte für Byte übertragen. Der Freie Speicherbereich ist somit klar mit FF zu erkennen. Doch hier mal ein Beispiel: 1. Zeile 6 aus der zu schreibenden Hex Programmfile: :100050000C94CE00421A371A2C1A211A161A0B1AAF 2. Zeile 6 aus Microcontrolle gelese. :100050000C94CE00DB1BE01BE51BEA1BEF1BF41B23 hier noch zeile 7 direkt zum vergleich untereinander zu schreiben :10006000001AF519EA194D1A00407A10F35A00A047 ausgelesen :10006000001C051C111C161C00407A10F35A00A03D