Moin, gerade bin ich bei meinen Eltern und habe eine Platine mit einem unbeschriebenen ATmega8 zusammengelötet. Leider habe ich den Programmieradapter vergessen. Der liegt in meiner Wohnung, wo ich aber kein Lötzeug für eventuelle Änderungen habe. Gibt es irgendeine Möglichkeit zu sehen, ob ein neuer (unbeschriebener) AVR läuft? An den Pins kann man es wohl nicht erkennen. Die sind im Auslieferungszustand hochohmig, wenn der Controller nicht läuft, wahrscheinlich auch. Für die Taktanschlüsse müsste man wohl die Fuses entsprechend programmiert haben. Wie sieht es mit der Stromaufnahme aus? Kann man daran erkennen, ob der Controller läuft oder sich vielleicht im Dauerreset befindet? Gibt es andere Möglichkeiten?
Ob er grundsätzlich lauffähig ist oder ob es irgendwo ein Problem gibt (kein Takt, Dauerreset, falsche Versorgung aus irgendeinem Grund).
Wenn man ihn 'so' einschaltet, sollte er ja trotzdem etwas tun. Entweder die FF im Speicher überspringen oder ständig nach einer Anweisung resetten, je nachdem, was er eben bei dem Opcode FF macht.
Dussel schrieb: > Wenn man ihn 'so' einschaltet, sollte er ja trotzdem etwas tun. Entweder > die FF im Speicher überspringen oder ständig nach einer Anweisung > resetten, je nachdem, was er eben bei dem Opcode FF macht. Und wie erkennst du das von außen? Du kannst nur die Stromaufnahme an Vcc messen und mit den Werten im Datenblatt abgleichen. Hat aber weiter nicht besonders viel Aussagekraft.
...also von hier aus kann ich ganz deutlich sehen, das er läuft. Man kann auch mal vorsichtig den Finger drauf legen. Man müsste ja den Oszillator spüren, oder ??
bj schrieb: > Man kann auch mal vorsichtig den Finger drauf legen. > Man müsste ja den Oszillator spüren, oder ?? Falls er falsch angeschlossen ist, kann man das ebenfalls mit der Fingermethode ermitteln. (Das war kein Scherz)
falls dein PC noch eine parallele Schnittstelle hat, könntest du den AVR auch ohne Adapter beschreiben. http://thomaspfeifer.net/einfaches_atmel_programmierkabel.htm
Reset und Spannungsversorgung kannst du mit einem Multimeter prüfen. Ein jungfräulicher AVR wird intern getaktet, da kannst du von außen weder etwas messen noch etwas falsch machen.
Wenn der Reset Pin von außen high ist, dann läuft er.
Peter schrieb: > Dussel schrieb: >> Wenn man ihn 'so' einschaltet, sollte er ja trotzdem etwas tun. Entweder >> die FF im Speicher überspringen oder ständig nach einer Anweisung >> resetten, je nachdem, was er eben bei dem Opcode FF macht. > > Und wie erkennst du das von außen? Genau das ist ja die Frage. Thomas L. schrieb: > falls dein PC noch eine parallele Schnittstelle hat, könntest du den AVR > auch ohne Adapter beschreiben. > > http://thomaspfeifer.net/einfaches_atmel_programmierkabel.htm Daran habe ich auch gedacht, habe ich aber nicht. MaWin schrieb: > Wenn der Reset Pin von außen high ist, dann läuft er. Auch wenn der Controller einen Fertigungsfehler hat? Auch wenn er beim Löten zu heiß wurde? Auch wenn die Pins nicht richtig angeschlossen sind (gut, das kann man mit einem Multimeter prüfen). Auch wenn es Störungen gibt, die ein sauberes Anschwingen nicht erlauben? Stefan U. schrieb: > Ein jungfräulicher AVR wird intern getaktet, da kannst du von außen > weder etwas messen noch etwas falsch machen. Das habe ich mir gedacht. Aber ich wollte doch mal fragen, ob es nicht irgendwelche Tricks gibt. Dann bleibt mir wohl nichts anderes übrig, als es zu riskieren. Danke für die Antworten.
Ja - und selbst, wenn du läuft/läuft nicht herausgefunden hättest. Was machst du dann ohne Prog-Adapter? Programmieren geht doch sowieso nicht. Auf dem Stand bist du (wieder zu Hause) in wenigen Minuten genau so. - Vielleicht unterhältst du dich mal mit den Eltern? - Unternimmst was mit den Jugend-Bekanntschaften? - ???
Dussel schrieb: > Dann bleibt mir wohl nichts anderes übrig, als es zu riskieren. Riskiere es! Das ganze Leben besteht aus Risiken! Milliarden solcher Prozessoren werden so bestückt und hinterher programmiert.
Hi Irgendwie verstehe ich das grundlegende Problem nicht. Wobei mir auch nicht in den Sinn käme, extra zu meinen Eltern zu fahren, um dort einen µC zu verlöten ;) Nun denn, das Ding ist verlötet - mit Spannung dran KÖNNTE der µC Lebenszeichen von sich geben, unprogrammiert aber wohl eher nicht. Zu Deinen Mutmaßungen, was wohl ist, wenn 'sonst was' zutrifft - Du hast vergessen zu fragen, ob der µC noch läuft, wenn man - aus Versehen - ein oder mehrere Beinchen abflext - nein, dann ist Er hin (mit Bordmitteln zumindest). Also: Wie meinen? MfG
Dussel schrieb: > Gibt es irgendeine Möglichkeit zu sehen, ob ein neuer (unbeschriebener) > AVR läuft? jaein, gibt es nicht. In Werksauslieferung sind alle IOs als Eingänge beschaltet, das (äquivalente) Programm, dass läuft lautet
1 | int main(void){ |
2 | return 0; |
3 | }
|
der Atmega tut also nichts. Das einzige, was man "sehen" kann ist, dass der Atmega Strom aufnimmt. Aber das als Indiz zu betrachten, dass er läuft halt ich für zweifelhaft.
michael_ schrieb: > Dussel schrieb: >> Dann bleibt mir wohl nichts anderes übrig, als es zu riskieren. > > Riskiere es! > Das ganze Leben besteht aus Risiken! > Milliarden solcher Prozessoren werden so bestückt und hinterher > programmiert. So hoch ist das Risiko natürlich jetzt nicht. :D Es wäre nur schön gewesen, Fehler vorher ausschließen zu können. Patrick J. schrieb: > Irgendwie verstehe ich das grundlegende Problem nicht. > Wobei mir auch nicht in den Sinn käme, extra zu meinen Eltern zu fahren, > um dort einen µC zu verlöten ;) Mein ganzes Lötzeug steh bei meinen Eltern und das will ich auch nicht in meine Wohnung mitnehmen (u.A. wegen Platz und Gewicht). Bei meinen Eltern bin ich gerade zu Besuch und habe nebenbei was gelötet. Das Programmiergerät liegt aber in meiner Wohnung. Das habe ich da vergessen. Patrick J. schrieb: > Also: Wie meinen? Es gibt ein paar nicht offensichtliche Fehlerquellen und ich wollte sichergehen, dass keine davon vorliegt. M. K. schrieb: > Dussel schrieb: >> Gibt es irgendeine Möglichkeit zu sehen, ob ein neuer (unbeschriebener) >> AVR läuft? > > jaein, gibt es nicht. In Werksauslieferung sind alle IOs als Eingänge > beschaltet, das (äquivalente) Programm, dass läuft lautet > int main(void){ > return 0; > } > der Atmega tut also nichts. Aber der Takt läuft ja schon und der Prozessor arbeitet die Befehle ab, auch wenn es eben nur FF ist. M. K. schrieb: > Das einzige, was man "sehen" kann ist, dass > der Atmega Strom aufnimmt. Aber das als Indiz zu betrachten, dass er > läuft halt ich für zweifelhaft. Das denke ich auch. Deshalb fällt das auch raus. Tja, bald werde ich es wissen.
Dussel schrieb: > Aber der Takt läuft ja schon und der Prozessor arbeitet die Befehle ab, > auch wenn es eben nur FF ist. Das schon. Jedoch wirst Du keinen Unterschied bemerken, wenn er es nicht tut.
Dussel schrieb: > Aber der Takt läuft ja schon und der Prozessor arbeitet die Befehle ab, > auch wenn es eben nur FF ist. Welche Befehle? Ein unbeschriebener AVR hat keine Befehle, die er abarbeiten könnte. Der ist direkt fertig mit dem Programm, was im Allgemeinen untypisch ist da Programme in der Regel immer Endlos Loops sind.
MaWin schrieb: > M. K. schrieb: >> er ist direkt fertig mit dem Programm, > > Und was macht er dann? Nix mehr außer Strom verbrauchen. Der Befehlscounter steht am Ende und wartet auf einen Reset. Da die automatischen Resets ja auch nicht aktiv sind bei einem unbeschriebenen AVR wartet er auf den St. Nimmerleinstag sofern nicht die Resetleitung auf 0 gezogen wird oder man was anderes Sinnvolles mit dem AVR macht.
falls du einen Arduino hast, kannst du mit dem einen AVR beschreiben https://www.arduino.cc/en/Tutorial/ArduinoISP
> Der Befehlscounter steht am Ende und wartet auf einen Reset. Ich dachte er läuft dann über. Was ist 0xFF eigentlich für eine Operation? Ich habe sie im "Atmel AVR 8bit Instruction Set" PDF nicht gefunden.
0xFFFF gibt es nicht als OpCode, gab es aber wohl 1997 noch. Und laut [1] wurde zumindest bei den AVRs in 2004 noch SBRS r31,7 ausgeführt. Ob das immernoch so ist, weiß ich nicht. Aber da der Controller dabei sowieso nichts erkennbares macht, hilft es dem TO auch nicht. [1] http://www.avrfreaks.net/comment/83257#comment-83257
M. K. schrieb: > Welche Befehle? Ein unbeschriebener AVR hat keine Befehle, die er > abarbeiten könnte. Der ist direkt fertig mit dem Programm, was im !? Er nimmt sich ein Wort und arbeitet es ab. Ein Ende sieht der nicht. Es gibt ja keine Endekennung. Stefan U. schrieb: > Ich dachte er läuft dann über. Tut er auch. > Was ist 0xFF eigentlich für eine Operation? Ich habe sie im "Atmel AVR > 8bit Instruction Set" PDF nicht gefunden. 0xFFFF (16-Bit Befehle) Aber tatsächlich scheint es keinen zu geben. Der AVR hält aber auch nicht an, wenn er darauf trifft. lalelu schrieb: > Und laut > [1] wurde zumindest bei den AVRs in 2004 noch SBRS r31,7 ausgeführt. Das wäre dann ein Decoderfehler. SBRS R31, 7 ist eigentlich 0xFFF7 Kann natürlich sein, dass man sich die Überprüfung dieses Bits gespart hat. Mögliche Lösung für den TO: Spannung anlegen. /RESET auf GND ziehen. Mittels MOSI und SCK die drei Bytes $AC $53 und $00 in den Controller schieben. (Siehe 'Serial Programming Algorithm' im Datenblatt) Während das dritte Byte in den Controller geschoben wird, bekommt man an MISO $53 zurück. Das kann man z.B. mit entprellten Tastern und einer LED (mit Widerstand) machen. Dann weiß man, dass der Controller läuft und Takt hat. Gruß Jobst
Brummbär schrieb: > Dussel schrieb: >> Aber der Takt läuft ja schon und der Prozessor arbeitet die Befehle ab, >> auch wenn es eben nur FF ist. > > Das schon. Jedoch wirst Du keinen Unterschied bemerken, wenn er es nicht > tut. Doch, natürlich. Wenn er aus irgendeinem Grunde nicht läuft (z.B. weil Reset durch einen Zinnpopel auf GND liegt), wird die Stromaufnahme sehr viel geringer sein, weil dann nämlich die MCU "steht". Der Sachverhalt entspricht in etwa dem "IDLE"-Stromsparmodus.
Hallo, "Mein ganzes Lötzeug steh bei meinen Eltern und das will ich auch nicht in meine Wohnung mitnehmen (u.A. wegen Platz und Gewicht). Bei meinen Eltern bin ich gerade zu Besuch und habe nebenbei was gelötet. Das Programmiergerät liegt aber in meiner Wohnung. Das habe ich da vergessen." Dagegen hilft nur, Werkstatt und Lebensschwerpunkt geordnet unter einen Hut zu bringen. MfG
Jobst M. schrieb: > lalelu schrieb: >> Und laut >> [1] wurde zumindest bei den AVRs in 2004 noch SBRS r31,7 ausgeführt. > > Das wäre dann ein Decoderfehler. > SBRS R31, 7 ist eigentlich 0xFFF7 > Kann natürlich sein, dass man sich die Überprüfung dieses Bits gespart > hat. In dem verlinkten Kommentar wurde geschrieben, dass der Opcode früher (1997) nicht als 1111 111r rrrr 0bbb, sondern 1111 111r rrrr _X_bbb spezifiziert war. Da für den Opcode 0xFFFF mWn kein Verhalten spezifiziert ist, würde ich das auch nicht als Fehler bezeichnen. Zusatzfakt: Beim Z80 wurde auch bei der Dekodierung gespart. Die unspezifizierten Opcodes haben nützliche, neue Funktionen gebracht, die dann untersucht und dokumentiert wurden: http://www.z80.info/z80undoc3.txt Und noch was zum Thema: Falls die Schaltung noch mehr als den µC enthält, wird der Strom eventuell schwierig zu messen sein. Aber wenn die Stromaufnahme nicht übermäßig hoch (Kurzschluss/Verpolung) ist und alle Pins sauber gelötet sind, sollte der Controller auch funktionieren. Die ICs werden ja nach der Fertigung überprüft und die größten Risiken danach sind mMn Hitze beim Löten und ESD. Beides lässt sich ausschließen, wenn man ordentlich arbeitet und die ICs aus einer "normalen" Quelle hat.
M. K. schrieb: > Der Befehlscounter steht am Ende und wartet auf einen Reset. Nein. Er läuft immer weiter und arbeitet das unbeschriebene Flash ab.
MaWin schrieb: > M. K. schrieb: >> Der Befehlscounter steht am Ende und wartet auf einen Reset. > > Nein. Er läuft immer weiter und arbeitet das unbeschriebene Flash ab. Udn was macht er wenn er am Ende des Flashs ist? Bei mir hat noch nie ein Programm von vorne begonnen wenn ich keine Endlosschleife drum gebastelt habe.
> Bei mir hat noch nie > ein Programm von vorne begonnen wenn ich keine Endlosschleife > drum gebastelt habe. Vermutlich, weil dein Compiler genau wie meiner in solchen Fällen automatisch eine Endlosschleife an das Programm anhängt. Die main() Funktion wird niemals verlassen. Beispiel für eine leere main() Funktion beim ATtiny13, cmpiliert mit avr-gcc 5.3.0:
1 | Test.elf: file format elf32-avr |
2 | |
3 | Sections: |
4 | Idx Name Size VMA LMA File off Algn |
5 | 0 .text 0000002c 00000000 00000000 00000054 2**1 |
6 | CONTENTS, ALLOC, LOAD, READONLY, CODE |
7 | 1 .data 00000000 00800060 00800060 00000080 2**0 |
8 | CONTENTS, ALLOC, LOAD, DATA |
9 | 2 .stab 00000078 00000000 00000000 00000080 2**2 |
10 | CONTENTS, READONLY, DEBUGGING |
11 | 3 .stabstr 0000005b 00000000 00000000 000000f8 2**0 |
12 | CONTENTS, READONLY, DEBUGGING |
13 | 4 .comment 00000011 00000000 00000000 00000153 2**0 |
14 | CONTENTS, READONLY |
15 | 5 .note.gnu.avr.deviceinfo 0000003c 00000000 00000000 00000164 2**2 |
16 | CONTENTS, READONLY |
17 | 6 .debug_info 000002b8 00000000 00000000 000001a0 2**0 |
18 | CONTENTS, READONLY, DEBUGGING |
19 | 7 .debug_abbrev 00000294 00000000 00000000 00000458 2**0 |
20 | CONTENTS, READONLY, DEBUGGING |
21 | 8 .debug_line 0000001d 00000000 00000000 000006ec 2**0 |
22 | CONTENTS, READONLY, DEBUGGING |
23 | 9 .debug_str 000000f6 00000000 00000000 00000709 2**0 |
24 | CONTENTS, READONLY, DEBUGGING |
25 | |
26 | Disassembly of section .text: |
27 | |
28 | 00000000 <__vectors>: |
29 | 0: 09 c0 rjmp .+18 ; 0x14 <__ctors_end> |
30 | 2: 0e c0 rjmp .+28 ; 0x20 <__bad_interrupt> |
31 | 4: 0d c0 rjmp .+26 ; 0x20 <__bad_interrupt> |
32 | 6: 0c c0 rjmp .+24 ; 0x20 <__bad_interrupt> |
33 | 8: 0b c0 rjmp .+22 ; 0x20 <__bad_interrupt> |
34 | a: 0a c0 rjmp .+20 ; 0x20 <__bad_interrupt> |
35 | c: 09 c0 rjmp .+18 ; 0x20 <__bad_interrupt> |
36 | e: 08 c0 rjmp .+16 ; 0x20 <__bad_interrupt> |
37 | 10: 07 c0 rjmp .+14 ; 0x20 <__bad_interrupt> |
38 | 12: 06 c0 rjmp .+12 ; 0x20 <__bad_interrupt> |
39 | |
40 | 00000014 <__ctors_end>: |
41 | 14: 11 24 eor r1, r1 |
42 | 16: 1f be out 0x3f, r1 ; 63 |
43 | 18: cf e9 ldi r28, 0x9F ; 159 |
44 | 1a: cd bf out 0x3d, r28 ; 61 |
45 | 1c: 02 d0 rcall .+4 ; 0x22 <main> |
46 | 1e: 04 c0 rjmp .+8 ; 0x28 <_exit> |
47 | |
48 | 00000020 <__bad_interrupt>: |
49 | 20: ef cf rjmp .-34 ; 0x0 <__vectors> |
50 | |
51 | 00000022 <main>: |
52 | 22: 80 e0 ldi r24, 0x00 ; 0 |
53 | 24: 90 e0 ldi r25, 0x00 ; 0 |
54 | 26: 08 95 ret |
55 | |
56 | 00000028 <_exit>: |
57 | 28: f8 94 cli |
58 | |
59 | 0000002a <__stop_program>: |
60 | 2a: ff cf rjmp .-2 ; 0x2a <__stop_program> |
Man beachte die letzte Zeile mit dem rjmp befehl.
Stefan U. schrieb:. > Vermutlich, weil dein Compiler genau wie meiner in solchen Fällen > automatisch eine Endlosschleife an das Programm anhängt. Die main() > Funktion wird niemals verlassen. Aber sicher doch! Nur folgt dann gleich der Aufruf von exit(), was bei der AVRlibc (mangels Betriebssystem, das übernehmen könnte) eine Endlosschleife (bei ausgeschalteten Interrupts) ist. Edit: Wie du dankenswerterweise gleich dokumentiert hast ;-)
> Nur folgt dann gleich der Aufruf von exit()
Ja stimmt, hast Recht.
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.