eigentlich nicht ;)
Wenn der Bootloader sich schon in seiner FSM befindet so benötigt er
exakt 0x00,0x00,0x00,0x00 um quasi einen Restart von sich selber zu
machen um erneut in die Baudraten Detektion zu springen. Gleich nach
diesen Nullen muß also 0x0D folgen, an Hand dessen die Baudrate
Detektion die Baudrate ermittelt.
Wenn aber die FSM schon aktiv ist und hat schon 1 Kommando Byte
verarbeitet dann reichen die 4 Null-Bytes nicht aus um ein gültiges
Restart Kommando zu dekodieren. Der Bootloader antwortet mit ERRORCRC
oder ERRORCOMMAND, hauptsache er macht nicht irgendwas unanständiges
(eben der Grund warum alle Kommandos separat mit CRC abgesichert sind).
Am besten ist es 7-8 solcher Nullen zu senden, und das ist in meiner
inoffiziellen Version auch schon gefixt.
Der Bootloader war bei dir aber schon in seiner FSM, weil du entweder
nach dem vorherigen Test den AVR nicht reset hast oder das
"RunApplication" Kommando der PC-Software nicht ordentlich ausgeführt
wurde. Es kann durchaus sein das der FTDI Treiber/FTDI selber sofort
alle Daten im Buffer löscht wenn die PC-Software nach dem Senden dieses
Kommandos sofort die VCom schließt. Ich rufe zwar FlushFileBuffers auf,
aber solche Probleme habe ich schon bei einigen Treibern gesehen.
Also wenn du mal testest dann prüfe auch mal ob deine Anwendung nach
einem Disconnect der PC-Software auch automatisch gestartet wird.
Die Aufrufe der neuen Methoden in IApplication sind trivial. Habe nur
wenig Zeit das Beispiel zu korregieren (weswegen es in den letzen ZIPs
auch nicht mehr drinnen ist). Beim nächsten offiziellen Update packe
ichs mit bei.
Gruß Hagen
Hallo.
ich habe das jetzt auch mal bei mir getestet.
Aber ich bekomme leider keine Verbindung zum AVR.
Folgende Einstellungen habe ich in der asm gemacht:
1
.include "m644def.inc"
2
3
#message "compile for" __PART_NAME__
4
5
.ifndef PageSize
6
.error "Device don't support Bootloader !"
7
.else
8
9
10
.equ UseWDR = 1 ; set to 0/1 to de/activate WatchDog Support
11
.equ UseAutobaud = 1 ; set to 0/1 to de/activate Baudrate Detection
12
.equ UseVerify = 0 ; set to 0/1 to de/activate Verify FLASH Command, FLASH write/erase includes implicit verify, can be deactivated
13
.equ UseE2Write = 0 ; set to 0/1 to de/activate EEPROM Write Command
14
.equ UseE2Read = 0 ; set to 0/1 to de/activate EEPROM Read Command
15
.equ UseSRAM = 0 ; set to 0/1 to de/activate SRAM Commands
16
.equ UseCrypt = 0 ; set to 0/1 to de/activate cryptography
17
.equ UseCryptFLASH = 0 ; set to 0/1 to de/activate only use of cryptography for writing to FLASH
18
.equ UseCryptE2 = 0 ; set to 0/1 to de/activate only use of cryptography for writing to EEPROM
19
.equ UseVersioning = 0 ; set to 0/1 to de/activate Versioning for Application Software
20
.equ UartInvert = 0 ; set to 1 to invert UART levels, for RS232 drivers such as MAX232
21
22
23
.equ RX_PORT = PORTD ; Receive Port and Pin
24
.equ RX = PD0
25
.equ TX_PORT = PORTD ; Transmit Port and Pin
26
.equ TX = PD1
27
28
.set XTAL = 16000000 ; only important for BootDelay if Autobaud is used
29
.set BootDelay = XTAL/4 ; 250ms
30
.set BootBaudrate = 115200 ; only used if no Baudrate Detection activated, XTAL is important
31
.set BootVersion = 3 ; Version 3, must be not changed
32
.set BootCodeSize = 406 ; compile and set to value in [.cseg] Used, compile again
Fuses gesetzt auf:
BOOTSZ: Boot Flash size = 1024 words Boot address =$7C00
SUT_CKSEL: Ext. Crystal Osc. 8.0 - Mhz Start-up time: 16k CK+65ms
Quarz: 16Mhz.
Als Port ist bei mir Com10 und Baud habe ich mal auf 2400 gestellt.
Habe habe ich falsch gemacht ?
Danke, Markus
Hallo.
Hab den Fehler gefunden.
.equ UartInvert = 0 muss 1 sein.
Ich nutzte den FTDI 232RL.
Jetzt geht es wunderbar und schön schnell.
Danke für dieses gute Programm.
lg, markus
@Markus:
> BOOTSZ: Boot Flash size = 1024 words Boot address =$7C00> .set BootCodeSize = 406
Die BootCodeSize hast du nach der 1. Kompilation aus AVRStudio so
aktualisert ?
Wenn ja dann benötigt dein Bootloader 1024 Word = 2048 Bytes an FLASH.
Real verbraucht der Bootloader davon aber nur 406 Bytes. Somit stehen
1642 Bytes an FLASH ungenutzt zur Verfügung.
Ich empfehle dir also diesen verschwendeten Platz mit dem Bootloader in
anderer Konfiguration auszunutzen, setze
.equ UseWDR = 1
.equ UseAutobaud = 1
.equ UseVerify = 1
.equ UseE2Write = 1
.equ UseE2Read = 1
.equ UseSRAM = 0
.equ UseCrypt = 1
.equ UseCryptFLASH = 1
.equ UseCryptE2 = 1
.equ UseVersioning = 1
.equ UartInvert = 1
UseCryptFLASH/UseCryptE2 kannst du auch auf 0 setzen wenn du möchtest
das man den AVR mit oder ohne Verschlüsselung benutzen kann.
Wenn dann würde ich aber nur UseCryptE2=0 setzen, man kann also mit oder
ohne Verschlüsselung den EEPROM schreiben. Bei UsCryptFLASH=1 kann der
FLASH nur mit Verschlüsselung geschrieben werden. Das erhöht die
Sicherheit enorm. Besonders eben auch die Datenintegrität und ihre
Überprüfung wird mit der Verschlüsselung weitaus besser sein, da diese
quasi eine 64Bit secure Prüfsumme benutzt, neben der 16Bit CRC die
sowieso immer über die Daten berechnet wird.
Erzeuge vor der Kompilation mit der PC-Software ein neues Passwort mit
der PC-Software -> Button "Make Password".
Setze BootSign: auf einen längeren Wert, zb. BOOTLOADER, um die
Wahrscheinlichkeit einer Fehlanmeldung stark zu reduzieren.
Setze in BootMsg: einen für dich aussagekräftigen Titel/Copyright.
Selbst wenn du alle diese Features aktivierst wirst du maximal 950 Bytes
von den 2048 zur Verfügung stehenden Bytes des FLASHs verbrauchen.
Dh. der Bootloader ist für die großen ATMegas so klein das er mehrmals
in die minimale FLASH Size für eine Bootpage reinpasst.
Du könntest noch eine 1Kb Lookup Tabelle für deine Anwendung in diesem
FLASH unterbringen.
Gruß Hagen
> Am besten ist es 7-8 solcher Nullen zu senden, und das ist in meiner> inoffiziellen Version auch schon gefixt.
Also dazu kann ich nur sagen, das der Connect jetzt mit jeder Version
funktioniert ! sobald ich in AppCMD 1x /00 setze !!
> Der Bootloader war bei dir aber schon in seiner FSM, weil du entweder> nach dem vorherigen Test den AVR nicht reset hast oder das> "RunApplication" Kommando der PC-Software nicht ordentlich ausgeführt> wurde. Es kann durchaus sein das der FTDI Treiber/FTDI selber sofort> alle Daten im Buffer löscht wenn die PC-Software nach dem Senden dieses> Kommandos sofort die VCom schließt. Ich rufe zwar FlushFileBuffers auf,> aber solche Probleme habe ich schon bei einigen Treibern gesehen.
Bei der Theorie muß ich dich leider enttäuschen ! Hab die letzten Tests
sowohl mit FTDI als auch mit Max232 getestet, bei beiden das exakt
gleiche verhalten !!
> Also wenn du mal testest dann prüfe auch mal ob deine Anwendung nach> einem Disconnect der PC-Software auch automatisch gestartet wird.
Das funktioniert einwandfrei !
> Die Aufrufe der neuen Methoden in IApplication sind trivial.
Für dich vielleicht ! :-)
> Habe nur wenig Zeit das Beispiel zu korregieren (weswegen es in den> letzen ZIPs> auch nicht mehr drinnen ist). Beim nächsten offiziellen Update packe> ichs mit bei.
Kein Problem ! Muß meine App. halt noch nen bißchen warten ! Ich werds
überleben !
Gruß Stefan
@Stefan:
>Bei der Theorie muß ich dich leider enttäuschen ! Hab die letzten Tests>sowohl mit FTDI als auch mit Max232 getestet, bei beiden das exakt>gleiche verhalten !!
Was benutzt du als BootSign: ?
Bzw. poste mal alles was in der ASM nach BootInfo: steht und die Section
[BootSign] aus der INI Datei.
Gruß Hagen
Das Einzige was mir auffällt ist die Baudrate von 256000. Takt im AVR
sollte mindestens 7.68MHz sein ist dann aber schon Fehleranfällig bei
der Baudratedetektion. Hast du mal mit geringerer Baudrate probiert ?
>Hast du mal mit geringerer Baudrate probiert ?
Ja klar ! 256000 war nur mal zum Testen ob es damit auch geht !:-)
Aber durch die BaudRate-Detection sollte es ja eigentlich auch egal sein
was da drin steht !?
>Aber durch die BaudRate-Detection sollte es ja eigentlich auch egal sein>was da drin steht !?
Jain ;) ganz egal ist es nicht, bei der Rechnung XTAL / Baudrate - 29
darf kein Wert kleiner 1 rauskommen. Aber selbst wenn 1 rauskäme so wäre
das schon sehr kritisch (Abtasttheorem).
Dh. je geringer die Taktfrequenz des AVRs und je
ungenauer/kurzzeit-instabiler desto geringer sollte die Baudrate
eingestellt werden.
Je geringer der Wert bei XTAL/Baudrate-29 ist desto exakter sollte die
Taktfrequenz durch die Baudrate teilbar sein, also ohne Rest.
Je geringer aber die Baudrate ist desto längere Timeouts muß die
PC-Software benutzen. Je größer diese Timeouts sind desto langammer ist
der Verbindungsaufbau. Die Wahrscheinlichkeit für ein ungünstiges
Connect-Timing steigt.
Gruß Hagen
OK ! Neue Erkenntnisse !
Feste BaudRate-BootSign(10Zeichen)-AppCmd(leer):
Connect funktioniert ! Aber nur das letzte Zeichen vom BootSign wird
angezeigt !
BaudRate-Detection-BootSign(10Zeichen)-AppCmd(leer):
Connect funktioniert ! Aber es wird abwechselnd das komplette BootSign
oder das letzte Zeichen ausgegeben !!!
Gruß Stefan
Und gleich noch was merkwürdiges hinterher !
Mit deiner Debug-AVRootloader Datei kommen abwechselnd das komplette
BootSign oder die letzten 2 Zeichen !!!
Mit deiner AVRootloader 3.1(bzw. 3.0 mit neuestem update) Datei kommen
abwechselnd das komplette BootSign oder das letzte Zeichen !!!
Übrigens sowohl mit FTDI als auch Max232 !
Gruß Stefan
> Mit deiner Debug-AVRootloader Datei kommen abwechselnd das komplette> BootSign oder die letzten 2 Zeichen !!!>> Mit deiner AVRootloader 3.1(bzw. 3.0 mit neuestem update) Datei kommen> abwechselnd das komplette BootSign oder das letzte Zeichen !!!
Sorry, da war ich ein bißchen voreilig !!
Hatte bei der AVRootloader 3.1 noch ein /00 im AppCMD stehen, dadurch
fehlte hier ein Zeichen !!
Also die beiden Versionen reagieren identisch !!
Gruß Stefan
Wo wird was angezeigt ? Beim Wert "Ident:" oder "Received:" ?
Beim Ident muß immer stehen:
AppCmd + $00 $00 $00 $00 $0D + BootSign
Bei Received darf niemals das BootSign drinnen stehen. Wenn das der Fall
sein sollte dann empfängt die PC-Software teilweise Daten die sie selber
abgesendet hat, und das darf überhaupt nicht sein, egal ob 1-Wire oder
nicht.
Lade dir mal aus dem WEB bei sysinternals.com den PortMon und sniff mal
real alles das mit was über die COM geht.
Deine Angaben sind teilweise sehr verwirrend für mich, kosten mir Zeit
und bringen im Endeffekt nichts. Es wäre auch gut wenn du bei solchen
Sachen die Ausgabe im Protkollfenster mit postest, dann kann ich mir
wesentlich besser ein Bild machen.
Gruß Hagen
> Wo wird was angezeigt ? Beim Wert "Ident:" oder "Received:" ?
Steht bei recived ! eine Kennzeichnung Ident hab ich noch nirgens
gesehen !!
> Beim Ident muß immer stehen:> AppCmd + $00 $00 $00 $00 $0D + BootSign
So eine meldung hab ich noch nie gesehen !
> Bei Received darf niemals das BootSign drinnen stehen. Wenn das der Fall> sein sollte dann empfängt die PC-Software teilweise Daten die sie selber> abgesendet hat, und das darf überhaupt nicht sein, egal ob 1-Wire oder> nicht.
Dann hab ich wohl nen riesen Problem !! Weil genau da steht das nämlich
drin.
29.01.09-18:22:25-812 > Device disconnected
29.01.09-18:22:26-640 > Connecting on port COM1...
29.01.09-18:22:26-703 > Switch to 2-Wire mode
29.01.09-18:22:26-765 > received:
$48,$61,$6C,$6C,$6F,$21,$21,$21,$21,$61,$61,$00,$93,$07,$03,$10,$FF,$FF,
$FF,$FF,$39
29.01.09-18:22:26-765 > Device connected
> Lade dir mal aus dem WEB bei sysinternals.com den PortMon und sniff mal> real alles das mit was über die COM geht.
Werd ich gleich mal versuchen !
> Deine Angaben sind teilweise sehr verwirrend für mich, kosten mir Zeit> und bringen im Endeffekt nichts. Es wäre auch gut wenn du bei solchen> Sachen die Ausgabe im Protkollfenster mit postest, dann kann ich mir> wesentlich besser ein Bild machen.
OK ! Ich gelobe Besserung ! Will es dir ja nicht noch schwerer machen
als du es mit mir eh schon hast ! :-)
Danke
Stefan
Hab mal 2 Scans mit Portmon gemacht.
Test2: AppCmd(leer)-> Connect
Test3: AppCmd(AppCMD)-> kein Connect
Sag mal, arbeiter der AVRootloader eigentlich mit einem WDR wenn er
keinen Connect bekommt, oder versucht er es immer weiter ?
Gruß Stefan
$48,$61,$6C,$6C,$6F,$21,$21,$21,$21,$61,$61,$00,
$93,$07,$03,$10,
$FF,$FF,$FF,$FF,
$39
$48,$61,$6C,$6C,$6F,$21,$21,$21,$21,$61,$61,$00, -> in ASCII
"Hallo!!!!aa" ist deine BootMsg:
Danach kommen 4 Bytes BootInfo: wobei $93,$07 -> ATmega8, $03 =
BootVersion 3 und $10 = Anzahl der FLASH Pages die der Bootlaoder
benötigt $10 * 64 = 1024 Bytes.
Nun kommen 4 Bytes Versionsnummer, $FFFFFFFF heist noch keine Anwendung
drinen.
Als letztes Byte $39 = SUCCESSCODE, du hast UseVersiong=1 und UseCrypt=1
aber UseCryptFLASH = 0 und UseCryptE2 = 0. Somit kannst du
unverschlüsselt wie auch verschlüsselt mit dem Bootloader kommunizieren.
Allerdings benuzt die PC-Software in diesem Fall immer keine
Verschlüsselung.
Sooo, mal abgesehen das du das Zeichen ! zu lieben scheinst, ich sehe in
diesen Daten nichts vom BootSign: Das BootSign: steht per Standard auf
"BOOT".
Zitat:
>> Bei Received darf niemals das BootSign drinnen stehen. Wenn das der Fall>> sein sollte dann empfängt die PC-Software teilweise Daten die sie selber>> abgesendet hat, und das darf überhaupt nicht sein, egal ob 1-Wire oder>> nicht.>Dann hab ich wohl nen riesen Problem !! Weil genau da steht das nämlich>drin.
Das was ich sehe ist eine perfekte Antwort des Bootloaders im AVR.
>Sag mal, arbeiter der AVRootloader eigentlich mit einem WDR wenn er>keinen Connect bekommt, oder versucht er es immer weiter ?
Nein nicht mit dem WDT. Ein WDR würde ja bedeuten das er sich immer
wieder
selber aufruft.
Solange der Bootloader in der Wartephase auf einen Connect ist und er am
RX Pin irgendwas empfängt (toggelt) wartet er solange bis er ein
gültiges Connect empfangen hat. Dh. er versucht die Baudrate zu
berechnen und wartet auf den Wert in BootSign. Sobald sich am RX Pin
nichts mehr tut wird nach einem Timeout die Anwendung gestartet. Deshalb
ist das #define XTAL und BootDelay wichtig.
Wenn also im Normalfalle der Bootloader per RESET/Poweron angesprungen
wurde und sich in BootDelay Millisekunden nichts am RX Pin getan hat
dann wird die Anwendung gestartet.
Wenn sich aber in dieser Zeitspanne was am RX Pin tut so wird quasi
diese Zeitspanne erneut gewartet, eben ein Timeout. Solange also irgend
eine PC-Software was in dieser Phase was sendet gibt es nur zwei
Möglichkeiten aus dieser Schleife rauszukommen: a) für BootDelay
Millisekunden hört die Software auf was zu senden oder b) sie sendet den
korrekte BootSign Sequenz und der Bootloader antwortet zB. mit den Daten
wie du sie oben gepostet hast.
Der Watchdog wird mit UseWDT unterstützt. Aber auch nur um die WDT
Zeiten zu verlängern damit der Bootloader nicht durch den WDT gestört
wird. Man kann ja den WDT per WDTON Fuse permanent aktivieren und würde
der Bootoader nicht das berücksichtigen so stört der WDT den Bootloader.
Finally: ich sehe in deinen geposteten Daten keinerlei Fehler.
Die Daten in den .LOG Files vom PortMon mal bitte auf HEX stellen, bei
Sonderzeichen macht PortMon ein '.' und somit wie0 man nicht was das
bedeutet. -> Menu -> Options -> Show HEX.
Gruß Hagen
Hallo Hagen !
OK, das mit dem BootSign hab ich wohl gründlich falsch verstanden
gehabt, Sorry !
Inwieweit beeinflußt eigentlich die Einstellung der Baudrate im Program
den Verbindungsaufbau ?
Hab nämlich festgestellt das bei AppCmd(leer) der Verbindungsaufbau mit
115200 Baud tadellos funktioniert, aber bei zunemender Zeichenanzahl in
der AppCmd ich mit der Baudrate runtermuß um sporadisch noch einen
Connect zu bekommen. Sprich Connect funktioniert dann nur noch zu 30-40%
!
Hab im Anhang nochmal 2 Test, diesmal mit Hex !
Gruß Stefan
In Test4_PortMon.LOG hast du zweimal einen Connect aufgezeichnet. Der 1.
davon hat super funktioniert, ab Zeile 22.
Beim 2. Connect, ab Zeile 76 reagiert der AVR erst auf den zweiten
Connect versuch. Er ist beim ersten noch in er FSM und antwortet deshalb
mit C2 C2 -> ErrorCRC. Ein Command kann minimal 4 Bytes lang sein, bei
2x Fehler C2 (ERRORCRC) hat er also 8 Bytes empfangen. Das stimmt
insoweit mit der Anzahl der voeher gesendeten Bytes über ein, sind 9
Bytes im Connect String.
Danach, beim zweiten Senden des Connect Strings, verbindet er sauber.
Das heist der AVR ist schon in der Command-FSM, denn das ist er einzige
Punkt an dem ein ERRORCRC gesendet wird.
Test5_PortMon.log ist da schon erheblich interessanter.
Nach senden des Connect Strings, Zeile 22 zb., wird vom AVR die Bytes 80
00 empfangen. Nur woher kommen die ? Vom AVR garantiert nicht. Es
scheint so auszusehen das irgendwas auf deinem Board nicht stimmig ist.
Es gibt kein Kommando das mit den gesendeten Bytes für "AppCmd"
übereinstimmen würde und der AVR würde mit C2 oder C3 darauf reagieren
müssen, wenn er in seiner FSM wäre. Einzige Erklärung die ich noch habe,
wenn es tatsächlich am Bootloader läge, ist das irgendeines der Bytes,
bzw. sogar mehrere, innerhalb der Baudrate Detektion, als 0D Sequenz
erkannt wird. Er arbeitet dann mit falscher Baudrate und sendet wiederum
ein C2, aber wir sehen es als 80 00 mit anderer Baudrate.
Wenn man den AVRootloader.ASM nun mit fester Baudrate programmieren
würde, zb. 112500, dann müsste beim gleichen Test wie in
Test5_PortMon.log was anderes rauskommen.
Die Gefahr das die Baudrate Detektion andere Bytessequenzen
fälschlicherweise als 0D Sequenz interpretiert ist gegeben und führt
zwangsläufig dazu das der AVR eine andere Baudrate detektiert.
Ich weiß es nicht warum es bei dir nicht sauber funktioniert. Es ist ja
nun nicht so das es mit dem FTDI nicht funktionieren würde, das
bestetigten ja die positiven Rückmeldungen hier im Forum.
Gruß Hagen
Sag mal, wenn du AVRootloader.ASM kompiliert hast, dann hast du doch aus
dem Message Window vom AVRStudio den Wert aus CSeg Used in das ASM bei
BootCodeSize eingetragen und mit AVRStudio erneut kompiliert. Dann hast
du dir den Output im Message Window nochmal genauer angeschaut und dort
den Hinweis gesehen auf welche Bootfuses du den AVR setzen solltest.
Nach dem Flashen des HEX über ISP hast du auch die Boot Fuses
entsprechend eingestellt, richtig.
Denn ich denke auch da könntest du einen Fehler gemacht haben. Dieser
Fehler könnte sein das der Bootloaderr Code im FLASH an einer falschen
Addresse gespeichert wurde im Vergleich zu den eingestellten Bootfuses.
Das würde dann nämlich bedeuten das nach einem RESET der AVR mitten in
den Bootloader springen könnte und es so zu erklären ist warum der AVR
ständig in der Command FSM drinnen ist statt in der Baudrate Detektion +
BootSign Überprüfung zu warten.
Gruß Hagen
Hagen Re wrote:
> Sag mal, wenn du AVRootloader.ASM kompiliert hast, dann hast du doch aus> dem Message Window vom AVRStudio den Wert aus CSeg Used in das ASM bei> BootCodeSize eingetragen und mit AVRStudio erneut kompiliert. Dann hast> du dir den Output im Message Window nochmal genauer angeschaut und dort> den Hinweis gesehen auf welche Bootfuses du den AVR setzen solltest.> Nach dem Flashen des HEX über ISP hast du auch die Boot Fuses> entsprechend eingestellt, richtig.
AVRASM: AVR macro assembler 2.1.30 (build 592 Nov 7 2008 12:38:17)
Copyright (C) 1995-2008 ATMEL Corporation
C:\Dokumente und
Einstellungen\Stefan\Desktop\AVRootloader_3_0\AVRootloader\AVR\AVRootloa
der.asm(68): Including file 'C:\Programme\Atmel\AVR
Tools\AvrAssembler2\Appnotes\m8def.inc'
C:\Dokumente und
Einstellungen\Stefan\Desktop\AVRootloader_3_0\AVRootloader\AVR\AVRootloa
der.asm(126): compile for ATmega8
C:\Dokumente und
Einstellungen\Stefan\Desktop\AVRootloader_3_0\AVRootloader\AVR\AVRootloa
der.asm(164): Including file 'C:\Dokumente und
Einstellungen\Stefan\Desktop\AVRootloader_3_0\AVRootloader\AVR\AVRootloa
der.inc'
C:\Dokumente und
Einstellungen\Stefan\Desktop\AVRootloader_3_0\AVRootloader\AVR\AVRootloa
der.asm(161): WARNING: actual settings compromise security !
C:\Dokumente und
Einstellungen\Stefan\Desktop\AVRootloader_3_0\AVRootloader\AVR\AVRootloa
der.inc(114): Please program Boot Fuse to Third Boot Start !
C:\Dokumente und
Einstellungen\Stefan\Desktop\AVRootloader_3_0\AVRootloader\AVR\AVRootloa
der.asm(955): No EEPROM data, deleting C:\Dokumente und
Einstellungen\Stefan\Desktop\AVRootloader_3_0\AVRootloader\AVR\AVRootloa
der.eep
ATmega8 memory use summary [bytes]:
Segment Begin End Code Data Used Size Use%
---------------------------------------------------------------
[.cseg] 0x001c00 0x001f3a 792 34 826 8192 10.1%
[.dseg] 0x000060 0x000060 0 0 0 1024 0.0%
[.eseg] 0x000000 0x000000 0 0 0 512 0.0%
Assembly complete, 0 errors. 0 warnings
->
BootSZ1 = 0 BooTSZ0 = 1 BootRST = 0
Hab mal die Baudrate-Detection raus genommen und mit 115200 und 19200
getestet! gleiches Ergebnis ! sobald was in der AppCmd drin steht kein
Connect ! Aber ... mache ich zwischen den Connect-Versuchen einen Reset,
dann bekommt er beim nächsten versuch 1x einen Connect !
Es sieht also so aus als ob ich irgendein problem mit dem 'Internen
Reset' bzw. des Ablaufs der ConnectRoutine im AVR habe. Und was mich
wirklich irritiert ist halt die Tatsache das es ohne AppCmd funktioniert
und mit eben nicht ! Bzw. wenn er connectet dann mal mit vollem BootSign
oder nur mit dem letztn Buchstaben. Siehe Test4 ab Zeile 23 und ab Zeile
81 ! So geht das dann immer im Wechsel !
Gruß Stefan
Hallo Hagen !
kannst du dir mal die angehängte LogDatei anschauen.
Beim ersten Connectversuch war AppCMD leer. Beim zweiten Versuch ab
Zeile 123 war AppCMD = /00 ! Die empfangenen Zeichen sind in beiden
Fällen identisch außer das Sie im ersten Fall hintereinander stehen und
im zweiten Fall untereinander. Kannst du mir sagen woran das liegen
könnte ? bzw. kann ich diese /00 nicht einfach auf AVR-Seite Hardcoden
??
GRuß Stefan
Hi Stefan,
probiere mal die neuste Version im Attachment aus. Ich habe den
Verbindungsaufbau verändert.
Bisher würde bei einem Connect Versuch erstmal auf 1-Wire eingestellt.
Dann wurde der Connect-String gesendet und versucht exakt diesen Wert
sofort wieder vom COM Port zu lesen. Schlug dies fehl so wurde auf
2-Wire Mode umgeschaltet. DIese Vorgehensweise birgt aber ein Problem.
Wenn nämlich der AVR den 2-Wire Modus benutzt so empfängt der PC ja
sofort den Signature-String des AVRs statt dem soeben gesendeten
Connect-String. Der AVR ist also schon in seiner FSM drinnen, aber die
PC-Software schaltet erst jetzt in den 2-Wire Modus. Darauf hin versucht
sie erneut einen Connect im 2-Wire Modus und sendet erneut den
Connect-String. Das ist der Grund warum bei dir diese Probleme
auftraten.
Nun ist das geändert. Die PC-Software geht erstmal von 2-Wire Modus aus.
Sendet den Connect-String und empfängt die komplette Antwort. Dieser
String kann nun am Anfang den Connect-String selber enthalten, ergo
1-Wire Modus muß benutzt werden. Aus den empfangen Daten wird der vorher
gesendete Connect-String entfernt und der Rest dieser Daten ist die
Signature des AVRs die er gesendet hat.
Der Verbindngsaufbau und die Unterscheidung zwischen 1/2-Wire ist nun
wesentlich stabiler und schneller.
Gruß Hagen
Hier die neuste Version 4
Neuerungen:
- RS485/Profibus Unterstützung, dh. im Halbduplex Verfahren kann man
RS485 Treiber benutzen die einen Data Enable (DE) Eingang besitzen. Im
AVRootloader.asm einfach UseRS485=1, DE_PORT und DE setzen. Möchte man
invertierte Pegel nutzen dann noch UseRS485invert=1 setzen. Diese
Funktionalität konnte ich aber leider noch nicht testen ;(
- verändertes Verhalten des Watchdog Timers. Wird UseWDT=1 gesetzt so
wird der WDT im Bootloader explizit aktiviert und auf 2 Sekunden Timeout
gesetzt. Tritt nach 2 Sekunden ein WDT auf so wird ein RESET
durchgeführt. Somit ist die Stabilität des Bootloaders verbessert worden
wenn zb. ein ungeplanter Verbindungsabbruch auftreten sollte. Bitte
beachten das in der eigenen Anwendung auf den WDT reagiert werden muß,
oder er deaktiviert wird. Wie das geht zeigt das Testprojekt im Ordner
\test\.
- Mit UseSaveMCUCSR=1 wird der Wert aus dem Reset-Register MCUCSR in den
Stack gespeichert (RAMEND) bevor er in den WDT Routinen gelöscht wird.
Somit stehen diese Informationen für die Anwendung zur Verfügung. Wie
man das zb. in WinAVR GCC benutzen kann sieht man im Beispiel Projekt im
Ordner \test\
- Mit UseBootMode=0/1/2/3/4 kann man das Startverhalten des Bootloaders
beeinflussen. Über diese Konfiguration wird eingestellt das der
Bootloader zb. nur bei einem Power Up, externen Reset, Watchdog Reset
oder per Jump aus der Anwendung gestartet wird. Mit diesen Bootmodis
kann man die Startup Zeit der Anwendung beeinflussen. eg. verkürzen und
nur auf ausgewählte Ereignisse fixieren.
- Mit UseBootVector=1 wird am Ende des FLASHs ein Sprungvektor zum
Einsprungspunkt des Bootloaders erzeugt. Über diesen Vektor kann man aus
der eigenen Anwednung universell für alle AVR Typen die diesen
Bootloader benutzen den Bootloader aufrufen. Man muß also nicht explizit
die Startadresse des Bootloaders mehr berechnen.
- Mit UseSpecialFuncs=1 werden am Ende des Bootloaders verschiedene
zusätzliche Funktionen und eine Sprungtabelle eingebunden. Diese
Spezialfunktionen können aus der eigenen Anwendung heraus aufgerufen
werden. Sie können auch durch eigenen Code/Lookup Tabelle erweitert
werden.
Der normale Anteil an Code des Bootloaders ist so kompakt das er auf
größeren ATMegas mehrmals in die kleinste Bootsektion reinpasst. Man
verschwendet also in diesem Fall ungenutzen FLASH den man nun für diese
Spezialfunktionen aus der Anwendung heraus benutzen kann.
Zur Demonstration wurden die Funktionen zur Abfrage der AppVersion und
BootMsg/BootInfo eingebaut. Wie man diese benutzt kann man im Test
Projekt im Ordner \test\ für WinAVR GCC anschauen und austesten.
- im Ordner \test\ ein Test-Projekt in WinAVR GCC zur Demonstration der
Bootloader Funktionalität. Im Headerfile AVRootloader.h eine universelle
Schnitstelle zum Bootloader.
- durch einige Optimierungen im Code konnte der benötigte FLASH
reduziert werden
- mehr Kommentierungen
Bugfixes/Veränderungen:
- die AVR Typen ATMega161/ATMega163/ATMega323 benötigen bei der
Ausführung des SPM Befehles ein spezielles programmtechnisches Vorgehen.
Diese wurde gefixt und eingebaut.
- der Connect Prozess wurde verändert. Die Abfrage/das Warten auf das
BootSign von der PC-Software benutzt nun einen Timeout innerhalb
BootDelays. Bei der alten Version mit UseAutobaud=1 konnte es an dieser
Stelle zu einer Endlosschleife kommen, der Bootloader verblieb also bei
einem Kommunikationsabbruch endlos in dieser Schleife.
- im neuen Connect Prozess erwartet der Bootloader nach dem Empfang des
BootSign eine 16 CRC über diese BootSign. Dies inkrementiert die
Stabilität des Connect Prozess und beseitigt gleichzeitig ein Problem
beim Connect. Bei der alten Version konnte man beim BootSign "BOOT" zb.
auch mit einem Wert wie "BOOT1234" einen Connect bekommen. Die
zusätzlichen Zeichen "1234" störten die Command-FSM des Bootloaders und
es stellt auch ein Sicherheitsrisiko dar wenn man das BootSign als
Passwort betrachtet.
- wenn UseVersioning=1, UseCrypt=1 und UseCryptFLASH=1 war so wird ja
die AppVersion Nummer auf cryptographisch sichere Weise bei einem Update
per ACY Datei überprüft. Diese Überprüfung war nicht ganz korrekt. Ist
gefixt.
PC-Software:
- die Kommunikationsgeschwindigkeit wurde durch Optimierungen
beschleunigt.
- einige Fehler in der Bedienung etc.pp. beseitigt
- neue Einstellungen in der AVRootloader.ini
* [System]-AppCmd, [System]-AppCmdResponse, [Timeouts]-AppCmd.
über diese Einstellung kann man der Software mitteilen das sie bei einem
Connect erstmal das AppCmd an die eigene Anwednung zu senden hat. Wenn
nun in AppCmdResponse ein Wert steht so wartet die Software auf den
Empfang dieses Wertes. Eure Anwendung muß also dann dieses Response
senden und startet dann den Bootloader per Watchdog oder direktem
Sprung.
Nach Empfang des Response wartet die Software [Timeuts]-AppCmd
Millisekunden bevor sie mit dem Connect weiter macht. Startet man den
Bootloader in der eigenen Anwendung zb. per Watchdog und Endlosschleife
dann entsteht ein minimaler Timout von 17ms. Damit die PC-Software
ebenfalls diese Zeitspanne wartet kann man zB. Timeouts.AppCmd=20
setzen.
* [Timeouts]-KeepAlive ist ein Interval in Millisekunden in dem die
PC-Software beim Bootloader nachfragt ob er noch aktiv ist. Hat man mit
UseWDT=1 den Watchdog aktiviert so muß dieser spätestens nach 2 Sekunden
periodisch zurückgesetzt werden. Exakt das macht die PC-Software im
Interval von KeepAlive. Das hat mehrere Vorteile. Die PC-Software
bekommt mit wenn eine Verbindung zum Bootloader unterbrochen wurde und
trennt die Verbindung automatisch. Der Bootloader seinerseits erkennt
das die Verbindung zur PC-Software getrennt wurde und wird spätestens
nach 2 Sekunden durch einen Watchdog Timeout terminiert. Zudem
inkementiert es auch die Stabilität des Bootloaders auf unvorhergesehene
Ereignisse. Ich empfehle also mit UseWDT=1 zu arbeiten.
* [Timeouts].Options. Dies ist ein Bitkodierter Wert. Bit 0 = 1 ist der
Debugmode der PC-Software. Bit 1=2 bestimmt das Verhalten im Connect
Prozess beim Senden der BootSign. Ist dieses Bit gesetzt so benutzt die
Software die alte Methode beim Senden des BootSign, also ohne CRC
Prüfsumme. Damit wird die Kompatibilität zum alten AVRootloader.asm
gewährleistet. Für die neuste Version darf dieses Bit nicht gesetzt
sein.
- der neue Connect Prozess geht von einer 2-Wire Verbindung aus und
schaltet erst während des Connects dynamsich auf 1-Wire um wenn dieser
benutzt wird. In der alten Version war es umgekehrt. Diese Veränderung
verbessert die Connect Performance und Stabilität.
- XPORT (TCP/IP zu RS232-Wandler) wird sauber unterstützt. Der Grund
einiger Änderungen in der Kommunikation. Bei Interesse gibt noch Tipps
wie man den XPORT ordentlich konfiguriert von mir.
Tipps:
Wird so wie im Testprojekt im Ordner \test\ der PinChange am RX Pin
benutzt um 1.) aus dem Power Down Sleep Mode aufzuwachen und 2.) den
Bootloader zu starten dann sollte man in AVRootloader.ini folgende
Einstellungen treffen
[system]
AppCmd=/AA
AppCmdResponse=
[timeouts]
AppCmd=20
Somit sendet die PC-Software erstmal das Zeichen 0xAA um den PinChange
in der ISR zu bedienen. Innerhalb dieser ISR wird der Bootlaoder per
Watchdog Reset gestartet mit minimalem Timeout von 17ms. Die PC-Software
wartet nun ihrerseits 20 ms und somit wird der gesammte Connect Prozess
verbessert da das Timing ideal aufeinander abgestimmt ist.
Lese Readme.txt im Ordner \test\ ;)
Wenn ich die Spezialfunktionen in Special.inc erweitert vergesst nicht
am Ende des Sources euren Sprungvektor einzubauen. Desweiteren muß die
.org Direktive aktualisiert werden. In AVRootloader.h könnt ihr sehen
wir ihr dann eure Funktionen aufrufen könnt.
Mit der Spezialfunktion "GetBootMsg" kann man nicht nur die BootMsg aus
dem FLASH auslesen sondern auch alles was danach kommt. Also auch
BootKey: das Passwort der Verschlüsselung. Das ist kein
Sicherheitsrisiko wenn ihr alle korrekt konfiguriert habt. Also
UseSRAM=0, UseCryptFFLASH=1, UseCrypt=1. Desweiteren liefert nur ihr
vorkompilierte ACY Dateien an eure Kunden aus. Somit ist jeder
Anwendungscode der programmiert wird durch euch authorisiert.
Gruß Hagen
@Hagen:
Ein fettes Dankeschön für den riesigen Ehrgeiz, den du hier in das
Projekt investierst! Absolut fettes Tool!
Vielleicht kann ich die Tage ja einige Funktionen testen.
Eine Sache ist mir noch aufgefallen. Ich benutze ja den 1-Wire Betrieb
auf einem ATtiny45 mit einem FTDI. Wenn ich in meiner Software den
1-Wire Pin als Ausgang nutze, dann erkennt die PC-Flash-Software in
einem Großteil der Fälle immer den 2-Wire Betrieb. In den Bootloader
komme ich durch das Trennen der Betriebsspannung. Den Resetpin benutze
ich als 1-Wire-Pin. Die Verbindung kommt zu Stande aber eben im 2-Wire
Betrieb, wodurch dann das Flashen fehlschlägt. Vielleicht hast du ja
eine Idee, woran es liegen könnte.
Grüße
Hm, der Reset Pin hat der einen internen Pullup ?
Der FTDI ist ein Pegelwandler und ich habe mit Use1Wire und
UseUartInvert=1 einige Probleme hardwaretechnischer Art gehabt. Zu
Testzwecken benutzte ich den Spare-RS232 vom STK500. Wenn man den RX-TX
per Brücke verschaltet dann empfängt die PC-Software korrekterweise das
was sie vorher gesendet hat. Überbrückt man RX-TX aber mit zb. einem 2k7
Widerstand so empfängt die Software nichts mehr. Warum dies so ist weiß
ich bisher auch noch nicht, es sollte ja kein Problem damit geben. Aber
exakt diese Minimalbeschaltung benötigt man wenn man 1-Wire mit
TTL-RS232 benutzen möchte.
Du kannst bei der neuen Version mal in der AVRootloader.INI
[Timeouts]-Options=1 setzen, bzw. auf 3 wenn du mit der alten
AVRootloader.asm testen möchtest (diese empfehle ich dir aber nicht da
gerade im Connect Prozess einige Änderungen erfolgten)
Mit diesen Änderungen siehst du dann im Protocol-Window der PC-Software
was sie sendet und was sie empfängt. Bei 1-Wire müsste bei "received
data:" erstmal das stehen was bei "send ident:" gesendet wurde. Plus am
Ende die Antwort des Bootloaders die mit 0x3? enden muß.
Hast du den 1-Wire in deiner Konfiguration überhaupt schonmal zum laufen
gebracht ?
Du könntest mir per PN, eg. Mail mal den Output des Protocolwindows
mailen. Vieleicht sehe ich ja mehr.
Gruß Hagen
@Hagen
Pullup am Resetpin ist auch drin. Überprüfe es aber morgen nochmal.
Ja die 1-Wire Konfiguration mit dem FTDI habe ich in den Griff bekommen.
Jedoch nur indem ich UseUartInvert=0 gesetzt habe und mit dem
Konfigurationsprogramm (MProg) von FTDI den FT232R so programmiert habe,
dass die RX/TX Leitungen invertiert werden. (Siehe Anlage)
Mit UseUartInvert=1 und 1-Wire tut sich gar nichts. Am Oszi sieht man,
dass der uC kein einziges Bit sendet.
Also die PC Software empfängt immer nur ihr eigenes Signal, wenn der Pin
ein hochohmiger Eingang ist. Ist er ein Ausgang, so liegt das
entsprechende Signal des uC am RX des Pegelwandlers. Der Widerstand ist
ja zwangsläufig nötig, da der TX des Pegelwanlders ja ein Ausgang ist.
Im 1-Wire Betrieb ist der uC Pin ja zumindest zeitweise auch ein Ausgang
und damit es dann keinen Kurzschluss gibt muss der Widerstand her.
Da die Verbindung ja korrekt Aufgebaut wird, nur eben der falsche
Wire-Modus erkannt wird, muss der uC Pin am Anfang nach dem
Wiederanlegen der Spannung ein Ausgang sein. Somit merkt deine Software,
dass die eigenen gesendeten Daten nicht ankommen. Der uC empfängt alles
korrekt und meldet sich dann zurück. Sehr strange. Also wenn man es
einfach mehrmals probiert, dann erkennt er irgendwann mit Glück den
1-Wire und man kann flashen^^
Ich schaue mir mal morgen die Sache mit deinen weiter angeführten Ideen
an
LG Mark
Liegt nicht an dir, es lag am Source. Es tut mir ja immer leid wenn mir
sowas passiert, sieht immer nach Schnellschuß aus, aber irgendwann
einmal muß ich an den Sourcen was kaputt repariert haben.
Im Attachment die gefixte Version. Ich habe sie nun in allen Modis
getestet. 1/2 -Wire, invertiert und nicht invertiert, direkt an RS232,
an USB-RS232 Wandler und am XPORT über TCP/IP.
So langsam überblicke ich die ganzen RS232 Kabel auf meinem Schreibtisch
nicht mehr ;)
Du nimmst einen zb. 2k7 Widerstand und schließt diesen zwischen RX und
TX am FTDI. Am RX Pin den RX des AVRs.
In deinem Falle ist es so das 1-Wire identisch zum zb. Dallas 1-Wire
oder I2C arbeitet. Der AVR zieht den RX/TX Pin aktiv nach Masse als
Ausgang. Ansonsten setzt er den Pin als Eingang. Der 2k7 Widerstand am
TX-FTDI zieht die Leitung auf VCC und ist also sowas ähnliches wie ein
externer Pullup und Stromegrenzung. Bei dieser Verschaltung benötigt man
keine Serienwiderstand falls man zb. mehrere AVRs an einer Leitung legen
möchte. Der AVR kann auch mit geringerer VCC betrieben werden als der
TX-FTDI Ausgang liefert.
Bei 1-Wire an nativer RS232, also ohne Pegelwandler, liegt ebenfalls ein
2k7 Widerstand zwischen RX und TX an der DB9. Auch dieser dient zur
Strombegrenzung und die internen Bodydioden des AVRs begrenzen negative
Spannung gegen Masse. Desweiteren zieht die TX Leitung ebenfalls den
RX-Pin gegen -15V. Der Bootloader benutzt hier Strong/Weak-High-Pegel
statt eben Strong-Low-Pegel wie bei dir. 1-Wire-native-RS232 läuft bei
mir bis auf 1.8 Volt VCC runter.
Gruß Hagen
Hallo Hagen,
mir ist gerade folgendes bei der aktuellen Version aufgefallen:
unter Win98se folgt dem 'Connect' sofort darauf wieder ein 'Disconnect'.
Auch im Debug-Modus ist kein Grund erkennbar.
Ausprobiert auf zwei Win98-PC und drei WinXP-PC mit identischem AVR-Chip
(M168).
Mit den Parametern UseBootMode=0, UseWDR=1 und UseSaveMCUCSR=0 überlebt
das MCUCSR beim M168 ohne besondere Tricks, beim M128 ist es immer
gelöscht (wie beschrieben).
Wäre es nicht einfacher bei UseWDR=1 immer das gerettete MCUCSR zu
restaurieren? - Dann könnte die Applikation immer gleich sein,
unabhängig davon ob ein Bootloader vorhanden ist oder nicht.
Gruß JoJo
>Wäre es nicht einfacher bei UseWDR=1 immer das gerettete MCUCSR zu>restaurieren? - Dann könnte die Applikation immer gleich sein,>unabhängig davon ob ein Bootloader vorhanden ist oder nicht.
Geht nicht, habe ich probiert. Man kann es nur löschen aber nicht wieder
neu setzen (M162). Wenn ich nur das WDRF lösche dann würde es für die
Anwendung nicht möglich sein darauf zu reagieren.
>Mit den Parametern UseBootMode=0, UseWDR=1 und UseSaveMCUCSR=0 überlebt>das MCUCSR beim M168 ohne besondere Tricks, beim M128 ist es immer>gelöscht (wie beschrieben).
Hm, das sollte eigentlich nicht der Fall sein. Bei UseWDR=1 lösche ich
es ja immer mit xout MCUCSR, zerol.
Ok, Fehler gefunden in der AVRootloader.inc auf folgendes abändern
; some redefinition of register names or bits
.ifndef MCUCSR
.equ MCUCSR = MCUSR
.endif ; .ifndef MCUCSR
Dämliche ständige Umbenammung der Registernamen durch Atmel. Wenn man
mal eine Librariy universell programmieren möchte muß man ständig seine
Registernamen per umdefinieren.
>unter Win98se folgt dem 'Connect' sofort darauf wieder ein 'Disconnect'.>Auch im Debug-Modus ist kein Grund erkennbar.>Ausprobiert auf zwei Win98-PC und drei WinXP-PC mit identischem AVR-Chip>(M168).
Das deutet darauf hin das die Windows Timer nicht sauber funktionieren.
Im Attachment die Version habe ich mal gefixt und im Debug Modus zeige
ich an ob die Timer sauber arbeiten.
In der INI in der Sektion [Timeouts] KeepAlive=500 setzen.
Es sollte jetzt periodisch "send keepalive" zu sehen sein. Wird die
Verbindung abnormal unterbrochen steht dann "keepalive failed".
Hm, könnte auch am MCUSR-Fehler liegen. Denn wenn im MCUSR/MCUCSR
Register das WDRF gesetzt ist und nicht vor dem Zugriff auf WDTCR
gelsöcht wird vereigert die MCU die neuen Einstellungen. Da durch den
Fehler in der AVRootloader.inc nicht MCUSR sondern MCUCR manipuliert
wurde, wurde auch der WDT nicht korrekt programmiert. Sicherlich stand
er noch auf 17ms Timeout und hat somit den Bootloader terminiert. Ich
denke das es daran liegen wird.
Gruß Hagen
Hi Hagen, ich bins wieder ;)
Habe deine Version 4 getestet und das UartInvert-Problem ist behoben :)
Dafür habe ich aber ein neues Problem. (Benutze die Version vom
09.02.2009) Ob es mit dem Bootloader zusammenhängt weiß ich nicht.
Benutze den ATtiny45 mit der Konfig:
1-Wire auf dem deaktivierten Resetpin. Vcc = 3,3V, Intern 8Mhz. Der Pin
ist nur auf ein Lötauge ausgeführt (Keine weiteren Bauteile dran).
Flashen geht ohne Probleme, dass Programm läuft dann auch sofort an.
Wenn ich jetzt aber die Versorgungsspannung aus- und wieder anschalte,
passiert nischt mehr. Das Programm läuft nicht mehr an. Das kann ich
daran sehen, dass ich im Programm einen Pin als Ausgang setze und HIGH
ausgebe. So nun habe ich aber eine Lösung gefunden, den uC zu laden des
Programms zu bewegen. Pullup-Widerstand am 1-Wire-Pin nach Vcc. Kannst
du mir sagen, warum das so ist? Die RESET-Funktion des Pins ist doch mit
dem FUSE-Bit ausgeschaltet.
PS: In der Software schalte ich den Watchdog sofort ab. Wie gesagt,
sobald das Programm einal läuft geht es. Schalte ich den uC einmal aus,
fährt er aber nicht mehr hoch.
Hier die Konfig aus der asm
UseWDR = 1
UseSaveMCUCSR = 0
UseE2Write = 1
UseE2Read = 1
UseCrypt = 1
UseCryptFLASH = 1
UseCryptE2 = 1
UseVerify = 0
UseVersioning = 1
UseBootVector = 0
UseSpecialFuncs = 0
UseSRAM = 0
UseAutobaud = 0
UseUartInvert = 1
UseRS485 = 0
RX/TX = PB5 (Deaktivierter Resetpin)
Hat es irgendwas mit dem Fix für das MCUCSR Register zu tun?
Nette Grüße
Mark
Um sicher zu gehen immer die neuste Version benutzen.
Du benutzt 1-Wire-TTL-Pegel und da ist es wichtig das extern ein Pullup
angeschlossen ist. Normalerweise ist das der Fall über den 2k7
Widerstand zwischen deinem RX-TX Pin am Pegelwandler. Der Pegelwandler
zieht den TX-Pin ja auf High wenn nichts gesendet wird. Exakt das könnte
das Problem bei dir sein. Der interne Pullup am Pin ist deaktivert damit
der 1-Wire-Source so funktionieren kann das beim Schalten auf Ausgang
der Pin Low-Pegel hat.
Problematisch wird es wenn man diesen vom AVR abtrennt, dann floated der
Eingang. Es ist also in jedem Falle empfehlenswert einen ext. Pullup am
Pin anzuschließen, da der interne nicht benutzt werden kann.
Gruß Hagen
Ah ok, dann ist klar was los ist. Ist intern der Pullup auch bei
UartInvert=0 abgeschaltet? Könnte man nicht den Pullup eingeschaltet
haben und bevor du den Pin als Ausgang benutzt ihn eben abschalten? Oder
soll das Aufgrund des kleinen Codes so sein? Wären ja aber auch nur eine
Hand voll ASM Befehle. Dann könnte man sich den ext. Widerstand sparen.
Ich Frage deshalb, weil ich sieben PCB Boards mit je 16 tinys schon
fertig habe. Aufgrund von Zeitdruck ist da ein neufräsen nicht möglich,
wohingegen die Platinen (bis auf die eine zum Testen) noch nicht
bestückt sind.
PS: Ich kann den neusten Bootloader nicht aufspielen, da auf der
Testplatine schon alles bestückt ist.. ISP ist da bei den 16 vernetzten
Tinys nicht drinne ;)
Besten Dank für die Erklärung! Achja, kannst du den Schaltplan für
1-Wire dann bitte updaten? Da ist kein Pullup drinne. Führt dann wie bei
mir heute dazu, dass es mal geht und mal nicht ;)
Beste Grüße
Mark
Hab grad mal in deinen Quellcode geguckt.
; initialize ports
cbi RX_DDR, RX
.if UseUartInvert && Use1Wire
cbi RX_PORT, RX
.else
sbi RX_PORT, RX <<--- Pullup an für Uartinvert=0//1-Wire :)
.endif ; .if UseUartInvert && Use1Wire
Sehe ich das richtig, dass für UartInvert=0 der Pullup tatsächlich
aktiviert ist? Das wäre für mich ja perfekt :) Dann stelle ich den FTDI
wieder auf invertierenden Modus um, und die Sache läuft :)
Grüße
Ja, bei 1-Wire und UseUartInvert=0 ist der interne Pullp aktiv. Bei
1-Wire mit UseUartInvert=1 ist er nicht drinne. Das hat tatsächlich
Gründe in der Codegröße und dem Timing. Du kannst versuchen ihn am
Anfang des Bootloaders zu aktivieren und in putc: dann ein/ausschalten:
1
; send char
2
putc:
3
de_0
4
cbi TX_PORT, TX
5
rcall waitf
6
rcall waitf
7
ldi cnt, 10
8
com paral
9
put3:
10
tx_out
11
rcall waitf
12
lsr paral
13
brcs put4
14
tx_0
15
put4:
16
rcall put5
17
dec cnt
18
brne put3
19
de_1
20
sbi TX_PORT, TX
21
put5:
22
ret
Sind 4 Bytes mehr Code und ob das wirklch geht weiß ich nicht.
Denn man müsste eigentlich ständig zwischen Eingang+Pullup und
Ausgang+Lowpegel umschalten. Dazu müsste aber die komplette putc und
waitf Routine umgeschrieben werden und deren Timing würde sich um 1 Takt
verändern. Diese Veränderung in der Zyklenanzahl hat es aber insich und
muß im komplettten Timing der UART Routinen bis hin zur Baudrate
Detektion berücksichtigt werden. Gehen tut grundsätzlich ja alles, aber
die Zeit und der Aufwand ist das Problem.
>Achja, kannst du den Schaltplan für 1-Wire dann bitte updaten?
Nö. der ist ja für 1-Wire mit UseUartInvert=0, also direkt an der RS232.
Man kann sogar noch die beiden Dioden rausnehmen, geht auch. Mit dieser
abgespeckten Schaltung habe ich 1-Wire mit UseUartInvert=0 und 1
erfolgreich getestet. Allerdings mit einem echten RS232-Pegelwandler von
Maxim. Kann schon sein das der FTDI sich da anders verhält. Ist ebenso
beim Spare-RS232 auf dem STK500 so, die haben da eine Schutzbeschaltung
eingebaut.
>PS: Ich kann den neusten Bootloader nicht aufspielen, da auf der>Testplatine schon alles bestückt ist.. ISP ist da bei den 16 vernetzten>Tinys nicht drinne ;)
Du hast also schon fest eine alte Version des Bootloaders drauf ?
Bedenke das je nach Version du in der AVRootloader.ini dann [Timeouts]
Options=2 setzen musst. Damit der Connect mit der alten BootSign Methode
arbeitet.
Gruß Hagen
>Das hat tatsächlich Gründe in der Codegröße und dem Timing.
Oki
>Diese Veränderung in der Zyklenanzahl hat es aber insich und>muß im komplettten Timing der UART Routinen bis hin zur Baudrate>Detektion berücksichtigt werden.
Reicht ja, dass ich es jetzt weis^^
>Nö. der ist ja für 1-Wire mit UseUartInvert=0, also direkt an der RS232.
Ein Vermerk, dass die Beschaltung eben nur für den Mode gilt, kann nicht
schaden.
>Du hast also schon fest eine alte Version des Bootloaders drauf ?
Es ist schon die Version 4 nur eben nicht der letzte Fix mit dem MCUCSR
Register.
>>Du hast also schon fest eine alte Version des Bootloaders drauf ?>Es ist schon die Version 4 nur eben nicht der letzte Fix mit dem MCUCSR>Register.
Du nutzt ATMega8, kein Problem bei diesem da dessen Register MCUCSR
heist.
ATTiny45 ist wiederum ein Problem dessen Register heist MCUSR.
Das sind so die miesen Stolperfallen durch Atmel die einem
Programmiererleben die Munition für Herzinfarkte liefern ;)
By the Way: großen Respekt für die Entwickler vom WinAVR GCC die solche
Probleme der Standardisierung mit Sicherheit auch kennen werden.
>>Nö. der ist ja für 1-Wire mit UseUartInvert=0, also direkt an der RS232.>Ein Vermerk, dass die Beschaltung eben nur für den Mode gilt, kann nicht>schaden.
Ich werde das Schematik anpassen wenn ich die Zeit dafür finde.
Grundsätzlich geht es eben auch ohne "Pullup" wenn man den
Serienwiderstand zwischen RX/TX am Pegelwandler mit betrachtet. Sauber
ist es nicht, das stimmmt.
Gruß Hagen
Hallo Hagen,
sorry das ich mich erst jetzt melde.
Das Problem mit Win98 besteht weiterhin (keepalive failed, terminate
connection). Falls Du noch eine Idee bezüglich der Timer hast dann gut,
ansonsten werde ich wohl über eine Verschrottung der Werkstattrechner
nachdenken müssen. Vielleicht gibt es ja dafür auch noch eine
"Abwrackprämie".
Gruß JoJo
> keepalive failed, terminate connection
das bedeutet "create timer" und "release timer" und "send keepalive"
sisht du in dem Protokoll. Das heist die Timer funktionieren, nur der
Bootloader im AVR antwortet nicht auf das Keepalive Kommando. Falsch
Version ? falsch konfiguriert ?
Was seht bei [timeouts] ? Mal Wert Base auf 50 oder 100 hochgesetzt ?
Neuste Version mit dem BugFix für das MCUCSR benutzt ?
Gruß Hagen
Ja, das Problem tritt ja auch nur bei den Win98-Rechnern auf.
Bei den WinXP-Rechnern läuft alles einwandfrei. Bootloader ist auch neu
compiliert. Win98-Protokoll als Anlage.
Gruß JoJo
>12.02.09-17:00:51-090 > send appcmd $0A 0A 2A 52 53 54 0A>12.02.09-17:00:51-090 > send ident $00 00 00 00 00 00 00 00 00 0D 42 4F 4F
54
>12.02.09-17:00:51-200 > send appcmd $0A 0A 2A 52 53 54 0A>12.02.09-17:00:51-200 > send ident $00 00 00 00 00 00 00 00 00 0D 42 4F 4F
54
>12.02.09-17:00:51-260 > received data $C2 94 06 04 08 30
1.) nimm mal bitte die $0A aus deinem AppCmd raus, mindestens das 0A
Zechen am Ende des AppCmd.
Die Zeichen 0A,0B,0D,0F,85,87,C3,E1 werden von der Baudrate Detektion
erkannt und an Hand dieser die Baudrate berechnet.
Grundsätzlich betrachtet dürfte das kein Problem darstellen da die
neuste Version nur eine Verbindung akzeptiert wenn sie das exakte
BootSign empfängt und anschließend eine gültige 2 Bytes CRC über diese
BootSign.
2.) der AVR antwortet mit
C2 -> Error CRC
94 06 04 08 -> BootInfo
30 -> SUCCESS Code
Das er überhaupt C2 absendet deutet darauf hin das du garnicht die
neuste Version auf deinen AVRs installiert hast. Denn nur mit der alten
Version kann es zu solchen Synchronisationsproblemen der internen FSM
beim Verbindungsaufbau kommen, in Verbindung mit dem Connect Aufbau der
neusten Version. Das er rausfliegt ist dann nämlich logisch.
Der alte Source empfängt nach dem BootSign noch 2 Bytes der CRC über
dieses BootSign für die neue Version. Diese landen erstmal als Kommandos
in der FSM des Bootloaders. Er erwartet noch 2 weitere Bytes die die CRC
darstellen. Das erste mal nach einem Connect bei dem die PC-Software ein
Befehl absendet ist beim Keepalive wenn du nur verbindst. Der AVR
empfängt die ersten 2 Bytes dieses Befehles als 2 Bytes CRC des
vorherigen Befehles und sendet ErrorCRC als Antwort, meine PC-Software
disconnected dann.
3.) du benutzt "BOOT" als BootSign was der Standard der alten Version
ist. Die neuste benuzt "BOOTLOADER".
(und ich benutze dabei nur meine Glaskugel und mein Hirn)
Ergo wie oben in einigen Postings zu lesen war:
1.) Setze [Timeouts] Options=3 oder =2 um den alten Verbindungsaufbau
zur alten Version des Bootloaders zu aktivieren. Dann dürfte es sauber
laufen.
2.) du hast auf deinen AVRs mit Sicherheit die alte Version installiert.
Wenn du updatest dann [Timeouts] Options=1 oder =0 setzen.
3.) man erkennt an Hand solcher Fehler das die interne FSM sehr stabil
gegen Protokollfehler ist. Schlimmer wäre es nämlich wenn sie in einem
solchen Fall zb. den FLASH löscht oder falsch programmiert.
Gruß Hagen
Hallo Hagen,
beim mir funktionieren die Versionen 2,3 und 4 deines Bootloaders
bestens und waren bisher auch sehr wertvoll für mich.
Die PC-Seite ist ein Acer-Notebook und die AVT-Seite ein Mega32 mit FTDI
FT232R.
Jedoch mit einem Asus Netbook bekomme ich leider keinen Connect mit der
selben AVR Hardware. Habe alle Versionen durchprobiert.
Mit deiner am 26.01.2009 geposteten Version (V3.0), mit Debug=1 zeigt
das Protocol für den Acer folgendes:
22.02.09-15:55:34-393 > Connecting on port COM3...
22.02.09-15:55:34-453 > Switch to 2-Wire mode
22.02.09-15:55:34-513 > received: $95,$02,$03,$08,$37
22.02.09-15:55:34-533 > Device connected
Beim Asus Netbook bekomme ich die gleiche Sequenz ad infinitum aber kein
Connect, bis ich Abort Connect drücke.
22.02.09-11:55:16-187 > Connecting on port COM3...
22.02.09-11:55:16-265 > Switch to 2-Wire mode
22.02.09-11:55:16-328 > received: $95,$02,$03,$08,$37
22.02.09-11:55:16-390 > received: $95,$02,$03,$08,$37
22.02.09-11:55:16-468 > received: $95,$02,$03,$08,$37
Meine Einstellungen sind:
.equ UseWDR = 1
.equ UseAutobaud = 0 .equ UseVerify = 1 .equ UseE2Write = 1
.equ UseE2Read = 1 .equ UseSRAM = 0 .equ UseCrypt = 1
.equ UseCryptFLASH = 1
.equ UseCryptE2 = 1
.equ UseVersioning = 0 .equ UartInvert = 1
.
.
.set XTAL = 16000000
.set BootDelay = XTAL/4
.set BootBaudrate = 115200
.set BootVersion = 3
.set BootCodeSize = 824
Hi Heinrich,
lade dir mal die neuste Version
Beitrag "Re: AVR-Bootloader mit Verschlüsselung"
Entpacke sie in einen separaten Ordner, wir sind nur an der neuen
PC-Software interessiert.
Im Ordner \Windows\ ist die neuste PC-Software. Setze alle Parameter
deren AVRootloader.ini auf die in deiner aktuellen AVRootloader.ini.
Zusätzlich [Timeouts] Options=3. Der Parameter Debug= der alten Version
ist entfernt worden und befindet sich als Bit in Options.
Nun starte diese neue Version und versuch eine Verbindung zum AVR mit
alten Bootloader.
Wenn das nicht funktioniert versuche sukzessive in [Timeouts] die Werte
für Base und Connect zu erhöhen. Zb. Base=100 und Connect=50 oä.
Bei solchen virtuellen Treiber wie dem FTDI eg. USB-Serialwandler sollte
Base auf minimal 50ms stehen.
Ein weiteres Problemfeld könnte der virtuelle Treiber des FTDIs auf
diesem Notebook sein. Mal reinstallieren.
Achso, und schau mal in die Datei AVRootloader.dev rein und suche nach
9502=, dort muß bei dir dann folgendes stehen
9502=1E9502, ATmega32 , 32768, 1024, 2048, 96, 128, 4, 8, 16, 32
Nur die AVRs in dieser Datei werden erkannt. Man kann also durch die
Editierung dieser Datei bestimmte AVRs ausschließen oder neue AVRs
nachträglich dem Bootloader mitteilen.
Gruß Hagen
Ich sehe gerade du hast UseAutoBaud=0 gesetzt. Es könnte sein das das
Timing des AVR-RS232 und FTDI-RS232 nicht exakt übereinstimmt. Deshalb
normalerweise immer UseAutobaud=1 setzen. Ich weiß nicht wie der FTDI
sein Timing erzeugt, es ist eigentlich unlogisch das das vom USB Host
abhängen sollte, aber vorstellbar ist heutzutage alles.
Andererseits empfängt ja die PC-Software eine gültige Rückmeldung vom
AVR. Ich denke also das mit der neuen PC-Sofwtare und höheren
Timeouts.Base das problem beseitigt sein sollte.
Gruß Hagen
Hallo Hagen,
der Connect geht jetzt mit deiner neuen PC-Version auf beiden Notebooks.
In der INI musste ich nix ändern. Ich werde jetzt noch Testen ob die
neue PC-Version auch mit allen anderen Bootloader Versionenen auf beiden
PC's funktioniert.
Deine Unterstützung ich echt super und das auch noch am Sonntag.
Gruß Heinrich
Alle PC-Bootloader sollten vollständig abwärtskompatibel sein. Nur bei
der neusten Version muß man in der .INI bei [Timeouts] Options=0 oder 2
setzen wenn man mit der alten oder neuen AVRootoader.ASM arbeitet. Dh.
das Bit #1 = 2 muß in Options bei der neusten PC-Software gesetzt sein
wenn man mit dieser eine ältere AVRootloader.ASM verbinden möchte.
Options=0 muß gesetzt sein wenn mit der neuen PC-Software auch mit der
neusten AVRootloader.ASM verbunden werden soll. Der Hintergrund ist eine
Änderung beim Verbinden mit dem Bootloader. In der neusten Version
erwartet der Bootloader nach dem Empfang des BootSigns noch eine 16 Bit
CRC über das zuvor empfangene BootSign. Dies beseitigt ein kleineres
Problem der älteren Versionen und macht den Verbindungsaufbau stabiler
und sicherer (wenn man das BootSign als Passwort betrachtet).
Ansonsten ist jede Version zu 100% abwärtskompatibel, was ich auch als
wichtig erachte wenn man zb. schon fertige Geräte mit älteren
AVRootloader Versionen updaten möchte.
Allerdings, wie du siehst, habe ich einiges an den PC-Softwares
verbessert um den Gesamtprozess der Kommunikation stabiler und auch
performanter zu machen.
Am Kommunikationsprotokoll selber hat sich, bis auf zwei Punkte, rein
garnichts geändert. Die zwei Punkte sind:
1.) neues Kommando 0xFD hinzugekommen. Dies ist nun das offizielle
"KeepAlive" Kommando und im Grunde nur ein Platzhalter. Dh. im
AVRootloader.ASM musste dafür garnichts geändert werden, es wird auf PC
Seite erwartet das der AVR mit 0xC3 = unbekanntes Kommando, antwortet.
Es dient nur dazu den Watchdog Timer im AVR zurückzusetzen. Dieser wird
bei jedem Kommmando zurückgesetzt falls UseWDT=1 gesetzt ist.
2.) bei UseVersioning=1 hat sich der Aufbau des ersten verschlüsselten
Initialisierungs-Blockes verändert. Statt 16 Bytes hat dieser Datenblock
dann 24 Bytes Größe. In den zusätzlichen 8 bytes ist die
Versionsnummernüberprüfung verschlüsselt kodiert. Da die alten
Bootloader Versionen das Versioning nicht unterstützen ist auch hier die
Abwärtskompatibilität sicher gestellt.
Ansonsten ist es eh immer so das nur verschlüsselte ACY Dateien
geupdated werden können die 1 zu 1 zur jeweiligen Bootloaderversion
erzeugt wurden. Dh. PC-Software-Version 3 kann nur ACY erzeugen für
Bootloader Version 3. Eine ACY erstellt mit Version 3 kann nicht auf
AVRs mit Bootloader Version 4 oder 2 installiert werden. Das mag im
ersten Moment eine starke Restriktion darstellen aber hier gilt aus
meiner Sicht die kryptographsiche Sicherheit als Priorität. Wenn
gewünscht kann das aber durchaus verändert werden, so daß die
PC-Software für den Bootloader der aktuell verbunden ist eine
versionerichtige ACY Datei kompiliert. Das aalles gilt aber nur bei
aktivierter Verschlüsselung.
Gruß Hagen
Hallo zusammen,
ich habe den Bootloader erfolgreich auf einem ATTiny25 installiert und
er funktioniert soweit sehr gut. Ich benutze den 1-wire Mode an PB0.
Wenn ich aber PB5 zuschalte (RSTDISBL) dann kann ich keine Verbindung
mehr zum Bootloader herstellen. Ich wollte aber gern PB0 freimachen und
PB5 benutzen. Hat einer eine Ahnung woran das liegen kann? Desweiteren
bekomme ich auch keinen Zugang wenn die Taktfrequenz des Tiny nur 1 MHz
beträgt. Ist das einfach zu wenig für die Baudrate Detektion?
Gruß Rene
Es ist zum Verrücktwerden...
ich kriege es einfach nicht hin.
Habe den atmega128 und probiere es gerade mit dem JTAGmkII es zum laufen
zu bewegen. aber es klappt einfach nicht.
Habe einen ftr232 und da die RX/TX auf den µP gelegt RX->TX TX->RX
in den Dateien die entsprechenden änderungen gemacht, aber es klappt
alles nicht.
UART zwischen PC und µP klappt, aber sobald ich einen Bootloader
reinmachen will, funktioniert es nichtmehr.
Wie muß ich denn die Fusebits im AVR Stuio setzen?
Ich hoffe das mir einer helfen kann...
Gruß
Horst
@Rene
Hast du vor dem Setzen des RSTDISBL Flags, Hagens ASM Datei geändert,
dass PB5 der 1-Wire-Pin ist und vorher auch geflashed?
Habe den Bootloader auf einem ATtiny45 laufen. Benutze aber eine feste
Baudrate von 115200 mit internen 8Mhz.
Ja habe ich, aber auch wenn ich den 1 Wire an PB0 lasse und nur RSTDISBL
setze geht es schon nicht mehr. Das finde ich sehr komisch. Benutzt du
PB5 (Reset) für 1-Wire? Kannst du das mal für mich überprüfen?
Gruß Rene
Ja ich benutze den Resetpin. Um in den Bootloader zu kommen, musst du
erst auf "Connect" gehen, dann die Spannung kurzzeitig unterbrechen. So
gehts bei mir. Wenn das geht, kannst du auch nen Pin-Change-Interrupt
nehmen um aus der Applikation in den Bootloader z.B. per Watchdogreset
zu kommen.
Hmm, genauso mache ich es. Hast du das 1-Wire Interface aus dem Archiv?
Benutzt du einen externen Pullup mit welchem Wert? Fragen über Fragen.
;-)
Gruß Rene
@Rene und allen anderen:
Wenn ihr solche Probleme habt dann postet hier doch bitte
- eure Konfiguration aus AVRootloader.asm, also alle UseXYZ=?, BootSign
usw. Einstellungen
- macht einen Verbindungsversuch mit der PC-Software (Button Connect...)
mit in der AVRootloader.INI eingestellten Option "Debug=1" bzw. bei
neuster Version Optionen=1. Im Protokoll Fenster (Memo) die ganzen
Meldungen hier per Copy&Paste einfügen
- beschreibt eure Hardware, also 1/2-Wire, direkt an RS232 oder an
MAX/FTDI Pegelwandler
- beschreibt welche Fuses ihr gesetzt habt, am Besten so wie sie
AVRStudio benennt, nicht AVRDude oder andere Programme die das wieder
anders handeln
Habe ich diese Infos dann kann ich auch konkreter helfen.
So Rene, wenn du UseUartInvert=1 hast dann musst du einen PullUp nach
VCC vom PB0 legen.
Gruß hagen
Hallo Hagen,
danke für deine ausführlichen infos zu den Versionen und deren
Kompatibilität. Ich bin jetzt aber etwas verwirrt und zwar aus folgendem
Grund:
Ich kann mich mit deinem PC-Bootloader V4.0 vom 10.2.09 trotz Option=0
mit einem AVRootloader welcher mit V2.0 erzeugt wurde verbinden und eine
mit V.2 erzeugte ACY erfolgreich flashen.
>Ich kann mich mit deinem PC-Bootloader V4.0 vom 10.2.09 trotz Option=0>mit einem AVRootloader welcher mit V2.0 erzeugt wurde verbinden und eine>mit V.2 erzeugte ACY erfolgreich flashen.
Ja geht auch beides ;) Aber man sollte bei der V4.0 Version den Connect
Prozess eben auf V3 und drunter einstellen, ist besser. Ohne diese
Änderung gehts auch, aber die FSM im Bootloader kommt durcheinander und
meldet einmalig ErrorCRC für das nächste Kommando das die PC-Software
sendet. Da alle Kommandos der PC-Software beim Fehler ErrorCRC bis zu 6
mal versuchen ihren Befehl auszuführen, gehts auch ohne diese
Einstellung. Dh. bei jeder Aktion der PC-Software gibt es ma. sechs
Versuche wenn ein CRC Fehler aufgetreten ist. Das macht die Sache so
stabil.
Und natürlich kannst du ein ACY, erzeugt mit einer älteren Version,
defakto mit jeder anderen Version auf einen AVR mit der gleichen Version
flashen lassen. Auch das ist so beabsichtigt und habe ich oben auch so
gemeint. Man kann nicht ein ACY mit zb. Version 3 auf einen AVR mit
Version 2 flashen. Man kann nicht mit PC-Software Verson 4 ein ACY für
AVR mit Version zb. 3 erzeugen. Aber ausführen kann jede
PC-Software-Version jede ACY Version.
Man muß da differenzieren zwischen ein ACY erzeugen, quasi kompilieren,
und als Script später auszuführen (Program Button). ACY Dateien sind
also sowas wie binäre Scripte deren Datenblöcke verchlüsselt sein können
und nur von AVRs akzeptiert werden die die gleiche Version wie die des
ACY haben, mit dem gleichen Passwort verschlüsselt wurden und wenn
UseVersioning=1 gesetzt ist muß deren Versionsnummer gleich oder höher
als die des AVRs sein.
Gruß Hagen
Korrektur: Ich habe nochmal in meine ToDo-Liste nachgeschaut und es ist
bei den ACY Files so:
Ab Version 3 kann man für jede beliebige AVR-Bootloader Version ein ACY
kompilieren/erzeugen. Die PC-Software benötgt ja erstmal eine Verbindung
zum Bootloader wenn sie eine ACY Datei erzeugen soll. Sie benutzt also
immer die Optionen und Versionsnummer die auf dem AVR installiert ist.
Man kann also, entgegen meinem vorherigen Statement, ohne
Versionskonflikte/Einschränkungen ACY Dateien erzuegen und ausführen
lassen. Das war aber bis zur Version 2 der PC-Software anders. Sorry für
diese Mißverständnisse aber so langsam bei der gewachsenen Komplexität
kann man auch mal durcheinander kommen ;)
Gruß Hagen
Hey Hagen,
ich habe jetzt nochmal einen Test mit InvertUart=0 und den Tinys
durchgeführt. Ausgangssituation war wieder, keine externe Beschaltung am
1-Wire Pin. Der FTDI wird bei bedarf mit einer Prüfspitze verbunden.
Mit InvertUart=1 ist der Pullup ja deaktiviert und der Tiny kam nicht
ins Hauptprogramm. Mit einem nachträglich Pullup war alles i.O. Ich habe
gedacht, dass bei InvertUart=0 der Widerstand entfallen kann. Nach dem
letzten Test weis ich es nun aber besser ^^ Statt eines Pullups braucht
man dringend einen Pulldown. Lässt man ihn weg, startet der uC wieder
nicht.
Was ich irgendwie nicht ganz verstehe ist, dass du in deinem Schaltplan
den 1-Wire Pin auch nur bei Bedarf über den Steckverbinder C1/C2
anschließt.
Startet denn dein uC bei unbeschalteten 1-Wire-Pin?
Es wäre natürlich cool, dass der uC auch hochfährt, wenn keine
Flankenänderung am Pin bei vorliegt.
Mir fällt noch ein Feature für die Programmiersoftware ein. Es wäre ganz
nützlich, wenn man eine andere Baudrate für das Senden des AppCmd
benutzen könnte als für das Flashen. Arbeite mit fester Bootloaderbaud
von 115200, in der Software aber mit 1,25Mbaud. Muss mir momentan mit
nem PinChangeInterrupt arbeiten, was nicht so praktisch ist. Würde
absolut reichen, wenn die AppBaud in der ini einstellbar wäre. Ist aber
nur ne Idee.
Grüße Mark
Ich benutze 1-wire direkt ohne Pegelwandler (max232 o.ä.) nur einen
Widerstand zwischen RXD und TXD. Wie gesagt benutze ich PB0 - 4 gehts
ohne Probleme. Sowie PB5 (RESET) ins Spiel kommt gehts nicht mehr.
Natürlich habe ich dann mit den neuen Einstellungen geflasht.
Die Fuse stehen so:
http://www.bogenschuetzen-moenchengladbach.de/share/Fuse.gif
Gruß Rene
@Mark:
Du benutzt aber immer den FTDI egal ob UseUartInvert=0 oder 1 ist. Neben
dem PullUp/Down wie du ihn benutzt könnte vielleicht noch die Erhöhung
des 2k7 Widerstandes zwischen RX-TX helfen. Auf alle Fälle benötigt man
bei UseUartInvert=1 einen externen PullUp der natürlich auch
entsprechend den Pegeln des FTDI + 2k7 Widerstandes dimensioniert ist.
Bei UseUartInvert=0 ist das im Grunde auch so, meine Empfehlung basiert
halt eben auf realen RS232 Pegeln von +-15 Volt bzw. +-10V bei USB-RS232
Wandlern.
In diesem Modus wird der Pin auf Weeak/Strong Pullup gewechselt beim
Empfangen und Senden.
Ich schätze mal das es am FDTI und seinen Pegeln liegen wird. An der
Software selber kann man nur noch wenig daran verändern, bzw. ganz
allgmein gesprochen kann man daran wenig was ändern. Das ist bei einer
I2C/1-Wire Software ebenfalls so.
Das mit der unterschiedlichen Baudrate:
Programmierbar ist im Grunde alles, nichts ist unmöglich solange es der
Physik unterliegt ;) Aber konzeptionell wäre es eine größere
Veränderungen in der PC-Software. Sobald das IApplication Objekt ein
IAVRootloader Protokollobjekt erzeugt, hat die Applikation schon ein
ICOM = Kommunikationsobjekt mit entsprechend eingestellter Baudrate
erzeugt. Das IAVRootloader-Protokollobjekt hat dann im späteren Verlauf
keine Zugriffe auf diese Funktionalität, es kann nur die
Senden/Empfangen Funktionen benutzen. Das nennt sich Kapselung in der
OOP und soll eine striktere Hierarchisierung im Source des
Programmierers bewirken und somit logischen Fehlern vorbeugen. Lange
Rede kurzer Sinn: konzeptionell ist dein Wunsch nicht vorgesehen worden
und das bedeutet einen höheren zeitlichen Aufwand für mich. Wenn es dir
nichts ausmacht lege ichs erstmal in die ToDo Liste für die nächste
Version ab ;)
Gruß Hagen
@Rene:
das sieht erstmal gut soweit aus, also da wo es korrekt läuft ;)
Beim 2. Protokoll kann man sehr gut erkennen das der AVR nicht
antwortet.
Es gibt nun einige Vorschläge um das Problem systematisch anzugehen:
1.) setze UseVersioning=0
2.) setze BootMsg auf leer -> BootMsg: ;.db "deine Nachticht", bloß das
Semikolon rein
Ich denke aber das dies nicht das Problem beseitigt.
3.) baue einen PullUp vom Pin nach VCC rein, 10-100K. Es könnte sein das
der Resetpin keinen Pullup verbaut hat oder dieser anders dimenstioniert
ist. Wobei bei meinem ATTiny461,44 und 85 benutze ichz auch immer den
Resetpin für den Bootloader, und das hat bisher immer funktioniert.
Ich meine das könnte am ehesten helfen.
Es muß ja einen Unterschied zwischen PB5 und den anderen Pins geben und
da fällt mir momentan nur der interne Pullup ein.
Wie programierst du eigentlich dann deinen Tiny45 im Nachinhein, per
Highvoltage-Parallel-Programming ? Bedenke das solange das Debugwire am
RESET noch aktiv ist das Verhalten des internen Pullups an PB5 sich
unterscheidet, irgendsowas läutet mir im Hirn gerade rum.
Wenn du aber den RESET als gleichwertigen Pin gefust hast dann sollte
Debugwire und ISP deaktiviert sein. Das bedeutet nur noch Highvoltage
Programming kann den AVR zurücksetzen.
Gruß Hagen
@Hagen
>Du benutzt aber immer den FTDI egal ob UseUartInvert=0 oder 1 ist.
Korrekt :)
>könnte vielleicht noch die Erhöhung des 2k7 Widerstandes zwischen RX-TX >helfe
ehm... also vielleicht haben wir uns irgendwie missverstanden. Solange
der FTDI am Pin angeschlossen ist, funktioniert alles einwandfrei in
allen Modi auch ohne externen Widerstand sei es Pullup oder Pulldown.
Der Punkt ist, dass es nicht funktioniert wenn der FTDI ABGEKLEMMT ist.
Der uC springt dann nach einem Restart nicht vom Bootloader ins
Hauptprogramm (Vgl. in deinem Schaltplan C1/C2 NICHT verbunden).
Hintergrund ist einfach, dass ich einen Pin nicht dauerhaft für das
Programmieren "verschwenden" will.
Grüße
>Der Punkt ist, dass es nicht funktioniert wenn der FTDI ABGEKLEMMT ist.>Der uC springt dann nach einem Restart nicht vom Bootloader ins>Hauptprogramm (Vgl. in deinem Schaltplan C1/C2 NICHT verbunden).
Hm, dann floated der Pin. Aber das sollte nur bei UseUartInvert=1 der
Fall sein und deswegen auch der ext. Pullup.
Wenn die Pegel am Pin stabil sind dann sollte der Bootloader nach
BootDelay Millisekunden, standardmäßig 250ms die Anwendung aufrufen.
Nun kommt es darauf an ob du UseWDT=1 gesetzt hast. Wenn ja muß deine
Anwendung den Watchdog frühzeitig deaktivieren oder ihn selber
periodisch zurück setzen. Er steht auf 2 Sekunden Timeout. Das heist
auch das BootDelay in diesem Fall niemals größer 2 Sekunden gesetzt sein
darf.
Falls du eine LED am AVR hast dann schalte sie doch mal im Bootloader
ein und in deiner Anwednung wieder aus.
Gruß Hagen
Moin Moin,
ja UseWDT ist eingeschaltet und InvertUart=0 und im Hauptprogramm
deaktiviere ich den Watchdog sofort, daran liegts nicht. Auf dem Osi
kann ich sehen, dass der uC nach den 2s neustartet (kurzer Low-Pulse auf
dem 1-Wire-Pin alle 2s).
Also bei den Test fährt der Controller nur hoch, wenn ein Low-Pegel am
1-Wire Pin anliegt, sonst tut sich gar nichts. Kannst du mal gucken, ob
du es nicht tatsächlich so programmiert hast?
Hallo Hagen,
vielen Dank für deine Arbeit mit dem Bootloader.
Ich verwende ihn um einen ATTiny85 im 1-Wire-Modus(ohne Verschlüsselung)
zu flashen.
In meiner Applikation werden sofort nach dem Anlegen der Versorgung
Taktsignale mit 22ms Periode auf den INT0 Eingang gegeben.
Ursprünglich sollte dieser Eingang auch als 1-Wire-Eingang genutzt
werden.
Das hat aber nicht funktioniert - die Applikation wurde nie ausgeführt.
Ich vermute das durch die Taktsignale der Bootloader ständig getriggert
wurde und nie in die Applikation gesprungen ist.
Habe dann einen - in der Applikation - als Ausgang beschalteten Port als
1-Wire-Port benutzt und so funktioniert es auch.
Gruß und schönes Wochenende
bandgap
Solange am Bootloader Pin sich irgendwas tut so lange verbleibt der
Bootloader in der Connect/Autobaud Schleife. Erst wenn für BootDelay
Millisekunden am Pin Ruhe ist springt er die Anwendung an. Das war in
älteren Versionen anders. Dort musste innerhalb von BootDelay
Millisekunden ein gültiger Connect String empfangen werden, ansonsten
sprang er die Applikation an. Nun, je nach Sichtweise verbessert oder
verschlechtert die eine oder andere Lösung das Gesamtverhalten und das
auch noch abhängig von Eurem eigenen HW-Aufbau.
Ich denke nochmal darüber nach und werde wahrscheinlich dieses Verhalten
konfigurierbar im ASM machen. Ansich kein großer Aufwand. Aber zuerst
mal versuche ich das Problem vom Mark C. nachzuvollziehen und zu lösen.
Danach werde ich erstmal dieses Projekt ruhen lassen, mitlerweile hat es
doch einiges an Zeit gekostet.
Gruß Hagen
Version 5.0
Ich hoffe das dies erstmal die letzte Version ist ;)
- das von Mark C. beschriebene Problem ist erstmal beseitigt
- mit UseResetDelay=0 oder 1 stellt man das Timeout Verhalten des
Bootloaders ein. Ist UseResetDelay=1 gesetzt so muß am RX Pin für
BootDelay Millisekunden Ruhe herrschen. Sobald sich am RX Pin was tut
wird der Timeout immer auf BootDelay Millisekunden verlängert.
Ist UseResetDelay=0 so handelt es sich bei BootDelay um ein
Gesamttimeout. Dh. nach spätestens BootDelay Millisekunden ohne
korrekten Verbindungsaufbau wird die programmierte Anwendung gestartet.
- UseSpecialWrite, UseSpecialWriteBoot, UseSpecialRead, UseSpecialMsg
sind neu. Mit ihnen steuert man welche der Spezialfunktionen für den
Zugriff durch die Anwendung eingebunden werden sollen.
UseSpecialWrite=1 bindet die Funkton write_flash(address, size, buffer)
ein. Mit dieser kann man den FLASH aus der Anwendung heraus
programmieren. Dabei muß man aber nich auf irgendwelche
Addressausrichtungen etc.pp. achten. Dh. man kann mit dieser Funktion
zb. 5 Bytes aus dem SRAM an eine FLASH Adresse schreiben ohne das
Pagealigment/boundary der FLASH-Pages beachten zu müssen.
UseSpecialWriteBoot=1 aktiviert die Möglichkeit in den Bootloader FLASH
Bereich schreiben zu können. Abgesichert wird das durch einen Magic Code
und die Lockbits müssen entsprechend gesetzt sein. Ob man das aktiviert
muß jeder selber wissen. Das M162 Test Projekt im Ordner \test\ macht
davon Gebrauch um das Passwort BootKey der Verschlüsselung aus der
Anwendung heraus zu ändern.
UseSpecialRead=1 aktiviert die Funktion read_flash(address, size,
buffer) mit der man einen Speicherbreich des FLASHs in den SRAM lesen
kann. Hilfreich ist dies wenn man per Lockbits der Applikation verbietet
den FLASH auslesen zu können, zb. Bootloader Section.
UseSpecialMsg=1 aktiviert die Funktion um auf die BootMsg: zugreifen zu
können. Also um zb. den Wert in BootMsg = Copyright oder BootInfo in der
eigenen Anwendung anzeigen zu lassen.
Das WinAVR GCC Test projekt für den M162 demonstriert den Zugriff auf
diese Anwendungsbezogenen Funktionen.
Gruß Hagen
Hallo,
ich habe den Bootloader in der Verion3 schon zum Laufen bekommen. Nun
probiere ich gerade an der neusten Verion 5 herum und habe Probleme, die
ich mir nicht erklären kann.
Ich bekomme eine Verbindung zum Bootloader - die wird aber nach ca. 250
ms sofort wieder beendet - warum ist das so?
Inhalt des Protokollfensters:
03.03.09-12:07:40-390 > Connecting on port COM28...
03.03.09-12:07:42-765 > Device connected
03.03.09-12:07:43-000 > Device disconnected
Device Information:
Connection : 2-Wire
Device name : ATtiny45
Device signature : 1E9206
SRAM size : 256 Byte
EEPROM size : 256 Byte
FLASH size : 4096 Byte
FLASH size for application : 3584 Byte
FLASH pagesize : 64 Byte
Bootloader size : 512 Byte
Buffersize for data : 216 Byte
SRAM start address : 96
Bootloader version : 5
Use bootsection : No
Versioning supported : Yes
Cryptography supported : No
Application software version : not defined
Application version address : 0x000DFA
Ich habe bereits versucht dem Problem durch Anpassen der Timeouts
entgegen zu wirken - bisher leider erfolglos. Bisher gelang nur das
Auslesen der Device Information.
Den ATtiny takte ich intern mit 128 kHz - deshalb nutzte ich für den
Bootloader auch nur 1200 Baud.
Hat jemand vielleicht einen Hinweis für mich?
Gruß Peter
Hallo...
hat schon mal jemand den RS485 getestet ?
Habe bei mir am AVR den SN75176 und am PC den Devantec USB-RS485.
Ich sehe das Daten gesendet werden und auch welche zurück kommen (LED's)
nur leider verbindet sie sich nicht.
lg, markus
@Peter:
Hallo,
-hast du sowohl auf dem AVR als auch auf dem PC die neue Version ?
-Aktiviere mal den Debug-Modus des Verbindungsaufbaus (über Timeouts,
Options=1) und poste mal den Connectaufbau.
- welche Option hast du bei UseResetDelay eingestellt ?
- hat der Verbindungsaufbau bei der Version 3 problemlos funktioniert ?
Gruß Stefan
@Stefan R.
Danke für deine Bemühungen. Ich habe in der Zwischenzeit schon weiter
geforscht und meine Befürchtung bestätigt -> es liegt am Watchdog.
Ich poste hier trotzdem nochmal die genauen Protocol-Ausgaben.
1
03.03.09-14:50:45-046 > Connecting on port COM28...
2
03.03.09-14:50:45-046 > Timeout.Connect = 50 ms
3
03.03.09-14:50:45-046 > Timeout.Base = 50 ms
4
03.03.09-14:50:45-046 > Timeout.Erase = 10 ms
5
03.03.09-14:50:45-046 > Timeout.Flash = 25 ms
6
03.03.09-14:50:45-046 > Timeout.Eeprom = 10 ms
7
03.03.09-14:50:45-046 > Timeout.Buffer = 1 ms
8
03.03.09-14:50:45-046 > Timeout.AppCmd = 0 ms
9
03.03.09-14:50:45-046 > Timeout.KeepAlive = 100 ms
Die Timeouts habe ich hier aus Verzweiflung abartig hoch gesetzt. Aber
wie gesagt - nun funktioniert es mit abgeschaltetem Watchdog-Support
(UseWDR=0). Ich hatte bei Version3 keine Probleme mit dem
Watchdog-Support - drum hatte ich diesen als Problemquelle
ausgeschlossen.
Ich werde jetzt weiter beforschen, warum hier der Watchdog-Reset
aufschlägt während der Bootloader läuft.
Übrigens; ich hatte UseResetDelay=1 da ich das für meine Anwendung auch
für sinnvoll gehalten hatte - und wie gesagt; das scheint ja auch nicht
mein Problem gewesen zu sein.
>> Die Timeouts habe ich hier aus Verzweiflung abartig hoch gesetzt. Aber> wie gesagt - nun funktioniert es mit abgeschaltetem Watchdog-Support> (UseWDR=0).
Na immerhin schon mal ein anfang !
> Ich werde jetzt weiter beforschen, warum hier der Watchdog-Reset> aufschlägt während der Bootloader läuft.
Autobaud, Bootdelay, XTal richtig gesetzt ??
> Übrigens; ich hatte UseResetDelay=1 da ich das für meine Anwendung auch> für sinnvoll gehalten hatte - und wie gesagt; das scheint ja auch nicht> mein Problem gewesen zu sein.
Versuch es trotzdem mal mit UseResetDelay=0, man weis ja nie ! :-)
Gruß Stefan
@Peter:
>ich habe den Bootloader in der Verion3 schon zum Laufen bekommen. Nun>probiere ich gerade an der neusten Verion 5 herum und habe Probleme, die>ich mir nicht erklären kann.>Ich bekomme eine Verbindung zum Bootloader - die wird aber nach ca. 250>ms sofort wieder beendet - warum ist das so?
1.) die PC-Software sendet alle Timeouts.KeepAlive Millisekunden ein
KeepAlive Kommand zum AVR Bootloader. Bei dir also alle 250ms. Das
KeepAlive Kommando ist nur ein Platzhalter und der AVR reagiert darauf
mit a) dem Rücksetzen des WDT, b) mit Antwort ERRORCOMMAND, also kein
gültiges Kommando. Wie ich oben schonmal beschrieben habe hat dieses
System zwei Vorteile. Erstens erkennt die PC-Software ob die Verbindung
zum AVR noch lebt und setzt dabei auch noch den interen WDT zurück und
zweites erkennt der AVR beim Ausbleiben dieses Kommandos das die
Verbindung getrennt wurde und lässt den WDT einen RESET durchführen.
2.) alle Anzeichen deuten darauf hin das ein sauberer Connect zum AVR
möglich ist. Probiere nun mal statt einem "manuellen Connnect" gleich
den AVR mit einer Software zu programmieren. Also sofort den "Program"
Button zu klicken statt erst den "Connect" Button. Damit testen wir ob
der AVR, wenn er beschäftigt ist, auch sofort per WDT einen RESET macht.
3.) der Auszug:
03.03.09-14:50:48-453 > send keepalive
03.03.09-14:50:49-453 > Timer released
03.03.09-14:50:49-453 > keepalive failed, terminate connection
zeigt deutlich das der AVR nicht auf das KeepAlive Kommando antwortet,
deine Annahme das der WDT zugeschlagen hat ist also sehr wahrscheinlich.
In Timeouts.KeepAlive hast du 100ms drinnen stehen, ändere das auf 250
oder 500. 100ms düften gehen sollten aber unnötig sein da der WDT auf 2
Sekunden eingestellt sein sollte. Falls nicht so wissen wir schonmal das
er schon früher als 100ms einen Timeout erzeugt.
4.) nun sollten wir mal nachrechnen welche Konsequenzen deine sehr
langsamme Baudrate für das System hat. Ich schätze mal das es damit
zusammenhängt. Dh. der Timeout des WDT ist schneller als die
eigentlichen Kommunikation längerer Kommando-/Datensequenzen bei 1200
Baud. Der WDT wird intern nur beim Warten auf ein Kommando zurückgesetzt
nicht während des Empfanges längerer Datensequenzen. Wir könnten nun
dieses Verhalten verändern indem wir im ASM folgends abändern:
bei putc:
[avr]
; send char
putc: xwdr
de_0
rcall waitf
[/avr]
bei getc:
[avr]
getc: xwdr
get9: rx_1
rjmp getc
[/avr]
und bei main: nun
[avr]
main: ldi paral, SUCCESS
mai1: rcall putc
movw crcl, zerol
; xwdr
rcall getw
[/avr]
das xwdr auskommentieren.
Mit diesen Änderungen setzen wir den WDT nicht bei nur bei jedem
Kommando zurück sondern vor jedem Senden und Empfangen eines Zeichens
über die UART.
Somit gilt der WDT Timeout relativ gesehen zur Baudrate immer für 1
Zeichen über die UART. Beim originalem Source gilt der WDT für eine
komplette Kommandosequenz inklusive allen übertragenen Datenblöcken. Und
das könnte bei 1200 Baud länger als 2 Sekunden dauern.
Ich denke das obige Änderungen dein Problem beseitigen sollten. Deine
Baudrate ist halt sehr langsam eingstellt ;)
Bis zur Version 3 wurde der WDT ganz anders genutzt als ab Version 4. Ab
dieser Version spielt der WDT eine aktiviere Rolle und soll
Verbindungsabrüche erkennen und den AVR zurück setzen und in der
PC-Software die Verbindung automatisch trennen.
Gruß Hagen
@Makrus:
>hat schon mal jemand den RS485 getestet ?
Nein leider noch nicht, du bist also Erster ;) Das ich es bisher noch
nicht slebrr testen könnte hatte ich aber schon oben geschrieben und
darauf hingewiesen.
>Habe bei mir am AVR den SN75176 und am PC den Devantec USB-RS485.>Ich sehe das Daten gesendet werden und auch welche zurück kommen (LED's)>nur leider verbindet sie sich nicht.
Du hast ~RE und DE mit dem DE_PIN am AVR verbunden. Laut Datenblatt
benötigen wir LOW-Pegel wenn wir was empfangen wollen und HIGH Pegel
wenn wir senden wollen. UseRS485Invert=0 setzen. Das Makro "de_1" setzt
dann ~RE und DE auf LOW.
Hast du die Aus/Eingänge A/B richtig herum angeschlossen ?
Nun können wir noch was am Timing des DE Pins verändern. In putc:
[avr]
; send char
putc: xwdr
de_0
rcall waitf
rcall waitf
ldi cnt, 10
...blabla
brne put3
de_1
put5: ret
[/avr]
können wir das "de_0" Makro sukzessive zwischen/hinter "rcall waitf"
verschieben. Vor dem Makro "de_1" können wir ein "rcall waitf" einbauen.
Somit verschieben wir sukzessive die Enablezeiten des RS485 Treibers.
Vieleicht hilft dies ja da zwar das SN75176 sehr kurze Propagationdelay
von par Nanosekunden hat aber der USB-RS485 eventuell ein länderes
Timing benötigt.
Gruß Hagen
Hallo Hagen,
folgende Settings:
UseUartInvert = 0
UseRS485 = 1
wenn ich USERS485Invert = 1 habe dann blinken meine TX und RX leds am
USB-RS485 wandler. Bei 0 blinkt nur die TX led.
RX = PD2
TX = PD3
DE = PD4
~RE und DE sind zusammen am PD4 angeschlossen.
(Nutze damit auch das DMX Protokoll)
habe deine Vorschläge mal ausprobiert, bringt aber keine Änderung.
lg, markus
@Markus:
Als erstes mal in AVRoorloader.ini [Timeouts] Options=1 setzen.
Dann schauen was bei "received data:" drinnen steht und eventl. hier
posten.
Mit den USB Dingern stehe ich so langsam auf Kriegsfuß da deren Treiber
immer so blöde Timingprobleme haben. Ergo: mal [Timeouts] Base=50 bis
100 setzen.
Gruß Hagen
@Markus:
Auf PC-Seite sitzt meine Bootloader Software und greift über einen VCOM
auf den FTDI zu. Der FTDI ist wie konfiguriert ? Müssen irgendwelche
Timings bei dem berücksichtigt werden ? Ich frage weil die RS485 im
AVRootloader nichts anderes wie Halbduplex RS232 ist mit der Erweiterung
das beim Senden einens Zeichens einfach ein Pin seinen Pegel wechselt.
Mehr nicht. Es werden keinen extra Timeouts oder Wartezeiten zwischen
dem Umschalten berücksichtigt noch Irgendwas auf höherer Protokolebene
wie Addressen oder so.
Ich frage mich nämlich ob der FTDI Treiber/HW vollständig transparent
für die PC-Software ihren DE/~RE Pin einstellt.
Gruß Hagen
@Hagen
Also am RX Pin des AVR sehe das Daten kommen (Oszi).
Nur am TX und DE Pin tut sich nix.
Mit einem USB 232TTL wandler geht es wenn ich direkt auf die RX/TX lege.
lg, markus
@Hagen
mit diesen Einstellungen sehe ich Daten auf RX und TX und auf DE. nur
leider kommt kein Connect zustande. Am USB Wandler blinkt auch nur die
TX Led
.equ UseUartInvert = 1
.equ UseRS485 = 1
.equ UseRS485Invert = 0
lg, markus
@Hagen
Hier noch ne Beschreibung.
Automatic Bus Turnaround
The RS485 bus features automatic direction turnaround. Under idle
conditions, where no data is being transmitted or received, the bus will
be in the high impedance listening mode. Any data that arrives on the
RS485 bus will be transmitted via the USB port to the PC. When the PC
transmits data the bus direction immediately turns around to transmit
the data out on the RS485 bus. When the PC stops transmitting data,
there is a 3uS delay to ensure that the final data high gets a firm
drive before setting the bus to idle (listening mode) again.
http://www.robot-electronics.co.uk/htm/usb_rs485_tech.htm
lg, markus
>FT_SetDataCharacteristics(ftHandle, FT_BITS_8, FT_STOP_BITS_2, FT_PARITY_NONE);
Der Bootloader benutzt 1 Stopbit, nicht 2.
>there is a 3uS delay to ensure
Das könnte das Problem sein. Der Bootloader benötigt keine 3µs um vom
Empfangen auf Senden zu schalten. Somit würde der FTDI nach dem Senden
die 3µs warten ohne Empfang und einige Daten verpassen. Man müsste also
im Bootloader ein 3µs Delay einbauen wenn der Bootloader anfängt zu
senden.
Wobei bei einer Baudrate von 115200 sind das in putc am Anfang schon
8.68µs.
Baue mal in getc: folgendes ein
[a]
getc: xwdr
rcall waitf
get5: rx_1
rjmp get5
[/a]
>mit diesen Einstellungen sehe ich Daten auf RX und TX und auf DE. nur>leider kommt kein Connect zustande. Am USB Wandler blinkt auch nur die>TX Led>.equ UseUartInvert = 1>.equ UseRS485 = 1>.equ UseRS485Invert = 0
Protokoll hier posten ;) Ich muß sehen was die PC-Software empfängt für
diese Einstellung. Grundsätzlich sind diese Einstellungen die ich als
korrekt erwartet hätte.
Ach und mit welchem XTAL arbeitet dein AVR ?
Gruß Hagen
Hallo Hagen,
danke für den Hinweis bei putc und getc noch ein xwdr einzufügen.
Das allein hat allerdings noch nich viel geholfen. Ich bekam zwar eine
stabile Verbindung - konnte dann aber FLASH und EEPROM nicht schreiben
(ICOM Error).
Ich habe dann zusätzlich noch den Watchdog-Timer auf 4 Sekunden erhöht.
Jetzt läuft alles wie es soll. Ausgezeichnet!
Schöne Grüße - Peter
>Ich habe dann zusätzlich noch den Watchdog-Timer auf 4 Sekunden erhöht.
Hm, das heist dann aber das die Programmierzeiten durch deinen so
niedrigen CPU_Clock so enorm langsam sind. In meinen EEPROM
Schreibroutinen habe ich das Zurücksetzen des WDT vor jedem
programmierten Byte schon vorgesehen und trotzdem gibts einen Timeout.
Naja, 128Khz, interner Oszillator, Schätzeisen, sind schon ziemlich
extreme Anforderungen für den Bootloader.
Gruß Hagen
Hallo Hagen,
ich hab schon wieder neue Sorgen. Der Bootloader funktioniert soweit
ganz gut - aber ein Verhalten kann ich mir noch nicht erklären;
nach einem Reset (getestet power up und external reset) startet die
Applikation nicht automatisch. Statt dessen scheint der Bootloader
ständig neu durchzustarten (zumindest wenn ich den Watchdog-Support
aktiviere).
Ich kann die Applikation nur starten, wenn ich die Bootloaderverbindung
aufbaue und dann wieder beende.
Ich hab mir jetzt schon Gedanken über das BootDelay gemacht. Aber daran
scheint es nicht zu liegen. Ich bin gerade dabei immer mehr durch den
Assembler-Code durchzusteigen. Trotzdem stelle ich mir jetzt die Frage,
ob mein Problem daher kommt, daß meine RX- und TX- Leitungen mit 10 K
pulled up sind. Kann ich mir aber nicht vorstellen.
Vielleicht ist ja das Problem bekannt - dann würde ich mich mal wieder
über einen Hinweis freuen. Ich werde derweilen mal genauer hinsehen, was
hier passiert ist.
Schöne Grüße - Peter
Das Problem hatte Mark C. auch schon mal. Du musst in deiner Anwendung
den Watchdog entweder selber periodisch zurücksetzen oder ihn
deaktivieren. Falls du WinAVR GCC benutzt dann schaue dir mal das Test
Projekt im ordner \test\ an.
Im AVRootloader.ASM habe ich dazu schon Änderungen eingebaut in der
AutoBaud und BootSign Detection Funktion so das dort immer der BootDelay
Timeout berücksichtigt wird.
Versuche mal UseResetDelay=0 zu setzen. Dann wird das BootDelay als
Timeout über alles benutzt. Dh. selbst wenn der RX Pin floated oder
andersweitig "getaktet" ist wird nach BootDelay Millisekunden die
Anwendung gestartet, falls kein gültiger Connect zustande kam. Das ist
ja der Grund warum man über UseResetDelay=0/1 das Timeout Verhalten des
Bootloaders in der Baudraten/BootSign Detektion verändern kann.
Wird UseResetDelay=1 gesetzt so verlängert sich der Timeout in diesen
beiden Funktionsteilen immer auf BootDelay Millisekunden solange der RX
Pin toggelt, eg. floated.
Beides kann erwünscht sein und hat seine Nachteile je nach Hardware.
PS: nochwas, du bist ja derjeninge mit den 128KHz CPU Takt, shit.
Überprüfe mal was BootDelay für einen Wert bekommt. 128000/4 = 32000 div
2^16 = 0. BootDelay steht bei dir auf 0 und das ist doof. Defakto ist
dein MCU Takt so gering das die Timeout Schleifen im Bootloader nicht
mehr die korrekte Timeoutzeit warten. Hm, muß ich erstmal drüber
nachdenken. Versuche mal BootDelay = 6 zu setzen.
Gruß Hagen
Hallo Hagen,
ich habe natürlich daran gedacht den Watchdog-Timer in meiner
Applikation abzuschalten. Das funktioniert ja auch.
Was sich hinter dem Parameter UseResetDelay verbirgt denke ich auch
verstanden zu haben.
Ja, aber dieses BootDelay... da ist mir noch nicht so ganz klar, wie du
damit den Timeout realisierst. Ich hatte gestern mit BootDelay = XTAL
und BootDelay = XTAL/4 getestet. Heute hab ich dann mal BootDelay = 6
probiert - na das ging natürlich nicht.
Ich hab nun wie gesagt versucht aus deinem Assembler-Code schlau zu
werden. Aber bisher tue ich mich da noch schwer. Vielleicht kannst du
mal ein bisschen beschreiben, wie du den Wert von BootDelay
verarbeitest.
Ich werde dann mal ne Debug-Session starten - vielleicht geht mir dann
ein Licht auf.
Viele Grüße - Peter
In der Baudraten/BootSign Detektion wird ein 24 Bit Wert dekrementiert.
das MSB dieses Wertes ist BootDelay/6. BootDelay/6 deshalb weil ein
Dekrementationschritt samt Abfrage 6 MCU Takte benötigt. Der Bootloader
wartet auf jeden Pegelwechsel am RX Pin und dekrementiert diesen 24 Bit
Wert. Ist er runtergezählt hat der Bootloader annäherend exakt
XTAL/BootDelay Millisekunden gewartet. Wenn also in BootDelay = XTAL/4
drinnen steht dann sind dies 1 Sekunde/4 = 250ms und in BootDelay steht
die Anzahl der Takte für 250ms. Bei der Initialisierung des 24 Bit
Zählers wird nur dessen MSB mit BootDelay/6 gesetzt. /6 weil die Anzahl
der MCU Takte um den 24 Bit Wert zu dekrementieren/abzufragen/RX Pin
abfragen 6 Takte benötigt.
Die Minimale Taktfrequenz in XTAL damit dieser Zähler korrekt für 250ms
arbeitet ist 4*6*2^16=1572864 ~1.6MHz. Also 1572864/4 = 393216 / 6 =
2^16 = 0x010000 und somit ist das MSB des 24 Bit Zählers = 1. Für einen
Timeout von 1 Sekunde sind es 1*6*2^16=393kHz.
Die Timeout Schleifen sind auf Grund ihrer Konstruktion also ungeeignet
für geringe XTAL Frequenzen. Das lässt sich aber abändern:
Gruß Hagen
Kostet 1 Word mehr an Code, dafür ist der Timeout auf 6 Takte exakt und
bei deinem kleinen XTAL besser. Vorher war es nur auf 2^16 Takte exakt.
Gruß Hagen
Hier eine korregierte Version.
Das RS485 Problem vom Markus C. wurde gefixt. Nun funktioniert der
Bootloader verifiziert auch mit RS485 Bussen. Getestet habe ich mit
einen FTDI FT232R an MAX487 -> SN75LBC176 an ATMega162 bis 256kBaud.
Das Problem mit extrem geringen XTAL Werten (siehe oben 128kHz) und den
Timeout Schleifen ist ebenfalls gefixt.
Desweiteren wurden einige Watchdog Reset Aufrufe anders plaziert.
Gruß Hagen
Hallo, Hagen,
erst sage ich besten Dank für deine Arbeit! Dein Bootloader funkzioniert
perfekt.
Nur habe ich festgestellt, dass mit letzte AVRootloader.exe habe ich
mein streng schiffrierte EEPROM aus Mega32 ohne Problem gelesen! Obwohl
schreiben kann ich nicht (natürlich ich habe keine gültige Password
angegeben).
Device Information---------------
Connection : 2-Wire
Device name : ATmega32, ATmega32A
Device signature : 1E9502
SRAM size : 2048 Byte
EEPROM size : 1024 Byte
FLASH size : 32768 Byte
FLASH size for application : 31744 Byte
FLASH pagesize : 128 Byte
Bootloader size : 1024 Byte
Buffersize for data : 1944 Byte
SRAM start address : 96
Bootloader version : 2
Use bootsection : Yes
Versioning supported : No
Cryptography supported : Yes
FLASH data must be encrypted : Yes
EEPROM data must be encrypted : Yes
Protocol------------------------
12.03.09-13:19:19-258 > Connecting on port COM1...
12.03.09-13:19:19-628 > Connecting on port COM4...
12.03.09-13:19:19-929 > Error: no Device found
12.03.09-13:19:26-757 > Connecting on port COM1...
12.03.09-13:19:27-137 > Connecting on port COM4...
12.03.09-13:19:27-307 > Device connected
12.03.09-13:20:00-736 > Reading EEPROM...
12.03.09-13:23:50-751 > Writing EEPROM...
12.03.09-13:23:50-811 > Cmd.SetBuffer.ResCheck(2) Error: Decryption
failed
12.03.09-13:24:13-835 > Reading EEPROM...
Also Reading geht anwandfrei ;-)
Habe Ahnung, dass genau so leicht kann man Flash einlesen.
mfg
Vladimir
Ja das ist richtig und auch Absicht so. Übrigens ist dieses Verhalten
seit Anbeginn im Bootloader so.
Einen kryptographischen Schutz beim Auslesen von Speichern die man per
Konfiguration auslesbar gemacht hat gibt es nicht.
Möchte man das Auslesen der Speicher verhindern so muß per Konfiguration
einfach diese Lesefunktion deaktiviert werden. Der beste
kryptographische Schutz ist es immer noch eine potentiell angreifbare
Funktion erst garnicht zu unterstützen, wo nichts ist kann nichts
geknackt werden.
Der FLASH kann gernerell nur geschrieben werden, ein Auslesen ist als
Funktion nicht vorhanden.
Das ist ua. der Grund für eine separate Verify-Funktion für den FLASH.
Mit dieser kann man ohne eine Lesefunktion zu haben denoch den Inhalt
des FLASHs überprüfen. Kryptographisch gesehen bedeutet dies das nur
Derjenige der das korrekte FLASH File extern besitzt auch die
Möglichkeit hat den aktuellen Inhalt des FALSHs zu überprüfen. Benutzt
man verschlüsselte ACY Dateien ist auch dieses Verify kryptograpisch
sicher für den Herausgeber dieser ACY. Ein Verify mit aktivierter
Verschlüsselung akzeptiert nur verschlüsselte Daten. Wenn also
UseCryptFLASH=1 ist kann nur mit verschlüsselten ACY Dateien ein Verify
gemacht werden.
Ein Auslesen des FLASHs ist im Bootloader nicht vorhanden auch nicht als
Backdoor oder so, egal ob mit oder ohne aktivierter Verschlüsselung.
Möglich wäre es schon das man den Bootloader so umschreibt das man Daten
nur lesen kann wenn vorher eine korrekte Authentifizierung übermittelt
wurde. Dies wäre sogar relativ einfach möglich.
Aber welchen Sinn würde das machen ?
Möchte man das Auslesen des EEPROMs seinen Kunden nicht gestatten dann
wird einfach UseE2Read=0 gesetzt und schon ist diese komplette Funktion
garnicht mehr im Bootloader vorhanden. Nichts Vorhandenes kann nicht
geknackt werden.
Eine Ausnahme ist UseSRAM=1. Diese dient zum "Mini-Debuggen" der
Anwendung. Mit ihr kann man zb. den aktuellen Inhalt des SRAMs, Register
und IO Ports auslesen und auch schreiben. Möchte man sichere
Kryptographie so muß UseSRAM=0 gesetzt werden.
Fazit: bei korrekter Konfiguration sehe ich keinen anderen Weg als den
AVR mit echt fetten Geschützen knacken zu müssen, also mit Reverse
Engineering auf Chip Ebene. Das Bootloader Protokoll und die
unterstützten Funktionen des Bootloader im Zusammenhang mit der
Arbeitsweise der verschlüsselten ACY Dateien, der verwendeten
Verschlüsselung und ihrer kryptographischen Komplexität und benutzten
Passwortlänge, ist aus meiner Sicht kryptographisch wasserdicht und
nicht knackbar mit praktisch vorhandenem Equipment, heutigem Wissenstand
und in praktikabler Zeit.
Aus meiner Sicht ist im Rahmen des Möglichen das kryptograpisch maximal
Machbare gemacht worden.
Bei mathematisch betrachtetem infinitimalem Aufwand ist jede
Verschlüsselung in unendlich kurzer Zeit knackbar.
>Habe Ahnung, dass genau so leicht kann man Flash einlesen.
Diese Vermutung kann ich also klar verneinen, es gibt keine Funktion zum
Lesen des FLASHs.
Gruß Hagen
Selbst solche erweitereten Angriffe wie den Strombedarf des AVRs und
damit der Bootloader Software zu überwachen dürften enormst schwierig
sein. Alle kryptographischen Operationen die zb. den Schlüssel aus dem
FALSH lesen oder ihn später dann im Algorithmus weiterverarbeiten sind
gleich gewichtet im Strombedarf. Dh. an Hand des Strombedarfes ist auf
Grund der symmmetrischen Operationen im XTEA Algorithmus kein Rückschluß
auf den verwendeten Schlüsselinhalt herzustellen. Diese Annahme von mir
ist aber mit Vorsicht zu genießen da ich nicht sicherstellen kann wie
Atmel seine Chips intern konstruiert hat. Es wäre aber schon sehr
fragwürdig das ein Opcode wie xor r1, r2 abhängig vom Inhalt in r1
und/odr r2 unterschiedlich Strombedarf bedeuten würde.
Gruß Hagen
Bei der Konfiguration
UseCrypt=1
UseCryptE2=1
UseE2Write=1
UseE2Read=1
kann man also
1.) nur verschlüsselte Daten in das EEPROM schreiben, nur der
Herausgeber des Modules ist also in der Lange den EEPROM zu schreiben
2.) alle Daten im EEPROM lesen, also auch die Endkunden können den
EEPROM lesen.
Dies dient auch einem ganz speziellem Zweck. Man kann auf sichere Art
die Veränderung der Konfigurationen im EEPROM updaten, der Kunde kann
sie sich auslesen aber eben nicht verändern. Damit dient diese
Funkionalität quasi als indirekte Kommunikationsschnittstelle zwischen
Herausgeber und Kunde.
Über diese Konfiguration hat man also einen kryptographsichen Writeonly
Schutz.
Soll der Kunde diese Daten nicht lesen können dann muß UseE2Read=0
konfiguriert werden. Das sichere Auslesen dieser Daten muß dann vom
Herausgeber über seine eigene Anwendung programmiert werden. Dies ist
dann auch flexibler durchführbar, zb. nur bestimmte Sektionen des
EEPROMs sind auslesbar für den Kunden.
Gruß Hagen
Hallo Hagen,
habe folgendes Problem, Tiny24, 1-wire, nur WDR und UartInvert ein.
Flashen geht, meine App. läuft auch, aber nur wenn der Bootloader
Connect wurde. Wenn der Loader ohne Connect verlassen wird, (wird er
auch und WDR wird auch abgeschaltet) hängt mein App. sich auf.
Es sieht so aus, als wenn er keine Interrups mehr ausführt, als wenn
noch ein Flag an ist. Bevor ich alles zerrlege, hast Dueine Idee?
Gruß Willi
Das Problem gab es hier schon mehrmals. Du brauchst extern einen
Pullup/Pulldown widerstand, wenn du den Programmierstecker nicht die
ganze Zeit am Pin anliegen hast. Für UartInvert=1 brauchst du einen
Pullup für UartInvert=0 einen Pulldown. Oder du passt diese neue
BootDelay-Funktion an.
Hoffe ich hab es richtig rum im Gedächtnis gehabt.
Bei UartInvert=1 und 1-Wire benötigst du einen externen Pullup. Ist im
Schematik auch zu sehen. Setze auch noch UseResetDelay=0.
Ansonsten ist es schwierig zu beurteilen wo das Problem liegt. Ich
könnte auf deinen Source mal einen Blick werfen, vielleicht liegts nur
an einem kitzekleinem Detail. Schicke ihn mir bitte per PN.
Ich habe nämlich gerade am Connect-Timeout usw. in den letzten Versionen
stark gearbeitet, da sollte es keinerlei Probleme mehr mit geben.
Übliche Verdächtige:
- Brownout nicht aktiviert
- VCC schlecht
- WDT nicht ordentlich deaktiviert oder benutzt
- SEI Aufruf vergessen
- ISRs nicht korrekt (Register sichern, wiederherstellen)
- extrem geringe Taktfrequenz
Gruß Hagen
Guten Morgen,
Hallo Mark, Hallo Hagen,
ich habe nicht das Problem mit dem PullUp bei UartInv=1 (PullUp ist
vorhanden). Der Bootloader wird ja auch nach 0,3 sek verlassen (hab
extra einen Pin in meiner App. gesetzt) dann sieht es so aus, als wenn
kein Interrups mehr ausgeführt werden. Mein Code ist folgender:
[[http://www.mikrocontroller.net/attachment/47695/DCC_Lockdecoder.zip]]
die Version
mit Tiny24 ohne Programierung.inc (ist sonst zu groß). Komisch ist nur,
das wenn der Bootloder 1x Connect und gleich wieder verlassen wird,
läuft meine App.. War gestern schon sehr spät, muß ich heute Abend
schaun, wo er hängen bleibt.
Bei dieser Gelegenheit gleich noch eine Frage: ich will den Loader für
meinen DCC Lokdecoder benutzen, hier kann er aber nur explizit aus
meiner Software aufgerufen werden ( weil der Lokdecoder ja ständig
keinen Kontakt zur Schiene hat und somit immer wieder einen PowerOnReset
bzw BrownOutReset macht) und da sind 0,3 sec Verzögerung nicht drinn.
Das würde ja mit Deinem Loader und Mode 4 "nur aus App starten" kein
Problem sein. Dann muß ich aber das erste mal meine App. und den Loader
in einem HEX zusammenfassen und in den Flash schreiben, sonst hab ich
ein "Henne-Ei" Problem. Hast Du hier noch einen Tip für mich?
Gruß Willi
>in einem HEX zusammenfassen und in den Flash schreiben, sonst hab ich>ein "Henne-Ei" Problem. Hast Du hier noch einen Tip für mich?
Nein hast du nicht das habe ich schon berücksichtigt ;)
Also du hast nur den Bootloader das erste mal geflasht. Alle Bytes im
FLASH vor dem Bootloader sind somit 0xFF. Der Bootloader reagiert nur
wenn in MCUCSR = 0x00 drinnen steht. Der Bootloader benutzt UseWDT=1.
Der AVR wird eingeschaltet und MCUCSR <> 0. Bootloader initialsiert WDT
und dabei wird MCUCSR = 0 gesetzt. Bootloader möchte Anwendung aufrufen
springt aber an eine Stelle im FLASH die mit 0xFF gefüllt ist,
genaugenommen springt er bei ATTinys an BootStart -2 und dort steht
0xFFFF statt einem RJMP MainApp. 0xFF ist so wie der NOP Code, ergo
läuft die MCU wieder in den Bootloader Code rein. Da nun aber MCUCSR = 0
ist bedeutet dies das der Bootloader aus der "Anwendung" heraus
aufgerufen wurde.
Ergo: im Bootmode=4 und UseWDT=1 wird der Bootloader auch aufgerufen
wenn keine Anwendung im FLASH installiert wurde. Und zwar beim zweiten
Aufruf des Bootoaders nach einem RESET, PowerUp, Brownout, WDT Reset.
Denoch erachte ich diese BootMode=4 als "gefährlich". Warum nicht auf
den WatchDog triggern ? Ist viel eleganter.
Denn wenn BootMode=4 und UseWDT=0 ist dann wird der Bootloader
tatsächlich nur durch eine Anwednung aufrufbar sein, es sei denn man
ändert AVRootloader.asm so ab das das MCUCSR Register gelöscht wird.
Benutzt du aber den WDT mit UseWDT=1 und BootMode=3 ist das wesentlich
cleverer. Du hast erstens ein wesentlich stabileres Verhalten des
Bootloader und deiner Anwednung auf unvorhersehbare Ereignisse. Zweitens
kannst du den Botloader per RJMP oder per WDT Timeout starten. Startest
du per WDT Timeout wird ein "echter" RESET des AVRs gemacht und somit
sind alle Register/Ports etcpp. immer korrekt initialisiert. Das könnte
auch dein Problem im aktuellen Projekt sein. Du rufst den Bootloader per
RJMP auf hast aber vorher schon bestimmte Einstellungen wie Timer etcpp.
getroffen. In deiner Main() deiner Anwednung verlässt du dich nun darauf
das alle Register und Ports wie nach einem RESET initialisiert wurden,
und initialsiierst sie demzufolge nicht explizit neu. Der Bootloader
kehrt selber per RJMP zu Main() zurück und somit übernimmmt dein Code
eine teilweise initialisierte Hardware vom vorherigen Aufruf der Main()
weil du den Bootlaoder per RJMP aufgerufen hast.
Ich empfehle immer den WDT zu benutzen, sowohl im Bootloader per
UseWDT=1 wie auch in der Anwendung beim Aufrufen des Bootloaders. In
deiner Anwednung elber kannst du den WDT ja deaktivieren, musst du sogar
wenn du ihn nicht für deine App benutzen möchtest.
Gruß Hagen
Vergessen: drittens könnte es theroretisch zu dem Fall kommen das der
Bootloader beim Programmieren einer neuen Anwendung Scheiße baut. Diese
halb geflashte Anwendung könnte somit später aufgerufen werden. Sie
läuft dann ab einem gewissen Punkt in den unprogrammierten FLASH rein
und somit am Ende in den Bootloader. Bei BootMode=4 und UseDT=0 und ohne
Zurücksetzen des MCUCSR Registers würde der AVR quasi tot geflasht sein.
Mit UseWDT=1 aber würde eine "fehlerhafte" Anwendung quasi nicht
reagieren und der durch den Bootloader programmierte Watchdog würde
spätestens nach 2 Sekunden einen RESET erzwingen der schlußendlich den
Bootloader aufruft. AVR nicht tot geflasht und der Bootloader
interagiert für die Anwednung als Failsave ;)
Gruß Hagen
Ich habe mal kurz den DCC Source angeschaut. Variable BitZaehler und
einige andere werden in Main nicht initialisiert. Diese Variablen werden
in den ISR mit Daten gefüllt aus denen später das DCC Kommando dekodiert
wird. Sind sie aber nicht initialisiert und mit Daten des vorherigen
Runs der Applikation gefüllt funktioniert der Code nicht mehr sauber.
Dh. der Code erwartet im Grunde das er aus einem RESET mit definierten
Startbedingungen heraus aufgerufen wird. Wurde der Bootloader aber per
RJMP aufgerufen so springt dieser selber per RJMP Main wieder in die
Anwendung. Der Bootloader sleber läuft korrekt da er jede Hardware die
er für sich benötigt initialisiert und ansonsten ohne ISRs oder andere
HW lauffähig ist. Das gilt dann aber nicht mehr für den DCC Dekoder.
Würdest du den Bootloader per WDT Timeout starten so wird ein RESET des
AVRs ausgelösst und dann der Bootloader gestartet. Dieser wiederum ruft
dann per RJMP Main den DCC Dekoder auf und dieser hat einen vollständig
neu initialsierten AVR vor sich.
Ändert aber nichts an der Sache das du die uninitialiserten Variablen
des DCC dekoders trotzdem im Main() korrekt initialisieren musst. Denn
diese vaiablen liegen in Register oder dem SRAM der ja durch den
Bootloader Code ebenfalls modifiziert wird.
Gruß Hagen
Hallo Hagen,
ich habe leider ein Probelm mit deinem Bootloader. Ich verwende einen
AtMega16 und einen FTDI 232 BM und kann keine Verbindung aufbauen um die
Software einzuspielen.
Das angepasste AssemblerFile ist im Anhang.
Der letzte Versuch war auch schon mit 9600 Baud fix eingestellt und
brachte auch keinen Erfolg.
Danke vielmals
Michael
Hallo Hagen,
ersteinmal Danke für die vielen und vor allem schnellen Tips!
Das mit meiner nicht initialisierten Variablen überprüf ich gleich
einmal, momentan hab ich den Bootloader aber noch mit WDT getestet! Die
Geschichte wie das in dem fertigen Projekt aussehen kann, darüber habe
ich mir bis jetzt nur ein paar Gedanken gemacht, aber nach Deinen
Erläuterungen, denke ich, das ich es dann über den WDT mache, ich würde
den dann in Abhängigkeit einer Variablen ein/ausschalten und somit die
Programmierfunktion im normalen Betrieb deaktivieren, das mit dem
durchlaufen des leeren Flash ist natürlich richtig daran habe ich nicht
gedacht.
Gruß willi
Ich nocheinmal,
die Variabelen werden alle Initialisiert, Bitzaehler wird vor jedem
gebrauch in der DCC Schleife gelöscht, ich habe die Variablen, welche eh
immer wieder vor gebrauch erst neu gesetzt werden im main nicht
nocheinmal gesetzt.
Aber schauen wir mal, das findet sich schon.
willi
@Michael:
>ich habe leider ein Probelm mit deinem Bootloader. Ich verwende einen>AtMega16 und einen FTDI 232 BM und kann keine Verbindung aufbauen um die>Software einzuspielen.>Das angepasste AssemblerFile ist im Anhang.
Welcher Anhang ?
Hast du UseUartInvert=1 gesetzt, wie im ASM gefordert wenn man einen
Pegelwandler wie den MAX oder FTDI benutzt ?
Gruß Hagen
Oh, sorry, hab ich vergessen, denn Anhang mit hochzuladen... Aber
jetzt...
Ja habe ich, bei meinem letzten Versuch habe ich die automatische
Baudrate deaktiviert und eine fixe Baudrate von 9600 eingestellt, hat
aber leider auch nicht funktioniert.
Danke
@Michael:
ich fasse also mal zusammen:
- ATMega16
- 8 Mhz Takt, entsprechend Fuses gesetzt, zb. CHKDIV8 ist nicht gesetzt
- FTDI Pegelwandler
- RX,TX liegt auf PORTD an PD0/PD1 und wurde am FTDI korrekt verbunden
- UseAutoBaud=1 wieder setzen, das korregiert evntl. Fehler beim XTAL
etcpp.
- UseSRAM=1 ist im Zusammenhang mit UseCrypt=1, UseCryptFLASH=1 ein
Sicherheitsrisiko, spielt zwar nichts zur Sache aber denoch wichtig zu
bemerken
- BOOTRST Fuse wurde gesetzt
- Boot Section Fuses wurde auf 1024 Bytes = 512 Words gesetzt
- in AVRootloader.exe auf dem PC wurde "BOOTLOADER" als BootSign
augewählt
- in AVRootloader.ini [Timeouts] Options =1 setzen und schauen was im
Protokollfenster als "received:" angezeigt wird. Den Inhalt des
Protokollfensters hier posten, nachdem du den Connect Button gedrückt
hast.
- auf dem PC wurde alles soweit vorbereitet das über den virtuellen COM
Port der FTDI erreichbar ist, eventl. noch mal testen ob das alles geht.
Dazu am FTDI den RX-TX Pin brücken und per PC-Software einen Connect
versuchen, sollte dann 1-Wire Modus erkennen und das empfangen was
gesendet wurde.
Falls du ein Oszi hast wird es Zeit es zu befeuern und mal zu schauen
was am RX Pin des AVRs ankommt.
Gruß Hagen
Hallo Hagen,
so, Fehler gefunden, lag bei mir. Mein Code+Bootloader war zu groß für
den Tiny24 und beim zusammenkürzen war dann doch ein Register nicht mehr
ordentlich initialisiert.
Habe jetzt folgenden Stand: Bootloader mit UseBootMode = 3, UseWDR = 1,
UseUartInvert = 1, RX=TX Port, feste Bautrate im AVR. App. läßt sich
problemlos laden und läuft auch. Aber der Bootloader wird immer
aufgerufen (bei Mode=3 sollte das aber nur nach einem WDT Reset
geschehen), wenn kein "Connect" wartet er "BootDelay" ab und startet
dann meine App.. Das sollte er eigentlich nicht. Er sollte nur gestartet
werden, wenn ich in meiner App. einen WDT Reset erzeuge (so wie Du oben
gezeigt hast). Nocheinmal zusammengefasst, momemtan schalte ich den WDT
sofort in meiner App. aus, das bedeutet, Der Loader solte eigentlich nur
beim leeren Flash aufgerufen werden, sobald meine App. im Flash ist gibt
es keinen WDT Reset mehr und somit sollte der Bootloader bei Mode = 3
immer sofort übersprungen werden, macht er aber nicht, er wartet immer
"BootDelay" ab und startet erst dann meine App..
Hast Du hier noch ein Tip für mich?
Gruß Willi
Habs gerade nochmal getestet und bei mir funktioniert das einwandfrei,
ATMega162.
Erklärung könnte sein das deine Anwendung irgendwie in den Bootloader
reinläuft.
Kannst du mal eine Minimal Anwendung bauen in der eine LED an einem Pin
ausgeschaltet wird. Im AVRootloader.asm lässt du diese LED dann leuchten
und zwar nach der Abfrage des UseBootMode und vor der Initialisierung
der Ports.
Wenn jetzt der Bootloader durchstartet beginnt diese LED zu leuchten.
Ohne die Minimal-App leuchtet sie also dauerhaft. Sobald die App
geflasht wurde leuchtet die LED nicht mehr. Die App sollte einen Pin
abfragen der extern auf LOW gezogen wird wenn der Bootloader gestartet
werden soll. Sie benutzt dann den WDT um den Boootloader zu starten. Du
kannst jetzt einen externen RESET, PowerUp usw. machen die LED darf
nicht leuchten. Erst wenn der Pin auf Low gezogen wird sollte sie für
BootDelay Millisekunden leuchten.
Gruß Hagen
Hallo Hagen,
danke für deine Antwort, ich habe die Einstellungen getroffen, leider
hilft dies nicht.
Ja ich habe schon mit dem Oszi gemessen, am RX Pin liegen die Pakete an,
jedoch sendet der uC nichts zurück. Die Kommunikation funktioniert
zwischen Pc und uC mit der "richtigen" Software, nur leider kann ich
keine Verbindung für ein Bootloaderupdate aufbauen.
Reicht es eigentlich nur den Bootloader in den AtMega zu laden und
anschließend das "richtige" Hex File mittels deinem Programm zu laden.
Oder muss von Beginn an das "richtige" Hex File mit kompiliert werden?
Danke schonmal für deine Antwort.
Michael
Hallo Michael
> Die Kommunikation funktioniert> zwischen Pc und uC mit der "richtigen" Software, nur leider kann ich> keine Verbindung für ein Bootloaderupdate aufbauen.
Wenn das funktioniert muß es auch mit Bootloader gehen. Ist also ein
Fehler in den Einstellungen. Mach mal folgendes:(wie Hagen oben schon
gesagt hat)
- in AVRootloader.ini [Timeouts] Options =1 setzen und schauen was im
Protokollfenster als "received:" angezeigt wird. Den Inhalt des
Protokollfensters hier posten, nachdem du den Connect Button gedrückt
hast.
> Reicht es eigentlich nur den Bootloader in den AtMega zu laden und> anschließend das "richtige" Hex File mittels deinem Programm zu laden.
Ja !
> Oder muss von Beginn an das "richtige" Hex File mit kompiliert werden?
Auf keinen Fall !
Gruß Stefan
Hallo Hagen,
Hallo Stefan,
ich habe die ini- Datei geändert und das Protokoll gespeichert befindet
sich im Anhang, bei diesem Versuch habe ich das asm- File mit euren
Tipps aktualisiert.
Welche Einstellung kann ich mit "UseBootVector" treffen?
Danke im Voraus
Michael
UseBootVector=1 speichert ganz am Ende des FLASH einen Sprung zu
BootStart. Da diese Address fix ist ist es nun ein leichtes einen
universellen Aufruf des Bootloaders aus der Applikation durchzuführen.
Wenn du den Bootloader aus deiner Anwendung heraus aufrufen möchtest
dann kannst du dies über einen Sprung über diesen Vektor oder per
Watchdog Timeout. Ich empfehle per WDT.
Schau dir das Test-Projekt im Ordner \test\ an, das sollte eigentlich
alles demonstrieren.
RESET per Pullup nach VCC und Taster an GND, ist schon richtig wie du
das machst.
Zurück zum eigentlichen Problem. Gehe mit dem Oszi an den TX Pin des
AVRs und schaue ob der AVR sendet. Oder setze UseRS485=1 und definiere
einen freien Pin bei DE_PORT und DE_PIN. Dieser Pin geht High wenn der
Bootloader sendet und Low wenn er empfängt. Falls du schon eine LED auf
deinem Board hast dann benutze deren Pin & Port für DE_PIN & DE_PORT. Du
solltest dann ein Blinken sehen wenn der AVR sendet, geringe Baudrate
dann aber einstellen.
Ich denke du hast irgendwas nicht korrekt konfiguriert oder mit deiner
HW stimmt was nicht.
An und für sich ist es eigentlich ganz simpel den Bootloader zum Laufen
zu bekommen. Ich weiß nicht wie einfacher ich noch alles bauen soll ;)
Wie hast du den AVR angeschlossen ? Erkläre mal deine Hardware.
Achso: in deinem Protokoll antwortet der AVR nicht. Trenne deinen FTDI
vom AVR und verbinde dessen RX-TX Leitung per Brücke. Versuche dann
erneut einen Connect über die PC-Software und sage mir was du im
Protokollfenster siehst.
Gruß Hagen
Hallo Hagen,
ich habe Rx und Tx miteinander verbunden und das Protokoll in den Anhang
gehängt.
Die Hardware funktioniert bestimmt, den Fehler können wir ausschließen,
denn der uC redet aktuell mit Matlab und bekommt davon wieder Befehle
zurück.
Danke
Michael
Juhu, es klappt, frag mich nicht wieso?
Ich debugge und gebe einen externen Reset und drücke anschließend im
Debugger Start ist die Verbindung da.
Werde es noch mal analysieren und dir dann bescheid geben.
Danke vielmals für deine Bemühungen und für diesen spitzen Bootloader
Michael
Hallo Hagen,
habe mein Problem mit dem Start des Bootloaders gefunden, der Loader
startet in Mode 3 auch bei einem Brown_Out_Reset. Kannst es ja Bitte
einmal überprüfen, ich habe folgenden Code in den T24 geladen:
Main:
MCUSR_ausgeben:
ldi w,0b11111111
out DDRA,w
pop w ; MCUSR holen (im Loader
gesichert)
rol w ; LEDs sind an A1 bis A5
(nichtA0-)
out PORTA,w
WDT_off: ; WDR ausschalten
(nachBootloader9
WDR
; Clear WDRF in MCUSR
; ldi w, (0<<WDRF)
; out MCUSR, w
; Write logical one to WDCE and
WDE
; Keep old prescaler setting to
prevent unintentional Watchdog Reset
; in w, WDTCSR
; ori w, (1<<WDCE)|(1<<WDE)
; out WDTCSR, w
; Turn off WDT
; ldi w, (0<<WDE)
; out WDTCSR, w
port_tog:
cbi Porta,5
nop
nop
sbi Porta,5
rjmp PC-4
LED 1-4 zeigen dann den MCU Status an. LED 5 toggelt wenn er fertig ist.
Folgendes verhalten:
1. ext Reset erzeugt -> Loader wird sofort verlassen, ist richtig
2. Brown_OUT_Reset -> Loader wird angesprungen, ist falsch
3. WDR_Reset erzeugt -> Loader wird angesprungen, ist Richtig
Danke Willi
Da es einige AVRs gibt die noch andere Reset Quellen haben als obige,
zb. USB-AVRs haben noch USBRF oder es gibt noch den JTAG-Reset JTRF oder
OCDRF = Onchip Debug Reset.
Allerdings baut die letzte Methode darauf das undefinierte Bits im
MCUCSR auf 0 stehen.
Gruß Hagen
Ich habe das einmal so abgeändert, kannst ja einmal schauen, ob das mit
dem rest von Deinem Code passt:
.if UseBootMode != 0
andi paral, (1 << WDRF) | (1 << BORF) | (1 << EXTRF) | (1 << PORF)
breq bm1
.ifdef BootModeFlag
sbrs paral,BootModeFlag
.endif
Jetzt wird Brown_OUT nur noch bei Mode 0 mit berücksichtigt. Mein Mode 3
läuft so auch.
Willi
welches Letzte ? Hast du mal das neue ZIP getestet ? Sollte eigentlich
funktionieren, es sei denn es ist tatsächlich so das undefiniert Bits im
MCUCSR auf 1 stehen.
Gruß Hagen
Ja das meine ich, es reicht schon das wie vorgeschlagen zu ersetzen:
"ändere es so ab:.if UseBootMode
.ifdef BootModeFlag
sbrc paral, BootModeFlag
.endif
cpse paral, zerol
jmpapp
.endif ; .if UseBootMode"
Eigentlich sind nur die Vier Bits wie oben im MCUSR vorhanden, aber wer
weiß was die nicht benutzten so machen. Das mit dem BORF geht doch auch.
Guten Morgen Willi
> Guten Morgen Willi
jo man sollte am Sonntag Abend nicht an 4 Projekten gleichzeitig basteln
(Fernsehen im Hintergrund, Unterhaltung mit Freundin, Arbeit am
Bootloader und meine DSSS Simulation). Habs wieder geändert auf deine
Version, hat den Vorteil das es Bulletproof ist und wenn man auf den
Spezial-AVRs deren Resetquellen benutzen möchte ist die Änderung im
Source trivial. Dachte halt im Übereifer das man noch par Bytes Code
einsparen könnte, falsch gedacht.
Gruß Hagen
>Eigentlich sind nur die Vier Bits wie oben im MCUSR vorhanden, aber wer>weiß was die nicht benutzten so machen. Das mit dem BORF geht doch auch.
Atmel ;) Aber der Source im letzten ZIP maskiert nur die bekannten Bits
aus, alle unbekanten werden auf 0 ausmaskiert. Somit ist das jetzt
sauber, aber das mit dem tst paral denke ich hätte auch funktioniert.
Der Unterschied ist eben das mit dem andi paral, (1 << WDRF) | (1 <<
EXTRF) | (1 << PORF) | (1 << BORF) wirklich nur auf diese Resetquellen
getriggert wird. Dh. im Klartext, lösst auf einem USB-AVR der USB Reset
aus so wird der Bootloader durch einen solchen Reset gestartet u.u.A.
einem direkten RJMP. Bei der Methode mit tst paral wird der Bootloader
aber durch einen USB-Reset nicht gestartet. Möchte man dieses Verhalten
erreichen so muß jetzt der Source manuell geändert werden und in die
andi Maskierung noch (1 << USBRF) hinzugefügt werden, gleiches gilt für
JTRF und OCDRF, die auch noch überschneidend definiert sind.
Andererseits gibts im MCUCSR noch ungenutzte Bits und die könnten da sie
undefiniert sind auch auf 1 stehen. Ohne Ausmaskierung dieser Bits würde
der Code dann auch nicht mehr das machen was er sollte.
Lange Rede kurzer Sinn: solche Fragen, nach der universellsten Lösung,
beschäftigen einen Programierer der ein Projekt pflegt das auf möglichst
allen AVRs laufen soll.
Gruß Hagen
Hi Hagen,
erstmal danke für die saubere Arbeit!
Habe festgestellt, dass die Implementierung des Bootloaders per ISP mit
dem neuen AVR-Studio (4.16) nicht mehr funktioniert (mega644P).
Ist dir das auch schon aufgefallen?
Mit 4.15 (letzte Version) gibt's keine Probleme.
[OT]
Übrigens scheint's den mega644 bei Reichelt nicht mehr zu geben, habe
unter dessen Bestellnummer den mega644P geliefert bekommen.
[/OT]
Version 6.0
Das von Thilo angesprochene Problem ist ein Fehler im neusten AVRStudio
4.16. Alle ASM Files die nicht bei .org 0 anfangen werden durch die
Programmiersoftware des AVRStudio nicht korrekt aus dem HEX File
ausgelesen. Soweit meine Vermutung zu diesem Problem.
In der AVRootloader aus dem Attachment habe ich mit einem kleinen Fix
dieses Problem behoben (AVRootloader.inc). Es werden einfach zwei Bytes
0xFF an Addresse 0 des FLASHs geschrieben. Beruhigend zu wissen das
nicht nur mir solche dämlichen Fehler unterlaufen ;)
Dies ist aber nicht der Grund gleich eine komplett neue Version zu
bauen. Es wurden einige Umbauten am Source getätigt mit Sicht auf den
XMega.
Das Problem mit dem UseBootMode und den verschienden Reset Sourcen der
unterschiedlichen AVRs wurde vollständig gelösst. Neu ist das man mit
UseBootMode=4 nun auch auf einen USB Reset bei USB AVRs triggern kann.
Zu beachten ist aber das einige dieser AVRs und deren Includes in \AVR
Assembler2\ nicht vollständig, eg. korrrekt definiert sind. Ein weiterer
Fehler im neuen AVR Studio den ich entdecken durfte.
Falls also beim Kompilieren von AVRootloader.asm für USB AVRs eine
Meldung kommt das USBRF nicht definiert wäre so sollte man erstmal das
entsprechende Include von Atmel mit dessen Datenblättern vergleichen und
eventuell das Flag USBRF von Hand deklarieren.
Desweiteren wurde natürlich die AVRootloader.dev Datei und das ASM um
alle neu im AVRStudio 4.16 hinzugekommenen AVRs aktualisiert.
Die Reihenfolge der einzelnen Codebestandteile des Bootloader wurde
geändert. Der eigentiche Bootloader Code beginnt bei BootStart und endet
nach BootKey.
Die kompletten Funktionen aus Special.inc samt der RJMP Vektortabelle
bei FLASHEND wurde an das Ende des FLASHs verschoben. Neu zu diesen
Funktionen ist die Funktion "dospm" verschoben wurden.
Dies alles dient zur Vorbereitung der Möglichkeit den Bootloader selber
updaten zu können. Im Minimalfall setzt man UseSpecialBootVect=1. In
diesem Moment wird in den letzten 16 Bytes des FLASHs die dospm Funktion
und eine 2 Entry Sprungtabelle kompiliert. Über die so eingebaute
"dospm" Funktion kann die Anwendung den SPM Opcode ausführen und über
diesen den Bootloader selber updaten. Natürlich müssen die Lockbits
entsprechend so gesetzt sein das die Bootsection per SPM geschrieben
werden darf.
Bei dieser Konfiguraton verbraucht man den geringsten FLASH und hat
denoch alle Möglichkeiten offen.
Oder man bindet die komfortableren Funktionen writeflash und readflash
mit ein. Sollte per Fuses das Lesen der Bootloader Section per LPM
deaktiviert worden sein so muß readflash sowieso mit eingelinkt werden.
Dazu UseSpecialRead=1 setzen. Mit der Funktion write_flash(),
UseSpecialWrite=1 und UseSpecialWriteBoot=1 hat man eine wesentlch
komfortablere Methode um den FLASH zu schreiben. Einfach x Bytes im SRAM
puffern und per write_flash() an die Zieladdresse schreiben lassen.
Diese Funktion kümmert sich dann autom. um das Page Aligment/Boundary,
IRQs und EEPROM Writes usw.
Geht man über die einfachere "dospm" Funktion muß man sich natürlich um
alles selber kümmern, spart aber bischen was an FLASH. Auf ATTinys ist
das alles natürlich unnötig da dort der SPM immer ausführbar ist
(SELFPRG Fuse).
Gruß Hagen
Hallo Hagen,
wirklich toller Bootloader den du programmiert hast.
Mir ist dennoch eine Kleinigkeit im Windows-Programm, zum Flashen der
Firmware, aufgefallen. Sobald man im EEPROM-Editor die Zeichen etwas
schneller tippt, scheint dieses einzufrieren. Dann lassen sich keine
Zeichen mehr bearbeitet.
Abhilfe schafft dann, die Verbindung zum Gerät zu unterbrechen und
anschließend wieder aufzubauen. Danach ist das EEPROM-Editor-Fenster
wieder bedienbar.
Weiterhin noch viel Erfolg mit dem großartigen Projekt "Bootloader"
Micha
@Micha,
konnte dein Problem nicht reproduzieren. Ich vermute du hast 1. die
Baudrate sehr gering eingestellt und 2. in AVRootloader.ini [Timeouts]
KeepAlive sehr klein eingestellt. Der Wert in KeepAlive sollte zwischen
250 bis 1000 ms betragen. Er bedeutet das alle KeepAlive Millisekunden
die Software im Hintergrund ein Packet an den AVR sendet. Wenn man also
verbunden ist entsteht so eine periodische Hintergrund Aktivität die je
nach Baudrate schnell oder langsam abgearbeitet wird. Falls du in deinem
AVR Bootloader UseWDT=0 gesetzt hast dann kannst du KeepAlive auch
weitaus höher setzen. Sollte UseWDT=1 sein so sollte KeepAlive nicht
1000 ms überscheiten da ja der WDT im AVR spätestens all 2 Sekunden
zurückgesetzt werden muß.
Gruß Hagen
@Hagen
Danke für deine Tests und die ausführliche Antwort. Ich betreibe den
Bootloader tatsächlich mit einer sehr geringen Baudrate von 1200Baud/s.
Der KeepAlive Timeout steht bei 250ms. Ich werde morgen probieren ob
eine Erhöhung des Timeout eine Verbesserung mit sich bringt. Den
Watchdog hab ich im Code manuell auf 4 Sekunden erhöht, damit dürfte ich
noch genug Luft für den KeepAlive Timeout haben.
MfG
Micha
Hallo Hagen
Versuch gerade deinen Bootloader auf einem mega32m1 mit externen clock
von 14,758 Mhz zu bekommen.
Der Chip meldet sich einfach nicht.
Habe das ganze auf einem mega16 mit internen clock von 8 Mhz probiert.
Da läuft alles wunderbar.
Das Programm kann ich für beide avr compilieren. keine Fehler.
Kannst du mir bitte weiterhelfen.
Vielen Dank im Voraus.
@Alex:
> Kannst du mir bitte weiterhelfen.
Und wie ?
Übliche Verdächtige:
1.) BootCodeSize nicht gesetzt, also erstmal auf 0 setzen, neu
kompilieren und das was im Messagewindow bei cseg [used] im AVRStudio
steht nach BootCodeSize schreiben, neu kompilieren und nicht stören
daran das in der neusten Version nun bei cseg [used] ein Wert der um +2
Bytes größer ist drinnen steht (AVRStudio 4.16 Bugfix)
2.) Fuses und Lockbits richtig ? Wenn du AVRootloader.ASM kompilierst
schaue in das Messagewindow vom AVRStudio was dort steht wie du die
Fuses setzen sollst. Exakt so im AVRStudio auch einstellen (BOOTSZ
Fuses)
Clock-Fuses korrekt ? CKDIV8 Fuse ?
3.) geht die Kommunikation ? also erstmal RX-TX am Dongle verbinden und
schauen das AVRootloader.exe bei [Timeouts] Options=1 eine 1-Wire
Verbindung erkennt. Im Protokoll Fenster siehst du das einmal das
empfangen wird was gesendet wurde. Mit diesem Test hat man also die
Kommunikation bis nach dem Dongle (MAX232, FTDI usw.) getestet. Bei
1-Wire RS232 Dongle aus 1-Wire.png ist das natürlich inklusive.
4.) nun in AVRootloader.asm UseRS485=1 setzen und DE_PORT/DE_PIN auf
einen Pin an dem zb. eine LED nach VCC angeschlossen wurde, oder
UseRS485Invert=1 setzen invertiert die Logik. Nun solltes du jedesmal
wenn der Bootloader selber sendet die LED aufleuchten sehen (evntl.
Baudrate geringer setzen)
5.) BootSign: ist identisch zum BootSign im AVRRootloader.exe ?
6.) UseAutoBaud=1 gesetzt ?
7.) BootDelay nicht zu knapp bemessen ?
8.) überschneiden sich RX/TX Pin/PORT mit dem ISP/DebugWire ? Wenn ja
könnte sich beides gegenseitig stören.
9.) eigene Hardware überprüfen, VCC stabil ?
10.) Schwingt der Quarz ?
Falls irgendwas von diesen Tipps dein Problem lösen sollte bitte teile
es mir mit, so kann ich bei ähnlichen Anfraen gezielter reagieren.
Gruß Hagen
Hallo Hagen.
Danke für die prompte Antwort.
Habe die aktuellste Version von dir genommen und da ging es auf anhieb.
Finde es ein bischen blöd im Forum die ganzen Beiträge durchzuschauen um
die aktuellste Version herauszufinden.
Aber dein Bootloader ist echt gut. Vielen vielen Dank.
MFG Alex
Hallo zusammen,
zunächst einmal SUPER, daß es mit diesem Bootloader prinzipiell extrem
einfach ist eine neue Software auch in das Pollin AVR-Net-I/O-Board zu
bekommen. Endlich kann ich meinen ISP-Programmer beiseite legen.
Soweit so gut. Konkret habe ich vor die EtherSex-Firmware mittels
AVRootloader aufzuspielen. Mit einem über die Webseite vom ethersex
erstellten image (Größe 72k) klappt das auch bestens, jedoch beinhaltet
die so erstellte Version außer einer HTML-Seite nichts - und das reicht
mir verständlicherweise nicht aus.
Daher habe ich mir mittels GIT das gesamte respository auf den
Linux-Rechner geladen. Compilieren klappt auch bestens, jedoch läßt sich
das erstellte HEX-File (trotz 55K Größe) partout nicht mittels
AVRootloader auf den ATMega32 aufspielen.
Ich bekomme immer folgende Fehlermeldung:
Hi,
vielleicht sind es einfach die Zeichen am Zeilenende ?
Mal mit einem Editor von UNIX nach Windows wandeln der Hex Datei ?
zB. mit Notepad++....
Gruß Sven
Zeige mal das HEX File.
Dieser Fehler bedeutet exakt das was er aussagt: das HEX File ist
ungültig und fehlerhaft. Entweder ist es kein gültiges Intel HEX Format,
oder es enthält Records die nicht im Standard definiert sind, oder in
den einzlenen Zeilen mit den Daten sind Sonderzeichen drinnen also kein
HEX, oder die CRC über eine Zeile stimmt nicht.
Das ich das jetzt nicht genauer in der Fehlermeldung aufgechlüsselt habe
möge man mir verzeihen, aber wann kommt solch ein Fehler schon vor.
Gruß Hagen
@Sven:
>vielleicht sind es einfach die Zeichen am Zeilenende ?>Mal mit einem Editor von UNIX nach Windows wandeln der Hex Datei ?
Nee das kann es nicht sein. Grundsätzlich baue ich solche Parser immer
so das es Sonderzeichen wo Sonderzeichen möglich sind auch ignoriert.
Dh. an irgendeiner Stelle, wo laut Standard klar definiert wurde was da
zu stehen hat, steht in seinem HEX File irgendwas was da nicht
hingehört.
Gruß Hagen
@Alex:
>Finde es ein bischen blöd im Forum die ganzen Beiträge durchzuschauen um>die aktuellste Version herauszufinden.
Ja ich weiß und ich hatte auch schonmal angedacht im Wiki ein Artikel zu
bauen. Aber die liebe Zeit reicht nicht aus.
So bleibt nur ein Tipp von mir: lese den Thread von Unten nach Oben,
dann wirst du mit Sicherheit die aktuellste Version als erstes finden.
Denn ich verspreche dir das ich chronologisch betrachtet nicht in der
Lage bin eine zukünftige Version schon in der Vergangenheit fertig zu
stellen ;)
Gruß Hagen
Hallo Hagen,
danke für die schnelen Rückantworten (auch Dank an Sven)
Hagen Re wrote:
> Dh. an irgendeiner Stelle, wo laut Standard klar definiert wurde was da> zu stehen hat, steht in seinem HEX File irgendwas was da nicht> hingehört.
Feature-Request: fehlerhafte Stelle anzeigen und genaueren Grund angeben
Da ich die Original Debian-Pakete OHNE jegwelche Änderungen verwende
kann ich mir eigentlich nicht vorstellen, daß der Compiler hier Murks
macht.
Aber vielleicht hilft dennoch folgender Hinweis:
In einer funktionierenden Datei endet diese beispielsweise mit:
1
:1066A000B1F6D363BA6B8B95869F12841FEB668617
2
:1066B0007FF6B6B56AB249D283E3D1713A62B66663
3
:0C66C000C8E77F006C0B23456810000049
4
:00000001FF
Eine nichtfunktionierende Datei sieht am Ende hingegen so aus:
1
:104E2000CE010E94DE2708C0E114F10419F0F70159
2
:104E3000C1937F019A9449F7E114F104A9F0F701B5
3
:104E4000108
gezeigt sind jeweils die letzten Zeilen. EVentuell hilft das ja noch zr
Fehlereingrenzung
Jo das hilft sehr, deine fehlerhafte HEX Datei wurde abgeschnitten, es
fehlt der Rest.
Letzte Zeile :104E4000108
Es folgen 0x10=16 Bytes die an Adresse 0x4e40 gespeichert werden sollen
da Recordtyp 0x00. Danach folgen die Datenbytes 0x10 und 0x8? aber wo
ist der Rest der angeblichen 16 Bytes und deren CRC ?
>Feature-Request: fehlerhafte Stelle anzeigen und genaueren Grund angeben
Jo das wäre sinnvoll aber aus der Abwägung diverser Zeitgründe heraus
nicht sofort.
Gruß Hagen
>>Feature-Request: fehlerhafte Stelle anzeigen und genaueren Grund angeben>> Jo das wäre sinnvoll aber aus der Abwägung diverser Zeitgründe heraus> nicht sofort.
OK, das passt schon. Dann werde ich in der Zwischenzeit mal in Erfahrung
bringen, warum das Paket der aktuellen DEBIAN-Installation (lenny, 5.0)
den Murks macht oder ob es das FTP-Programm zwischen Linux und
Windows-Rechner war. Ich werde berichten.
Hagen Re wrote:
> ...deine fehlerhafte HEX Datei wurde abgeschnitten, es fehlt der Rest.
In der Tat, auf dem Linux-System ist die Datei korrekt, packe ich sie
mit GZIP und transferiere sie dann und entpacke sie anschließend auf dem
WIndoff-System wieder ist sie auch auf diesem korrekt. Lediglich beim
direkten Transfer wird die Datei immer an der selben Stelle
abgeschnitten. Selbst wenn ich als Transferart BINARY einstelle passiert
dies. Nun ja, ganz herzlichen Dank für den Hinweis, aber da hätte ich im
Traum nicht dran gedacht, ist mir auch noch nie passiert. Aber nun
behelfe ich mir halt immer mit vorangegangenem GZIP und gut ist.
Nochmals Danke!
Den Feature-Request lasse ich natürlich trotzdem bestehen. :-)
Hello all,
I´m sorry, I dont know German language, my apologies.
Is there a way to get the email of Mr. Hagen, please, in order to
contact him? I would like to know more about the bootloader.
Best regards,
Luiz
luiz,catalan at gmail.com
Hallo,
ich versuche mit dem Bootloader einen Mega88 über einen FTDI FT232R zu
flashen, leider ohne Erfolg.
Die "üblichen Verdächtigen" habe ich schon durchgearbeitet.
Problem:
Der Bootloader funktioniert mit MAX232, aber nicht mit dem FT232R
Der AVRootloader findet zwar das Device korrekt, aber kann's nicht
Flashen.
Immer ähnliche Fehler:
Ab 115200baud kommt ab Version 4 auch keine Verbindung mehr zustande.
Es klappt auch, den 1-Wire-Modus wird zu erkennen, wenn ich RXD und TXD
verbinde. Mit H-Term kann ich über den FT232R Daten zum µC schicken und
bekomme auch Welche zurück. An der Schaltung kann es also eigentlich
nicht liegen, das
1
.equUseUartInvert=1
ist auch korrekt, denn beim MAX ist es auch nötig, und da funktioniert
es ja auch.
Bin ratlos!
Habe schon verschiedene Quarze, Einstellungen ausprobiert, immer der
gleiche Fehler.
Wäre sehr dankbar für jegliche Ratschläge!!
Gruß Jan
>wie berechnet sich auch F_CPU/x die 250ms?? Was für ein Teiler ist für >18,432MHz empfehlenswert?
XTAL/x, möchtest du 1 Sekunde / 4 = 250 Millisekunden warten so setze
BootDelay = XTAL/4 da 250ms = 1 Sekunde / 4 ist. Weist du wieviele Takte
eine MCU mit XTAL = 18,432MHz benötigt für 1 Sekunde ? Ich denke das
wird die Lampe zum leuchten zu bringen ;)
Die schlußendliche Wartezeit in BootDelay ist eher eine Funktion der
eingestellten Baudrate un damit immer ein Kompromiß. Je höher die
Baudrate und das BootDelay desto öfter kann die PC Software einen
kompletten Connectionstring wiederholt aussenden, ergo desto
wahrscheinlicher ein gültiger Verbindungsaufbau. Je geringer die
benutzte Baudrate und je kürzer das BootDelay desto weniger
Connectiongsrings kann die PC Software senden.
Nun zu deinem eigentlichen Problem:
Öffne AVRootloader.ini und setze in Sektion [Timeouts] das Topic "Base="
mal auf 100. Statt wie im Standard 50ms auf 100ms. Dieser Timeoutwert
ist bei Treibern wie dem des FTDI, virtueller COM Port, manchmal sehr
entscheidend. Die VCOM-Treiber sind in ihrem Timing angewiesen auf das
Gesamttiming der CPU, eg. Tasksheduler und laufende Task im
Gesamtcontext des Betriebsystemes.
Benutze bitte die aktuellste Version, diese ist zZ. Version 6.
Gruß Hagen
Ansonsten scheint es bei dir irgndwelche sporadischen
Timing-/Kommunikationsfehler zu geben. Die fehlermeldungen sind also
nicht speziell auf ein Modul, eg. eine spezielle Aktion/Kommando wie
Erase, Program, FLASH oder EEPROM etc.pp. bezogen sondern auf das Timing
oder Datenübertragung.
Deswegen kann ich dir nur den Tipp geben mal den Timeout.Base Wert in
der INI zu erhöhen. Ansonsten mal schauen ob deine Spannungsversorgung
des FTDI stabil ist. Ich weiß ja nicht ob dein FTDI Modul ein fertig
gekauftes oder selber aufgebautes ist, bei Selbstbau stellt sich die
Frage ob die USB Anbindung ordentlich terminiert ist.
Mit BootDelay=XTAL/4 habe ich gute Erfahrungen gemacht. Damit konnte ich
in diversen Projekten immer eine Verbindung aufbauen, speziell wenn
UseResetDelay=1 eingestellt ist. Also zb. ATTiny45/44/461 mit internem
RC-Oszillator und/oder 64MHz PLL Takt oder 20Mhz ext. Quarz bei
Baudraten von 4800 bis 112500 oder ATMega162 mit ext. Quarz, alles
jeweils in 1/2-Wire mit USB-RS232 Wandler, normaler RS232 mit/ohne MAX
Pegelkonverter oder sogar an XPORT TCP/IP-RS232 Wandler bis 256000 Baud
oder am USB-RS485 Bus. Hm, also im Grunde in jeder möglichen
Konfiguration und bisher in diesem Thread erwähnter Hardware.
Gruß Hagen
Hallo Hagen,
danke für die schnelle Antwort!
Ok, jetzt ist das mit dem Delay und dem Teiler klar - war mir wohl zu
einfach, um es zu verstehen :-)
Hatte auch schon mal mit den Timings herumprobiert.
Mit Basis 100 kommen folgende Fehler, je nach Baud:
unter 115200Baud Dieser:
...
das verbinde ich dann mit einem ca. 100mm langen Flachbandkabel an
folgendes Board:
http://www.minimexle.de/shop/links.php
Schaltplan siehe Bauanleitung MiniMEXLE V2.0 Seite 7 von 35.
Bye, Jan
Hast du vielleicht einen kommerziellen USB-RS232 Konverter rumliegen ?
Falls ja probiere es mal mit dem. Ich denke nämlich das irgendwas mit
deinem Aufbau nicht stimmt. Die Fehlermeldungen die du bekommst sind
nicht nachvollziehbar und an Stellen bei denen mit funktionierender
Datenübertragungen nie irgendwelche Fehler auftreten. Zb.
"Cmd.SetBuffer.ResCheck(2) Error: 00 operation failed", der Code 0x00
ist normalerweise garkein Fehlercode, Fehlercodes sind 0xC? kodiert. Dh.
an eine Stelle im Code erwartet die PC-Software einen Returncode wie
0x3? oder 0xC? bekommt aber ein falschen Code zurückgemeldet. Das kann
nur passieren wenn irgendwas bei der Datenübertragung schief gelaufen
ist. Denn es gibt nur zwei Gruppen von gültigen Returncodes, 0x3? die
SUCCESS-Codes und 0xC? die ERROR-Codes, kannst du in AVRootloadr.inc
nachlesen. Die PC-Software empfängt aber den Wert 0x00 als Returncode
und der ist falsch.
"Cmd.SetBuffer.WriteData() ICOM: write error." deutet darauf hin das ein
Timeout beim Schreiben=Senden von Daten auftrat. Nun ist es aber so das
normalerweise niemals Timeouts beim Schreiben passieren da die Treiber
ja gepuffert mit einem sehr großen Sendebuffer arbeiten. Dieser Fehler
dürfte garnicht auftreten und deutet eher daraufhin das der USB Kanal
hardwartechnisch gestört sein könnte. Deshalb meine Frage mit deinem
Aufbau.
Gruß Hagen
Hagen wrote:
> Hast du vielleicht einen kommerziellen USB-RS232 Konverter rumliegen ?
--> LogiLink USB zu RS232 Adapter und davon weiter mit
MAX-Adapterplatine funktioniert, so wie nur mit MAX-Adapter am COM des
PC
Muss wohl wirklich irgendwie an der FT232R Platine liegen, obwohl die
nun wirklich überschaubar ist und für puren Datentransfer in beide
Richtungen funktioniert.
Habe gerade eine andere Platine fertiggelötet, dort ist ein FT232BL
drauf, werd's gleich mal damit probieren, evtl. geht es ja bei dem
Layout.
Grüße, Jan
Hallo,
scheinbar liegt es ja an meiner kleinen Adapterplaine.
Kann jemand andere Werte für die Kondensatoren vorschlagen, mit denen es
erfolgreich funktioniert?
(Habe die Werte direkt aus dem Datenblatt von FTDI übernommen.)
Schaltplan siehe 4 Beiträge Schaltplan FTDI FT232RL (4 Beiträge zurück
nach oben).
Danke im Voraus,
Jan
>--> LogiLink USB zu RS232 Adapter und davon weiter mit>MAX-Adapterplatine funktioniert, so wie nur mit MAX-Adapter am COM des>PC
Probiere doch mal den 1-Wire-RS232 Adapter den ich im Bild 1-Wire.png im
ZIP beigelegt habe am LogiLink Adapter. Du kannst auch 2-Wire direkt an
der RS232-DB9 anschließen, habe ich auch schon so am Laufen. Dazu nur
einen 2k7 Widerstand in der TX-Leitung und RX direkt am Pin des AVRs.
Bei direktem Anschluß an der DB9 immer UseUartInvert=0 setzen.
Gruß Hagen
Hi Hagen,
nachdem der Thread mittlerweile, in meinen Augen, ein wenig
unübersichtlich geworden ist, spricht was dagegen, das ich einen Artikel
drüber anlege, anfange?
Grüße
Wolfgang
Nicht im Geringsten, ich wäre dir sogar sehr dankbar da meine Zeit sehr
knapp ist. Wenn du aber Fragen haben solltest dann melde dich bei mir
per PN damit ich dir eine ausführlichere Antwort geben kann. Ich bin bis
jetzt noch nichtmal zur Dokumentation des Protokolles gekommen.
Gruß Hagen
Habe heute meine andere Platine (USB<->433MHz) mit dem FTDI FT232BL in
Betrieb genommen. Da funktioniert der Rootloader 6.0 bestens!
Werde bei Gelegenheit mal die Adapterplatine für den FT232R neu Routen,
evtl. geht es ja dann.
Bye, Jan
So, hal mal den Artikel
http://www.mikrocontroller.net/articles/AVR-Bootloader_mit_Verschl%C3%BCsselung_von_Hagen_Re
"AVR-Bootloader mit Verschlüsselung von Hagen Re" angelegt und die
Historie aus diesem Thread, soweit nachvollziehbar rüber genommen.
Jetzt sollte man rangehen und die ganzen Connect-Möglichkeiten
(Schaltbläne mal auflisten, bzw. die mittlerweilen vielen Paramter
auflisten, erklären.
@Jan Spieler
> scheinbar liegt es ja an meiner kleinen Adapterplaine.> Kann jemand andere Werte für die Kondensatoren vorschlagen, mit denen es> erfolgreich funktioniert?> (Habe die Werte direkt aus dem Datenblatt von FTDI übernommen.)
Hallo Jan !
Mein Aufbau sieht eigentlich genauso aus, auch die Kondensatoren wie im
Datenblatt. Was für einen Ferrit nutzt du denn (abgesehen davon das du
ein Symbol von ner Diode genommen hast) ? Ich hab bei mir 10 µH !
Meine Kommunikation läuft mittlerweile sehr stabil auf 128.000 Baud.
Gruß Stefan
PS: Und immer den neuesten Bootloader verwenden ! Kann Wunder bewirken !
:-)
Stefan R. wrote:
> Was für einen Ferrit nutzt du denn (abgesehen davon das du> ein Symbol von ner Diode genommen hast) ?> Ich hab bei mir 10 µH !> Meine Kommunikation läuft mittlerweile sehr stabil auf 128.000 Baud.>> Gruß Stefan> PS: Und immer den neuesten Bootloader verwenden ! Kann Wunder bewirken !> :-)
Hallo Stefan,
vielen Dank für die Rückmeldung!!!
Ich habe bei Pollin folgenden Artikel bestellt:
1
Perlendrosseln 250 309
--> Die Diode fand sich nur grad so am schnellsten als passendes Package
(ich weis: schlechter Grund)
Leider ist bei Pollin keine Induktivität der Ferritperle angegeben!
Habe auch folgendes von Reichelt, kann ja mal die Ferritperle gegen die
Spule austauschen (einziges Problem --> SMD statt THT):
Erst mal vielen Dank für die Infos,
habe auch noch vor, mit dem Oszi die Spannungsversorgungspins des FTDI
zu prüfen, ob das Layout evtl. einen schlechten Einfluss hat. Bei meinem
FT232B-Board ist eine Massefläche zw. den Daten und VCC Leiterbahnen,
beim FT232R-Board nicht.
Hab heut leider keine Zeit mehr, aber morgen werd ich das mal prüfen und
die Induktivität einlöten.
Grüße,
Jan
> Ich habe bei Pollin folgenden Artikel bestellt:>
1
Perlendrosseln 250 309
> --> Die Diode fand sich nur grad so am schnellsten als passendes Package> (ich weis: schlechter Grund)> Leider ist bei Pollin keine Induktivität der Ferritperle angegeben!> Habe auch folgendes von Reichelt, kann ja mal die Ferritperle gegen die> Spule austauschen (einziges Problem --> SMD statt THT):>
Reichelt hat die auch als THT Bauteil: SMCC 10µ
> Erst mal vielen Dank für die Infos,> habe auch noch vor, mit dem Oszi die Spannungsversorgungspins des FTDI> zu prüfen, ob das Layout evtl. einen schlechten Einfluss hat. Bei meinem> FT232B-Board ist eine Massefläche zw. den Daten und VCC Leiterbahnen,> beim FT232R-Board nicht.
Ich glaub nicht das es am Layout liegt ! Die RX u. TX-Leitungen sind
nach meiner erfahrung relativ unempfindlich, außer du hättest
irgendwelche Bauteile die enorme EMV abstrahlen !
Gruß Stefan
@ All Perlendrossel von Pollin ist nicht für FT232R geeignet!!
Es lag an der Perlendrossel von Pollin. Ich habe diese gegen die
10µH-Induktivität getauscht und siehe da, Alles klappt bestens!!
Sogar bis 256.000baud!!
Danke nochmals für die Hilfe an Hagen und Stefan!
Wünsche noch schöne Oster-Tage,
Grüße, Jan
Hallo Hagen!
Ich würde bei mir gerne eine Art Zweites AppVersion einbauen (also eine
Zahl die im AVR gespeichert ist und die ich mittels Programm auslesen
kann)
Auf AVR Seite sehe ich da kein Problem, da ich einfach ne Kopie von
AppVersion nehmen kann, aber wie kann ich die aus Delphi heraus abfragen
?
Kannst du mir da vielleicht nen Tip geben ?
Wie weit ist eigentlich die Funktion um den Bootloader abzudaten ?
Funktioniert das schon ?
Viele Grüße
Stefan
Hallo,
super Bootloader.
Habe mit Tiny13 ein kleines Problem
Bekomme beim Versuch des programmieren folgende Fehlermeldung:
Error: Can not find RJMP to Main
Wo finde ich Beschreibung der Fehlermeldungen?
Vielen Dank im Voraus,
Grüße
Oliver
@Stefan,
die AppVersion besteht aus 4 bytes, wie eine IP Addresse, und der Wert
255 ist reserviert. Was spricht nun dagegen diese AppVersion als zwei 2
Bytes Versionsnummern zu betrachten ?
Aus Delphi heraus mit der AVRootloader.dll meinst du wohl. Das
IAVRootloader Interface unterstützt einige Sub-Interfaces. Das wären
IAVRootloader.COM: ICOM das Kommunikationsinterface, i.A. zur RS232 des
Betriebssystemes, das .Command: ICommand Interface zum Zugriff auf die
Lowlevel Kommandoebene eg. Protokoll des Bootloaders und das .Device:
IDevice Interface zum Zugriff auf alle Parameter des aktuell connected
AVRs. Letzeres ist das was du brauchst.
Das IDevice Interface sieht so aus:
1
IDevice=interface
2
['{9EC8A92B-F6BB-47F3-A9C9-DF8F4F481F49}']
3
functionSignature:Integer;stdcall;
4
functionName:WideString;stdcall;
5
functionInfo:WideString;stdcall;
6
functionFlashSize:Integer;stdcall;
7
functionAppFlashSize:Integer;stdcall;
8
functionAppVersion:Integer;stdcall;
9
functionAppVersionString:WideString;stdcall;
10
functionEepromSize:Integer;stdcall;
11
functionRamSize:Integer;stdcall;
12
functionRamStartAddress:Integer;stdcall;
13
functionPageSize:Integer;stdcall;
14
functionBufferSize:Integer;stdcall;
15
functionVersion:Integer;stdcall;
16
functionUseBootSection:Bool;stdcall;
17
functionRetCode:Byte;stdcall;
18
functionSupport:Integer;stdcall;
19
functionXMLFileName:WideString;stdcall;
20
end;
und die Methode .AppVersion: Integer ist das was du suchst.
Also mit
>Wie weit ist eigentlich die Funktion um den Bootloader abzudaten ?>Funktioniert das schon ?
Ja und Nein ;) Ja in dem Sinne das der Assemblerteil das schon voll
unterstützt. Er kann je nach Wunsch verschienden Funktionen einbinden
über die es mögich ist den Bootloader selber neu zu programmieren. Das
hatte ich oben im Thread schonmal beschrieben. Essentiell ist es so
gelösst das in der letzten FLASH Page diese Funktionen ausgerichtet
sind. Man kann also mit diesen Funktionen alle FLASH Pages bis zum Begin
der letzten FLASH Page mit diesen Funktionen auf sichere Weise neu
programmieren. Über die Sprungtabelle ganz am Ende des FLASHs kann die
eigene Anwendung diese Funktionen aufrufen.
Nein in dem Sinne das es noch keine vorgefertigte Anwendung für die AVRs
gibt die nun diese Funktionen benutzt um einen neuen Bootloader zu
programmieren.
Dh. konzeptionell bin ich von Anfang an davon ausgegangen das der
Bootloader selber sich nicht selbst updaten kann. Sondern das er erstmal
eine Update-Anwednung in den normalen App-FLASH programmiert, diese dann
startet und erst diese Anwendung updated den Bootloader. Die letzte
FLASH Page aller Botloader wäre dann immer identisch. Dieses Vorgehen
hat mehrere Vorteile aus Sicht der Sicherheit und Stabilität. 1.) würde
diese Anwendung im aktuellen Gerät keinen Schaden anrichten da sie
keinerlei Pins benötigt. 2.) würde diese Anwendung solange gestartet
werden wie sie im AVR ist und der neue Bootloader noch nicht
programmiert. 3.) würde diese Anendung universell für alle AVRs
funktionieren. 4.) das HEX File dieser Anwendung enthält am Ende als
Datenbereich im FLASH den neuen Bootloader. 5.) sie würde ein
Prüfsummenverfahren benutzen um sicherzustellen das der soeben
programmierte Bootloader mit dem in der Anwendung gespeicherten Kopie
identisch ist. Die gleiche Prüfsummenlogk kann auch benutzt werden um
beim Start der Anwendung zu überpüfen ob der neue Bootloader schon
installiert wurde.
Extern bräuchte man ein vorkompiliertes HEX File dieser Anwendung. Das
landet zusammen mit dem neuen Bootloader HEX in eine kleine EXE die beie
HEX Files merged. Diese HEX File könnte dann mit Hilfer der PC-Sowftare
in ein kryptographsich geschütztes ACY File umgewandelt werden und man
hat somit auch hier wieder den Updateschutzt integriert. Diese Funktion
des Zusammenfassens beider HEX Files könnte in die PC-Software
integriert werden.
So jedenfalls wäre mein Konzept. Allerdings brauche ich es perönlich
nunmal garnicht und stehe zur Auffassung das ein Bootloader einmal
konfiguriert wird und sich danach nie wieder ändert sobald er im Gerät
programmiert wurde.
Gruß Hagen
@Oliver:
>Error: Can not find RJMP to Main
Lass mich raten, dein Source ist in Assembler programiert und du benutzt
bei .org 0 im Source keinen Reset Vektor ?
Dh. an der ersten Addresse (0x0000) im Program steht normalerweise immer
ein RJMP Main, also ein Sprung zu deiner Hauptroutine des Programmes.
Die Addresse 0x0000 wird immer dann angesprungen wenn der AVR
gestartet/resetted wurde.
Meine PC-Software sucht nun nach diesem RJMP um die Startadresse der
Main zu berechnen. Denn bei den Tinys gibt es ja keine eigene Bootloader
Section im FLASH und deshalb wird getrickst indem die Software diese
RJMP Main in RJMP BootStart patcht. Der Orgiginale Sprung zu Main wird
in die 2 Bytes vor BootStart in das HEX File gepatcht. Somit weis der
Bootloader später wo er hinspringen muß wenn der die Anwendung starten
möchte.
Falls meine Vermutung richtig ist so baue mit
1
.org 0
2
rjmp Main
3
4
Main:
diesen Sprung bitte ein.
Ansonsten bliebe noch die Möglichkeit das dein HEX File beschädigt ist.
Gruß Hagen
Hallo Hagen !
> die AppVersion besteht aus 4 bytes, wie eine IP Addresse, und der Wert> 255 ist reserviert. Was spricht nun dagegen diese AppVersion als zwei 2> Bytes Versionsnummern zu betrachten ?
Stimmt eigentlich ! Daran hab ich noch garnicht gedacht !
>
1
>ifAVRootloader.DoConnect(True)then
2
>try
3
>Version:=AVRootloader.Device.AppVersion;
4
>finally
5
>AVRootloader.DoDisconnect;
6
>end;
7
>
Das hab ich schon implementiert ! Genauso wie die Neuprogrammierung der
AppVersion.
>So jedenfalls wäre mein Konzept. Allerdings brauche ich es perönlich>nunmal garnicht und stehe zur Auffassung das ein Bootloader einmal>konfiguriert wird und sich danach nie wieder ändert sobald er im Gerät>programmiert wurde.
Hast du eigentlich auch wieder Recht. Ist für mich auch nicht
ausschlaggebend. Hat mich nur interressiert, weil du es mal erwähnt
hattest.
Danke !
Gruß Stefan
Hallo an alle,
kann mir vielleicht irgendjemand ein paar Informationen geben, wie ich
mit der AVRootLoader.dll unter C++ umzugehen habe? In Delphi scheint das
ja alles ganz einfach zu sein - einfach den 'Header' unter 'uses'
angeben, die nötigen Methoden der IApplication implementieren und
fertig. Aber auch nach ausgiebiger Netzrecherche habe ich nicht
herausgefunden, wie man selbiges in C++ anzustellen hat.
Wie muss ich grundsätzlich vorgehen um diese DLL einzubinden, das
IApplication-Interface zu implementieren und letzten Endes ein
IAVRootloader Objekt zu erhalten?
Für jeden auch noch so kleinen Ansatz einer Hilfestellung wäre ich sehr
dankbar :)
Gruß
Marcel
Hi Marcel,
im Grunde exakt so wie in Delphi, mit dem Unterschied das diese
Interface Unit als C++ Header transliert werden muß. Im einfachsten
Falle einen Recordtyp deklarieren. Es müssen nun alle Methoden
angefangen bei IUnknown bis zu meinen Interfaces in exakt der gleichen
Reihenfolge als procedurale Member, Funktionszeiger, in diesem Record
deklariert werden.
Ich kenne mich in C++ und seiner Unterstützung für Interfaces nicht aus,
aber da diese Form der Interfaces eine unterstützte Methode bei
Microsoft Windows Produkten ist, siehe ActiveX,COM,DCOM usw., dürfte das
auch vom C++ unterstützt werden. Ich kann dir aber den grundsätzlichen
und internen Aufbau, sprich Funktionsweise von solchen Interfaces und
deren allozierten Objekten quasi in prozeduraler Sprache erklären.
Ein alloziertes interfaced Objekt ist ein Zeiger auf einen Record.
Dieser Speicherbereich enthält als erstes Member einen Zeiger auf die
VMT-> Virtual Method Table, also wiederum einen Record in dem alle
Methoden als Zeiger eingetragen sind. Jede dieser Methoden wird einen
impliziten unsichtbaren 1. Parameter erwarten, nämlich Self oder This,
der Zeiger auf diesen Record = alloziertes Objekt. Nach dem VMT zeiger
kommen schon private Member, quasi Objekt/Klassenbezogene Datenfelder.
Das ist quasi schon der ganze Trick der sich OOP nennt. Entscheidend ist
das der Compiler das als "Sprachfeature" uterstützt und nun zb. diesen
impliziten Parameter Self/This einer Objektmethode unsichtbar macht, das
er bei Interfaces abgeleitet von IUnknown automatisch die
Stanardmethoden ._AddRef und ._Release aufruft um eine
Referenzzählung/Lebenszeitzähler/Garbage Collection und wie das alles
bennant wird, machen zu können. Und als dritter wesentlicher Punkt wird
der Compiler eine Unterstützung von Typcast solcher Objekte
implementieren indem er transparent und unsichtbar für den Entwickler
die Methode ._QueryInterface() eines Objektes aufruft.
Nungut in Delphi/PASCAL sähe also ein manuell erzeugtes IUnknown
Interface/Objekt so aus:
Wie du siehst so schwierig ist das Konzept OOP als Umsetzung in unsere
Programmiersprachen garnicht.
Da meine DLL schon den ganzen Quatsch mit der Allozierung/Freigabe usw.
selber macht brauchts du eigentlich nur den richtigen Recordtyp für
deren VMTs zu deklarieren und musst dann den Zeiger auf das Objekt, ergo
IAVRootloader usw. alle den Methoden die du aufrufen möchtest als ersten
Param übergeben.
Aber das wäre der manuelle Weg und C++ sollte eigentlich von Hause aus
Interfaces unterstützen.
Schau auch mal hier rein dort habe ich ein anderes Beispiel gepostet:
http://www.delphipraxis.net/topic7357_waitcursor.html&highlight=forged+interfaces
In diesem Thread und folgende beschreibe ich wie und warum ich solche
Interfaces in meinem DEC Math benutzt habe:
http://www.delphipraxis.net/topic14699,0,asc,77.html
Du könntest also auch den manuellen prozeduralen Weg gehen und damit auf
die C++ Sprachfeatures für die Unterstützung von Objketen und deren
Interfaces ganz verzichten.
Leider kenne ich mich in diesem Punkt eben mit C++ nicht praktisch
konkret aus und würde hier auch PASCAL/JAVA oder sogar moderen BASIC
Dialekte dem C++ vorziehen.
Gruß Hagen
Übrigens findet man eine Menge im Netz zu C++ und Interfaces, zb. hier
http://www.learncpp.com/cpp-tutorial/126-pure-virtual-functions-abstract-base-classes-and-interface-classes/
ab Abschnitt "Interface-Classes".
Du musst halt nur darauf achten das die Interfaces in meiner DLL schon
abgeleitet von IUnknown (IInterface in Delphi) sind und damit die 3
vererbten Methoden .QueryInterface(), ._AddRef() und ._Release() nicht
vergessen.
Gruß Hagen
Hallo Hagen,
ich versuche einen ATmega128 per Bootloader(V6) zu flashen.
Das funktioniert immer genau 1 mal, danach kommt keine Verbindung zum
AVR mehr zustande.
Also wird vermutlich der Bootloader überschrieben.
Habe jetzt alle möglichen Lockbit-Kombinationen getestet, der Bootloader
wird trotzdem wohl jedesmal überschrieben.
Habe die Lockbits nach einem früheren Beispiel mit einem AtMega8535
programmiert = gleiches Ergebnis.
Also LB = disabled,BLB0=SPM prohibited in App.Sektion,BLB1=No lock on
SPM and LPM.(andere Kombinationen im Bootbereich auch erfolglos
getestet)
Bootflashsize and Bootreset sollten passen.
Irgendwie sehe ich den Baum vor lauten Wäldern nicht.
Gruß
bandgap
BOOTSZ Fuses nicht gesetzt. Dh. du hast die Boot Section nicht aktiviert
was dazu führt das der Bootloader nicht per RESET angesprungen wird.
Stattdessen startet der AVR bei Adresse 0x0000 und da ab diesen
Speicherzellen bis zum Bootloadercode alles der Opcode 0xFFFF steht,
gleich wie NOP, läuft der AVR in den Bootloader rein. Aber sobald der
Bootloader eine Anwendung geflasht hat wird er selber niemehr aufgerufen
es sei denn deine Anwendung macht dies. Dh. setze deine BOOTSZ Fuses
richtig, aktiviere damit die Bootloader Section im FLASH damit der
Bootloader beim RESET auch gestartet wird, dann klappt es auch und du
hast Zeit die Datenblätter im Bereich "Memory-Progarmming" nochmals zu
lesen ;)
Gruß Hagen
Hallo Hagen,
vielen Dank für die Hinweise. Der Fehler war in den Einstellungen der
PC-Software. Connect-Timeout war auf 0, der Verbindungsaufbau wurde
einfach zu schnell abgebrochen.
Hab ich jetzt auf 500ms geändert, funktioniert nun alles bestens.
Gruß
bandgap
Wenn der Connect-Timeout <= 0 ist wird stattdessen der Wert in Base
benutzt. Ein guter Wert für Base ist 50 Millisekunden. Aber diese
Timeouts sind keine direkte Erklärung für das Verhalten bei dir.
Denn der Verbindungsaufbau erfolgt immer von PC-Seite und wenn diese
einen Versuch startet dann im Normalfalle ohne zeitliches Ende, also nur
durch manuellen Eingriff des Benutzers wird dieser dann abgebrochen. Ich
kenne deine Konfiguration des Bootloaders leider nicht aber jenachdem
wie dieser konfiguriert ist, zb. UseAutoBaud=0 oder BootDelay sehr
klein, müssen stiktere Timings eingehalten werden.
Ein Überschreiben des Bootloaders ist eigentlich nicht möglich es sei
denn du hast die Spezialfunktionen so aktiviert und nutzt diese auch aus
deiner Anwendung heraus und überscheibst den Bootloader absichtlich.
Gruß Hagen
>Hab ich jetzt auf 500ms geändert, funktioniert nun alles bestens.
das bedeutet die PC-Software wartet jetzt 500ms auf eine Antwort vom
Bootloader. Entweder arbeitest du mit einer extrem geringen Baudrate
oder es ist noch irgendwas an der Kommunikation nicht sauber und stabil.
Normalerweise wird man im Connect Timeout einen Wert kleiner Base, also
so 10 oder 20 Milisekunden vorgeben damit man schneller einen Scan über
alle COM Port im AUTO Modus machen kann. Dh. diesee Einstellung ist
dafür gedacht noch schneller statt langsammer zu sein.
Ich empfehle dir also UseAutoBaud=1 zu setzen, BootDelay auf XTAL/4 =
250ms, UseResetDelay=1, UseWDT=1, UseBootMode=0. XTAL auf den richtigen
Wert des eingestellten Taktes.
Ein weiterer häufiger Fehler ist es BootCodeSize=0 zu setzen, bzw. nicht
korrekt berechnen zu lassen.
Sollte all dies nicht bei dir der Fall sein, dann kann es nur noch an
einer geringen Baudrate liegen oder eben schlechte Übertragung über die
RS232, sprich HW-Aufbau checken.
Gruß Hagen
Hallo Hagen,
ich habe die Einstellungen nochmal zurückgeändert nach deinen
Empfehlungen:
meine Einstellungen:
XTAL=7372800
Boot Delay=XTAL/4
UseBootMode=0
UseWDR=1
UseAutobaud=1
UseResetDelay=1
BootCodeSize liegt bei 516Bytes mit UseSRAM=1
RX_TX_Port=E => RS-232 / STK300
Controller Mega128
so kommt nur beim ersten Verbindungsaufbau eine problemlose Verbindung
zum Controller zustande.Nach dem flashen des Programms ist ein erneutes
Beschreiben des Controllers über den Bootloader nicht mehr möglich.
Es kommt keine Verbindung mehr zustande.Die PC-Software versucht über
COM1 und COM3(USB-Serial-Port) eine Verbindung zu erstellen bricht dann
aber mit :Error:no device found ab.
Wenn ich dann den BootDelay auf XTAL/2 hochsetze und den ConnectTimeout
auf 500ms so funktioniert der Verbindungsaufbau.(auch bei wiederholtem
flashen)
Mein erster Verdacht mit dem Überschreiben des Bootloader-Bereichs war
eine Schlussfolgerung aus der Tatsache das der erste Verbindungsaufbau
immer problemlos ist, wenn dann das erstemal über den Bootloader
geflasht wurde aber keine Verbindung mehr zustande kam.(Error:no device
found)
Grüße
bandgap
Ok, setze in der PC-Software als erstes mal den COM Port von AUTO auf
den Port an dem sich der AVR befindet. Probiere es dann nochmal mit
meinen empfohlenen Einstellungen. Möchtest du AUTO benutzen dann
verändere statt Connection Timeout den Wert in [System] ConnectTrials
auf zb. 6 oder mehr. Er steht jetzt auf 3 und das kann uU. ein
ungünstiges Timing im AUTO Modus bedeuten.
Wie startest du den Bootloader ? Durch einen RESET ?
Gruß Hagen
Hallo Haagen,
ich habe Heute Deinen Bootloader mal getestet,
voll cool, hat auf Anhieb funktioniert :-)
Jetzt wollte ich jedoch meinen Atmega8 via 1Wire flashen,
und da bekomme ich zwar eine Verbindung.
Connection : 1-Wire
Device name : ATmega8, ATmega8A
Device signature : 1E9307
SRAM size : 1024 Byte
EEPROM size : 512 Byte
FLASH size : 8192 Byte
FLASH size for application : 7680 Byte
FLASH pagesize : 64 Byte
Bootloader size : 512 Byte
Buffersize for data : 984 Byte
SRAM start address : 96
Bootloader version : 6
Use bootsection : Yes
Versioning supported : No
Cryptography supported : No
... doch leider wird diese sofort wieder abgebaut.
04.05.09-23:19:15-218 > Connecting on port COM2...
04.05.09-23:19:15-593 > Switch to 1-Wire mode
04.05.09-23:19:15-593 > Device connected
04.05.09-23:19:16-436 > Device disconnected
Als Anschaltung an RS232 habe ich die Schaltung aus dem Bild 1-Wire.png
verwendet.
UasUartInvert=0, direkt an RS232 das untere Bild ohne Schottky Dioden
einfach direkt auf die Schnittstelle.
Ich dachte mir, wenn das so einfach funzt brauche ich keinen MAX232 :-)
doch nun komme ich irgendwie nicht weiter.
PS:Kann es daran liegen das ich im Moment den internen Osczilator
verwende?
Schöne Grüße
Hannes
Hallo Hagen (jetzt auch richtig ;-))
sorry war mein Fehler, hab den Fehler jetzt gefunden!
Bei der Umstellung auf 1Wire habe ich vergessen
BootCodeSize von 432 auf 430 anzupassen.
Kaum macht man's, wie es beschrieben ist, so funzt es auch.
Schöne Grüße
und nochmals besten Dank für diesen coolen Bootloader.
Gruß Hannes
Schön das sich das Problem von selbst erledigt hat ;) Denoch kann ich
nicht nachvollziehen warum das an der falschen BootCodeSize gelegen
haben soll. Hast du irgendeine der UseSecialXXX Funktionen aktviert ?
Das wäre für mich jetzt die einzige Erklärung warum es zu Problemen
kommen sollte. Da du einen ATmega8 benutzt, der die Bootsections auch
unterstützt, berechnet das ASM an Hand des Wertes in BootCodeSize den
korrekten Reallocationspunkt, eg. Startadresse des Bootloaders. Nun,
beim AVRMega muß der natürlich an einer Grenze alloziert werden die mit
einer der programierbaren Bootsections begint. In deinem Falle also die
letzten 512 Bytes im FLASH. Ob in BootCodesize nun 432 oder 430 Bytes
drinnen steht macht ausschließlich nur dann einen Unterschied wenn man
die UseSecialXXX Funktionen aktiviert hat, in deinem Fall. Ich hoffe
also das dies der Fall ist ansonsten könnte ich mir nämlich nicht
erklären warum das bei dir nicht funktioniert haben sollte.
Die Standardvorgehensweise für die Installation des Bootloaders ist
folgende:
1.) ASM konfigurieren
2.) BootCodeSize=0 setzen
3.) kompilieren
4.) aus dem AVRStudio Message Window den Wert bei CSEG Used in
BootCodeSize setzen
5.) erneut das ASM kompilieren
6.) im Message Window nachschauen welche BOOTSZ Fuses man setzen soll
7.) HEX File in AVR flashen
8.) Fuses entsprechend setzen
9.) AVR mit PC verbinden, je nach Konfiguration
10.) Connect Versuch und Test Anwendung flashen lassen
Gruß Hagen
Thread beobachten
Seitenaufteilung abschalten
