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 | |
2 | |
3 | |
4 | |
5 | |
6 | |
7 | |
8 | |
9 | |
10 | |
11 | |
12 | |
13 | |
14 | |
15 | |
16 | |
17 | |
18 | |
19 | |
20 | |
21 | |
22 | |
23 | |
24 | |
25 | |
26 | |
27 | |
28 | |
29 | |
30 | |
31 | |
32 | |
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
UartInvert=1, du benutzt doch einen Pegelwandler sagt mir meine Glaskugel ;) Gruß Hagen
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
> Bzw. poste mal alles was in der ASM nach BootInfo: steht und die Section > [BootSign] aus der INI Datei. > ASM:
1 | |
2 | |
3 | |
4 | |
5 | |
6 | |
7 | |
8 | |
INI-Datei:
1 | |
2 | |
3 | |
4 | |
5 | |
6 | |
7 | |
8 | |
9 | |
10 | |
11 | |
12 | |
13 | |
14 | |
15 | |
16 | |
Sollte der Aufruf der AppCmd nicht ungefähr so funktionieren : Result:= 'App-Code/00/00'; Gruß Stefan
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
Achso, dein modifiziertes AppCmd kannste raus nehmen (die Nullen entfernen).
Super ! Das neue Update hat auf anhieb funktioniert ! Echt klasse ! Ich danke dir für deine Mühe, war ja nun echt keine leichte Geburt :-) Gruß Stefan
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
Angehängte Dateien:
-
MProg.jpg
(110 KB)
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
Gast
#1142356
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
Gast
#1142599
Deine Erklärung(en) leuchten wie immer ein. Austesten kann ich das erst Morgen. Ergebnis folgt... Gruß JoJo
Gast
#1143691
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 | |
2 | |
3 | |
4 | |
5 | |
6 | |
7 | |
8 | |
9 | |
10 | |
11 | |
12 | |
13 | |
14 | |
15 | |
16 | |
17 | |
18 | |
19 | |
20 | |
21 | |
22 | |
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
Gast
#1144357
>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
Gast
#1145144
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
Gast
#1146113
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
Gast
#1156948
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
Gast
#1157076
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
Gast
#1158528
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.
1 | |
2 | |
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
Gast
#1161025
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
Hallo So da bin ich wieder. Habe die benötigten Infos zusammengetragen. Hier die Konfiguration aus AVRootloader.asm:
1 | |
2 | |
3 | |
4 | |
5 | |
6 | |
7 | |
8 | |
9 | |
10 | |
11 | |
12 | |
13 | |
14 | |
15 | |
16 | |
17 | |
18 | |
19 | |
20 | |
21 | |
22 | |
23 | |
24 | |
25 | |
26 | |
27 | |
28 | |
29 | |
30 | |
31 | |
32 | |
33 | |
34 | |
35 | |
36 | |
37 | |
38 | |
39 | |
40 | |
41 | |
42 | |
43 | |
44 | |
45 | |
46 | |
47 | |
48 | |
Damit läuft alles super:
1 | |
2 | |
3 | |
4 | |
5 | |
6 | |
7 | |
8 | |
9 | |
10 | |
11 | |
12 | |
13 | |
14 | |
15 | |
16 | |
17 | |
18 | |
19 | |
wenn ich nun nicht PB0 sondern PB5 benutzen will:
1 | |
2 | |
3 | |
4 | |
5 | |
6 | |
7 | |
8 | |
9 | |
10 | |
11 | |
12 | |
13 | |
14 | |
15 | |
16 | |
17 | |
18 | |
19 | |
20 | |
21 | |
22 | |
23 | |
24 | |
25 | |
26 | |
27 | |
28 | |
29 | |
30 | |
31 | |
32 | |
33 | |
34 | |
35 | |
36 | |
37 | |
38 | |
39 | |
40 | |
41 | |
42 | |
43 | |
44 | |
45 | |
46 | |
47 | |
dann passiert das:
1 | |
2 | |
3 | |
4 | |
5 | |
6 | |
7 | |
8 | |
9 | |
10 | |
11 | |
12 | |
13 | |
14 | |
15 | |
16 | |
17 | |
18 | |
19 | |
20 | |
21 | |
22 | |
23 | |
24 | |
25 | |
26 | |
27 | |
28 | |
29 | |
30 | |
31 | |
32 | |
33 | |
34 | |
35 | |
36 | |
37 | |
38 | |
39 | |
40 | |
41 | |
42 | |
43 | |
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
Hier noch mal 2 Bilder vom Steckbrett:
PB0:
http://www.bogenschuetzen-moenchengladbach.de/share/PB0.gif
PB5:
http://www.bogenschuetzen-moenchengladbach.de/share/PB5.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?
Gast
#1174760
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
Gast
#1179194
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.. beim m1280 kann UART3 und 4 nicht genutzt werden. lg, markus
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
Gast
#1179458
@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 | |
2 | |
3 | |
4 | |
5 | |
6 | |
7 | |
8 | |
9 | |
10 | |
11 | |
12 | |
13 | |
14 | |
15 | |
16 | |
17 | |
18 | |
19 | |
20 | |
21 | |
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
Hier mal der Link zum Schaltplan des USB-485. http://www.hoelscher-hi.de/hendrik/light/openrdm/open_rdm.gif 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 03.03.09-18:57:23-609 > Connecting on port COM4... 03.03.09-18:57:23-609 > Timeout.Connect = 100 ms 03.03.09-18:57:23-609 > Timeout.Base = 100 ms 03.03.09-18:57:23-609 > Timeout.Erase = 10 ms 03.03.09-18:57:23-609 > Timeout.Flash = 15 ms 03.03.09-18:57:23-609 > Timeout.Eeprom = 10 ms 03.03.09-18:57:23-609 > Timeout.Buffer = 1 ms 03.03.09-18:57:23-609 > Timeout.AppCmd = 0 ms 03.03.09-18:57:23-609 > Timeout.KeepAlive = 250 ms 03.03.09-18:57:23-609 > Timeout.RTSPulse = 0 03.03.09-18:57:23-609 > Timeout.RTSInterval = 0 03.03.09-18:57:23-609 > Timeout.ConnectTrials = -1 03.03.09-18:57:23-609 > Timeout.MaxPacketSize = 0 03.03.09-18:57:23-609 > send ident $00 00 00 00 00 00 00 00 00 0D 42 4F 4F 54 4C 4F 41 44 45 52 03.03.09-18:57:24-906 > send ident $00 00 00 00 00 00 00 00 00 0D 42 4F 4F 54 4C 4F 41 44 45 52 03.03.09-18:57:26-187 > send ident $00 00 00 00 00 00 00 00 00 0D 42 4F 4F 54 4C 4F 41 44 45 52 03.03.09-18:57:27-468 > send ident $00 00 00 00 00 00 00 00 00 0D 42 4F 4F 54 4C 4F 41 44 45 52 03.03.09-18:57:28-750 > send ident $00 00 00 00 00 00 00 00 00 0D 42 4F 4F 54 4C 4F 41 44 45 52 03.03.09-18:57:30-031 > send ident $00 00 00 00 00 00 00 00 00 0D 42 4F 4F 54 4C 4F 41 44 45 52 03.03.09-18:57:31-312 > send ident $00 00 00 00 00 00 00 00 00 0D 42 4F 4F 54 4C 4F 41 44 45 52 Also der USB-RS485 funktioniert fürs senden und empfangen. Ich habe bei Geräten hier die mit DMX arbeiten auch das RDM protokoll drinnen und da ist auch senden / lesen ohne Probleme möglich. So sieht zb. der Init des FTDI für das DMX / RDM aus. FT_ResetDevice(ftHandle); FT_SetBaudRate(ftHandle, 250000); //250kBaud FT_SetDataCharacteristics(ftHandle, FT_BITS_8, FT_STOP_BITS_2, FT_PARITY_NONE); FT_SetFlowControl(ftHandle, FT_FLOW_NONE, 0, 0); FT_Purge(ftHandle, FT_PURGE_RX); FT_Purge(ftHandle, FT_PURGE_TX); FT_SetTimeouts(ftHandle, 50, 50); lg, markus
@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
Gast
#1182325
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
Gast
#1182679
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
Gast
#1183473
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
Ändere:
1 | |
2 | |
3 | |
4 | |
5 | |
6 | |
7 | |
8 | |
9 | |
10 | |
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
Gast
#1183744
Hallo Hagen, vielen Dank für die Anpassung. Jetzt funktioniert das BootDelay wie erwartet. Schöne Grüße & schönes Wochenende!
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
Gast
#1190656
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
Gast
#1191163
Danke für schnelle und volständige Antwort. Respect! mfg Vladimir
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
Möchtest du denoch UseWDT=0 und BootMode=4 benutzen dann ändere AVRootloader.asm so ab
1 | |
2 | |
3 | |
4 | |
5 | |
6 | |
7 | |
8 | |
9 | |
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
@Toralf, probier den Bootloader per WDT zu starten das schließt schomnmal par Möglichkeiten aus:
1 | |
2 | |
3 | |
4 | |
5 | |
6 | |
7 | |
8 | |
Wenns damit geht muß irgendwas in Main() bei der Initialisierung noch fehlen. Gruß Hagen
Danke Hagen, wird aber erst heute Abend. gruß willi
@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
aja, eine Frage noch, wie führt ihr den Reset durch. Ich habe einen PullUp vom Reset zu Vcc und mit einem Taster ziehe ich Reset gegen GND. LG 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
Habs gefunden, ist ein logischer Fehler
1 | |
2 | |
ist natürlich falsch, ändere es so ab
1 | |
2 | |
Noch besser ist es so
1 | |
2 | |
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
Hast es schon gefunden, Danke. Ist ein super Bootloader, den Du da geschaffen hast. Danke nocheinmal Willi
@Willi: ändere es so ab:
1 | |
2 | |
3 | |
4 | |
5 | |
6 | |
7 | |
Für alle anderen die korregierte Version im Attachment. Gruß Hagen
Hagen, das letzte geht nicht. 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
Hallo Hagen, Danke noch einmal, schläfst Du überhaupt, einmal? Gruß Willi
Gast
#1195399
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
Gast
#1196141
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, danke, und der HEX Editor ist ein 3'rd Party Produkt, muß ich wohl mal in deren Sourcen stöbern gehen. Gruß Hagen
Gast
#1196696
wow, coole Sache hagen. Deine ausführlichen Beiträge sind immer wieder ein Genuß. cu chris
@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
Gast
#1196979
@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
Gast
#1197489
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
Gast
#1198519
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:
1 | |
2 | |
Diese Fehlermeldung ist mir leider nicht aussagekräftig genug und hilft mir nicht wirklich weiter. Hier noch der Output vom Compilieren des ethersex:
1 | |
2 | |
3 | |
4 | |
5 | |
6 | |
7 | |
8 | |
9 | |
10 | |
11 | |
12 | |
13 | |
14 | |
Platz sollte im mega32 noch genügend vorhanden sein. Frage daher: Woran liegt´s?
Gast
#1198742
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 | |
2 | |
3 | |
4 | |
Eine nichtfunktionierende Datei sieht am Ende hingegen so aus:
1 | |
2 | |
3 | |
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. :-)
Gast
#1210504
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
Gast
#1210505
Sorry again, wrong email. the correct one is luiz.catalan at gmail.com
Gast
#1210883
Hi Luiz, you can register here: http://www.mikrocontroller.net/user/register If you are registered and logged in, you can send him a mail by clicking the link behind his name.
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:
1 | |
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 | |
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:
1 | |
2 | |
3 | |
4 | |
5 | |
6 | |
7 | |
und drüber Jener:
1 | |
2 | |
3 | |
4 | |
5 | |
6 | |
7 | |
Leider immer wieder das gleiche, Connecten klappt, Falshen nicht. Gruß, Jan
Angehängte Dateien:
-
USB_RS232_Board.PNG
(3,8 KB)
Hallo, hier mein Schaltplan, wonach ich das Board geroutet, -ätzt und -lötet habe. Bye, Jan
Angehängte Dateien:
-
USB_RS232_Schaltplan.PNG
(8,6 KB)
... 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 | |
--> 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):
1 | |
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 | |
> --> 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): >
1 | |
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
Gast
#1231680
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 | |
2 | |
3 | |
4 | |
5 | |
6 | |
7 | |
8 | |
9 | |
10 | |
11 | |
12 | |
13 | |
14 | |
15 | |
16 | |
17 | |
18 | |
19 | |
20 | |
und die Methode .AppVersion: Integer ist das was du suchst. Also mit
1 | |
2 | |
3 | |
4 | |
5 | |
6 | |
fragst du das ab. Gruß Hagen
>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
Gast
#1231705
Bezw. wo muss ich Sprungadresse zur meinem Programm einfügen. Danke Oliver
@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 | |
2 | |
3 | |
4 | |
diesen Sprung bitte ein. Ansonsten bliebe noch die Möglichkeit das dein HEX File beschädigt ist. Gruß Hagen
Gast
#1231781
Hallo Herr Hagen, danke für die Info,
1 | |
2 | |
3 | |
4 | |
Hatte natürlich in meinem ASM Programm keine Sprung am Start Danke Oliver
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 | |
2 | |
3 | |
4 | |
5 | |
6 | |
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
Gast
#1244654
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:
1 | |
2 | |
3 | |
4 | |
5 | |
6 | |
7 | |
8 | |
9 | |
10 | |
11 | |
12 | |
13 | |
14 | |
15 | |
16 | |
17 | |
18 | |
19 | |
20 | |
21 | |
22 | |
23 | |
24 | |
25 | |
26 | |
27 | |
28 | |
29 | |
30 | |
31 | |
32 | |
33 | |
34 | |
35 | |
36 | |
37 | |
38 | |
39 | |
40 | |
41 | |
42 | |
43 | |
44 | |
45 | |
46 | |
47 | |
48 | |
49 | |
50 | |
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
Gast
#1250900
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
Gast
#1250921
Hallo Haagen, vielleicht bringt die Logdatei von Portmon (Sysinternals) was Gruß Hannes
Gast
#1250933
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
Antwort schreiben
Bitte melde dich an, um einen Beitrag zu schreiben.