Forum: Mikrocontroller und Digitale Elektronik Atmega 32_16PU, JTAGICE_MKII, Programiersprache C, STK 500


von Michael S. (misei_3216)


Lesenswert?

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

von Georg G. (df2au)


Lesenswert?

Der STK500 verstellt gern mal die Betriebsspannung. Wenn dann BOD 
aktiviert ist, steht alles still.

von Michael S. (misei_3216)


Lesenswert?

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.

von Marc S. (marc_s86)


Lesenswert?

was hast du denn an den AVR angeschlossen?  villeicht sind deine 
Ausgänge durchgebrannt?

von Michael S. (misei_3216)


Lesenswert?

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?

von Michael S. (misei_3216)


Lesenswert?

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ß?

von spess53 (Gast)


Lesenswert?

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

von Michael S. (misei_3216)


Lesenswert?

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

von Michael S. (misei_3216)


Lesenswert?

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.

von spess53 (Gast)


Lesenswert?

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

von Michael (Gast)


Lesenswert?

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

Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.