Ich habe ein Notebook / Windows 7.32 / so einen billigen China USB-ISP Programmer / AVR-Studio 4 Extreme Burner einige Tiny13A. Das Alles funktioniert soweit auch wunderbar, aber... Flashe ich mein fehlerfreies Programm mit Extreme Burner in den Tiny zeigt er mir zwar keine Fehlermeldungen an, beim Auslesen des Tiny wird mein Pogramm aber um genau 32 Byte versetzt im Speicher angezeigt. Dies muss wohl nahe an der Wahrheit sein, denn... Ein superkleines Testprogramm (setzt in einer Endlosschleife alle Pins auf High und Low) funktioniert einwandfrei (Multimeter zeigt 2,2 V an). Speise ich ein Programm ein, dass nur wenige Byte größer ist gehen alles Pins auf Low und nichts regt sich mehr (habe viele Variationen ausprobiert). Alle Programme, die ich einspeise, werden vom AVR-Studio 4 als fehlerfrei angezeigt. Mit den Befehlen selbst und wie sie angeordnet sind scheint weder AVR-Studio-4 noch der Tiny13a Probleme zu haben (werden ohne Fehlermeldung verarbeitet). Dieser China-USB-ISP-Programmer gefällt mir, weil er USB hat, superklein und leicht verständlich ist. Möchte diesen weiternutzen. Extreme-Burner nutzer ich, weil ich hier nur auf Flashen drücken muss und das Programm alle notwendien Einstellungen von selbst macht. Ich hatte auch andere Programme ausprobiert, die aber auch einen Fehler beim Programmabgleich angezeigt haben. Die Tinys sind alle im Auslieferungszustand. Ich gebe nur mein Programm in den Flash-Speicher, sonnst nichts. Im Internet habe ich gelesen, dass wohl auch einige Andere haargenau das gleiche Problem haben, wie ich. Ich habe nur keine Lösung dafür gefunden. Kann jemand was dazu sagen? Grüße
:
Bearbeitet durch User
Hi
>Kann jemand was dazu sagen?
Poste mal das ausgelesene Hex-File.
MfG Spess
Das ausgelesene Hex-File habe ich grade leider nicht zur Hand. Ich habe es aber haarklein nachgeprüft. Es ist fehlerfrei mein Programm. Es ist im Ausgelesenem Hex-File nur um genau 16 Byte nach hinten versetzt. Nachtrag: Es sieht ungefähr so aus: 00000000 FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF 00000010 FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF Ab 00000020 finde ich Byte für Byte mein Programm. Grüße
:
Bearbeitet durch User
Marcel Kmiec schrieb: > um genau 32 Byte versetzt Marcel Kmiec schrieb: > um genau 16 Byte nach hinten versetzt Was denn nun?
Das Programm ist um 32 Bytes (oder wieviel auch immer) versetzt. Das ist eine Feststellung, die erst mal garnix sagt. - In welche Richtung versetzt? - Läuft das Programm fehlerfrei? - ??? Könnte es sein, dass die Interrupt-Sprung-Tabelle einfach um die hinteren (ungenutzten) Sprünge verkürzt wurde? Wäre doch eine sinnvolle Optimierung...
>Ich habe nur keine Lösung dafür >gefunden. Dann schmeiss die die Möhre weg. Es lohnt sich nicht sich wegen 5 Euro zu ärgern.
Ich hatte mal was ähnliches mit einem Equinox Programmer. Beim programmieren war der EEprom auch versetzt. Es war auf Auto gestellt. Dann hab ich manuell den Startpunkt eingestellt. Sieh mal, ob du manuell einstellen kannst.
Das Pogramm ist um 32 Byte versetzt. Ich hatte mich nur verzählt und konnte die 16 nicht mehr auf 32 ändern. Interrupts habe ich in den Testprogrammen nicht verwendet. Nur Schleifen, DDRB, PORTB und com bzw eor Befehle. Wir gesagt gebe ich nur wenige dieser Befehle ein funktioniert es (obwohl auch versetzt). Nur bei ein paar Befehlen mehr muckt es. Und nach den schlauen Antworten jetzt zur ernstgemeinten: Ich habe leider weder im Avr-Studio noch im Extrem-Burner eine Möglichkeit gefunden einen Startpunkt zu setzen. Der Extrem-Burner gibt bei der Verification aber auch einen Fehler aus. Dies sollte er denke ich aber nicht tun, wenn er der Meinung ist alles richtig gemacht zu haben. Ich glaube ehr das ist ein Problem an der Schnittstelle selber. Grüße
Hat Dir da möglicherweise jemand eine leere Interrupttabelle untergejubelt? Normalerweise beginnen nur die Hardcore-Programmierer bei null.
Wenn das Programm läuft, dann steht es vermutlich richtig im Flash und entweder beim Auslesen oder beim Abspeichern ist was kaputt. Extreme Burner ... nie gehört. Klingt aber nicht vertrauenerweckend. Und Programmen die angeblich alles automatisch machen, traue ich nicht weiter als ich den Datenträger werfen kann. Probier halt mal ein anderes Flash-Tool und/oder einen anderen Programmer. Wobei es unwahrscheinlich ist, daß es an letzterem liegt. XL
An seinem Programm oder dem Programmer liegt es nicht. Dachte ich. Aber ich hab noch mal gelesen. Marcel Kmiec schrieb: > Speise ich ein Programm ein, dass nur wenige Byte größer ist gehen alles > Pins auf Low und nichts regt sich mehr (habe viele Variationen > ausprobiert). Es muß im Programm selber ein Offset sein. Oder beim Programmieren des Chip.
Ein SW-Bug entweder im Programmer oder im Burner oder beide vertragen sich nicht. Daß Störungen auf dem SPI eine Addition durchführen können, halte ich für extrem unwarscheinlich.
Mal einen anderen Chip auslesen, wo man weiß, was und wo drauf ist.
Als erstes muss mal das 'Stochern im Nebel' abgestellt werden. Es muss her: Das HEX-File, so wie es von der Entwicklungsumgebung kommt und in den Tiny gebrannt wird Das HEX-File, welches vom Tiny zurückgelesen wird. Diesen Versatz möchte ich in den beiden HEX-Files verifizieren können. Denn im Zweifel vertaue ich den Programmierern des Burner mehr, als einem Neuling, der in jedem 3.ten Satz betont, dass sein Programm fehlerfrei ist. Bei einem Neuling kann es schon sein, dass er ein HEX-File falsch liest, weil er nicht bedacht hat, dass nur weil ein HEX-File anders beginnt, es deswegen nicht unbedingt unterschiedlich sein muss. In jedem HEX-File Datenrecord steht die Adresse drinnen, an die die Daten im Speicher zu platzieren sind.
Damit die Gemüter mal was runerkochen: Folgendes Programm habe ich als ersten Test geschrieben.
1 | .include "tn13Adef.inc" |
2 | |
3 | ldi r16, 0xFF |
4 | out DDRB, r16 ; Kompletter Port B ist Ausgang. |
5 | out PORTB, r16 ; Alle LEDs an |
6 | |
7 | programmschleife: |
8 | com r16 ; Alle LEDs invertieren |
9 | out PORTB, r16 |
10 | rjmp programmschleife ; Endlosschleife |
Dabei kommt folgendes Hex-File raus.
1 | ef0f bb07 bb08 9500 bb08 cffd ffff ffff |
2 | ffff ffff ffff ffff ffff ffff ffff ffff |
Am Chip liegen 4,9 V an und an den Pins kann ich 2,2 V messen. Das Programm läuft offensichtlich. Beim flashen bekomme ich ein Verify Error. Beim Auslesen erhalte ich.
1 | ffff ffff ffff ffff ffff ffff ffff ffff |
2 | ffff ffff ffff ffff ffff ffff ffff ffff |
3 | ef0f bb07 bb08 9500 bb08 cffd ffff ffff |
Das andere Programm ist folgendes.
1 | .include "tn13Adef.inc" |
2 | |
3 | .def tmp = r16 |
4 | .def zahler1 = r17 |
5 | .def zahler2 = r18 |
6 | .def zahler3 = r19 |
7 | .def exor = r20 |
8 | |
9 | .org 0x0000 |
10 | rjmp main ; Reset Handler |
11 | |
12 | main: |
13 | ldi tmp, 0xff |
14 | out DDRB, tmp |
15 | out PORTB, tmp |
16 | rjmp loop |
17 | |
18 | |
19 | loop: |
20 | inc zahler1 |
21 | cpi zahler1, 0xff |
22 | breq led1 |
23 | rjmp loop |
24 | |
25 | led1: |
26 | ldi exor, 0x01 ; zustandwechsel auf PB0 alle 256 durchläufe |
27 | eor tmp,exor |
28 | out PORTB, tmp |
29 | ldi zahler1, 0x00 |
30 | |
31 | inc zahler2 |
32 | cpi zahler2, 0xff |
33 | breq led2 |
34 | rjmp loop |
35 | |
36 | led2: |
37 | ldi exor, 0x02 ; zustandwechsel auf PB1 alle 65536 durchläufe |
38 | eor tmp,exor |
39 | out PORTB, tmp |
40 | ldi zahler2, 0x00 |
41 | |
42 | inc zahler3 |
43 | cpi zahler3, 0Xff |
44 | breq led3 |
45 | rjmp loop |
46 | |
47 | |
48 | led3: |
49 | ldi exor, 0x04 ; zustandwechsel auf PB2 alle 16777216 durchläufe |
50 | eor tmp,exor ; sollte irgendwas zwischen 1 und 10 sekunde sein |
51 | out PORTB, tmp |
52 | |
53 | ldi zahler3, 0x00 |
54 | rjmp loop |
55 | ; ich habe das Programm auch mit com anstelle von eor in led3 ausprobiert |
56 | ; und die eor aus led2 und led1 entfernt. funktionierte aber auch nicht. |
Dabei kommt folgendes Hex-File raus.
1 | c000 ef0f bb07 bb08 c000 9513 3f1f f009 |
2 | cffc e041 2704 bb08 e010 9523 3f2f f009 |
3 | cff4 e042 2704 bb08 e020 9533 3f3f f009 |
4 | cfec e044 2704 bb08 e030 cfe7 ffff ffff |
5 | ffff ffff ffff ffff ffff ffff ffff ffff |
Beim flashen gibt es Verify Error und alle Pins gehen auf Low. Beim Auslesen erhalte ich.
1 | ffff ffff ffff ffff ffff ffff ffff ffff |
2 | ffff ffff ffff ffff ffff ffff ffff ffff |
3 | c000 ef0f bb07 bb08 c000 9513 3f1f f009 |
4 | cffc e041 2704 bb08 e010 9523 3f2f f009 |
5 | cff4 e042 2704 bb08 e020 9533 3f3f f009 |
6 | cfec e044 2704 bb08 e030 cfe7 ffff ffff |
Ich habe mit vielen Variantionen dieser Programme versuche gemacht und komme auf keinen erfassbaren Fehler. Andere Flashprogramme geben auch ein Verify Error aus und noch mehr Fehlermeldungen. Alle meine 150 Tinys (auch andere Tiny-Typen) die ich habe sind neu und unbeschrieben. Ein Neuling bin ich auch nicht wirklich. Ich habe damals vor 20 Jahren den C64 in Assembler und Maschinenspache programmiert und wollte jetzt mit den Tinys wieder einsteigen. Grüße
:
Bearbeitet durch User
Hi
>c000 ef0f bb07 bb08 c000 9513 3f1f f009
Hast du an den Zeilen etwas verändert, weggelassen? Das übliche Format
ist Intel-Hex. Und da sieht eine Zeile so
:100000000C943E000C9446000C9447000C9448005D
aus.
MfG Spess
Hi, nur so ne idee, Ich hab nen noch billigeren Programmer (marke Eigenbau nach Fishl.de) auch mit USb, und nutze ebenfalls den extrem burner. Allerdings muß ich beim ersten Flashen eines tiny den Programmer auf einen langsmen mode umstellen, da der tiny einen vorteiler von 1/8 eingestellt hat, und dann möglicherweise nicht mitkommt. (Tiny läuft im Urzustand mit 500Khz (4Mhz/8)) Könnte mir vorstellen, dass da bei der Adressierung über ISP was durcheinander gerät? Hast Du schon mal versucht als erstes die Fuse bits zu setzen,und CKDIV8 zu deaktivieren?
An Nobi Das was ich hier habe ist auch so ein Fishl-kompatibles Teil. Ich habe die Fusebits mal ausgelesen. Sie stehen auf: Low 6a High ff Extend ff Lock ff Laut Beschreibung ist dies 9,6 Mhz / 8. Laut der Beschreibung für den Fishl-Programmer soll der alles über 1 Mhz locker mitmachen. Ich habe nun auch keine Lücken im Vergleich vorher und hinterher. Es ist nur versetzt. Aber... Laut Beschreibung hat der Tiny13a eine Start-Up-Time von 14CK plus 64 ms, wo ich jetzt ehr drauf tippen würde. Aber... Von den Attiny13A (DIP) habe ich nur 10 zum experementiren und kapputspielen. Die anderen 100 Attiny13a (Soic) sind für ein Projekt fest verplant. Ich möchte also nicht allzu leichtsinnig irgendwo rumklicken und was zerstören. Laut Beschreibungen im Internet kann man so einen Tiny am leichtesten mit den Fusebits vernichten. Ich müsste also schon recht genau wissen was ich da an- und ausschalte. Grüße
Hi Lass die Fuses in Ruhe. Daran liegt es nicht. Aber noch mal: >Dabei kommt folgendes Hex-File raus. >c000 ef0f bb07 bb08 c000 9513 3f1f f009 Der AVR-Assembler des 4er Studios erzeugt so etwas nicht. Willst du uns veräppeln? MfG Spess
Wenn ein Programm funktioniert, heißt das nicht unbedingt, dass alles in Butter ist. Eine Tüte voll FFFF am Programmanfang macht, den Atmels zumindest, nichts aus. Interessant wird es erst, wenn Unterbrechungen im Spiel sind.
An Spess53 Nein ich bin Windows-Nutzer. Zwinker... Erstes Programm vorher von Avr-Studio-4
1 | :020000020000FC |
2 | :0C0000000FEF07BB08BB009508BBFDCF4D |
3 | :00000001FF |
Erstes Programm hinerter von Extreme-Burner
1 | :100020000FEF07BB08BB009508BBFDCFFFFFFFFF2D |
2 | :00000001FF |
Zweites Programm vorher von Avr-Studio-4
1 | :020000020000FC |
2 | :1000000000C00FEF07BB08BB00C013951F3F09F0EE |
3 | :10001000FCCF41E0042708BB10E023952F3F09F0F7 |
4 | :10002000F4CF42E0042708BB20E033953F3F09F0BE |
5 | :0C003000ECCF44E0042708BB30E0E7CF31 |
6 | :00000001FF |
Zweites Programm hinter von Extreme-Burner
1 | :1000200000C002E0042308BB00C013951F3F09F085 |
2 | :10003000ECCF40E0042708BB10E023852F3F09F0F8 |
3 | :00000001FF |
So wie ich es oben notiert habe zeigt es mir Extreme-Burner im Hauptfenster an. Nur, dass da noch die Adressen davor stehen (beginnend mit oben-links bei 0). Grüße
:
Bearbeitet durch User
An Amateuer Das sehe ich ganz genauso wie Du. Ich denke das erste kleinere Programm läuft nur, weil er zwar immer zu "den" ersten FF springt, aber ohnehin immer nur die gleiche Schleife durchfährt und bei den FF eben einfach nichts macht (wie Befehl NOP). Ändert aber grade nichts an der Sache... Grüße
HI Ist zwar nicht wahrscheinlich, aber lösche doch mal mal den Extended Segment Address Record (:020000020000FC) aus dem original Hex-File. Evtl. kommt den Brennprogramm damit nicht zurecht. MfG Spess
An Spess Ich denke ich habe grade gelernt, dass Hex-Code nicht das gleiche ist wie Maschinen-Code. So wie du oben den Maschinen-Code nicht lesen kannst, kann ich den Intel-Hex-Code nicht lesen. Ich kann aber eine Ascii-Datei aufmachen, sie mit der Datei-Erweitung "Hex" versehen und versuchen sie in das Flash-Programm zu speisen. Du brauchst mir nur sagen was drin stehen soll. Grüße
Marcel Kmiec schrieb: > An Spess > > Ich denke ich habe grade gelernt, dass Hex-Code nicht das gleiche ist > wie Maschinen-Code. So wie du oben den Maschinen-Code nicht lesen > kannst, kann ich den Intel-Hex-Code nicht lesen. Der ist leicht zu lesen. Ausserdem gibt es Doku dazu
1 | :020000020000FC |
mal in die Felder aufgedröselt
1 | :02 0000 02 0000 FC |
2 Datenbytes, Adresse 0, Satztyp 2 (=Extended Address), Daten: 0 und Prüfsumme D.h. da steht: setze die Extended Address auf 0
1 | :0C0000000FEF07BB08BB009508BBFDCF4D |
in die Felder aufgedröselt
1 | :0C 0000 00 0FEF07BB08BB009508BBFDCF 4D |
0C Datenbytes, Datenadresse: 0, Satztyp 0 (=Daten), die Daten selber und wieder die Prüfsumme. D.h. da steht im Klartext: Beginnend ab der Speicheradresse 0, kommen die Datenbytes 0F EF .... Bei dem was du ausgelesen hast, steht
1 | :100020000FEF07BB08BB009508BBFDCFFFFFFFFF2D |
in die Felder aufgedröselt
1 | :10 0020 00 0FEF07BB08BB009508BBFDCFFFFFFFFF 2D |
10 Bytes Daten, Datenadresse 20, Satztyp 0 (=Daten), die Daten und wieder eine Prüfsumme. D.h. im Hex-File steht tatsächlich drinnen, dass er die Daten von der Adresse 0x0020 geholt hat. (*) Nur warum ist mir nicht klar. Ich hab den Extreme Burner auch schon benutzt. Aber sowas ist mir noch nie untergekommen, dass er beim Brennen eigenmächtig einen Versatz um 0x20 Bytes eingebaut hätte. (*) und genau darum ging es. Ob im Hex-File schon die falsche Adresse eingetragen ist, wo die Bytes hinzubrennen sind.
:
Bearbeitet durch User
Hi >Ich denke ich habe grade gelernt, dass Hex-Code nicht das gleiche ist >wie Maschinen-Code. So wie du oben den Maschinen-Code nicht lesen >kannst, kann ich den Intel-Hex-Code nicht lesen. Wieso? Geht doch im AVR Studio. Einfach im linken Fenster (Project) den Zweig 'Output' aufklappen und Doppelclick auf das Hex-File. Und schon hast du das im Editor. MfG Spess
Marcel Kmiec schrieb: > Ich denke ich habe grade gelernt, dass Hex-Code nicht das gleiche ist > wie Maschinen-Code. So wie du oben den Maschinen-Code nicht lesen > kannst Oh, ich denke, denn kann Spess sehr wohl lesen. Vielleicht nicht flüssig (nur unter Zuhilfename eines Disassemblers oder in Handarbeit mit der "instruction set reference") aber lesen kann er ihn auf jeden Fall. Ich selber müßte übrigens auch zu einem der genannten Hilfsmittel greifen... Wie auch immer, genau so, wie wir zu Hilfsmitteln greifen können, kannst du das auch. Eine (für das vorliegende Problem durchaus hinreichende) Beschreibung des "Hex"-Dateiformats kannst du schon in der Wikipedia finden. Ich persönlich vermute aber eine ganz andere Sache als Ursache des Problems. Auch Spess glaubt ja nicht wirklich an Probleme bei der Interpretation des Hex-Formats, das hat er in seinem Posting deutlich zu erkennen gegeben. Es ist also mehr so ein Schuß in's Blaue, um einfach abzuklärende Sachen auf die Schnelle ausschließen zu können. Er hatte wohl nicht damit gerechnet, daß es IRGENDEINEN AVR-Programmierer geben könnte, der nicht weiß, wie Hexfiles funktionieren... Wie auch immer, meiner Meinung nach liegt ein rein physikalisches Problem vor. Entweder in der Verbindung zwischen Programmer und Controller oder bei der Energieversorgung des Controllers während des Flashens. Ersteres halte ich für deutlich wahrscheinlicher. Deswegen wäre meine erste Aktion, die drei SPI-Leitungen auf ihren Durchgangswiderstand zu prüfen und zwar nicht irgendwo, sondern jeweils direkt vom Pin des Programmer-IC zum entsprechenden Pin des Controllers. Ich könnte fast wetten, daß eine der Leitungen hochohmig ist...
Es war nicht meine Absicht jemanden auf den Schlipps zu treten. Ich komme aus einer Zeit, wo es keine Hex-Files gab. Ich kann aber den Maschinen-Code anhand meiner eingegebenen Befehle lesen (um mich mal auf das Glatteis zu wagen). Lässt man alle Labels weg sind in fast allen Fällen die Befehle und die Werte 1:1 zusammengehörig (war zumindest damals so). Ich messe jetzt mit angeschlossenem Programmer und Tiny-Chip (Usb ausgestöpselt) folgende Leitungen: VCC 10 - 24 Ohm (schwankt bei der Messung) GND 13 Ohm MISO 3 Ohm SCK 3 Ohm RST 3 Ohm MOSI 3 Ohm Grüße
c-hater schrieb: > Ich könnte fast wetten, daß eine der Leitungen hochohmig ist... Da wär ich mir nicht sicher. Das seltsame ist ja: Die Datenbytes an sich sind ja anscheinend korrekt im Flash. Nur eben an der falschen Stelle. Mysteriös.
>Ich kann aber eine >Ascii-Datei aufmachen, sie mit der Datei-Erweitung "Hex" versehen und >versuchen sie in das Flash-Programm zu speisen. Du brauchst mir nur >sagen was drin stehen soll. Dann flash halt mal die HEX im Anhang und zeig uns was ausgelesen wird.
Marcel maß: >Ich messe jetzt mit angeschlossenem Programmer und Tiny-Chip (Usb >ausgestöpselt) folgende Leitungen: >VCC 10 - 24 Ohm (schwankt bei der Messung) >GND 13 Ohm Das ist aber anständig viel... Kümmere Dich erst mal um den Leitungs- bzw. Kontaktwiderstand, sonst suchst Du Dir einen Wolf. MfG Paul
An Holger Beim Lesen rausgekommen ist: :100020000FEF07BB08BB009508BBFDCFFFFFFFFF2D :00000001FF An Paul Baumann Mit der Stromversorgung habe ich keine Probleme.
Paul Baumann schrieb: > Marcel maß: >>Ich messe jetzt mit angeschlossenem Programmer und Tiny-Chip (Usb >>ausgestöpselt) folgende Leitungen: > >>VCC 10 - 24 Ohm (schwankt bei der Messung) >>GND 13 Ohm > > Das ist aber anständig viel... Mal wieder Quark von dir. Die Messung ist einfach Mist.
Marcel schrub:
>Mit der Stromversorgung habe ich keine Probleme.
Na dann..
Gut -dann viel Glück beim Finden der Ursache.
MfG Paul
Das stand in der HEX Datei: >:0C0000000FEF07BB08BB009508BBFDCF4D >:00000001FF und das wird gelesen: >:100020000FEF07BB08BB009508BBFDCFFFFFFFFF2D >:00000001FF Schon wieder dieser Offset drin. Es wird immer merkwürdiger.
Marcel Kmiec schrieb: > komme aus einer Zeit, wo es keine Hex-Files gab. Dann mußt du noch deutlich älter sein als ich. Und ich bin schon ziemlich alt, viel zu alt für meinen Geschmack... > Maschinen-Code anhand meiner eingegebenen Befehle lesen (um mich mal auf > das Glatteis zu wagen). Lässt man alle Labels weg sind in fast allen > Fällen die Befehle und die Werte 1:1 zusammengehörig (war zumindest > damals so). Damals(tm) gab es mit Sicherheit noch keine AVR-Architektur. Und bei der AVR-Architektur sind längst nicht alle Codebestandteile so eingängig in den Opcodes wiederzufinden, wie du das (vielleicht von Z80 oder 6502?) so in Erinnerung hast. Lies' bitte die bereits erwähnte instruction set reference. Da ist auch die Codierung drin beschrieben. > VCC 10 - 24 Ohm (schwankt bei der Messung) > GND 13 Ohm > MISO 3 Ohm > SCK 3 Ohm > RST 3 Ohm > MOSI 3 Ohm Das ist ja sogar durchgängig völlig Scheiße. Der Durchgangswiderstand sollte sich bei derart kurzen metallischen Verbindungen ausnahmslos im Bereich weniger zehn mOhm bewegen. Ich würde mal behaupten, daß dein Multimeter nix taugt. Eventuell Batterie alle? Aber spannend sind trotzdem die Versorgungsleitungen, denn deren Widerstand unterscheidet sich zumindest erheblich von den restlichen Leitungen. Insbesondere GND ist sehr bedenklich...
Wenn ich die Versorgungsspannung am Chip messe komme ich auf 4,9 Volt. Da alle Leds leuchten wird der Strom auch in Ordnung sein. Und zur Diskusion standen hier die Datenleitungen. Und... Ich habe an GND und VCC längere Leitungen verwendet, damit ich diese niemals mit den Datenleitungen verwechseln kann. Weiter ist das Offset konstant. Zu konstant für eine einfache Schwankung in den Leitungen, für mein Geschmack. Grüße
Marcel Kmiec schrieb: > Wenn ich die Versorgungsspannung am Chip messe komme ich auf 4,9 > Volt. Das sagt exakt garnix. Mit einem Multimeter kannst du garnicht schnell genug messen. Hast du wenigstens die Batterie von dem Teil endlich getauscht? > Da alle Leds leuchten wird der Strom auch in Ordnung sein. Du bist entweder krass unwissend oder ein Troll. > Und zur > Diskusion standen hier die Datenleitungen. Sagt wer? > Und... Ich habe an GND und > VCC längere Leitungen verwendet Etliche Meter lang? > Weiter ist das Offset konstant. Zu > konstant für eine einfache Schwankung in den Leitungen, für mein > Geschmack. Du weißt nichtmal, wie man einfachste Größen korrekt mißt. Und jetzt willst du mir erzählen, du hast die Ursache des Offsets gefunden? Und das mußt du ja wohl, da du mögliche Ursachen konsequent ignorierst. Tipp: 32 Byte entspricht ziemlich genau der Größe einer Flashpage des Tiny13A... Aber egal, da du ja offensichtlich selbst die Ursache gefunden hast, können wir alle das Problem wohl als gelöst abhaken...
An C-Hater Ich denke nicht, dass das verteilen von Beleidigungen in dieser Sache produktiv ist. Wenn du Vorschläge hast höre ich mir die gern an. Nur lass bitte dieses "sieh mal selber zu, ob du was machen kannst".
Nu fetzt euch mal nicht so. Das bringt keinen weiter. Hast du mal die ISP Frequenz kleiner gemacht? Bei deinem zweiten ausgelesenen Programm fehlen grosse Teile.
An Holger Das ist mir auch aufgefallen, wollte aber noch nichts sagen, um nicht was doofes von mir zu geben. Leider kann ich weder im Programmiergerät noch im Extreme-Burner etwas zur Geschwindigkeit einstellen. Deswegen wollte ich den ja haben. Der stellt alles selber ein. Verwende ich aber Khazama (Flashprogramm) bekomme ich zusätzlich die Fehlermeldung Synchonisation fehlgeschlagen (Sinngemäß wiedergegeben). Dieser versucht dann gar nicht erst zu flashen. Da habe ich noch geglaubt, dass ich im Khazama-Programm was falsch eingestellt habe. Grüße
>Verwende ich aber Khazama (Flashprogramm) >bekomme ich zusätzlich die Fehlermeldung Synchonisation fehlgeschlagen >(Sinngemäß wiedergegeben). Das ist das beste Zeichen für eine falsche ISP Frequenz. Irgendwo muss man die bei deinem Prommer einstellen können. Wenn nicht taugt das Ding halt nichts.
Da ich vorraussetzte, dass das Avr-Studeio-4 von sehr guter Qualität ist, die Flash-Programme Extreme-Burner und Khazama mindestens eine gute Qualität haben müssen und die Tinys mit Sicherheit sehr gute Qualität haben müssen, ist das schwächste Teil in der Kette der China-Fishl-Clone. Einstellen kann ich an dem Teil von außen definitiv nichts. Ich ging davon aus, dass das Teil vom Flash-Programm eingestellt wird. Was mich wundert ist, der Tiny13a und die Flash-Programme werden in der Kompatibilitätsliste aufgeführt. Im Internet kann ich aber lesen, dass auch Andere mit genau dieser Kombination die gleichen Probleme haben wie ich. Nichts desto Trotz: Ich habe auch schon nach anderen Programmiergeräten geschaut. Es gibt aber reichlich viele. Ich würde mich wenn für einen entscheiden der mit Avr-Studio-4 kompatibel ist und nach Möglichkeit wenig Geld kostet. Alles was ich dafür so in der Bucht finde ist aber auch nur nachgemacht. Grüße
Hi >Ich habe auch schon nach anderen Programmiergeräten geschaut. Es gibt >aber reichlich viele. Ich würde mich wenn für einen entscheiden der mit >Avr-Studio-4 kompatibel ist und nach Möglichkeit wenig Geld kostet. Auch wenn letztere Bedingung nicht ganz erfüllt wird: Original AVR ISP MKII. Was bei Verwendung von so einem Chinakracher zusammen mit Second-Hand-Software herauskommt sieht man ja. MfG Spess
In der Tat. Vorher weiss man sowas aber schlecht. Wo bekomme ich das Teil her und was kostet es?
Legste noch 12 euros für nen dragon drauf, kannste auch debuggen.
Marcel Kmiec schrieb: > Da ich vorraussetzte, dass das Avr-Studeio-4 von sehr guter Qualität > ist, die Flash-Programme Extreme-Burner und Khazama mindestens eine gute > Qualität haben müssen und die Tinys mit Sicherheit sehr gute Qualität > haben müssen, ist das schwächste Teil in der Kette der > China-Fishl-Clone. Bla bla. > Einstellen kann ich an dem Teil von außen definitiv > nichts. Ich ging davon aus, dass das Teil vom Flash-Programm eingestellt > wird. So ist das. Anständige Flash-Programme (ich beuge mich jetzt mal aus dem Fenster und nenne avrdude als Referenz) melden sich auch, welche Frequenz sie eingestellt haben oder ob sie dabei ein Problem hatten. Denn in der Tat sind die usbasp Clone aus China dafür berüchtigt, daß sie mit einer urururalten Firmware ausgeliefert werden, die die softwaremäßige Umstellung der ISP-Frequenz noch nicht unterstützt. Jetzt kann man entweder das zehnfache ausgeben und ein AVR ISP MK2 kaufen, oder man macht ein Firmware-Upgrade auf dem usbasp. Dafür braucht man allerdings zumindest einmalig einen zweiten ISP-Programmer, weil der usbasp keinen Bootloader hat. Als temporäre Notlösung sollte auch auf dem China-Clone irgendwo ein Lötjumper "slow ISP" oder so ähnlich sein, mit dem man hardwaremäßig den ISP-Takt auf Minimum zwingt. Augen aufmachen! XL
Nachtrag: apropos Extreme Burner ... wenn der wirklich den µC trotz fehlgeschlagener Synchronisierung brennt und/oder eine fehlgeschlagene Einstellung der ISP-Frequenz nicht wenigstens als Warnung anzeigt, dann ist das ein Fall für die Tonne.
Marcel Kmiec schrieb: > Ich > komme aus einer Zeit, wo es keine Hex-Files gab Das mag man wohl bezweifeln. Anno 1975 (als ich meinen ersten TMS9000) programmiert habe) gab es die schon.
Hi Marcell, das habe ich in meinem post auch gemeint, ich muss definitiv beim tiny die ISP frequenz kleiner machen, wenn Du ein fischl pendant als programmer hast, dann sollte dort ein jumper für genau diesen Zweck vorhanden sein. Wenn der programmer soweit funktioniert, dass du über die fuses die Taktferquenz höher schalten kannst, kannst Du auch wieder schneller flashen.
Ich mein so Veränderungen, im Sinne von Halbieren oder Achteln, sind ja schon ein recht weiter Sprung. Die Programme sind aber zumindest annähernd richtig im Speicher. Der Frequenzunterschied dürfte gar nicht all zu groß sein. Ich habe aber im Extreme-Burner unter den Fuses eine recht lange Hex-Zahl gefunden, die irgendwas mit der Tiny-Internen-Geschwindigkeit zu tun hat. Weiter Unten auch noch ein Button der mit Kalibrieren beschriftet ist. Aber wie gesagt: Sind Fuses. Da drücke ich nicht so leichtsinnig drauf. Grüße
Die Jumper sind meist nicht eingelötet. Bohrungen dazu sind, zumindest bei meinen zwei Exemplaren, vorhanden.
Wenn du so ein Clone hast der zwei SMD-Leds (eine für Bereit eine für Aktivität) hast, dürfte die Jumperstelle direkt neben den Leds sein.? Wenn ich den Jumper schließe passiert was?
Du kannst mir gern mal eine Schritt-für-Schritt-Anleitung geben. Leider kann ich erst am Montag weiterlesen. Aber wenn das eine halbwegs sichere Methode ist, gebe ich gern ein/zwei Tinys für her. Grüße
:
Bearbeitet durch User
Ich habe dieses Teil. Ich der denke der gesuchte (nichtvorhandene) Jumper ist die Stelle markiert als J2. http://www.pocketmagic.net/wp-content/uploads/2012/05/usbasp_4.jpg
Jumper 1 neben den LED's ist die Selbstprogrammierung, J2 darunter für die Spannungsversorgung vom Programmierboard und J4 darunter für die Taktbegrenzung, wenn Augen und Ohmmeter mich nicht täuschen.
Sehe gerade auf dem Bild, dass sich auch diese Nachbauten ständig verändern. Bei mir sitzt der AT nicht diagonal auf der Platte. Jumper für den Takt sollte aber einen Pin des IC's mit GND vom Wannenstecker verbinden.
Zu den Beschriftungen auf dem China-Clone: Möglicher Jumper ist nur die Stelle, die als J2 markiert wurde. Auf der anderen Seite der Leds ist ein 6-Pin-Baustein (ich denke Digital) der auch mit einem J markiert wurde. Weitere Markierungen mit J oder Möglichkeiten was anzulöten gibt es wohl nicht. Auf der Unterseite ist ein Datum aufgedruckt, das mit dem Datum der letzten Fischl-Firmware identisch ist. sind aber alles nur die Aufdrucke.
Oh schade. Ich dachte jetzt am Montag kann ich lesen wie ich was versuchen kann.
Und weiter geht es... Nachdem ich mir jetzt einen beschissenen Dragon Modell C (Beschissen weil Defekt) und einen Dragon Modell D besorgt habe ist die Thematik mit dem Versetzem Programm immernoch die gleiche. Bisher sind mit dem Dragon D folgende Probleme aufgetreten: Dragon Modell C ist beim ersten Anschließen abgefackelt (Spannungsregler Defekt). AVR-Studio-4 konnte keine Verbindung zum Treiber aufbauen (Gelösst). Erfolgreich ein Upgrade vom Dragon Modell D über AVR-Studio-4 durchgeführt. Attiny13a mit dem ISP des Dragon verbunden (Sowohl Tiny als auch ISP werden über das VCC des Dragon versorgt). Im Studio kann ich erfolgreich die richtige Spannung auslesen. Beim ISP-Speed bekomme ich scheinbar nur bei 500 kHz eine Antwort ohne Fehlermeldung. Beim lesen der Signatur bekomme ich den ersten Fehler (0x01 0x03 0x05 passt nicht zum ausgewähltem Device). Beim Flashen bekomme ich die Meldung, dass mit den Flashen alles in Ordnung verlaufen ist. Beim Verify bekomme ich die Meldung, dass mein Programm an Adresse 0x01 steht anstatt an 0x00 "Warning: Flash byte address 0x0000 is 0x01 (should be 0x00). FAILED". Die Verkabelund habe ich fünf Mal mit verschiedenen Methoden überprüft. Beim ersten Versuch mit diesem Aufbau vor 10 Stunden habe ich sogar nur nullen als Antwort bekommen. Hex-File, das ich eingebe:
1 | :020000020000FC |
2 | :1000000000C00FEF07BB08BB00C013951F3F09F0EE |
3 | :10001000FCCF41E0042708BB10E023952F3F09F0F7 |
4 | :10002000F4CF42E0042708BB20E033953F3F09F0BE |
5 | :0C003000ECCF44E0042708BB30E0E7CF31 |
6 | :00000001FF |
Hex-File, das ich raus bekomme:
1 | :10000000010103030505070709090B0B0D0C070F79 |
2 | :100010001110131B11151707191919191D1C0F00A1 |
3 | :100020006A21012327052727212D2B0B3D252F276B |
4 | :100030003131133335313737393D393B3D3D3F3F62 |
5 | :10004000014043434545430309696B4B4D4D4F0008 |
6 | :100050006A11535357151757595959195F5F7F5FE5 |
7 | :1000600060607363656567636D296B7B6D2D2F6FB2 |
8 | :100070007071737335747777793D797B7D7D3F7FC0 |
9 | :10008000818183C185C7878789898B8F8F8F8F00F7 |
10 | :10009000D5801391949517D799889B006A8C9F1FE0 |
11 | :1000A000A180A323A585B7006A89BBAB252DAFAF7F |
12 | :1000B000F191B3006A3597B7F9B8BBB9FDFDFFBF41 |
13 | :1000C000E1C0C3006AC1C7C7E9C9CBCBCDCDCFCF93 |
14 | :1000D000D0C0D3006AD1D3D3DDDDDFDFDDDDDFFFCC |
15 | :1000E000E1F0F3F3E5E5E7E761696FEBEDEFEFFFD3 |
16 | :1000F000F0F17373F1F7F7F7F9F87BFBFFFCFFFF03 |
17 | :100100000100830104050307090D090B050D0F0FFD |
18 | :10011000111113130415971719081B006A1D0F00FE |
19 | :100120006A01232327053727A129093B2D006A2FC0 |
20 | :1001300011113333B531333339393B393C3DBF3F8E |
21 | :100140004141434341474747C909494B454D0F4F3B |
22 | :1001500040517353445557006A1D1F597D5D4F4FE1 |
23 | :1001600061006AE3E56567276978632B2D6D2F6F62 |
24 | :1001700071793371747D733779787B7B7D3D7F7FB7 |
25 | :1001800081818183858187878900D58B8D8C8F00C4 |
26 | :100190006A91919195949F9399889B9FDD9D9F8FE4 |
27 | :1001A000A1E183A3A5A787B7A9E9A989BCA5AFAF9A |
28 | :1001B000B0B9B391B5BDF3B7B8B9BFFBBDBDFFBF13 |
29 | :1001C000C0C1C3C1C4C5C3E7C9CDEBCBCDCFCFC779 |
30 | :1001D000D1D0DBD1C5006AC7D9DDF9CBDD00D5DFD1 |
31 | :1001E000E1E1F3E3E1E4E7E3E9F8E3EFEFFCE7EF74 |
32 | :1001F000F1F0FBF3F5F5F3F7F9FDF9FBFDFDFFFF7A |
33 | :100200000100D5030501070709006A0B050D0F0F53 |
34 | :1002100001006A131515131718191B1B1D0D1F1F3D |
35 | :1002200031006A232127272729212F290D3C272F39 |
36 | :10023000313033006A1537006A383B006A3C3F3F73 |
37 | :1002400001416143444547474D09694B454D4F4F77 |
38 | :100250001151531375445F006A795B4B5D006A7FEF |
39 | :100260007000D5636500D57769296B6B6D2D6F6F55 |
40 | :10027000713173737177777739797B7B7D3D7F7FC0 |
41 | :10028000818183818585078789890F8B8D8D07CF34 |
42 | :1002900090999391849D139799889BDB9D8D1FDF87 |
43 | :1002A000B021E383A500D5B721ADAB89BC00D5BF94 |
44 | :1002B000B9B1B1B3B5006A97B8393FFB3D3D3F3F97 |
45 | :1002C000C1C1C1E1C5C5C7C7CDC9CBCB4DCDEFCFEE |
46 | :1002D000D9D1D3D3D5C5D757D9D9F9CBDDDDDFDF18 |
47 | :1002E000E1006AE1E4E567E3E9E9EBEB656D6F6F77 |
48 | :1002F000F1F1F1F3F4F4F7F3FDFD7B7FFDFDFFFF7A |
49 | :100300000101010305006A0709098B0B0F0D0F0797 |
50 | :10031000111113110415971719099B1B1F0C1F1F8F |
51 | :100320002101330125006A0729382B23AD2D2F0029 |
52 | :100330006A113333B5313337391919193C3D3F3F11 |
53 | :1003400061404363450547470948434F4D450F4FBB |
54 | :100350004059535B5551175759591B1B5F5D4F004F |
55 | :100360006A212361647467006A696B7B6D6D6F6FCE |
56 | :1003700071006A717500D5777939797B7D3D7F7F12 |
57 | :1003800081818383858587878DC98B838D8C8F8FB2 |
58 | :10039000919193006A95879F9D999B8B9DDD9F9F6F |
59 | :1003A000B1006A83B5A5E3A7B8A1EB89BC006A8F49 |
60 | :1003B000B0006AB3BDF197B7B9BDB9BB9FBCBFFF71 |
61 | :1003C000C1C1C3E1C5C1C7C7C9C8CBC3CDCDCFCF9C |
62 | :1003D000C0D1D3D3F7C4D7D7F9C8DB006AFDDFDFBC |
63 | :1003E000E1E1E3E3E5E1E7F7E1EDEBEBFD006AEFE7 |
64 | :1003F000F0006AF3F5006AF3F9F8FB006AFDFF000C |
65 | :00000001FF |
Warum ist das so schwer ein Programmiergerät für AVR zu finden, das einfach nur funktioniert? Das Ärgert mich jetzt sehr, dass ich jetzt hier drei Programmiergeräte liegen habe und ich keins davon sinnvoll nutzen kann, aber dafür schon 100 € für hingeblättert habe.
:
Bearbeitet durch User
Ich habe jetzt einfach nur das USB-Kabel abgezogen und wieder eingesteckt. Jetzt funktioniert gar nichts mehr. Ich kann weder die Spannung auslesen noch das Device Setting hinter mich bringen. Die Leds des Dragon reagieren normal.
Nach erneutem Firmwareupdate und ISP-Speed 250 kHz stimmt zwar die Signatur aber mein Programm ist auf 0x20 versetzt. Also Ergebniss wie ganz am Anfang. Das gleiche mit ISP-Speed 125 kHz. und auch bei 6,478 kHz. Nach erneutem Upgrade bekomme ich beim 250 kHz eine andere Signatur übergeben. Beim Flashen ist das Ergebnis das gleiche wie eben auch.
Also das ist doch sehr auffällig, das Du in den verschiedensten Szenarien mit verschiedenen Programmern etcpp. immer auf dieses Phänomen triffst, auf das, soweit ich weiss, kein anderer trifft. (Das wäre mal eine Suche hier Wert). Das einzige was ich selbst davon kenne, ist, daß bei einem völlig neuen Projekt die Signatur, Verify usw. einige Male fehlschlagen und nachdem man an den Kabeln gewackelt und ihnen gute Worte gegeben hat, alles geht. Dann auch über Tage hinweg bis man wieder irgendwas Größeres verändert. Diese ganzen Clowns, - äh, Clone - sind mir dazu noch suspekt, obwohl man fairerweise sagen muss, dass viele hier, nach anfänglichen Schwierigkeiten, damit ganz gut klarkommen (oder sie wegschmeissen ohne hier weiter darauf einzugehen). Aber ein Versatz um 0x20 Bytes? Meine Vermutung ist, das Du irgendwas völlig anderes, aber grundsätzliches falsch machst und immer wieder falsch machst. Als vorletzte Maßnahme würde ich sehr gerne mal ein Foto von Deinem Aufbau sehen auf dem auch der PC, das Netztteil und so weiter zu sehen sind. Also mehr oder minder Dein ganzer Arbeitsplatz. Und dann noch ein Foto nur von der Zielplatine. Nenne hier auch mal die genaue Version von AVR-Studio 4 (ich hoffe ich habe da nichts übersehen) und poste vielleicht auch mal den kompletten Projektorder als ZIP. Vielleicht fällt einem hier etwas auf. Als letzte Maßnahme und um uns allen mal den Glauben wieder zu geben, würde ich Dir vorschlagen, hier freundlich zu fragen ob jemand aus Deiner Nähe mal mit seinem Laptop und einem Original STK500 oder einem Original-Dragon zu Dir kommt und auch eine kleine Platine mitbringt und dann mal Schritt für Schritt zu Deiner Konfiguration übergeht. Irgendwo auf dem Weg muss der Haken auftauchen.
Und bitte mal die Signatur von dem ATtiny13A auslesen und posten.
Ich gebe dir gern mal vorab eine Möglichst allumfassende Beschreibung. Notebook: Ist ein Asus EeePC 1201HA mit Original-Netzteil und der Akku ist fit. Die beiden USB-Anschlüsse auf der linken Seite sind dem Powermanagment am nächsten und ich habe schon oft USB-HDDs dran betrieben. Studio: AVR-Studio-4.19 (habe aber mit USBAsp und Extreme Burner das gleiche Ergebnis gehabt) Dragon: Ist Modell A08-0396.D und augenscheinlich ein Originalteil vom Fachhändler, für 60€. Tiny: 10 Stk Attiny13a DIL. Das Problem tritt stichprobenartig bei allen auf. Target: Ein einfaches kleines Breadbord mit zugehörigen Stiftkabeln (für die Daten verwende ich die Kurzen, für GND und VCC je ein Langes). Der Tiny ist direkt auf den Breadboard und die Stiftkabel gehen in Flachbandkabel, die mit den Dragon verbunden sind. Zu ISP führt ein 6Pol 10cm Kabel und zu VCC ein 10Pol 30cm Kabel. Verbindungen: ISP 1 zu Tiny Pin 6 ISP 2 zu VCC 6 ISP 3 zu Tiny Pin 7 ISP 4 zu Tiny Pin 5 ISP 5 zu Tiny Pin 1 ISP 6 zu VCC 5 VCC 3 zu Tiny Pin 4 VCC 4 zu Tiny Pin 8 Ich habe auf dem Breadboard auch eine Led mit 500 Ohm zwischen VCC und GND, als Indikator. Mit oder ohne ist es das gleiche. Wenn ich vom Dragon eine Antwort bekomme die nicht 0x00 lautet, bekomme ich die Signatur 0x01 0x03 0x05. Jetzt in wenigen Versuchen habe ich mehrmals eine Signatur bekommen, von der AVR-Studio sagt sie währe richtig. Was ich viel phänomenaler finde ist, dass sich das Verhalten vom Dragon ändert, wenn ich ein Firmwareupgrade mache.
Nachtrag: An den Kabeln gewackelt habe ich lange genug (mit der LED als Indikaator). Da ist kein Wackler drin. Und Dragon misst glatte 5V am ISP.
In der Bedienungsanleitung stand nichts von einem Kondensator. Laut der Beschreibung eines anderen Nutzers ist ihm Sein nagelneuer Dragon mit einem Kondensator racketenschnell abgeraucht (hat dannach nur noch nullen zurück gegeben).
Meine Frage bezog sich auf die keramischen 100nF zwischen VCC und GND des ATtiny. Poste mal bitte schnell ein Bild des Aufbaus- bevor hier die Blockkondensatordiskussionen wieder losgehen.
Angehängte Dateien:
-
101_27892.JPG
310 KB -
101_27902.jpg
190 KB -
189405_BB_00_FB.EPS_1000.jpg
29 KB
Bild 1 So ähnlich sieht das alles aus. Bild 2 So sitzt der Tiny auf dem Board. Bild 3 Und ich denke du meinst so einen Kondensator. Von dem habe ich auch gesprochen.
Tiny10Nutzer schrieb: > Und ich denke du meinst so einen Kondensator. Von dem habe ich auch > gesprochen. Ja. Und ohne diesen hat der ATtiny das Recht, jeden Blödsinn zu machen, den er will. Und auf dem Steckbrettaufbau fehlt er. Oft macht er es nicht. Aber das Recht dazu hat er.
:
Bearbeitet durch User
Grrr.... Rate aml was ich grade nicht zur Hand habe. Warum ist der nicht im VCC des Dragon drin?
Tiny10Nutzer schrieb: > Warum ist der nicht im VCC > des Dragon drin? Das würde Dir nichts nützen. Blockkondensatoren müssen immer unmittelbar an den Versorgungsanschlüssen jedes Digital-ICs sitzen. Es werden sogar welche drin sein. Aber zu weit weg. Hast Du keine 33nF-220nF, die Du quer drüberstecken oder -löten kannst?
:
Bearbeitet durch User
ich könnte mir vorstellen das der Programmer die Interrupttabelle frei läßt und dahinter erst mir dem Programm anfängt. Keine Ahnung wieviele Interrupt Einsprungadresse der Attiny13a hat du könntest aber mal aus dem Datenblatt die vollständige Tabelle eintragen und dann mal schauen ob dein Programm immer noch an der gleichen Stelle anfängt. bein Tiny26 wäre das z.B. .CSEG .ORG 0x00 rjmp RESET ; Reset handler reti ; rjmp EXT_INT0 ; IRQ0 handler reti ; rjmp PIN_CHANGE ; Pin change handler reti ; rjmp TIM1_CMP1A ; Timer1 compare match 1A reti ; rjmp TIM1_CMP1B ; Timer1 compare match 1B reti ; rjmp TIM1_OVF ; Timer1 overflow handler reti ; rjmp TIM0_OVF ; Timer0 overflow handler reti ; rjmp USI_STRT ; USI Start handler reti ; rjmp USI_OVF ; USI Overflow handler reti ; rjmp EE_RDY ; EEPROM Ready handler reti ; rjmp ANA_COMP ; Analog Comparator handler reti ; rjmp ADC ; ADC Conversion Handler mit der Adresse nach dem .ORG kannst du auch mal experimentieren ob du damit das Programm woanderst hinbekommst.
Im Moment habe ich überhaupt keine Kondensatoren da. Meine Lötausrüstung habe ich auch grade verliehen. Sonnst hätte ich mir die Kondensatoren schon so kombiniert, dass es passt. Was ist mit dem Kollegen dem sein Dragon wegen genau so einem Kondensator weggeraucht ist? Die Dragons scheinen insgesammt aussergewöhnlich empfindlich zu sein. Mein Modell C ist ja auch schon beim Einschalten verdampft.
also ich habe einen Dragon der ersten Stunde und da ist noch nichts abgeraucht, liegt vielleicht daran das ich in der Wohnung ohne Schuhe rumlaufe und dem Teil noch keinen Funken gegönnt habe außerdem prüfe ich die Anschlüsse zur Platine immer nochmal durch bevor ich Saft drauf gebe.
Die meisten Dragon sind sicher sowieso nur abgeraucht, weil sie in der Packung blieben und das leitfähige Schaumzeug noch drunter war.
Na dann schenke ich dem Dragon doch noch etwas Vertrauen. Aber der Bug im Spannungsregler des C ist wohl allgemein bekannt und wurde von AVR nur zu Beginn für Privatanwender ausgetauscht. Der Chip der Buggy ist, ist derart empfindlich, dass eine kurze Berührung mit dem Finger ausreicht um den Bug auszulösen. Wie auch immer... Ich werde der Frage nach den Interrupttabellen mal sehr genau nachgehen, habe aber selber dazu noch Fragen: In den meisten Beispielprogrammen finde ich nie komplette Interrupttabellen, zu Begin des Programms. Werden die vom Compiler nicht von selbst ergänzt bzw. vom Chip einfach ignoriert, wenn diese nicht explizit angegeben werden? Ich kann im Tiny13 nur 512 Befehle insgesamt eingeben. Da möchte ich mir natürlich jeden Befehl sparen, wie ich nur kann. Wenn diese Interrupts in den Beispielprogrammen angegeben werden, werden diese mit Symbolen eigegeben. Heißt das nicht, dass diese in einem anderen Speicherbereich (außerhalb des Programms) stehen?
ich programmiere mit .asm da muss man es per Hand machen, aber nur wenn man die Interrupts auch verwendet. Wenn also ein Interrupt auslöst springt das Programm an die entsprechende Stelle holt sich dort die Sprungadresse zu Interruptroutine die dort stehen sollte(Sprungbefehl) die Interruptroutine sollte dann auch wieder mit reti beendet werden oder man schreibt statt eines Sprungbefehles direkt reti dort hin dann bewirkt der Interrupt keine falsche Verzweigung im Programm. Ich weiß aber nicht wie der C Compiler das macht und ob man es verstellen kann. Evtl. wird es nur bei Interrupt Nutzung oder immer. Diese Tabellen sind in jeden Datenblatt bei den AVR enthalten.
Na ich programmier jetzt auch in Assembler. Dort werden sie aber in den Beispielen mit Symbolen angesprochen (und in den Symbolen mit Sprungbefehlen beladen). Ich denke mal, dass die Symbole in den Include-Dateien definiert werden. Ich habe jetzt auch Beispielprogramme gesehen in denen beispielsweise der Reset-handler in Adresse 0x00 geschrieben wird (.org 0x00 rjmp main). Aber wie gesagt werden derartige Angaben ehr selten bzw. schonmal gar nicht vollständig gemacht (laut Beispiele). Was mich noch mehr wundert ist, dass ja bei "nichtangeben" der Interrupttabellen mein Programm an Adresse 0x00 stehen müsste. Das kann ja gar nicht sein und gar nicht funktionieren. Warum funktioniert das in den Beispielen dann trotzdem?
ob es reset oder main heist spielt keine Rolle. Ich nenne es bei mir immer Reset und in dieser Routine initialisiere ich den Stackpointer, setzte die Ein- und Ausgänge usw. bevor es dann weitergeht meinetwegen mit main: Ich vermute mal das eine leere Flashzelle als nop intepretiert wird, also macht es sich beim Programmablauf nicht bemerkbar da diese Speicherstelle einfach überflogen wird. in einer Includedatei habe ich folgendes gefunden
1 | .equ INT0addr =$001 ;External Interrupt0 Vector Address |
2 | .equ IOPINSaddr =$002 ;Pin change interrupt |
3 | .equ OC1Aaddr =$003 ;Output Compare1A Interrupt Vector Address |
4 | .equ OC1Baddr =$004 ;Output Compare1B Interrupt Vector Address |
5 | .equ OVF1addr =$005 ;Overflow1 Interrupt Vector Address |
6 | .equ OVF0addr =$006 ;Overflow0 Interrupt Vector Address |
7 | .equ USI_STARTaddr =$007 ;Universal Seria Bus Start Interrupt Address |
8 | .equ USI_OVFaddr =$008 ;Universal Seria Bus Overflow Interrupt Address |
9 | .equ ERDYaddr =$009 ;EEPROM Ready Interrupt Vector Address |
10 | .equ ACIaddr =$00A ;Analog Comparator Interrupt Vector Address |
11 | .equ ADCCaddr =$00B ;ADC conversion complete Interrupt Vector Address |
ist also nur ein Symbol für die Adresse, an die Adresse selber gehört dann aber der Sprungbefehl oder reti
Tiny10Nutzer schrieb: > Warum funktioniert > das in den Beispielen dann trotzdem? Es wurde schon mehrfach gesagt: Poste eines deiner Problemkinder hier, aber komplett. Dann kann dir geholfen werden.
Meine Vermutung ist grade. dass die Interrupttabelle gar nicht im Flash-Speicher ab 0x00 steht, sondern in einem anderen Speicherbereich. Mit Gewissheit kann ich das natürlich nicht sagen. Ist dem aber so, hat das Nichtangeben der Interrrupts keinen Einfluss auf mein Programm.
Tiny10Nutzer schrieb: > Meine Vermutung ist grade. dass die Interrupttabelle gar nicht im > Flash-Speicher ab 0x00 steht "Vermuten" heißt "nicht wissen". Die Interrupt Vektoren liegen unten ab 0 im Flash. Warum sollten sie auch woanders liegen?
Hallo Marcel, Tiny10Nutzer schrieb: > Was mich noch mehr wundert ist, dass ja bei "nichtangeben" > der Interrupttabellen mein Programm an Adresse 0x00 stehen müsste. Das > kann ja gar nicht sein und gar nicht funktionieren. Warum funktioniert > das in den Beispielen dann trotzdem? Beim Reset springt der Attiny an Adresse 0x00 und führt den Code dort aus. Dort kann ein Sprungbefehl stehen, oder auch gleich dein Programm. Wenn dein Programm so in der Interrupt-Tabelle steht, kannst du natürlich keine Interrupts verwenden, aber es funktioniert bestens. Ob Assembler oder nicht, die erzeugte Hex-Datei beginnt ab Adresse 0x00, und sollte also genau so auch im Attiny-Flash gespeichert werden. Die Programmierung kann da nicht die Ursache des Fehlers sein. Ich habe gerade anhand deiner Fotos (gute Qualität übrigens) mal die Verkabelung nachvollzogen, und keine Fehler entdeckt. Mir scheint der Widerstand aber Braun-Grün-Braun zu sein (also 150 Ohm und nicht 500 Ohm), aber das sollte auch nicht das Problem sein. Ich kann mir auf dieses Phänomen keinen Reim machen. Du machst alles richtig, es geht nur nicht. Leider habe ich keinen Attiny13A zur Hand (nur Attiny85) und kann dein Problem daher nicht nachbauen. Vielleicht solltest du wirklich noch einen 100nF nah am Attiny zwischen VCC und GND anbringen (ich glaube aber eher nicht dass das die Ursache ist). Hast du ansonsten einen USB-Hub mit Netzteil? Eventuell ist der USB-Port etwas schwachbrüstig ... Probier auch noch einmal einen anderen Platz im Breadboard. Manchmal sind die Federn schon so ausgeleiert, dass kein guter Kontakt zustandekommt. Ach, und ändere die ISP-Geschwindigkeit auf kleiner als 250kHz. Das Datenblatt verlangt weniger als 1/4 der Taktfrequenz, also ist 1/4 der Taktfrequenz zu schnell. Versuch bitte auch die Fuses auszulesen, um zu sehen ob da was schief steht. LG, Sebastian
:
Bearbeitet durch User
Note: AVR Dragon must sense the target voltage at pin 2 on the ISP header in order to set up the level-converter. For on-board targets, the voltage must be supplied from pin 2,4,6 on the VCC header (5V) into pin 2 (VTG) on the ISP header. When using off-board targets there should be no connection between VCC header and pin 2 of the ISP header. So wie ich es sehe fehlt dir eine Verbindung von VCC zu VTG wird anscheinend gebraucht wenn man seine Schaltung vom Dragon versorgen läßt, damit der Dragon die Spannung einstellen kann, weil er sonst keine Rückmeldung hat. Ich versorge mein Board immer extern und belaste den Dragon nicht für meine Schaltung.
Thomas O. schrieb: > So wie ich es sehe fehlt dir eine Verbindung von VCC zu VTG Nein, die Verbindung ist da. ISP VTG ist mit Dragon VCC pin 2 verbunden (Kabel hin, Kabel her), Attiny13A VCC pin 8 mit Dragon VCC pin 4. Zumindest sehe ich das auf den Fotos so. LG, Sebastian
:
Bearbeitet durch User
@Sebastian Ich staune grade Bauklötze. Ich sehe nur sehr sehr selten eine so professionelle Antwort in einem Forum. Daumen hoch. Das Breadboard ist neu und ich habe auch ein Zweites (gleiches). Auf dem sieht die Sache auch nicht anders aus. Es ist ja auch so, dass die Störung bei verschiedenen Progern ähnlich ist. Die Farben des Resitor sind nicht ganz originalgetreu. Es sind zwar keine ganzen 500 Ohm. Ich glaube aber mich zu erinnern, dass es 460 Ohm sein müssten (kanns aber grade nicht mehr genau sagen). Ohne Led ändert sich jedenfalls nichts. Ich werde das Alles nochmal an meinen Arbeitsrechner (am Montag) ausprobieren. Dieser USB-Anschluss stellt 8ß Watt bereit. Wie gesagt betreibe ich aber auch USB-HDDs am aktuellen Anschluss. Laut Betriebssystem sind ganze 500 mA auf dem Port bereit. Laut Datenblatt braucht der Dragon mindestens 100 mA und 300 mA empfohlen. Für den Kondensator brauche ich eine Weile. Nach Augenmass der Led kommen am Chip Spannung und Strom satt an. Was aber im nicht sichtbaren Bereich abgeht kann ich natürlich nicht sagen. Um nochmal kurz Offtopic zu gehen: Deine Erklärung zu den IRQs war einfach Klasse und sehr leicht verständlich. Nach deinen Angaben muss ich, wenn ich irgendeinen IRQ in Anspruch nehme, den Reset-Handler (0x00) angeben, da sonnst bei Reset der erste aufkommende IRQ angesprungen wird, ohne ausgelösst worden zu sein. Im Umkehrschluss bedeutet dies aber auch, wenn ein IRQ ausgelösst wird, ohne dass ich diesen mit ".ORG RJMP ??" einen Sinn gegeben habe (und statt dessen Sinnloserweise einfach mein Programm dort steht) wird der IRQ dann zu einer bestimmten Stelle meines Programms (unkontrolliert) springen und ein wenig Chaos verursachen. Ich hoffe die Sätze sind nicht zu lang geworden. Aber sag mal bitte ob ich das so richtig verstanden habe. Grüße
Nachtrag: Ich konnte mit den USBAsp noch alle Bits auslesen. Die Tinys sind alle definitiv im Auslieferungszustand. Attiny13a Anwählen http://www.engbedded.com/fusecalc
Das mit den 100nF ist eher wichtig als unwichtig. Es kann gehen, sollte aber, gerade bei Problem, ungefähr das erste sein, was man ergänzt. Auch, das das Problem bei verschiedenen Programmern das selbe ist, deutet darauf hin, das es ursächlich nicht an den Programmern liegt. Ich möchte noch einmal, diesmal etwas dringender, dazu raten, das Du hier mal das komplette Projekt postest, bei dem dieser Fehler auftritt. Zu dem abgerauchten Dragon: In dem Artikel hier http://www.mikrocontroller.net/articles/AVR-Dragon unter dem Punkt "Empfindliche Hardware " ist klar beschrieben, das dies ein bekanntes Problem ist. Halte Dich damit erstmal nicht auf. Zu den Interrupt-Vektoren. Solange keine Interrupts aktiviert werden sollte die tatsächliche Position (unter gewissen Bedinungen) keine Rolle spielen. Diese "gewissen" Bedingungen kannst Du herstellen, wenn Du den Tiny definitiv vorher löschst. Denke auch daran, die Fues nach dem Löschen wieder zu setzen. Es kann allerdings sein, dass Dir der Zusammenhang zwischen Interrupt-Vektoren und der org-Anweisung nicht in aller Konsequenz deutlich ist. So das Du einen eigentlichen Programmfehler nun irrigerweise einer fehlerhaften Annahmen über die Position des Codes zuschreibst. Hier ist glaube ich, die Bemerkung angebracht, das die Vermutung, dass Du Fehler gemacht hast, nicht als ehrenrührig gedacht ist. Wir machen alle Fehler. Das ist OK so. Soweit ich erkennen kann, hast Du Dir nach Deinen Fähigkeiten alle Mühe gegeben. Das ist mehr als man von manch anderem hier sagen kann, der hier "dumme" Fehler gemacht hat. Da aber sonst niemand dieses Problem hat, ist es wahrscheinlich, das ein "Facepalm" dabei rauskommt. Die große Mühe die Du Dir gegeben hast, die fast überwältigende Menge an Details die Du hier schreibst, die aber keinerlei Hinweis auf die Ursache enthält, macht es wahrscheinlich, das es sich wirklich um was eher - ähem, scheinbar selbstverständliches - handelt. Aber, wiegesagt: da Du hier wirklich bemüht mitarbeitest, wird Dir das vermutlich keiner übelnehmen. Und nochmal die dringende Bitte, den kompletten Projektordner, bei dem das Problem auftaucht, als ZIP zu posten. (Das ist doch ein kleiner Kritikpunkt, das Du darauf so garnicht eingehst). Falls Du mal ungefähr schreibst, wo Du wohnst, lässt sich vielleicht einer breitschlagen Dir einen 100nF Kondensator zu spenden. Da ich mittlwerweile neugierig bin, was die Ursache ist, wäre ich dazu unter Umständen auch bereit.
Was mir auch gerade noch auffällt ist, das Du Dich als "Tiny10"-Nutzer bezeichnest, das Problem aber für den Tiny13 schilderst. Hast Du in den Projekteinstellungen wirklich den Tiny13 eingestellt? Wiegesagt. Poste mal den kompletten Projektordner als ZIP. Das ist das allerdringendste, denke ich.
Ach, noch was: Du schreibst Du benutzt Windows 7. Ich selbst benutze das nicht zuhause. Hatte aber mal auf Arbeit damit zu tun. Ich will jetzt keinen Flamewar provozieren, aber es lohnt sich vielleicht es mal mit einem XP zu probieren. Hast Du noch einen weiteren Rechner?
>Nach deinen Angaben muss >ich, wenn ich irgendeinen IRQ in Anspruch nehme, den Reset-Handler >(0x00) angeben, da sonnst bei Reset der erste aufkommende IRQ >angesprungen wird, ohne ausgelösst worden zu sein. Im Umkehrschluss >bedeutet dies aber auch, wenn ein IRQ ausgelösst wird, ohne dass ich >diesen mit ".ORG RJMP ??" einen Sinn gegeben habe (und statt dessen >Sinnloserweise einfach mein Programm dort steht) wird der IRQ dann zu >einer bestimmten Stelle meines Programms (unkontrolliert) springen und >ein wenig Chaos verursachen.
Sorry. Zu früh auf abschicken gedrückt. Ich wollte dazu noch schreiben: Das klärt sich alles, wenn wir den Code sehen. An sich ist das fehlen der IRQ-Vektoren solange kein Problem, solange Du den Chip immer löschst. Falls Du ein .org verwendest, das hinter der Tabelle liegt, stehen da nämlich NOPS. Falls Du aber kein .org verwendest, steht Dein Code eben genau "auf" der Vektortabelle. Das schadet aber auch nicht, solange Du im Code keine spezifischen Interrupts freigibst.
Tiny10Nutzer schrieb: > Für den Kondensator brauche ich eine Weile. Nach Augenmass der Led > kommen am Chip Spannung und Strom satt an. Was aber im nicht sichtbaren > Bereich abgeht kann ich natürlich nicht sagen. Die Abblockkondensatoren erfüllen zwei Aufgaben. In so einem Attiny stecken jede Menge Feldeffekttransistoren. Wenn deren Gates umgeladen werden fliessen kurzfristig (Nanosekunden oder kleiner) recht hohe Ströme in die Gatekapazitäten. Längere Zuleitungen der Versorgungsspsnnung (mehrere Zentimeter) haben Widerstände, so dass diese kurzen Stromstöße die Spannung einbrechen lassen. Aufgabe eines Abblockkondensators ist es, diese Spannungseinbrüche zu verhimdern, damit a) der Attiny weiter mit einer sauberen Spannung arbeitet, und b) die Spannungsabfälle auf der Versorgungsleitung nicht als Funkmüll (EMI - elektromagnetische Interferenzen) abgestrahlt werden. Diese Effekte kann men aber mit einer LED nicht sehen. Bitflüsterer schrieb: > Was mir auch gerade noch auffällt ist, das Du Dich als "Tiny10"-Nutzer > bezeichnest, das Problem aber für den Tiny13 schilderst. Hast Du in den > Projekteinstellungen wirklich den Tiny13 eingestellt? Tatsächlich gibt es im Atmel Studio die Auswahl Attiny13 und aber auch Attiny13A. Ein Fehler an diese Stelle kann sehr wohl die beschriebenen Auswirkungen haben! Bitflüsterer schrieb: > Ach, noch was: Du schreibst Du benutzt Windows 7. Ich benutze Windown 8.1 und Atmel Studio 6.1, und es funktioniert soweit alles. LG, Sebastian
:
Bearbeitet durch User
>Ich benutze Windown 8.1 und Atmel Studio 6.1, und es funktioniert soweit >alles. Das ist schön und gut. Aber wir reden hier von Windows 7 und AVR-Studio 4. Ich sage ja nicht, das das die Ursache ist, aber das es mit W8 und AS6 bei Dir geht, heisst ja nicht, dass nicht durch die Verkettung unglücklicher Umstände die Kombination W7 und AS4 bei dem TO nicht gehen könnte. Es wäre jedenfalls kein Fehler das mal gegenzuprüfen. Was den Tiny angeht: Full Ack. Es muss völlig klargestellt werden um welchen Typ es sich genau handelt. Tiny13 oder Tiny13A oder was auch immer. (Ich war da etwas wurschtig indem ih von Tiny13 schrieb.)
Einen Sockel mit Kondensator habe ich Bestellt. Kommt im Laufe der Woche bei mir dann an. Ich habe unter der Woche und am Wochenende verschiedene Wohnadressen und habe offengesagt nicht so gern Besuch. Ob die Led dran oder weg ist verändert nichts. Das Löschen des Tiny versuche ich auch immer zuerst. Nur ich bekomme jetzt mit dem Dragon nicht mal eine Verbindung zum Tiny. Da bringt auch Löschen nichts. Das Thema der IRQs war Offtipic. Ich habe in meinen Testprgrammen keine IRQs oder .ORGs verwendet (Siehe Assembler-Programme am Anfang). Ich verwende bis jetzt immernoch die gleichen beiden Testprogramme. Macht kein Sinn weiter zu Programmieren, solange ich mein Problem nicht gelösst bekomme. Ich kann euch gern den Projektordner als ZIP bereit stellen. Ich frage mich nur grade was ihr dann seht. Ich habe Probleme damit das Hex-File in den Tiny zu bekommen bzw. überhaupt eine sinnvolle Verbindung zum Tiny zu bekommen. Stehen darüber Informationen im Programmverzeichnis?
Aus dem ersten Post: einige Tiny13A. >Es muss völlig klargestellt werden um >welchen Typ es sich genau handelt. Frage beantwortet.
>Ich kann euch gern den Projektordner als ZIP bereit stellen. Ich frage >mich nur grade was ihr dann seht. Eine Erklärung, was man alles darin erkennen kann würde hier zu umfangreich. Es ist einfacher sich auf das zu beschränken, was wir dann, nach Ansicht, als problematisch bezeichnen. Bitte stelle nicht als Bedingung das wir das jetzt erstmal genau erklären. Poste einfach genau den Stand mit dem Du das Problem reproduzieren kannst.
Na mal ganz cool Freunde. Ich habe mich Tiny10Nutzer genannt, weil ich vier davon habe (unbenutzt) und ich die Dinger Klasse finde. Ich nutze sie aber "NOCH" nicht. Ich habe AtTiny13A. 10 in DIP (DIL) und 200 in SOIC. Das der Tiny13 nicht das gleiche ist wie der Tiny13A habe ich schon von selbst gemerkt und habe auch in allen Flash-Programmen auf die richtige Einstellung geachtet.
Angehängte Dateien:
Tiny10Nutzer schrieb: > Einen Sockel mit Kondensator habe ich Bestellt. Kommt im Laufe der > Woche bei mir dann an. Ich benuzte im Breadboard immer diese Tht-Kondis, noch von Maria (marsch-elektronik.de). LG, Sebastian
Ich hab mir jetzt gedacht, wenn näher dran besser ist, dann direkt im Sockel drin. Ich habe jetzt den Sockel bestellt der im Bild oben (von mir) zu sehen ist. Sollte nicht so verkehrt sein. Und dürfte sich bequem weiterverwenden lassen. @sebastian. kannst du mir noch schnell sagen ob ich in meinem Denken von den IRQs (siehe Offtopic oben) richtig oder falsch liege?
> ... ob ich in meinem Denken von den IRQs (siehe Offtopic oben) richtig > oder falsch liege? Nanu? Ist Dir doch schon beantwortet worden. Beitrag "Re: Programm ist im Tiny versetzt." Also, in dem Projekt kann ich nichts auffälliges feststellen, das einen Zusammenhang mit dem Problem haben könnte. Schade. Warten wir mal ab, was der Kondensator bringt.
>kannst du mir noch schnell sagen ob ich in meinem Denken von den IRQs >(siehe Offtopic oben) richtig oder falsch liege? Das ist völlig Wurst. Du kannst 1,2,3,4,5 in den Tiny ab Adresse Null brennen. Das ist zwar kein funktionierendes Programm, aber das musst du so auch wieder auslesen können. Ohne einen Offset von 32. Alles andere hier ist sinnloses Gelaber.
Eins ist allerdings doch auffällig an dem was Du schreibst. >Wenn ich vom Dragon eine Antwort bekomme die nicht 0x00 lautet, bekomme >ich die Signatur 0x01 0x03 0x05. Jetzt in wenigen Versuchen habe ich >mehrmals eine Signatur bekommen, von der AVR-Studio sagt sie währe >richtig. Das ist aber nicht die Signatur vom ATiny13a. Die sollte 0x1E 0x90 0x07 sein. Hat AVR Studio die Signatur nun als richtig bezeichnet, als Du 0x01 0x03 0x05 zurückgelesen hast oder als Du 0x1E 0x90 0x07 gelesen hast?
Sorry. Ihr beide versucht grade krampfhaft einen Fehler in meinem Tun zu finden. Und vieleicht habe ich auch einen oder mehrere gemacht. Aber wenn ich einen gemacht habe, hat ihn noch keiner hier gefunden. Ich habe vom Dragon drei Signaturen als Antwort bekommen. Eine war 0x00 0x00 0x00. Eine war 0x01 0x03 0x05. Und an der dritten habe ich mir nur gemerkt, dass ABR-Studio-4 sie als richtig markiert hat. Ob es die von dir genannte ist, kann ich jetzt grade nicht sagen. Und ich müsste jetzt stundenlang rumdoktoren um die Signatur nochmal angezeigt zu bekommen. Helfen tut mir das Rumdoktoren dann aber auch nicht weiter.
>Sorry. Ihr beide versucht grade krampfhaft einen Fehler in meinem Tun zu >finden. Und vieleicht habe ich auch einen oder mehrere gemacht. Aber >wenn ich einen gemacht habe, hat ihn noch keiner hier gefunden. Sicher. Solange man den Fehler nicht gefunden hat, hat man ihn nicht gefunden. Das ist eine Tautologie. Fehlersuche besteht eben gerade darin, das man Widersprüche klärt und Annahmen und Tatsachen miteinander vergleicht. Wo Du da eine "krampfhafte" Vorgehensweise siehst, verstehe ich nicht. Auch hat das mit Dir persönlich nichts zu tun. Aber gut. Dann sieh' eben alleine zu wie Du weiterkommst. Viel Erfolg noch.
Ich bin für jede Hilfe dankbar. Und ich finde es auch richtig die Fragen zu stellen, die vorher noch keiner gestellt hat. Und ich bin mir auch der Tatsache sicher, dass hier fast jeder in Sachen AVR mehr drauf hat als ich. Nur kann man auch Leute die ein Problem nicht selbst gelösst bekommen vorverurteilen. Und selbst jetzt nachdem du so auf die Schnelle keinen Fehler bei mir gefunden hast, werde ich das Gefühl nicht los als wolltest Du mich für Dumm verkaufen. Es soll Leute geben die fühlen sich bei sowas auf den Schlipps getreten. Wie gesagt: Wenn du einen Fehler findest bin ich ganz Ohr. Nichts für ungut.
>Sorry. Ihr beide versucht grade krampfhaft einen Fehler in meinem Tun zu >finden. Und vieleicht habe ich auch einen oder mehrere gemacht. Aber >wenn ich einen gemacht habe, hat ihn noch keiner hier gefunden. Hab grade nochmal von Anfang an gelesen. Ich meine mit "Ihr beide" nur einen. Wie gesagt: Nichtgs für ungut.
Wenn du mal und mal nicht die Signatur angezeigt bekommst, dann hast du entweder ein Verbindungsproblem oder aber deine Stromversorgung stimmt nicht. Hast du mittlerweile die Abblockkondensatoren drinnen? Anfangs dachte ich auch immer das ist doch quatsch, weil es auch ohne lief, bis die ersten Ungereimtheiten aufkamen. Wie stand es weiter oben? Er hat das Recht sich merkwürdig zu verhalten.
Eigentlich ist es nicht auszuhalten, wie du wahllos in dem Problem rumstocherst. Such dir jemanden, bei dem das funktioniert und dann der Fehler eingekreist wird. Es ist nicht die Hardware. Auch die Diskussion uber IRQ und Sprungtabelle ist sinnlos. Die muß das File sowieso enthalten. Dann mußt du dir klar werden über das Fileformat. Wahrscheinlich liegt wie schon mehrfach erwähnt der Fehler. Es gibt .bin, das sind Files die das beinhalten, was du im Programmerfenster findest. Es gibt auch solche, die sich .hex nennen, aber eigentlich .bin sind. In letzter Zeit ist Intel-Hex zum Standard geworden. Es gibt aber noch andere, wo die Speicherorganisation mit enthalten ist. Man kann aber die Typen leicht konvertieren. Ich hab mal den extreme Burner installiert. Der will Intel-Hex. Also lade mal die Datei nochmal hoch, die du brennen willst. Vielleicht kann dein Problem nachvollzogen werden.
Hallo Marcel, programmieren, hex flashen, fuses auslesen und so weiter machen keinen Sinn, solange die Signatur nicht gelesen werden kann. Das Lesen der Signatur ist die Bestätigung, dass die Kommunikation zwischen Progger und Attiny funktioniert. Wenn die Signatur nicht korrekt gelesen wird, stimmt dort etwas grundsätzlich nicht, und muss als erstes behoben werden. Das erste Ziel sollte also zunächst nur darin bestehen, reproduzierbar die korrekte Signatur (0x1E9007) lesen zu können. Dazu in Atmel Studio erst mal nur Tools -> Device Programming benutzen, und kontrollieren, ob dort auch wirklich AVR Dragon Attiny13_A_ ISP ausgewählt ist. Meine Bemerkung mit 125kHz von oben muss ich übrigens zurücknehmen. Der Attiny13A läuft js im Werkszustand mit 1.2MHz, 1/4 davon ist 300kHz, also sollte eine ISP-Frequenz von 250kHz in Ordnung sein. Ich würde an deiner Stelle jetzt auf HVSP umschwenken. Du hast ja einen Dragon, und der Aufwand ist nicht viel höher als ISP. Und als aller Erstes nur versuchen, die Signatur korrekt auszulesen. Alternativ: Den Aufbau noch einmal kontrollieren. Diese Breadboard-Kabel lösen sich manchmal von ihren Steckern ohne dass man das auf Anhieb erkennt. Also mit dem Multimeter noch einmal die Widerstände vom Beinchen (!) des Attiny bis zum Anschluss am Dragon durchmessen. Und dann noch einmal versuchsweise ein externes 1Mhz Rechtecksignal and pin 2 vom Attiny13A (CLKI) anlegen. Nach deinen Angaben sind die Fuses zwar im Werkszustand (low 0x6A, high 0xFF), aber in deiner Situation würde ich mich noch nicht auf das korrekte Auslesen der Fuses verlassen. LG, Sebastian
Sebastian Wangnick schrieb: > programmieren, hex flashen, fuses auslesen und so weiter machen keinen > Sinn, solange die Signatur nicht gelesen werden kann. Das Lesen der > Signatur ist die Bestätigung, dass die Kommunikation zwischen Progger > und Attiny funktioniert. Wenn die Signatur nicht korrekt gelesen wird, > stimmt dort etwas grundsätzlich nicht, und muss als erstes behoben > werden. Eigentlich ist es Wurscht, ob die Signatur stimmt. Hauptsache, es kommt eine zurück. Das Programm kann man in jeden AVR brennen und zurücklesen. Ein Hardware-Versatz bei den AVR kann ich mir nicht vorstellen. Wenn im Fenster des Programmers das bei 0000H beginnt, dann ist es auch im Prozessor. Also nochmal, das File hochladen. Und nicht nur den Text posten.
Tiny10Nutzer schrieb: > Nach deinen Angaben muss > ich, wenn ich irgendeinen IRQ in Anspruch nehme, den Reset-Handler > (0x00) angeben, da sonnst bei Reset der erste aufkommende IRQ > angesprungen wird, ohne ausgelösst worden zu sein. So ungefähr. Wenn du einen IRQ aktivierst, dann springt der Attiny beim Auslösen des IRQ die Programmadresse (den "Vector") des IRQ an. Also beim Attiny13A zum Beispiel 0x0003 beim Überlauf des Timers, 0x0006 bei TIM0_COMPA, 0x0007 bei TIM0_COMPB und so weiter. Siehe Datenblatt, Tabelle 9-1. Normalerweise programmiert man an diese Adressen einen Sprungbefehl zur eigentlichen Interrupt-Routine, weil man ja nur zwei Bytes (ein Word) zur Verfügung hat (danach folgt ja gleich ein anderer IRQ-Vector) und dort eben sinnvoll nur ein Sprungbefehl hinpasst. Beim Reset springt der Attiny immer zu 0x0000. Wenn dort 0xFFFF steht (also NOP), dann führt er als nächstes den Befehl in 0x0001 aus. Wenn dort ebenfalls 0xFFFF steht, dann führt er als nächstes den Befehl in 0x0002 aus. Wenn dort auch 0xFFFF steht, aber dann in 0x0003 ein Sprungbefehl zu einr Interruptrouting für TIM0_OVF, dann springt er dann natürlich in diese Interruptroutine. Was du geschrieben hast stimmt also meistens. Man könnte aber, theoretisch, ein ganzes Anwendungsprogramm in den Adressen 0x0000-0x0007 unterbringen, und dann zum Beispiel zusätzlich noch eine WDT-Routine ab 0x0008 abspeichern. Wenn dann ein Reset statfindet springt der Attiny nach 0x0000 und führt fröhlich das Anwendungsprogramm aus, und wenn ein WDT-Interrupt auftritt wird nach 0x0008 gesprungen und dort weitergemacht. Also: Die Interrupt-"Vektoren" sind nichts anderes als vordefinierte Adressen im stinknormalen Programmspeicher, und wenn du sie nicht benutzt kannst du diesen Programmspeicher eben stattdessen als normalen Programmspeicher nutzen. > Im Umkehrschluss > bedeutet dies aber auch, wenn ein IRQ ausgelösst wird, ohne dass ich > diesen mit ".ORG RJMP ??" einen Sinn gegeben habe (und statt dessen > Sinnloserweise einfach mein Programm dort steht) wird der IRQ dann zu > einer bestimmten Stelle meines Programms (unkontrolliert) springen und > ein wenig Chaos verursachen. Ja, genau. LG, Sebastian
Michael_ schrieb: > Eigentlich ist es Wurscht, ob die Signatur stimmt. Hauptsache, es kommt > eine zurück. Nein, die Signatur muss erst mal stimmen, vorher kann man alles andere vergessen. Michael_ schrieb: > Also nochmal, das File hochladen. Und nicht nur den Text posten. Das hex-file ist doch schon oben in "Versandbereit.zip": :020000020000FC :1000000000C00FEF07BB08BB00C013951F3F09F0EE :10001000FCCF41E0042708BB10E023952F3F09F0F7 :10002000F4CF42E0042708BB20E033953F3F09F0BE :0C003000ECCF44E0042708BB30E0E7CF31 :00000001FF LG, Sebastian
Sebastian Wangnick schrieb: > Das hex-file ist doch schon oben in "Versandbereit.zip": Kann sein, das es irgendwo schon mal war, aber bitte nochmal! Und nicht .ZIP. Es ist ja klein genug. Sebastian Wangnick schrieb: > Nein, die Signatur muss erst mal stimmen, vorher kann man alles andere > vergessen. Mindestens in meinem alten Programmer konnte man die Signaturabfrage abschalten. Ein Programm für einen 2313 kann man problemlos in einen 8515 brennen. Laufen tuts nicht. Adresse 0000H bleibt nunmal die Adresse 0000H!
Ich habe im Flasher des Studio eingestellt: Attiny13a; ISP; Speed 250 kHz; Drücke auf Signatur lesen; Drücke auf löschen Beim Button Read-Speed bekomme ich am häufigsten 1.000 MHz. Hier habe ich zwischen 6 kHz und 8 MHz alles mit Write-Button ausprobiert. Er hats aber nicht immer angennommen. Die Ergebnisse waren sehr unzuverlässig und Flashen hat bisher kein einziges Mal richtig funktioniert. In der zweiten Karteikarte zum Flashen geht gar nichts (ist alles mit Fehlermeldungen verbunden). Weiter hinten bei HW wird mir 5V angezeigt. AVR-Studio-4 > Tools > Upgrade Dragon; funktioniert wunderbar. Auch AVR-Studio-4 > Tools > Programm AVR > Connect; funktioniert sofort und störungsfrei. Kondensator bekomme ich im Laufe der Woche. @Sebastian Danke für deine schnelle Antwort.
Hallo Tiny10Nutzer! Ich bin Neueinsteiger in diesem Metier! Mir wurde erzählt, daß man vorm Flashen erst mal die Signatur d. Proz. auslesen soll. Wenn diese schon falsch gelesen wird, liegt meist mit der ISP-Übertragung etwas im Argen. Bei mir läuft alles einwandfrei bei einem Übertragungstakt v. 125 kHz. Bei deiner Betriebsspannungsversorgung + Verbindungen v. Programmer z. Breadboard blicke ich nicht recht durch. Warum zwei Kabel lt. Foto? Ich arbeite z. B. nur mit der 6-pol. ISP-Verbindung u. habe bei der 6 pol. ISP-Buchse den Pin 2 (+5V) nicht beschaltet, versorge das Testboard mit einem eigene 9 V-Netzteil mit nachgeschaltetem 5V-Regler (7805). Auf dem Testboard sitzt selbstverständlich der 0,1 µF-Stützkondensator nahe am Proz.-IC! Mein Programmer wird über das USB-Kabel v. PC versorgt. ISP-Verbindungen zum Testbord sind nur 5 Leitungen: Reset, MOSI, MISO, SCK, GND. Meine Konfiguration: XP, AVR-Studio 4.18, Diamax All AVR. --> http://www.reichelt.de/DIAMEX-ALL-AVR/3/index.html?&ACTION=3&LA=446&ARTICLE=110345&artnr=DIAMEX+ALL+AVR&SEARCH=diamax++all+avr Weitehin: Gutes Gelingen! fredl
Sebastian Wangnick schrieb: > Michael_ schrieb: >> Eigentlich ist es Wurscht, ob die Signatur stimmt. Hauptsache, es kommt >> eine zurück. > > Nein, die Signatur muss erst mal stimmen, vorher kann man alles andere > vergessen. > Richtig! Er kommt ja nicht mal so weit das, was auch immer er da brennen will, zu brennen, wenn er keine gescheite Verbindung zum uC hat.
vielleicht ist das Ding auch verfused (Taktquelle) dann wird er keine Signatur zurückbekommen
Die 10 Dinger sind (bzw wahren) Werksneu und an den Fuses war ich nicht dran. @Fredl Wird berücksichtigt.
@Fredl Am Dragon kommt am ISP keine %V raus. Das soll wohl nur eine Messleitung sein. Ich muss den Target aber von irgendwoher mit Strom versorgen. Dafür stellt der Dragon auf einem anderen Stecker 5V bereit, die ich aber auch auf den ISP-Port geben muss. So kommt die zweite Leitung zu stande. Du hast mich aber auf eine Idee gebracht. Aus dem Billig-China-Progger kommen doch auch 5V raus. Den werde ich nachher mal zur Stromversorgung verwenden. Grüße
Grinst... Keine Fehlermeldung mehr. Die Led blinkt. Hex-File-In :020000020000FC :1000000000C00FEF07BB08BB00C013951F3F09F0EE :10001000FCCF41E0042708BB10E023952F3F09F0F7 :10002000F4CF42E0042708BB20E033953F3F09F0BE :0C003000ECCF44E0042708BB30E0E7CF31 :00000001FF Hex-File-Out :1000000000C00FEF07BB08BB00C013951F3F09F0EE :10001000FCCF41E0042708BB10E023952F3F09F0F7 :10002000F4CF42E0042708BB20E033953F3F09F0BE :10003000ECCF44E0042708BB30E0E7CFFFFFFFFF31 :00000001FF (Den Speicher der mit FF gefüllt ist habe ich hier mal gekürzt) Ich habe jetzt hier den Billig-China-Progger nur zur Stromversorgung und den Dragon nur zum Proggen verwendet (also gleiche Schaltung nur statt Dragon VCC den Fishl VCC). Es gab von Vorn bis Hinten direkt keine Fehlermelung. Signatur Stimmte; ISP-Speed wurde direkt erkannt; Löschen ging; Flaschen ging; Verify ging und Read ging. Und... Led blinkt. Mich wundert nur etwas, dass das Ende des Hex-File minimal abweicht.
Tiny10Nutzer schrieb: > Grinst... > > Keine Fehlermeldung mehr. Die Led blinkt. > Ich habe jetzt hier den Billig-China-Progger nur zur Stromversorgung und > den Dragon nur zum Proggen verwendet (also gleiche Schaltung nur statt > Dragon VCC den Fishl VCC). Es gab von Vorn bis Hinten direkt keine > Fehlermelung. Signatur Stimmte; ISP-Speed wurde direkt erkannt; Löschen > ging; Flaschen ging; Verify ging und Read ging. Und... Led blinkt. > > Mich wundert nur etwas, dass das Ende des Hex-File minimal abweicht. Herzlichen Glückwunsch! So ist das mit der Stromversorgung. Ist mir heute auch passiert, aber mit einem TDA2822. Hatte gestern noch damit getestet, für einen elektronischen Gehörschutz und heute funktionierte das nicht mehr. Nur dumm, dass ich alles raus gerupft hatte, ohne einen Schaltplan gezeichnet zu haben. Letztlich lag es am Steckbrett.
Tiny10Nutzer schrieb: > Mich wundert nur etwas, dass das Ende des Hex-File minimal abweicht. Dein Original File endet bei 0x3b. Das siehst du an dem verkürzten letzten Record. Beim Auslesen wird immer ein 16-Bytes Record gelesen. Wenn du vergleichst, siehst du, dass es am Ende deines Original Files mit 0xff = gelöschte Zelle weiter geht.
Ich habe den Kondenstor jetzt mal ausprobiert. Es ist so wie Ihr es gesagt habt. Ich kann den Tiny jetzt ohne externe Stromquelle programmieren. Danke auf jeden Fall für all Eure Antworten. Grüße
Tiny10Nutzer schrieb: > Hex-File-In > :020000020000FC > :1000000000C00FEF07BB08BB00C013951F3F09F0EE > :10001000FCCF41E0042708BB10E023952F3F09F0F7 > :10002000F4CF42E0042708BB20E033953F3F09F0BE > :0C003000ECCF44E0042708BB30E0E7CF31 > :00000001FF Das original Hex (das identische wird mir vom Assembler in AVRStudio 4 ausgespuckt, wenn ich deinen Code kompiliere) enthält 'zur Sicherheit' ein Extended Segment Address Record (Typ 02), siehe http://de.wikipedia.org/wiki/Intel_HEX Irgendein Intel Hex Interpreter in deiner Programmierkette kommt mit diesem Record nicht klar und misinterpretiert die '02' als Startadresse des Codes, wobei er sich noch verhaspelt. Wenn du vor dem programmieren also immer die erste Zeile des HEX löschst, sollte es in Zukunft richtig klappen. Allerdings wird dieses Record evtl. mal nötig, wenn du mehr als 64k adressieren willst.
Matthias Sch. schrieb: > Irgendein Intel Hex Interpreter in deiner Programmierkette kommt mit > diesem Record nicht klar und misinterpretiert die '02' als Startadresse > des Codes, wobei er sich noch verhaspelt. Merksatz für dich: vor dem ersten Kaffee keine Posts schreiben! Das Problem ist längst gelöst. Es war der fehlende Abblockkondensator am Target. Traurig, daß man 130+ Posts braucht, um das fetzustellen. Allerdings habe ich die Hoffnung, daß der TE diese Erfahrung nicht vergißt. Und dann war es ja für etwas gut. XL
Axel Schwenke schrieb: > Es war der fehlende Abblockkondensator > am Target. Traurig, daß man 130+ Posts braucht, um das fetzustellen. > Allerdings habe ich die Hoffnung, daß der TE diese Erfahrung nicht > vergißt. Und dann war es ja für etwas gut. Dem kann man sich nur anschließen.
Axel Schwenke schrieb: > Das Problem ist längst gelöst. Es war der fehlende Abblockkondensator > am Target. Und es zeigt deutlich, zu welche merkwürdigen Ergebnissen ein Weglassen derselben führen kann. Obwohl ich gestehen muss, dass ich bei den Symptomen mit Sicherheit nicht an die Blockkondensatoren gedacht hätte.
Nur mal so ganz nebenbei, hatte letztens ein ähnliches Problem mit einem ATmega8. Es kann sein, dass hier auch die Beschaltung (Kondensator) nicht korrekt lief. Jedenfalls hat das programmieren mit der kleinsten ISP-Frequenz (2kHz oder so) geklappt.. Wenn man Probleme beim programmieren hat, sollte man vielleicht zuerst die Frequenz so klein wie möglich einstellen...
Thread beobachten
Seitenaufteilung abschalten
Bitte 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.