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
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
