avr studio 4.12
- Ersteller neuer
- Erstellt am
Hi Thomas,
AVRISPmk2 ? STK500 ? ... ?
mehr Input !
Gruß
Dino
welchen Programmer benutzt du denn ?
AVRISPmk2 ? STK500 ? ... ?
mehr Input !
Gruß
Dino
Hi,
bei der Fehlermeldung können es ein Paar Probleme sein,
Ich vermute aber es begrenzt sich auf :
1. Falsch angeschlossen
1.2 kann es sein dass du an MISO / MOSI / SCK etwas Externes beschalten hast ? Das wäre dann auch schlecht. Mindestens mit 1K deine Applikation gegen über dem Programmer anbinden.
Kondensatoren solltest auch erst nach dem 1K anbringen..
oder (wie der Fehler auch sagt)
2. Ache darauf dass die ISP Porgrammier geschwindigkeit maximal 1/4 der Oszillator fequenz hat. (ich schaue sogar dass ich maximal 1/8 hab ..)
Also wenn die CPU mit 8 Mhz intern Läuft + (Clock / 8 Fuse) hast 1MHz, also die ISP Frequenz Maximal auf 125 KHz laufen lassen.
gruß
bei der Fehlermeldung können es ein Paar Probleme sein,
Ich vermute aber es begrenzt sich auf :
1. Falsch angeschlossen
1.2 kann es sein dass du an MISO / MOSI / SCK etwas Externes beschalten hast ? Das wäre dann auch schlecht. Mindestens mit 1K deine Applikation gegen über dem Programmer anbinden.
Code:
Also
PortPin--(Programmer)
|--[1K ]--(deine Application)oder (wie der Fehler auch sagt)
2. Ache darauf dass die ISP Porgrammier geschwindigkeit maximal 1/4 der Oszillator fequenz hat. (ich schaue sogar dass ich maximal 1/8 hab ..)
Also wenn die CPU mit 8 Mhz intern Läuft + (Clock / 8 Fuse) hast 1MHz, also die ISP Frequenz Maximal auf 125 KHz laufen lassen.
gruß
ich bedanke mich erst einmal das du mir antwortest.ich fange erst damit an.
wenn das erledigt ist habe ich noch ein paar fragen.wie ist das zu verstehen.
1.2 kann es sein dass du an MISO / MOSI / SCK etwas Externes beschalten hast ? Das wäre dann auch schlecht. Mindestens mit 1K deine Applikation gegen über dem Programmer anbinden.
die anderen attiny lassen sich programmieren.
gruß thomas
wenn das erledigt ist habe ich noch ein paar fragen.wie ist das zu verstehen.
1.2 kann es sein dass du an MISO / MOSI / SCK etwas Externes beschalten hast ? Das wäre dann auch schlecht. Mindestens mit 1K deine Applikation gegen über dem Programmer anbinden.
die anderen attiny lassen sich programmieren.
gruß thomas
Hi Thomas,
die an diese Pins soll über einen 1k-Widerstand in Reihe an die Port-Pins.
Damit der Programmer die Signale übersteuern kann, die evtl von der Pheripherie
an den Atmel gesendet werden.
Gabs irgendeine Application Note von Atmel drüber ...
Oder dieses Bildchen ...
das hab ich mal zusammen ge-pasted.
Rechte Seite - Mitte - Figure3
Gruß
Dino
den ISP-Anschluß direkt an die Port-Pins des Atmel und die andere Pheripherie
die an diese Pins soll über einen 1k-Widerstand in Reihe an die Port-Pins.
Damit der Programmer die Signale übersteuern kann, die evtl von der Pheripherie
an den Atmel gesendet werden.
Gabs irgendeine Application Note von Atmel drüber ...
Oder dieses Bildchen ...
das hab ich mal zusammen ge-pasted.
Rechte Seite - Mitte - Figure3
Gruß
Dino
halt öhm nun bin ich verwirrt ^^
mit was fängst du an?
Welche anderen Tinys lassen sich Programmieren ?
Was ist wie zu verstehen ?
Schaltplan deines Aufbaus ?
Weißt du wo man die Einstellungen bezüglich der ISP Frequenz vom Programmer macht ?
//edit danke dino ich bin grad auf der Arbeit da hab ich es nicht so mit Bildchen wo hochladen
naja wir kriegen das schon hin ^^
Gruß
mit was fängst du an?
Welche anderen Tinys lassen sich Programmieren ?
Was ist wie zu verstehen ?
Schaltplan deines Aufbaus ?
Weißt du wo man die Einstellungen bezüglich der ISP Frequenz vom Programmer macht ?
//edit danke dino
ich bin grad auf der Arbeit da hab ich es nicht so mit Bildchen wo hochladen naja wir kriegen das schon hin ^^
Gruß
Hi,
hehe ganz einfach
Auf der Rechten Seite hast du den AVR (deinen Tiny), Mittig hast du die Widerstände, Links hast du deine "IO" Pins die du mit irgendetwas beschalten kannst. (große Kapazitäten würde ich mir aber auch da verkneifen)
Unten ist dein ISP "Programmer".
Es geht einfach darum dass der Programmer die meiste Gewalt über die Pins hat.
Deswegen in der Mitte da 1K oder 4K7 damit der Programmer direkt am AVR sitzt und die "hoheit" über die Pins hat (egal was drausen dran hängt).
(das mit das es manchmal länger dauert .. liegt nicht am Alter ich bin demnächst 24 und bei mir dauerts manchmal auch länger *Gg*)
hoffe ich hab mich nun nicht zu verwirrend ausgedrückt (irgendwie passiert mir das gegen Abend immer ^^)
Gruß,
hehe ganz einfach
Auf der Rechten Seite hast du den AVR (deinen Tiny), Mittig hast du die Widerstände, Links hast du deine "IO" Pins die du mit irgendetwas beschalten kannst. (große Kapazitäten würde ich mir aber auch da verkneifen)
Unten ist dein ISP "Programmer".
Es geht einfach darum dass der Programmer die meiste Gewalt über die Pins hat.
Deswegen in der Mitte da 1K oder 4K7 damit der Programmer direkt am AVR sitzt und die "hoheit" über die Pins hat (egal was drausen dran hängt).
(das mit das es manchmal länger dauert .. liegt nicht am Alter ich bin demnächst 24 und bei mir dauerts manchmal auch länger *Gg*)
hoffe ich hab mich nun nicht zu verwirrend ausgedrückt (irgendwie passiert mir das gegen Abend immer ^^)
Gruß,
Hi Thomas,
von nem Transistor (bipolarer oder MOSFET) wär auch kein Problem. Über die
Pins würd ich aber nicht "gewaltiges" steuern. Also keine Motoren oder sowas
dransetzen das dann bei unkontrollierter Ansteuerung (während dem Prog-Vorgang)
was mechanisch oder elektrisch kaputt machen kann.
- Er kann deine .HEX-Datei lesen (das compilierte Programm)
- er kann den Progger installieren und ansprechen
- er geht in den Programmier-Modus
- er kann das Flash des Tinys nicht löschen ! (der Fehler)
- und danach hat er keine Lust mehr (leaving programming mode)
Evtl der Reset-Anschluß nicht richtig am Tiny dran ? oder irgend ein
anderer Anschluß nicht richtig verbunden ? ...
Gruß
Dino
Äh... eher nicht. Aber nen LCD oder Taster würden gehen. Oder ne Basis/Gate
von nem Transistor (bipolarer oder MOSFET) wär auch kein Problem. Über die
Pins würd ich aber nicht "gewaltiges" steuern. Also keine Motoren oder sowas
dransetzen das dann bei unkontrollierter Ansteuerung (während dem Prog-Vorgang)
was mechanisch oder elektrisch kaputt machen kann.
So wie es aussieht kann er den Tiny nicht ansprechen.
- Er kann deine .HEX-Datei lesen (das compilierte Programm)
- er kann den Progger installieren und ansprechen
- er geht in den Programmier-Modus
- er kann das Flash des Tinys nicht löschen ! (der Fehler)
- und danach hat er keine Lust mehr (leaving programming mode)
Evtl der Reset-Anschluß nicht richtig am Tiny dran ? oder irgend ein
anderer Anschluß nicht richtig verbunden ? ...
Gruß
Dino
hi,
hmmz also am Reset wird es denke ich nicht liegen, da er in den Programming Mode gelangen kann.. somit sollte das mit dem Reset schon passen *grübelz*
mir scheint es immer noch als ob ne kapazitive last auf Miso / Mosi / Sck / Reset liegt.
Ahh möp hast du ev. nen 470nF oder größer direkt am Reset ? Weil dann könnte er in den Programming mode gelangen da das langsam ist, jedoch das Erase (macht er mehr damit) könnte unter gehen durch das C.
(ev. das C am Reset mal ganz entfernen ums zu testen)
das andere würd mir nur noch die Frequenz einfallen hast du die mal überprüft ?
hmmz also am Reset wird es denke ich nicht liegen, da er in den Programming Mode gelangen kann.. somit sollte das mit dem Reset schon passen *grübelz*
mir scheint es immer noch als ob ne kapazitive last auf Miso / Mosi / Sck / Reset liegt.
Ahh möp hast du ev. nen 470nF oder größer direkt am Reset ? Weil dann könnte er in den Programming mode gelangen da das langsam ist, jedoch das Erase (macht er mehr damit) könnte unter gehen durch das C.
(ev. das C am Reset mal ganz entfernen ums zu testen)
das andere würd mir nur noch die Frequenz einfallen hast du die mal überprüft ?
Hi,
das läuft soweit ohne Probleme. 100nF hab ich auch schon mal gehabt und
das war auch Problemlos.
MOSI/MISO/SCK sollte man ohne irgendwelche Kapazitäten betreiben.
Gruß
Dino
ich habe bei mir nur nen 47nF am Reset zum GND und 22k nach +5V (Vcc).
das läuft soweit ohne Probleme. 100nF hab ich auch schon mal gehabt und
das war auch Problemlos.
MOSI/MISO/SCK sollte man ohne irgendwelche Kapazitäten betreiben.
Gruß
Dino
hehe dino ja,
alles unter 470nF ist kein Thema größer is s n Problem *grad nochmal ausgetestet ^^* vorschlag von Atmel ist ja 100nF gegen GND, 10k gegen VCC.
Klar Miso Mosi und Sck sind ja im Khz bereich .. da wäre nen C ganz schlecht ...
alles unter 470nF ist kein Thema größer is s n Problem *grad nochmal ausgetestet ^^* vorschlag von Atmel ist ja 100nF gegen GND, 10k gegen VCC.
Klar Miso Mosi und Sck sind ja im Khz bereich .. da wäre nen C ganz schlecht ...
hallo! ich schon wieder.
langsam verzweifle ich,ob es am Brenner liegt.wie ist das mit der isp freq. und
der oscillator calibratiom byte.eigentlich wollte ich nur Projekt nachbauen.wie
ist das mit ponypro. da habe ich einen Brenner.ich bin ja froh, dass sich jemand mit mir abgibt.vielleicht kannst du mir das Programm übersetzen. man muss den
calibirungs 0x72 wert in das asm schreiben(aber wie)ich kann dir die datei
mal schicken.
gruß thomas
langsam verzweifle ich,ob es am Brenner liegt.wie ist das mit der isp freq. und
der oscillator calibratiom byte.eigentlich wollte ich nur Projekt nachbauen.wie
ist das mit ponypro. da habe ich einen Brenner.ich bin ja froh, dass sich jemand mit mir abgibt.vielleicht kannst du mir das Programm übersetzen. man muss den
calibirungs 0x72 wert in das asm schreiben(aber wie)ich kann dir die datei
mal schicken.
gruß thomas
Hi,
kurz zwischendurch: Die Varianten gehen von 4.7K bis 24K, was ich so gelesen habe. Bei mir funktioniert die Resetbeschaltung (mit Diode) einwandfrei mit 4.7K / 47nF.
Grüsse,
Michael
kurz zwischendurch: Die Varianten gehen von 4.7K bis 24K, was ich so gelesen habe. Bei mir funktioniert die Resetbeschaltung (mit Diode) einwandfrei mit 4.7K / 47nF.
Grüsse,
Michael
Hi Thomas,
Wenn du nen Quarz mit 8MHz dran hast dann solltest du maximal mit einem viertel
dieser Frequenz programmieren (ISP-Frequenz). Also bei 8MHz maximal mit
2MHz die Daten vom Progger zum Atmel blasen.
Da manche Atmels aber noch ne Fuse haben, mit der man die Oszillatorfrequenz
auf ein Achtel runterteilen kann ...
also bei 8MHz Quarz nur 1MHz interner Takt ...
sollte man dann maximal mit 1/4 des internen Taktes proggen.
Bei 1MHz also maximal 250kHz ISP-Frequenz.
Diese ISP-Frequenz ist der Takt, mit dem der Progger die Daten zum Atmel
überträgt. Die kannst du nur am Progger einstellen.
Gruß
Dino
Das Calibration-Byte kannst du komplett vergessen. Brauchst du garnix dran machen.
Wenn du nen Quarz mit 8MHz dran hast dann solltest du maximal mit einem viertel
dieser Frequenz programmieren (ISP-Frequenz). Also bei 8MHz maximal mit
2MHz die Daten vom Progger zum Atmel blasen.
Da manche Atmels aber noch ne Fuse haben, mit der man die Oszillatorfrequenz
auf ein Achtel runterteilen kann ...
also bei 8MHz Quarz nur 1MHz interner Takt ...
sollte man dann maximal mit 1/4 des internen Taktes proggen.
Bei 1MHz also maximal 250kHz ISP-Frequenz.
Diese ISP-Frequenz ist der Takt, mit dem der Progger die Daten zum Atmel
überträgt. Die kannst du nur am Progger einstellen.
Gruß
Dino
ich hänge jetzt mal die datei an.in der an leitung steht!!!
OSCCAL wert vom attiny15 0x7C.
----------------------------------------------------------------------
Beim Ausmessen (bei der Herstellung) wird das Calibrationsbyte zwar noch
in die letzte EEP-Zelle und in die letzte Flash-Zelle (Low und High)
geschrieben, wird aber von den meisten ISP-Programmen beim ersten
Zugriff gelöscht und ist daher bei Verwendung von Ponyprog & Co nicht
wirklich verwendbar.
Um den Tiny15 zu calibrieren, muss man:
- mit ISP-Programm das Calibrationsbyte aus dem Signature-Space
ermitteln
- im AVR-Programm das Calibrationsbyte in das I/O-Register OSCCAL
schreiben
Kleines Handycap dabei: Das AVR-Programm kann das Calibrationsbyte nicht
lesen, das kann nur ein Programmer (ISP, HV-Ser.) von außen. Ein
Programmer kommt zwar an das Calibrationsbyte heran, hat aber keinen
Zugriff auf . Daher ist das Calibrieren des Tiny15 nicht ohne
Mitwirkung des Menschen automatisierbar. Im DCC-Programm findet man im
Reset-Block folgende Sequenz:
ldi TEMP1, EEOSCCAL ;hole Oszillator Calibrierung
rcall readEEProm
out OSCCAL, Temp2
Das lässt darauf schließen, dass der Calibrationswert im EEPROM an der
Adresse EEOSCAL erwartet wird. Die Suche nach EEOSCCAL ergab folgenden
Treffer:
.equ EEOSCCAL = 5 ;Speicherplatz OSCCAL im EEPROM
Nun wissen wir, dass es sich um Adresse 5 handelt, also das 6. Element
des EEPROM. Nun müssen wir ermitteln, woher das EEPROM seine Daten
bekommt und finden das hier:
;** hier beginnt das EEProm **
.ESEG
.ORG $0000
.db 0x01, 0x00 ; CV1 Adresse und CV2 StartSpeed
.db 0x80, 0x80 ; CV3 IncVAL und CV4 DecVal
.db 0x80, 0x71 ; CV5 MaxSpeed und CV6 OSCCAL
.db 0xFF, 0x01 ; CV7 Hersteller und CV8 Typ ID
.db 0xFF, 0xFF ; CV9 Frei und CV10 Frei
.db 0xFF, 0xFF ; CV11 Frei und CV12 Frei
.db 0xFF, 0xFF ; CV13 Frei und CV14 Frei
.db 0xFF, 0xFF ; CV15 Frei und CV16 Frei
.db 0x00, 0x02 ; CV17 HI-Byte und CV18 LO-Byte
.db 0x00, 0xFF ; CV19 Consist und CV20 Frei
.db 0xFF, 0xFF ; CV21 Frei und CV22 Frei
.db 0xFF, 0xFF ; CV23 Frei und CV24 Frei
.db 0xFF, 0xFF ; CV25 Frei und CV26 Frei
.db 0xFF, 0xFF ; CV27 Frei und CV28 Frei
.db 0x00, 0xFF ; CV29 Configuration Data und CV30 Frei
Und wenn wir uns die Datenzeilen ansehen, stellen wir fest, dass immer
zwei Bytes in einer Zeile notiert sind. Das 6. Element mit der Adresse 5
steht demnach in der dritten Zeile an zweiter Position und hat in diesem
Quelltext den Wert 0x71. Auch im Kommentar erkennt man, dass es sich um
den OSCCAL-Wert handelt, allerdings im DCC-Slang gleich noch mit einem
"CV"-Namen versehen.
Deine Aufgabe ist es nun
- mit einem ISP-Programm (z.B. Ponyprog2000) das Calibrationsbyte Deines
Tiny15 zu ermitteln,
es in den Quelltext einzutragen,
den Quelltext neu zu assemblieren,
die neu assemblierte Hexdatei in den Tiny15 zu brennen...
Ich lege in meinen Programmen das Calibrationsbyte übrigens immer in die
letzte Flash-Zelle, so kann ich bei neuen AVRs gleich die
Herstellerwerte benutzen. Manchmal ist es eben vorteilhaft, sich an
gewisse Konventionen zu halten.
--------------------------------------------------------------
gruß thomas
OSCCAL wert vom attiny15 0x7C.
----------------------------------------------------------------------
Beim Ausmessen (bei der Herstellung) wird das Calibrationsbyte zwar noch
in die letzte EEP-Zelle und in die letzte Flash-Zelle (Low und High)
geschrieben, wird aber von den meisten ISP-Programmen beim ersten
Zugriff gelöscht und ist daher bei Verwendung von Ponyprog & Co nicht
wirklich verwendbar.
Um den Tiny15 zu calibrieren, muss man:
- mit ISP-Programm das Calibrationsbyte aus dem Signature-Space
ermitteln
- im AVR-Programm das Calibrationsbyte in das I/O-Register OSCCAL
schreiben
Kleines Handycap dabei: Das AVR-Programm kann das Calibrationsbyte nicht
lesen, das kann nur ein Programmer (ISP, HV-Ser.) von außen. Ein
Programmer kommt zwar an das Calibrationsbyte heran, hat aber keinen
Zugriff auf . Daher ist das Calibrieren des Tiny15 nicht ohne
Mitwirkung des Menschen automatisierbar. Im DCC-Programm findet man im
Reset-Block folgende Sequenz:
ldi TEMP1, EEOSCCAL ;hole Oszillator Calibrierung
rcall readEEProm
out OSCCAL, Temp2
Das lässt darauf schließen, dass der Calibrationswert im EEPROM an der
Adresse EEOSCAL erwartet wird. Die Suche nach EEOSCCAL ergab folgenden
Treffer:
.equ EEOSCCAL = 5 ;Speicherplatz OSCCAL im EEPROM
Nun wissen wir, dass es sich um Adresse 5 handelt, also das 6. Element
des EEPROM. Nun müssen wir ermitteln, woher das EEPROM seine Daten
bekommt und finden das hier:
;** hier beginnt das EEProm **
.ESEG
.ORG $0000
.db 0x01, 0x00 ; CV1 Adresse und CV2 StartSpeed
.db 0x80, 0x80 ; CV3 IncVAL und CV4 DecVal
.db 0x80, 0x71 ; CV5 MaxSpeed und CV6 OSCCAL
.db 0xFF, 0x01 ; CV7 Hersteller und CV8 Typ ID
.db 0xFF, 0xFF ; CV9 Frei und CV10 Frei
.db 0xFF, 0xFF ; CV11 Frei und CV12 Frei
.db 0xFF, 0xFF ; CV13 Frei und CV14 Frei
.db 0xFF, 0xFF ; CV15 Frei und CV16 Frei
.db 0x00, 0x02 ; CV17 HI-Byte und CV18 LO-Byte
.db 0x00, 0xFF ; CV19 Consist und CV20 Frei
.db 0xFF, 0xFF ; CV21 Frei und CV22 Frei
.db 0xFF, 0xFF ; CV23 Frei und CV24 Frei
.db 0xFF, 0xFF ; CV25 Frei und CV26 Frei
.db 0xFF, 0xFF ; CV27 Frei und CV28 Frei
.db 0x00, 0xFF ; CV29 Configuration Data und CV30 Frei
Und wenn wir uns die Datenzeilen ansehen, stellen wir fest, dass immer
zwei Bytes in einer Zeile notiert sind. Das 6. Element mit der Adresse 5
steht demnach in der dritten Zeile an zweiter Position und hat in diesem
Quelltext den Wert 0x71. Auch im Kommentar erkennt man, dass es sich um
den OSCCAL-Wert handelt, allerdings im DCC-Slang gleich noch mit einem
"CV"-Namen versehen.
Deine Aufgabe ist es nun
- mit einem ISP-Programm (z.B. Ponyprog2000) das Calibrationsbyte Deines
Tiny15 zu ermitteln,
es in den Quelltext einzutragen,
den Quelltext neu zu assemblieren,
die neu assemblierte Hexdatei in den Tiny15 zu brennen...
Ich lege in meinen Programmen das Calibrationsbyte übrigens immer in die
letzte Flash-Zelle, so kann ich bei neuen AVRs gleich die
Herstellerwerte benutzen. Manchmal ist es eben vorteilhaft, sich an
gewisse Konventionen zu halten.
--------------------------------------------------------------
gruß thomas
Öhm nun bin ich verwirrt,
ist dein Problem dass du kein Hex file raus bekommst oder ist dein Problem dass du das Hex file nicht auf den Tiny bekommst ?!?
Also wenns ums Hex file bekommen geht ->
Avr Studio Starten
"New Project"
"Atmel AVR Assembler" auswählen, deinem Projekt nen Namen geben, dem Initial File nen namen geben, Create Folder & Initial File anklicken
Debugg platform "AVR Simulator" Device "Tiny15"
Finish.
Nun öffnet sich ein Fenster auf der Linkenseite müsste nun eine Ordnerstruktur sein wo du auf das ASM File findest.
Das hat sich im Hauptfenster auch schon geöffnet, so hier per Copy & Paste deinen Quelltext rein.
Dein Oscal hinschreiben wo du meinst das es hin muss?!?
Speichern
und dann "Build" Build anklicken.
(wenns halbwegs richtig gelaufen ist sollte sowas wie)
Assembly complete, 0 errors. ? warnings <- erscheinen
schon hast du in deinem Ordner das Hex file.
und !!! ein .epp file <- wichtig.
Diese beiden Flasht du nun auf deinen Tiny und es sollte alles laufen.
Wobei man das auch anderst hätte machen können ^^
Aber so hast du es dann wie in der Anleitung...
ist dein Problem dass du kein Hex file raus bekommst oder ist dein Problem dass du das Hex file nicht auf den Tiny bekommst ?!?
Also wenns ums Hex file bekommen geht ->
Avr Studio Starten
"New Project"
"Atmel AVR Assembler" auswählen, deinem Projekt nen Namen geben, dem Initial File nen namen geben, Create Folder & Initial File anklicken
Debugg platform "AVR Simulator" Device "Tiny15"
Finish.
Nun öffnet sich ein Fenster auf der Linkenseite müsste nun eine Ordnerstruktur sein wo du auf das ASM File findest.
Das hat sich im Hauptfenster auch schon geöffnet, so hier per Copy & Paste deinen Quelltext rein.
Dein Oscal hinschreiben wo du meinst das es hin muss?!?
Speichern
und dann "Build" Build anklicken.
(wenns halbwegs richtig gelaufen ist sollte sowas wie)
Assembly complete, 0 errors. ? warnings <- erscheinen
schon hast du in deinem Ordner das Hex file.
und !!! ein .epp file <- wichtig.
Diese beiden Flasht du nun auf deinen Tiny und es sollte alles laufen.
Wobei man das auch anderst hätte machen können ^^
Aber so hast du es dann wie in der Anleitung...