Atmega32 reagiert irgendwie nicht mehr!

hi!

ich weiss nich mehr genau wie es passiert ist, aber ich bin mir relativ sicher dass das letzte mal als ich meinen atmega32 (im rn-control) geflasht habe das programm funktioniert hat..

jedenfalls hab ich ihn für ein paar monate weggelegt und gerade wieder eingeschaltet..und es tat sich nix..ein angeschlossenes display zeigt nur ne init-zeile und reset-drücken bringt auch nix

flashen (über parallelport) geht auch nicht, das board is irgendwie "tot"

ist jetzt ein bisschen knapp beschrieben, aber ich weiss nicht woran es liegen könnte bzw was ich noch dazu schreiben soll um die fehlersuche zu erleichtern (fuses hab ich diesmal nich angefasst ;) )



hat jemand ne idee?

ich würd mal Spannung am µc messen, Quarz kontrollieren, ggf. einen anderen µC testen um Defekte am Programmer auszuschließen.

also spannung is da, der quarz scheint zu schwingen und nen anderen atmega hab ich natürlich nich zur hand ;) meinst du er könnte kaputt sein?

Hhmm wenn du absolut gar nix geändert hast würd ich mal auf defekten µC oder defekten Programmer tippen. Und da das Programm ja nicht mal mehr anläuft und das Display nix anzeigt würd ich auf den µC tippen.

hört sich ja nich so doll an..

ok danke, dann muss ich mal sehen dass ich irgendwo ne bestellung zusammenkriege und nen neuen atmega in den warenkorb schmeissen..

Wär jetzt meine Vermutung.. kann auch durchaus was anderes sein so dass du dir keinen neuen µC kaufen musst aber ich wüsste nicht was. Vllt kommen ja noch ein paar andere Kommentare, nicht dass du jetzt Hals über Kopf Geld ausgibst was (vllt) gar nicht notwendig ist.

Elkos noch ganz?

naja ich kann so dicke elkos leider nich mit meinem multimeter testen..

ja aber defekte elkos erkennt man am äußeren! (aufgebläht oä.)

nene, so schlimm siehts nich aus;) sehen ganz normal aus

dann wirds wohl der µC sein und bei dem C-Conrol prozessor sind das direkt 20 euro oder so...

so, ich hatte endlich einen neuen atmega32 gekauft, ausserdem nen avrisp II und da ich jetz auch nen anderen pc habe, auch avr studio installiert... nachdem avr studio so halbwegs lief(man is das teil ätzend..) habe ich ein altes programm geflasht (ein neues wollte avr studio nich kompillieren)..

angeschlossen is ein 16x2 lc-display, welches bei dem geflashten programm sofort eine "uhrzeit" anzeigt..das tat es auch. aber die uhr lief nicht wie es das program vorsieht, sondern blieb einfach bei 00:00 stehen. reset brachte nix, und jedes mal wenn ich den akku raus und wieder reinsteckte zeigte das display die uhr an, aber ohne dass sie lief. nach dem 5. mal akku ab und anstecken hatte das display wie beim alten µc nur noch einen balken gezeigt, herzlichen glückwunsch! keine reaktion mehr, avr studio meldet "sck is shorted" oder sowas


was ist nun passiert, frisst mein rn-control atmegas? :evil: :evil: :evil: :evil: oder bin ich einfach zu blöd für das teil?

Wenn der µC eine Zeit lang lief und dann plötzlich kaputt ist tippe ich auf eine falsche Beschaltung. Untersuche auch mal vor allem die Spannungsversorgung (vielleicht ist die Spannung zu groß oder so).

mfg

falsche beschaltung? da hängt nix am Rn-control dran, ausser dem display, welches auch monate lang funktioniert hat. akku is ein alter 8zellen nicd akku, also spannung sollte auch nich zu hoch sein, außer diese ominösen jumper zum spannungsmessen auf dem rn-control, aber das sollte auch nich problematisch sein

scheinbar haben 24h ruhe dem teil zu neuen kräften verholfen. danach hat er nämlich doch wieder das programm angezeigt..seltsamerweise konnte er sich mit der "normalen" taktfrequenz vom isp nicht mehr ansprechen lassen sondern nur mit 50Hz..(fuses waren nicht gesetzt, aber das programm konnte ich ihm doch auch mit der default taktrate draufladen..seltsam!)

naja mal schauen wielange er diesmal hält

Was für einen Programmer benutzt du überhaupt? Kann es sein, dass der spinnt und irgendwelche falschen Fuses setzt?

mfg

also ich denke nich, dass er spinnt. is der avrisp mkII, ganz neu gekauft und neueste fw drauf

Das klingt stark nach Hardwareschaden, vielleicht eine kalte Lötstelle die je nach Temperatur zwischen hochohmig und niederohmig wechselt.

Grüße
Thomas

Vielleicht auch eine unsaubere Verbindung zwischen AtMega und Programmer (nicht richtig in die Fassung gesteckt).

naja ich weiss es nicht, lötstellen und fassungen checken is nich unbedingt mein fachgebiet. jetz hab ich gleich das nächste prob mit dem teil, aber ich schau erstmal selbst ob ich das nich beheben kann..irgendwie sind die fuses wohl nich richtig gesetzt, waitms ist zwar genau aber die frequenz des beepers is geschätzt um den faktor 40 zu tief

Wenn der Befehl Waitms richtig ausgeführt wird, dann stimmt wohl die dem Compiler mitgeteilte Taktfrequenz mit der realen Taktfrequenz überein. Daher vermute ich ein Softwareproblem. Poste doch mal den aktuellen Code, der auf dem Controller läuft.

Grüße
Thomas

is leider etwas schwierig, denn die .hex datei is noch vom alten pc, mit winavr gemacht. den sourcecode davon kann ich nich mehr finden.. und avrstudio zickt noch rum..ich werds mal die tage nochmal versuchen

Ein Programm wird nicht richtig ausgeführt und du hast nicht mal das Listing davon? Dann schreib einfach ein neues, einfaches Programm und lass das testweise am Controller laufen. Lass einfach eine LED im Sekundentakt blinken oder so...

Grüße
Thomas

so, mitten in der nacht sitze ich wieder dran..

also ich schätze dass es mal wieder mit den fuses nicht funzt..also ich hab jetz das RN-Control demo programm in avr studio geladen, und es an den atmega gesendet (geht wieder nur mit niedriger sendefrequenz)
jetz piept er so als ob die fuses nich richtig gestellt worden wären, es is aber egal was ich einstelle es verändert sich nix. ich hab jetz alle "external chrystal high frequency" einstellungen gestestet die avr studio hat, aber es bleibt dabei, das piepen ist zu langsam..bin mal wieder am verzweifeln..

hallo, es geht wieder weiter, nachdem ich wegen ein paar traurigen gründen nich dransitzen konnte...

ich habe jetzt wiedermal die beispielcd rausgekramt und die fertige .hex datei vom beispielprogramm genommen, damit geht alles wunderbar! sobald ich aber das beispiel-c-programm von rn hineinlade, ist alles zu langsam! ich schätze es hat was mit dem makefile zu tun? ich habe die frequenz bei configuration auf 16000000 hz eingestellt, wie üblich, aber das scheint wohl nich zu klappen.. ich erinnere mich dass ich die gleichen probleme damals mit winavr hatte, und seit ich das makefile von der cd genommen habe, ging es damit..aber wieso erstellt avr studio ein falsches? bzw was stimmt hier nicht?

thx

Bei mir hat AVR Studio noch nie falsche Makefiles erstellt, wenn ich unter Configuration alles richtig einstelle (also Device und Takt und höchste Optimierung). DU benutzt auch die neueste Version von AVR Studio und WinAVR?

ja die versionen sind die neusten, device stimmt auch und sonst wüsste ich nich was man noch falsch einstellen könnte


wenn ich den takt bei configuration runter setzte dann funktioniert es, wenn ich 1000000hz einsetze scheint das timing zu stimmen, also 16 mal zu schnell...ich frag vielleicht nochmal drüben bei mikrocontroller.net...

Wird bei deinem waitms die Zeit mit einer Variablen übergeben?
Dann kann das nicht funktionieren.
Es gab erst kürzlich einen Thread darüber.

hallo hubert, kannst du mir das bitte genauer erklären? bzw den thread zeigen? ich hab jetz sozusagen das programm von rn-wissen genommen, klar wird da irgendwas an waitms übergeben.. und warum kann das nicht funktioniern?

http://www.roboternetz.de/phpBB2/vie...=487567#487567
In order for these functions to work as intended, compiler optimizations must be enabled, and the delay time must be an expression that is a known constant at compile-time. If these requirements are not met, the resulting delay will be much longer (and basically unpredictable)
Ich hoffe du kannst diese Erklärung lesen.

hallo, ja ich kann die erklärung lesen, leider hat von einer sekunde auf die anderen jetz das isp vom avr den dienst quittiert, ich schmeiss das ding echt gleich an die wand, sorry ](*,) ](*,) ](*,)

also habe ich das richtig verstanden, im rncontrol.h wird die funktion waitms() definiert, und überall benutzt ausser bei der tonerzeugung, wo _delay_ms() benutzt wird (warum?), und diese funktion geht nur wenn die compileroptimierung angeschaltet ist (ist sie bei mir aber...) und einen konstanten wert bekommt (der wert is doch konstant?) und sonst funktioniert das nicht (früher mit winavr hats aber funktioniert?) ?

und was is die offizielle lösung zu diesem problem? kein _delay_ms() benutzen? warum wird es an der stelle eigentlich benutzt und nich waitms()?

Das Problem ist, das der Compiler dem delay einen Wert beim compilieren zuweisen muss. Das wird bei diesem Programm mit einer Variablen gemacht.
Die offizielle Lösung ist, Timer benutzen.

Zitat:

---

Die offizielle Lösung ist, Timer benutzen.

---

Ich hab eine einfachere Idee (in diesem Beispiel wird 1,3s gewartet):

Code:

---

for(int i = 1300; i > 0; i--)
    _delay_ms(1);

---

EDIT:
Hab ich vergessen, 1300 kannst du natürlich durch deine Variable ersetzen.

also ich raffe nix mehr. manche funktionen des beispielprogramms scheinen normal zu laufen wie z.b. das led-lauflicht. der rest is total verhunzt. warum das früher ging versthe ich auch noch weniger..is mir leider alles zu hoch :(

Dann empfehle ich dir ein komplett neues Programm zu schreiben (das hättest du schon viel früher machen können) und erst mal die Wartefunktionen auszuprobieren.