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
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
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.
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
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.
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.
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
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.
@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
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
> 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.
> 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. ...
Thread beobachten
Seitenaufteilung abschaltenBitte 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
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.