Hallo! Mein Bootloader über Ethernet funktioniert wunderbar, er schreibt nur eine einzige Page (256 Bytes) nicht, genau ab Adresse 0x7D00 (32000) bis 0x7DFF. Diese lässt er aus (alles auf 0xFF), schreibt aber danach normal weiter. Es liegt definitiv nicht an meinem Code, da ich die Daten vor dem flashen nochmal seriell ausgegeben und geprüft habe. Über ISP ist der komplette Flash einwandfrei beschreibbar. Controller ist ein Atmega644, der Bootloader ist in den letzten 4 kB. Der Code zum eigentlichen flashen ist genau der im Abschnitt "API Usage Example" von http://www.nongnu.org/avr-libc/user-manual/group__avr__boot.html Fuses stehen so: http://tinyurl.com/9h45rq Bin etwas ratlos, hab mir die boot.h schon näher angeschaut finde aber keinen Anhaltspunkt. Warum immer genau ab Adresse 32000? Vielleicht ein Fehler in der avr-libc, aber wie finde ich den! Freue mich über Tipps! Grüsse, Stefan
Hi, das ist schon ein komisches Phänomen. Sollte es tatsächlich ein Fehler vom GCC sein, bleibt nichts anderes als ein Blick in den generierten Assembler Code. Ansonsten wäre eine Implementierung dieses Schreibzugriffs (mit irgendwelchen Dummywerten) in Assembler der Test, ob nicht deine mcu ne Macke hat. So long, Alex
chillfactor wrote: > Sollte es tatsächlich ein Fehler vom GCC sein, bleibt nichts anderes als > ein Blick in den generierten Assembler Code. Die ganze SPM-Behandlung ist bereits purer Assemblercode (allerdings per inline asm).
Stefan Bachm. wrote: > Mein Bootloader über Ethernet funktioniert wunderbar, er schreibt nur > eine einzige Page (256 Bytes) nicht, genau ab Adresse 0x7D00 (32000) bis > 0x7DFF. Diese lässt er aus (alles auf 0xFF), schreibt aber danach normal > weiter. Da hilft wohl nur: [Glaskugelmodus ein] - es liegt an einer Lib-Funktion (unwarscheinlich) - es liegt an Deinem Programm (sehr warscheinlich) - es liegt an Deinen Daten (auch möglich) [/Glaskugelmodus aus] > Es liegt definitiv nicht an meinem Code, Vorsicht! Bisher wurden alle, die das behauptet haben, nach der Lösung sehr kleinlaut. Insbesondere, wenn sie kein kurzes Codebeispiel beifügen, welches den Fehler reproduzieren läßt. > Der Code zum eigentlichen flashen ist genau der im Abschnitt "API Usage > Example" von > http://www.nongnu.org/avr-libc/user-manual/group__avr__boot.html Genau ist nie was. Weblinks können sich jederzeit ändern. Jeder Leser hier hat natürlich auch ganz große Lust, sich erstmal mühsam das nötige zusammen suchen zu müssen, was Du vielleicht gemeint haben könntest. Und dann weiß er immer noch nicht, wie Du es eingebunden hast. Peter
Ok, hier ein einfacher Beispielcode, mit dem ich den Fehler reproduzieren kann: http://rafb.net/p/uyWWSL64.html Der Bootloader schreibt ein 'B' seriell raus, wartet auf ein 'z', schreibt 'S', flasht sich selbst bis 0xEFFF mit Ziffern von 0 bis 255 (jeweils eine page) und am Ende ein 'R'. Im Anhang ein Auszug des Flash, mit Usbasp gelesen. Habe Winavr Version 20081205. Heute abend kann ich das Prozedere an einem zweiten Atmega ausprobieren, der ist zwar im Produktiveinsatz aber den Fehler will ich unbedingt beseitigen, vorher brauch ich kein Netzwerkkabel ziehen ;) >Jeder Leser hier hat natürlich auch ganz große Lust, sich erstmal mühsam >das nötige zusammen suchen zu müssen, was Du vielleicht gemeint haben >könntest. >Und dann weiß er immer noch nicht, wie Du es eingebunden hast. Mühsam? Was meinst du damit? Grüsse, Stefan
Es scheint der Atmega zu sein, auf dem zweiten funktioniert das ganze einwandfrei. Merkwürdig..
Stefan Bachm. wrote:
> Merkwürdig..
Ein Unterschied zu ISP ist, dass du bei ISP einen chip erase als
erstes machst, während der Bootloader nur einen page erase macht.
Kannst ja mal gucken, ob du die Page noch auf 0x00 geschrieben
bekommst (ohne page erase).
Scheint aber wirklich einfach nur kaputt zu sein.
Stefan Bachm. wrote: > Es scheint der Atmega zu sein, auf dem zweiten funktioniert das ganze > einwandfrei. Merkwürdig.. Finde ich auch. Ist das wirklich das gleiche Hex-File und die gleichen Fuses? Mit welcher Taktquelle betreibst Du denn den 644? Ich hab mal versehentlich nen AVR übertaktet, da hat dann der SPM-Befehl auch gesponnen. Ich nehme bei Quarzbetrieb auch immer den full-swing-Mode, der Stromsparmode ist sauempfindlich gegen Störungen auf VCC. Peter
Es ist auch wirklich das gleiche Hexfile und die gleichen Fuses, hab mehrere einstellungen probiert, auch ohne Brownout etc. Taktquelle ist bei beiden ein Quarz mit 8 Mhz, habs grad probiert mit Full Swing Crystal aber genau das gleiche. Der einzige Unterschied liegt noch in der Stromversorgung, ich tausche aber mal beide IC's gegenseitig um ganz sicher zu gehen. Werd auch mal den Quarz auslöten und mit 1 Mhz probieren.. Vielen Dank für die Hilfe! Grüsse, Stefan
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.