Hallo, ich habe häufig (nicht immer) das Problem, daß ein programmierter AVR am nächsten Tag seinen Dienst nur dann verrichtet, wenn ich das HEX-File mit PonyProg noch einmal in den AVR (Tiny13 als auch Mega8) lade. Ein einfaches Reset-Kommando reicht nicht aus. Als Programmer nehme ich diese "Schaltung" mit den 3 Widerständen am Parallelport. Kann es sich hier um minderwertige Bausteine oder zu häufige Programmierung handeln ? Gruß Günter
Ja, dann muß er aber irgendwann ins Alzheim...
Gast
#690954
>Kann es sich hier um minderwertige Bausteine oder zu häufige >Programmierung handeln ? Da handelt es sich eher um eine minderwertige Programmierhardware.
Wenn du ihn programmierst, dann tut er seinen Dienst, vergisst aber über die Zeit seine Daten? Dann liegts sicher nicht an der Programmierhardware. Es könnte am Programmspeicher-Flash liegen, da dieser nicht unendlich oft neu beschrieben werden kann. Ob sich dadurch verursachte Schäden allerdings in Vergesslichkeit oder bloss in nicht mehr programmierbaren Bytes äussern, weiss ich aber nicht.
Hängt das Funktionieren vielleicht davon ab, ob ein Programmieradapter angeschlossen ist und ob der Programmieradapter "irgendwie" vom Parallelport des PC versorgt wird? Dann wäre ein Bug in deinem AVR Aufbau z.B. dass der AVR ohne Adapter nicht aus dem RESET rauskommt. Zeige mal das Schaltbild und/oder ein aussagekräftiges Foto!
Gast
#690974
Brown-out Detection einschalten ( per Fuse Bits ). Sonst kann es bei zu "langsamer" Abnahme der Betriebsspannung zur teilweisen oder vollständigen "Löschung" des Flash-Speichers kommen. MfG
Ich versuche gerade mir eine Art Hausbus zu bauen. Dementsprechend sehen die Schaltungen aus: Zwei Tiny13: An Pin 2 hängt über einen Widerstand eine LED. Pin 5 ist der Bus Anschluß. Ansonsten 5 Volt über einen 78L05 mit den üblichen Kondensatorn. Eine Reset-Beschaltung über ein RC-Glied brachte auch keine Abhilfe. Mein Mega8 sitz auf einer myAVR-Platine und setzt serielle Signale (vom Webserver) auf PortB0 (Bus) um. Die Programmierschaltung scheint hier nicht auf große Beliebtheit zu stoßen. Allerdings sollte man doch meinen, wenn das Prg einmal funktioniert, müßte es doch dauerhaft gespeichert bleiben. Unabhängig von der Programmiermethode. Gruß Günter
Gast
#690991
Hi @ BenTu: Welche konkreten Hinweise hast du dafür? MfG Spess
BenTu wrote: > Brown-out Detection einschalten ( per Fuse Bits ). Sonst kann es bei zu > "langsamer" Abnahme der Betriebsspannung zur teilweisen oder > vollständigen "Löschung" des Flash-Speichers kommen. > > MfG Danke für den Tip. Werde ich versuchen. Gruß Günter
Hi Guenter, schonmal darueber nachgedacht, Dir einen gescheiten Programmer zu holen? ;) Kommt es denn in Deiner Schaltung zu einem langsamen absterben der Versorgungsspannung? Vielleicht postest ja mal einen Schaltplan. Gruss, Michael
Gast
#691081
> Allerdings sollte man doch meinen, wenn das Prg einmal funktioniert, > müßte es doch dauerhaft gespeichert bleiben. Unabhängig von der > Programmiermethode. So ist es. Programmiert wird über die ISP-Schnittstelle mit digitalen Signalen. Da ist es schnurz-piep egal, wie diese (korrekten) Signale generiert werden. Wenn Du den Controller schon oft geflascht hast, wird er evtl. so langsam am Ende seiner Lebensdauer sein. Aber Du kannst das doch selbst verifizieren: Wenn der Controller wieder nicht geht, flasht Du nicht einfach das Programm wieder drauf, sondern liest das alte erstmal aus. Dann kannst Du die beiden Hex-Files vergleichen, ob sich etwas geändert hat und wenn ja, was.
Da muesst er schon verdammt oft geflasht worden sein, um nachzugeben... ca. 10.000 Schreibzyklen (und faktisch wahrscheinlich noch einige mehr) macht der Speicher schon. Aber ein Auslesen und Vergleichen von Pruefsummen hilft natuerlich, den Verdacht zu verifizieren. Wenn Du 5 mal hintereinander den Speicher ausliest und sich diese 5 Abbilder untereinander unterscheiden ist das ein sicherer Indikator dafuer, dass entweder der Speicher korrumpiert ist oder ein Problem mit der Datenuebertragung vorliegt. Gruss, Michael
Hoi... ich würd einfach mal 'nen frischen AVR einsetzen... wenn der dieselben Probleme hat wird's wohl am Aufbau liegen. Wenn du den mit Ponyprog beschreibst, macht der eh 'nen verify - ob du willst oder nicht. Ansonsten schließ ich mich an: Sobald der Probleme macht, einfach das aktuelle Programm als HEX runterladen und mit dem Original vergleichen.
Hallo, ich hatte dieses Problem auch schon. Ich habe damals festgestellt, dass immer die ersten 2 Bytes im Programmspeicher verändert waren. Versuche ergaben, dass dieses Verhalten nur bei angeschlossenem Programmieradapter zu beobachten war. Lösung hier (Antwort von MAWIN): http://groups.google.de/group/de.sci.electronics/browse_thread/thread/9bcaafab08399b1c/e7dca04d0541c903?hl=de&lnk=gst&q=reinhard+richter# Entferne mal deinen Programmierstecker sofort nach dem Programmieren und schau ob der Prozessor immer noch Zicken macht. Gruß Reinhard
Gast
#691108
Ja, ich denke die im letzten Beitrag erwähnte Ursache klingt plausibel, sofern der AVR nicht sehr alt ist oder durch Überspannung gelitten hat. Komische Effekte gibt es da mehr als man glauben mag. Durch versehentliche, nicht mehr genau reproduzierbare Fehlbehandlung habe ich mal bei einem 90S1200 die Signatur gelöscht, obwohl das eigenlich gar nicht möglich sein sollte. Das Bauteil ist mit AVRDUDE weiterhin beschreibbar, aber nur, wenn man den Typ manuell vorgibt und die gelesene Signatur ignorieren läßt.
Gast
#691215
Ich habe die Programmierleitung (2Meter) bislang immer dran gelassen. Das könnte natürlich das Problem verursachen.
Sebastian wrote: > Durch > versehentliche, nicht mehr genau reproduzierbare Fehlbehandlung habe ich > mal bei einem 90S1200 die Signatur gelöscht, obwohl das eigenlich gar > nicht möglich sein sollte. Doch, das ist möglich. Irgendwo hier im Forum gibts die Befehle dazu, ich habe das reproduzierbar auch schonmal gemacht. Bei den neueren AVRs geht das aber nicht mehr.
> Ich habe die Programmierleitung (2Meter) bislang immer > dran gelassen... Kannst du ja auch weiterhin so machen, aber wenn du die Versorgungsspannung des µC aus- oder einschaltest, sollte die Programmierleitung entfernt sein - vor Allem, wenn sie so lang ist. Bei mir trat das Problem auch erst auf, nachden ich die Programmierleitung verlängert hatte. Steht alles in dem Thread im Link, den ich weiter oben gepostet hatte. Gruß Reinhard
Gast
#691265
des wegen gibt es den Kanada ST2000/300 Dongel. Der verhindert das Korumpieren des Flash bei abgeschalteter Versorgungsspannung, in dem er die Programmierleitungen nur bei eingeschalteter Versorgungsspannung durchschaltet.
Benedikt K. wrote: > Sebastian wrote: >> Durch >> versehentliche, nicht mehr genau reproduzierbare Fehlbehandlung habe ich >> mal bei einem 90S1200 die Signatur gelöscht, obwohl das eigenlich gar >> nicht möglich sein sollte. > > Doch, das ist möglich. Irgendwo hier im Forum gibts die Befehle dazu, > ich habe das reproduzierbar auch schonmal gemacht. Bei den neueren AVRs > geht das aber nicht mehr. Beitrag "ATmega64 vergist seine Signature-Bytes"
@liftmonteuer Winne
> des wegen gibt es den Kanada ST2000/300 Dongel.
Link? ^^^^^^^^^^^^^^
Google findet nichts :-(
Gruß Reinhard
Gast
#691305
sorry heist STK200 http://www.mikrocontroller.net/articles/STK200
Gast
#691306
wenn du danach googelst findest du an die100 Bschreibungen
Ja, mit der richtigen Bezeichnung hast du recht :-) Gruß Reinhard
denke mal das hier ein Problem der Resetbeschaltung vorliegt und es beim Programmieren Einbrüche gibt oder die Pause bis zum Pragrammierbeginn zu kruz ist weil das RC Gleid am Reset Pin falsch dimensioniert ist.
Antwort schreiben
Bitte melde dich an, um einen Beitrag zu schreiben.