mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik Atmega programmiert...keine Fusebits geändert...µC tot


Autor: Markus Kolar (markusk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Habe ein unangenehmes Problem.

bin besiter des Pollin Eval boards und habe den Atmega16 drauf. So nun 
habe ich ein Assemblerprogramm zum Übertragen von SPI Kommandos und 
anschleißende Daten zum Senden per ASK oder FSK an eine Sendestufe. Das 
hat soweit auch funktioniert, nur dass mein mein SPI Bus nicht immer 
nach nem reset angesprungen ist. War so alle fünf bis zehn Tastendrücke 
bis er anspran.

Das hat mich dazu veranlasst mein AssemblerProgramm noch etwas zu 
ändern. Nun habe ich den Atmega mit der neuen Version programmiert. Doch 
seitdem geht nichts mehr. Kein Signal, keine Erkennung des 
Basuteins...quasi tot.

Ponyprog kann auch die Security bits nicht auslesen...er sagt no device 
found.

Bevor jetzt Fragen kommen wie Stromversorgung ok oder mal nen anderen µC 
ausprobiert...ja Stromversorgung ist 100% in Ordnung und ich habe auch 
andere µC ausprobiert. Mittlerweile sind 3!! Atmega16 im Tiefschlaf oder 
gar tot. Das einmalige programmierern ging einwandfrei, aber danach geht 
nix mehr.

Ich frage mich ob das überhaupt möglich ist den µC mit nem Assembler 
progreamm so zu töten, oder irgendwelche bits zu ändern.

Soviel ich weiss geht das nicht.

Weiss jemand hilfe?


Als Anhang der Code als asm-File

Autor: Marc989 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi,
ich kenn zwar den Atmel nicht, aber gibt er irgendwas von sich 
(Quarz!!!). oder ist er auch hier tot? Wie ist es mit dem stromverbrauch 
des controllers, fließt da noch irgendwas?
Man kann zwar vieles anstellen aber so das sie danach tot-geflasht sind 
ist mir auch noch nicht vorgekommen.

Marc989

Autor: Markus Kolar (markusk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Nun ja der Quarz gibt in der Tat nix raus. Ok aber ich hab mittlerweile 
auch andere Boards, 3 an der Zahl, ausprobiert und es geht niergends 
was.

Autor: Erwin Reuss (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich glaube, ich kann das Problem absolut nachvollziehen. Deine 
Controller sind sicher nicht defekt.

Folgendes ist passiert: Weil Du die SPI-Schnittstelle vom Programm in 
Controller nutzt, wird die Programmierschnittstelle über die SPI-Pins 
blockiert. Das geschieht, weil zu Beginn des Programmiervorganges die 
Reset-Leitung kurzzeitig auf High und dann wieder auf Low gelegt wird. 
Wenn nun diese High-Zeit zu lang ist, werden schon die ersten Befehle 
ausgeführt und der SPI-Port umprogrammiert. Auch das nachfolgende Low 
auf der Reset-Leitung ändert nichts daran. Die Folge ist, daß sich der 
Controller über den SPI-Port nicht mehr programmieren läßt... zumindest 
mit diesem Programm nicht.

Abhilfe schafft hier nur ein anderes Programmierprogramm, das einen nur 
sehr kurzen High-Impuls (1-5 Mikrosekunden reichen) auf den Reset-Pin 
gibt, so daß das Programm nicht mehr anlaufen und die Pins 
umprogrammieren kann. Welches Programm dazu in der Lage ist, kann ich 
leider auch nicht sagen. Ich habe mir  deshalb schon mehrere eigene 
Programmiertools speziell für meine Anwendugen geschrieben, die dieses 
Problem umgehen.

Erwin Reuss

Autor: Simon K. (simon) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ahja, na das halte ich mal für ein Gerücht....

Eigentlich sollten alle Pins beim Reset Mode unabhängig von der 
Einstellung, die das eigentliche Programm vornimmt, sein.

Autor: Benedikt K. (benedikt) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Simon Küppers wrote:
> Eigentlich sollten alle Pins beim Reset Mode unabhängig von der
> Einstellung, die das eigentliche Programm vornimmt, sein.

Jain.
Was durchaus passieren kann:
Hat man ein SPI IC angeschlossen, kann dieses aktiv sein, da z.B. dessen 
Chipselect floatend ist und abhängig vom letzen Zustand auf dem CS Port 
dieser noch Low ist.
Abhilfe: Pullup an den Chipselects oder Widerstände zwischen SPI 
Eingangspin und IC, so dass der Programmer den Pin sicher auf Low/High 
ziehen kann.

Autor: Uwe (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi!
Sowas habe ich unlängst mal irgendwo gelesen, das soll tatsächlich so 
sein.
Abhilfe war wohl Reset schon bei Power on auf low halten bis ISP 
reagiert.
Habe ich aber nur gehört, aber einfach mal im Hinterkopf halten.

Viel Erfolg, Uwe

Autor: Markus Kolar (markusk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Es tut sich was. Ich hab mal auf gut Glück probiert ob evtl. nicht die 
Fuse bit für den Clock select irgendwie gesetzt sind. Hab einen 
Freq-Generator an den Xtal In-Pin gehängt und sieh da er konnte 
plötzlich die Fusebits wieder lesen...und siehe da...es waren alle 
gesetzt(also häckchen war drin). Habs dann überschrieben so wie sichs 
gehört und plötzlich liefen zwei der drei Atmega16 wieder. Lediglich bei 
einem kann ich die Fuse bits nicht ändern und es sind demzufolge alle 
noch gesetzt.

Merkwürdigerweise kann ich das nur mit meinem Notebook 
programmieren....der Desktop Rechner mit dem es bis Vorgestern 
einwandfrei lief hat nachwievor keinen Zugriff auf meine drei Atmega16.

Es bleibt aber immer noch die Frage warum der SPI-Bus nach nem Reset 
nicht sofort anläuft...ich muss meistens den Reset-button mehrmals 
drücken, bis sich was tut. Hab das ganze ans Oszi gehängt, deswegen kann 
ich das so genau sagen.

Autor: Erwin Reuss (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Simon Küppers:
Ich hatte vor einiger Zeit ein Projekt, bei dem die SPI-Pins sofort nach 
dem Reset allesamt als Ausgang geschaltet wurden. Prompt lies sich der 
Controller nicht mehr programmieren. Ich habe auch erst gedacht, daß ich 
den Controller gekillt hatte, aber dann hab ich es mal mit einem sehr 
kurzen Reset-Impuls versucht und damit klappte das sofort. Auch ich hab 
mich darauf verlassen, daß die Portpins beim Reset ihre ursprüngliche 
Funktion einnehmen, aber hier geht wohl Theorie und Praxis weit 
auseinander.


@Markus Kolar:
Ich nehme mal an, daß Dein Controller auf den internen RC-Takt oder der 
CLKDIV8 gesetzt ist. Dann kann es gut passieren, daß der Controller so 
langsam läuft, daß der SPI-Takt vom PC zu schnell ist. Der Notebook hat 
sicher einen langsameren Prozessor und erzeugt hierdurch einen 
geringeren SPI-Takt und dadurch läßt sich der Controller damit 
programmieren. Sobald Du die Fusebits wieder richtig gesetzt hast, 
sollte es auch mit dem PC funktionieren.

Erwin Reuss

Autor: Toby (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi,

ich habe leider soeben ein ähnliches Problem bekommen: seit einiger Zeit 
programmiere ich einige ATMEGA32 über die ISP-Schnittstelle mit PonyProg 
(Version  2.07c Beta  Jan  6 2008), was auch immer wunderbar 
funktioniert hat. Seit dem letzen Flashen hat sich an der Hardware und 
Software nichts geändert, ich habe also den gleichen Quellcode geflasht, 
wie er bereits auf dem Prozessor war. PonyProg hat auch gemeldet, dass 
das erfolgreich war. Doch jetzt lassen sich die Prozessoren nicht mehr 
ansprechen (nicht lesen und nicht schreiben). Versorgungsspannung liegt 
an, ob der Quarz noch was von sich gibt, habe ich noch nicht getestet. 
Das ärgerliche ist nur, dass ich in PonyProg keine Einstellungen 
geändert habe, sondern wie immer geflasht habe. Ich vermute (und hoffe 
schlimmstenfalls) dass die fuse-bits falsch gesetzt wurden. Aber wieso 
sollte PonyProg beim normalen Flashen, was hunderte Male funktioniert 
hat auf einmal die fuse-bits setzen? Ist das ein bekannter Bug? Was 
könnte noch die Ursache sein? Immerhin ist es gleich zwei mal 
hintereinander bei verschiedenen Prozessoren aufgetreten, was einen 
Hardwaredefekt bei den Prozessoren eigentlich unwahrscheinlich macht. 
Den ISP-Programmer habe ich an einem weiteren ATMEGA getestet, diesen 
konnte ich zumindest auslesen. Am Programmer scheint es also nicht zu 
liegen.

Toby

Autor: Bensch (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Ist das ein bekannter Bug?

Ja, Ponyprog ist ein bekannter bug....

Mehr als 90% aller Probleme hier im Forum treten bei diesem Schrott auf. 
Es gibt doch geung andere Programme, die weniger Probleme machen, also 
nutzt sie auch.

Autor: Hannes Lux (hannes)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Ich vermute (und hoffe
> schlimmstenfalls) dass die fuse-bits falsch gesetzt wurden.

Das liegt nahe.

> Aber wieso
> sollte PonyProg beim normalen Flashen, was hunderte Male funktioniert
> hat auf einmal die fuse-bits setzen?

Weil Ponyprog die Schnittstellen-ICs für Bitbanging missbraucht und 
dabei auch noch hart am Limit arbeitet. Dies hat zur Folge, dass bei 
etwas längeren Leitungen die Signale etwas verwaschen am AVR ankommen, 
die Unterscheidung H/L also zum Roulette wird. Durch Kippen einzelner 
Bits der ISP-Telegramme können die Telegramme fehlinterpretiert werden 
und statt des Beschreiben des Flashs werden eben mal schnell die Fuses 
verändert.

> Ist das ein bekannter Bug?

Ja, das ist seit Jahren bekannt.

> Was
> könnte noch die Ursache sein?

Der Transistor im Programmer des Pollin-Boards könnte eine zu geringe 
Stromverstärkung haben, wodurch der Reset nicht sauber und nicht schnell 
genug ausgeführt wird. Miss mal dessen Stromverstärkung aus und bau ggf. 
mal einen stärkeren ein.

Besserer Tip:
Kauf' Dir vernünftiges Equipment, Ponyprog und Pollin-Board gehören 
definitiv nicht dazu.

...

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.