www.mikrocontroller.net

Forum: Compiler & IDEs Grundlegende Fragen zum Bootloader


Autor: Martin (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi @ all

Ich möchte gerne einen Bootloader für den Mega128 schreiben. Anbindung 
über USB (FT245BM). Als Dateiformat sende ich eine Hex File.

Kann ich direkt Byte für Byte des Hex Files in den Flash des AVRs 
kopieren??

Wieviel RAM kann der AVR verwenden wenn das Programm in der Bootloader 
Section liegt. Soviel wie der AVR hat??

Leider verwende ich Interrupts für das Handshake des USB Chips. 
Irgendwie muss ich die Interruptsprungtabele verschieben, habe ich 
gelesen. Wie funktioniert das genau?

Besten Dank im Voraus

mfg Martin

Autor: kosmonaut pirx (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
hallo,
zu frage 1: klaro.
zu frage 2: afaik soviel wie da.

zu frage 3: rtfm :) steht da schön drin bei der irq-beschreibung (recht 
weit vorne im wälzer). beispiel (andere mcu):
  /*!
   * \brief Enable irq vector change.
   *
   * Enables interrupt vector change by setting the appropriate bits.
   */
  static inline void enable_irq_vector_change(){
    MCUCR |= (1<<IVCE);
  }
  
  /*!
   * \brief Switch irq vector table to bootloader section.
   *
   * Switch interrupt vector table to bootloader section. 
   * Performs actions as described at page 64 of documentation.
   */
  static inline void change_irq_vector_to_bl(){
    uint8_t mcucr_save = MCUCR;
    enable_irq_vector_change();
    MCUCR = mcucr_save | (1<<IVSEL);
  }
hth,
bye kosmo

Autor: kosmonaut pirx (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
achja, frage 1: byte für byte schreiben ist so nicht, habe ich 
missverstanden. musst schon das bootloader-prozedere befolgen, steht 
auch im manual oder siehe avr-libc oder siehe viele viele 
bootloader-implementationen.

Autor: Philipp Co (ba4_philipp)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich habe zu genau dem Thema auch ein paar Fragen und ich denke es passt 
hier vielleicht rein.

Also ich habe ein HEX File in dem zB dies hier drinsteht:

:10 0000 00 12C02BC05BC04AC039C027C026C025C0 63
:10 0010 00 24C023C022C022C020C01FC01EC01DC0 DB
:10 0020 00 1CC01BC01AC011241FBECFE5D4E0DEBF 28
:10 0030 00 CDBF10E0A0E6B0E0E6E1F0E102C00590 3F

:10 0040 00 0D92A036B107D9F710E0A0E6B0E001C0 EC
:10 0050 00 1D92A036B107E1F738C1D2CF1F920F92 9F
:10 0060 00 0FB60F921124CF93DF93CDB7DEB7DF91 98
:10 0070 00 CF910F900FBE0F901F9018951F920F92 67
...

Ich habe die Zeilen etwas auseinandergerückt. Wenn ich die Spezifikation 
von Intel da richtig verstanden habe, dann ist 10 die Länge der Bytes im 
Datenfeld hier also 16 (dez). Danach folgen 2 Byte für die 
Anfangsadresse des Datenblocks. Jetzt der Datentyp also 00 bedeutet hier 
Daten. Nun 16Byte Daten und am Ende ein Byte Checksumme. Ist das soweit 
richtig?

Wenn ich nun einen Bootloader bauen möchte, dann würde ich gerne diese 
boot_program_page (uint32_t page) Beispielfunktion verwenden.

Ich dachte mir das in etwa so: Ich lege einen Buffer an der 64 Byte groß 
ist. Lese sozusagen 4 Zeilen aus dem Hexfile in den Buffer und rufe dann 
diese boot_programm_page Funktion auf.

Meine Frage ist nun aber, was muss ich als page übergeben? Ist das immer 
der Offset aus dem Hexfile für die nächsten 65 Byte? Also bei den ersten 
64 Byte 0x0000 beim zweiten schreiben dann 0x0040 usw?

Vielen Dank schonmal
Gruß Philipp

Autor: irgendein Rahul (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>Ist das soweit richtig?
Ja (zumindest habe ich Intel-HEX bis jetzt auch so verstanden).

Ist der Bootloader-Schreibvorgang nicht mit einer bestimmten Blocklänge 
verbunden?

>Ist das immer der Offset aus dem Hexfile für die nächsten 65 Byte? Also
>bei den ersten 64 Byte 0x0000 beim zweiten schreiben dann 0x0040 usw?

Im Prinzip schon. Wenn du allerdings Adress-Sprünge (aus welchen Gründen 
auch immer) in der HEX-Datei hast, läuft dein Verfahren schief. (Ist 
zwar unwahrscheinlich, aber möglich...)

Besser wäre es dann wohl, immer nur eine Zeile auszuwerten und zu 
schreiben.

Autor: Philipp Co (ba4_philipp)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ja aber man muss ja immer 64Byte (eine Page) auf einmal schreiben, so 
wie ich das verstanden habe, deshalb braucht man auch den Buffer usw. 
Wenn dann müsste man bei einem Sprung (wo kann sowas passieren?) den 
Rest irgendwie auffüllen.

Oder hab ich da was falsch verstanden?

Autor: Herbert (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Versteht sich eigentlich von selbst, daher duerfte dieser Beitrag
ueberfluessig sein:

Du musst natuerlich die Bytes auch noch vom ASCII-Hex Format
in's Binaerformat wandeln.

Hebbe.

Autor: Philipp Co (ba4_philipp)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Herbert worauf bezieht sich das nun?

Autor: Herbert (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>@Herbert worauf bezieht sich das nun?

Darauf:

>>    Kann ich direkt Byte für Byte des Hex Files in den Flash des AVRs
>>    kopieren??

Die Formulierung legt nahe, dass der OP die Bytes direkt so,
wie sie ueber dir Leitung kommen, in's Flash schreiben moechte
(Annahme: Es findet keine Hex-Binaerwandlung auf PC Seite
statt, was wohl halbwegs unsinnig waere)

Autor: Martin (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Jetzt weiß ich schon mehr :)

Einige Fragen hab ich noch ;)

Also wie genau wird die CRC des Intel HEx Formates gebildet??

Zur Hex Binär Wandlung. VErstehe ich das richtig. ICh wandler die 2er 
Hex Zahlen in Dezimale Zahlen um, fülle damit die Bootpages und sende 
die dann über die Schnittstelle, oder??

>>Ist das immer der Offset aus dem Hexfile für die nächsten 65 Byte? Also
>>bei den ersten 64 Byte 0x0000 beim zweiten schreiben dann 0x0040 usw?

>>Im Prinzip schon. Wenn du allerdings Adress-Sprünge (aus welchen Gründen
>>auch immer) in der HEX-Datei hast, läuft dein Verfahren schief. (Ist
>>zwar unwahrscheinlich, aber möglich...)

Das werde ich einbeziehen...

Gruß Martin

Autor: Martin (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
So jetz weiß ich mehr. Bzw ích vermute es ;)

Also die CRC ist die Summer der Reste jedn Bytes bei einer Division 
durch 256. Sprich Summer von Moduko 256 bei jedem Byte. Stimmt das so??


Gefunden hab ich das hier:
http://www.schulz-koengen.de/biblio/intelhex.htm

Unten sind auch Beispiele. Bei dem 2. Beispiel (Datenbytes sind alle auf 
0) komme ich aber nicht auf die CRC. Nach meiner Methode komme ich auf 
0x41. Stimmt das?

Danke im Voraus

Gruß Martin

Autor: Philipp Co (ba4_philipp)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Das mit dem 2er Komplement werd ich auch gleich mal nachrechnen, ein 
sehr guter Link :)

Was mir noch nicht ganz klar ist: Kann ich an die boot_programm_page() 
Funktion die Startadresse der Daten übergeben, oder werden die Pages 
einzeln durchnummeriert? Also Page 1, 2 , 3 zB mit je 64 Byte oder 
übergebe ich als Page Adresse dann zB 0x0040 für die 2. Page weil es ja 
die nächsten 64 Byte (oben hatte ich irgendwo 65 stehen, sollte 
natürlich 64 sein) sind?

Und auch nochmal zu dem angesprochenem Sprung:
Sollte es nun wirklich in dem Hex File mal so einen Sprung geben, füllt 
man dann Raum zwischen den Adressen mit 0xFF? (Man muss ja die Page 
irgendwie beschreiben)

@Martin, ich hoffe es stört dich nicht, das ich in deinem Thread einfach 
so mit rumfrage, aber ich denke wir stehen vor den gleichen Problemen :)

Vielen Dank schonmal
Gruß Philipp

Autor: Karl Heinz (kbuchegg) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Also die CRC ist die Summer der Reste jedn Bytes bei einer Division
> durch 256. Sprich Summer von Moduko 256 bei jedem Byte. Stimmt das so??

Das klingt reichlich kompliziert.

Du zählst einfach alle Bytes zusammen, wobei du eventuelle
Überläufe der Summe von einem Byte ins nächste ignorierst.
Du rechnest einfach alles mit 8 Bit (In Assembler: in
einem Register die Summe bilden und ein eventuelles Carry
bleibt aussen vor. In C: die Summe ist ein uint8_t bzw.
unsigned char)

1. Zeile
10 + 00 + 50 + 00 + 69 + 73 + 20 + 70 + 72 + 6F +
67 + 72 + 61 + 6D + 20 + 63 + 61 + 6E + 6E + 6F

= 683

Da wir aber nur mit Bytes rechnen: 83

Die Prüfsumme ist daher das 2er Komplement davon: FF - 83 + 1 = 7D

Der Sinn der Berechnung des 2er Komplements besteht darin,
dass, wenn ich die Prüfsumme in der Addition auch noch mit
dazu nehme, immer 0 rauskommt.  83 + 7d = 100. Wir rechnen
aber im 8 Bit Raum und ignorieren alle Überträge: Also 00


2. Zeile

10 + 11 + 20 + ein ganzen Haufen 0  = 41

Die Prüsumme ist das 2 er Komplement: FF - 41 + 1 = BF

Beim Testen:
10 + 11 + 20 + ein ganzer Haufen 0 + BF = 100, also 00 -> passt

In Assembler rechnest du das 2 er Komplement natürlich nicht
wie oben aus. Viele Prozessoren haben einen Befehl dafür.
Wenn nicht, dann haben sie einen Befehl für das 1er Komplement
(alle Bits umdrehen) gefolgt von einem inc auf das Register.
Gibt es auch kein 1er Komplement, dann macht man einen
XOR mit FF, gefolgt vom inc

In C würde man wohl auch schreiben:
   Pruef = ~Summe + 1;
oder ganz einfach:
   Pruef = -Summe;

Besonders in der letzten Formulierung ( Pruef = -Summe )
sieht man sehr schön, warum da am Ende 0 rauskommen muss.
Die Prüfsumme wird geerade so konstruiert, dass sie die
Differenz zu 0 ist.



Autor: Joe Die (kosmonaut_pirx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
hallo,

>Was mir noch nicht ganz klar ist: Kann ich an die boot_programm_page()
>Funktion die Startadresse der Daten übergeben, oder werden die Pages
>einzeln durchnummeriert? Also Page 1, 2 , 3 zB mit je 64 Byte oder
>übergebe ich als Page Adresse dann zB 0x0040 für die 2. Page weil es ja
>die nächsten 64 Byte (oben hatte ich irgendwo 65 stehen, sollte
>natürlich 64 sein) sind?

woher hast du die routine boot_programm_page()? da sollte zu erfahren 
sein, wie das zu machen ist.

Autor: Philipp Co (ba4_philipp)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich habe diese Funktion identisch in einigen Bootloader gesehen und als 
ich danach gegoogelt habe, habe ich dies hier gefunden:

http://www.nongnu.org/avr-libc/user-manual/group__...

Leider kam dieser Übergabewert immer von der Gegenseite des Bootloaders 
in den Beispielen, die ich gesehen habe, deshalb weiß ich nicht was dort 
eingestzt wurde. Und auch in der Beschreibung aus dem Link hier werde 
ich nicht schlau.

Hat jmd einen Hinweis für mich? Diese Funktion würde ich auch gerne 
benutzen.

Vielen Dank
Gruß Philipp

EDIT: Hmm, wo ich mir die Funktion nochmal so ansehe, da wird die 
Adresse ja bei jedem Byte inkrementiert. Dann erscheint es vielleicht 
doch logisch die Adresse des 1. Bytes der Page zu übergeben. Also um bei 
meinem Beispiel von oben zu bleiben. Bei der 2. Page übergebe ich dann 
0x0040 für die 64Byte in meinem Buffer.
Sehe ich das richtig?

Autor: Joe Die (kosmonaut_pirx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
ah ja, sorry, habe ich überlesen (gedanklich zu weit oben).

du nimmst irgend eine adresse aus der page, die du schreiben willst. 
also meinethalben 0x40.
vorher sollte man sich aber einmal schlau machen, wie groß die page auf 
der mcu eigentlich ist. ich bezweifle einfach mal die 64 byte, aber mag 
ja sein. hängt vom controller ab. ist dein puffer kleiner als die page, 
hast du ein problem, da die routine die page vorher platt macht. das 
kann man sicher ändern :) oder aber den puffer so anpassen, das die page 
beim flashen nie wieder angefasst wird. letzteres ist meiner meinung 
nach ein wenig unflexibel, aber soll jeder halten wie er mag.

wo wird denn die adresse inkrementiert?

Autor: Philipp Co (ba4_philipp)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Die Adresse wird bei jedem Aufruf von boot_page_fill inkrementiert, also 
für das Byte (page + i).

Zu der Page Grösse befrag ich nochmal das Datenblatt, weiß gar nicht 
mehr wo ich die 64Byte her hatte. (Ging um den Mega 8)

Vielen Dank
Gruß Philipp

EDIT: Laut S.225 32 Words -> 64Bytes

Autor: Joe Die (kosmonaut_pirx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
ok, wir reden von zwei verschiedenen dingen.

voraussetzungen:
1. der avr besitzt einen sog. temporary buffer. der ist so groß wie eine 
page. der inhalt dieses und NUR dieses puiffers wird in eine page 
geschrieben.

das flash-prozedere lautet daher:
1. der temporary buffer muss gefüllt werden. das nennt sich bei atmel 
"page loading". in der avr-libc nennt sich das boot_page_fill (ist nur 
ein macro). das füllen geschieht word- weise, deswegen der uint16_t im 
beispiel der avr-libc.

2. der inhalt des temporary buffers wird in eine page geschrieben. 
welche page, das hängt vom inhalt des z-pointers ab. die avr-libc fasst 
die schritte dazu mit dem boot_page_write- macro zusammen.

in der doku steht das sehr ausführlich drin, afaik sogar mit einem 
beispiel, wenn auch in asm.

Autor: Philipp Co (ba4_philipp)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Achso, die Bootloader die ich bisher gesehen habe, die hatten ein 64 
Byte großes Array (dann wohl im RAM), darin wurden die Daten erstmal 
geschrieben, zB vom I2C kommend. Wenn 64 Byte voll waren, dann wurde 
diese boot_program_page() aufgerufen. Aber, wenn es so ist wie du sagst, 
dann kann ich mir doch eigentlich das 64 Byte Array sparen und mit 
boot_page_fill() direkt die Bytes in diesen Puffer schreiben und nach 64 
Bytes einmal boot_page_write() aufrufen. Die page Variable um 64 erhöhen 
und bei boot_page_fill wieder von vorne anfangen.

Oder hab ich das jetzt falsch verstanden?

Gruß Philipp

Autor: Joe Die (kosmonaut_pirx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
hm, könnte man - meiner meinung nach - auf den ersten blick so bringen.
vorsicht ist auf jeden fall geboten, da du den temp buffer nur einmal 
pro word schreiben kannst. willst du nochmal auf dieses word schreiben, 
musst du den ganzen puffer kicken (per page write oder rwwscre) und von 
vorne anfangen (seite 216 doku)

die doku vom atmega8 sagt auch, das beim page_write die letzten 6 bit 
der adresse (also im beispiel von "page") auf 0 sein müssen. d.h. 
page-aligned vorgehen, 0x00, 0x40, 0x80, 0xC0, 0x100 usw. sorry, da gabs 
wohl ne änderung zwischendurch.

Autor: Francesco Na (franceso-)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Das im Ram zwischenzubuffern, hat auch andere Vorteile.
Z.b. kann man mit einem Bottloader, der die Dateien entschlüsselt,
es gibt so auch recht kleine Verschlüsselungsalgorithmen, getrost ein
verschlüsseltes Firmwareupdate rausgeben, ohne daß man das Produkt 
nachbauen
kann und einfach das downloadbare update raufschmeissen kann.
Die Erweiterung zu den bestehenden bootloader gibt es, werden nur nicht
im Internet zum Download bekanntgegeben.

Autor: Philipp Co (ba4_philipp)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ja war auch nur eine Frage zum Verständnis. Ich werde am Donnerstag 
(leider kann ich nicht früher, obwohl es langsam in den Fingern juckt :) 
) mal anfangen zu testen.

Das ganze möchte ich für mein Auto haben, um die schlecht zugänglichen 
Module per CAN zu programmieren (keine Angst ist ein eigener CAN Bus, 
einen CAN hatte mein altes Auto vorher gar nicht)

Wenn ich den Bootloader geschrieben habe, wie sag ich dem gcc 
eigentlich, dass es ein Bootloader ist und er das Hex File so anlegt, 
dass zB avr-dude den ganzen Kram in der Bootloader Section ablegt und 
nicht am Anfang des Flash?

Und der Bootloader hat ja eine main() und diesen jump_to_app Kram (der 
einfach auf Adresse 0x0000 springt) Muss ich vorher noch etwas beachten 
oder kann ich (wenn ich die IRQs nicht umgebogen habe) einfach jederzeit 
aus meinem Bootloader in die normale App springen? Dann könnte ich mir 
das doppelte initialisieren des MCP2515 sparen, weil das ja schon der 
Bootloader erledigt hat. Und muss in der App danach noch etwas beachtet 
werden oder kann ich die so programmieren wie früher auch mit einer 
main() usw? (zweimal main() sollte ja egal sein, weil es ja woanders 
liegt)

Vielen Dank schonmal
Sorry das es so blöde Fragen sind, aber ich habe bisher keine Antworten 
dazu gefunden.

Gruß Philipp

Autor: Francesco Na (franceso-)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Also, bei den bootloadern über i2c, can usw. ist es üblich, daß
die Applikation zum Bootloader springt, nicht umgekehrt.
Dies ist darin begründet, daß das modul nur über ein Netzwerk erreichbar
ist, eben nicht direkt. Üblicherweise haben die eine fixe serielle 
number,
die Eindeutig ist, z.B jahr,monat,tag,id als 32bit nummer sowie eine 
kleinere
16bit Random sowie eine 8bit priorität und eine 8bit produktnummer, mit 
der
gewisse Verhalten gesteuert werden, die dann nötig sind, um so ein 
Netzwerk
von unprogrammierten Modulen gleichzeitig in kurzer zeit über das 
Netzwerk
zu lokalisieren, steuern und uploaden. Es kann noch einen hw-jumper 
geben,
wobei dann der bootloader einspringt, aber die ist eigentlich nur für 
den
absoluten Fehlerfall.

Autor: Philipp Co (ba4_philipp)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Naja die CAN Funktionen brauche ich ja eh in der Anwendung und in dem 
Bootloader. Ich dachte mir aus Sicherheitsgründen startet es ganz normal 
wie die seriellen Bootloader mit dem Bootloader, so ist sichergestellt, 
dass ich das Modul immer flashen kann notfalls indem ich kurz den Strom 
unterbreche (Jumper ist schlecht, weil zB je ein Modul in der Tür ist da 
müsste ich zum Jumpern die Türverkleidung entfernen).

Den Bootloader wollte ich vom Programm anspringen, indem ich über eine 
CAN Nachricht das Modul in eine Endlosschleife springen lasse und so der 
Watchdog das Modul neustartet.

Oder gibt es weitere Gründe den Bootloader aus der Applikation 
anzuspringen und diesen nicht beim start anzuspringen?

Gruß Philipp

EDIT: Der Bootloader muss dafür natürlich direkt pro Modul ansprechbar 
sein.

Autor: Francesco Na (franceso-)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Und was ist, wenn das Modul aufgrund eines Fehlers/EMF/... per Watchdog
rebootet, kann dann das Modul und der Flash korrumpiert werden ?
Weiters, wenn du mehrere module hast, und du den Strohm wegnimmst,
dann kannst du nicht alle gleichzeitig Flashen. OK, die haben eine 
eindeutige
CAN-Addresse, aber was, wenn das neue Firmware nicht funkt und den WDT
aktualisiert. Dann musst du einen cold-reset machen, und alle module
wollen neu geflasht werden.

Autor: Francesco Na (franceso-)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Bootloader für mega8 und mega32 über CAN gibt es bei dem HCAN projekt.
Solltest dir mal ansehen.

Autor: Philipp Co (ba4_philipp)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Warum sollte ich nicht alle gleichzeitig Flashen können? Außerdem ist 
das doch auch nicht notwendig. Ich habe mir vorgestellt, das sie beim 
starten eine Meldung senden welche Firmware Version sie zur Zeit haben 
und warum sie resetet haben (das mache ich auch jetzt schon). Darauf 
bekommen sie vom PC dann entweder den Befehl eine neue Firmware zu 
empfangen oder ganz normal die Firmware zu starten. Kommt diese Meldung 
meinetwegen nicht innerhalb von 500ms so starten sie ganz normal die 
Firmware.

Also ein Watchdog reset würde das Modul dann maximal 500ms ausser 
Gefecht setzen, aber wenn der auftritt läuft eh irgendwas nicht richtig.

Wenn das Modul wirklich aufgrund falscher Firmware zwar den Watchdog 
resetet, aber trotzdem nicht auf CAN Nachrichten hört, dann kann ich 
immernoch einfach die Sicherung rausziehen und wieder reinstecken. Ich 
kann doch trotzdem per CAN gezielt einem Modul sagen, dass es nun eine 
neue Firmware bekommt. Die anderen starten eh nach 500ms neu (falls sie 
mit an der Sicherung hingen) oder sie bekommen sofort die Nachricht, 
dass sie normal starten sollen.

Habe ich dabei etwas übersehen? Wie gesagt bisher sind das nur meine 
Gedanken noch läuft es nicht so.

Gruß Philipp

Edit: Gerade das Szenario mit dem falschen Firmware die den Watchdog 
trotzdem zurücksetzt spricht IMHO für die Version mit dem starten des 
Bootloaders beim Reset, denn sonst kann man das Modul ja gar nicht mehr 
flashen ohne diesen oben erwähnten Jumper. (Denn die falsche Firmware ja 
auch ignorieren könnte)

Autor: Ulrich P. (uprinz)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi!

Ich hoffe ich darf mich hier auch einklinken, denn ich habe sehr 
ähnliche Probleme.

Basis bei mir ist ein ATmega32, auch er hat Pages a 64 Bytes. Das mit 
den Pages ist vollkommen OK und meine Software braucht auch nur in Pages 
aktualisiert zu werden.
Ein Problem habe ich schon gelöst, da man im GCC eigene Segmente 
definieren kann und daher kann ich Versionsnummern und andere Infos in 
der letzten Page unter dem Bootloader unterbringen.

Ein großes Problem habe ich aber mit dem Bootloader:
Entweder muss ich ihn in das Projekt selbst einbinden. Das würde mir 
helfen, da ich komplexe Serielle Treiber für ein unidirektionales sehr 
schnelles RS485 Netz nur einmal schreiben brauche und diese auch aus der 
Cleint-Software nutzen kann. Das würde es aber notwendig machen, ggf. 
auch den Bootloader selbst austauschbar zu machen. Aus 
Sicherheitsgründen muss also ein Bootloader-Bootloader ins System. Oder 
ISP ist angesagt. Macht Spaß bei 100 Modulen pro Schrank und mind. drei 
Schränken. Ist etwa so nervig, wie das zerlegen und zusammenbauen von 
Autotüren mit Folienversiegelung.

Also die andere Version:
Der Bootloader enthält eine abgespeckte Version der RS485 Treiber und 
ist autark. Also müssen keine Querverweise in der Software auf ihn 
existieren und nur eine virtuelle Funktion für seinen Ansprung ist 
nötig.
Aber nun kann AVR Studio mit AvrGCC nicht mehr mithalten. Die Summe 
aller Segmente ist immer der komplette Flash des mega32. Ich finde keine 
Option dem LD beizubringen, dass mein mega32 nur ein Flash von 0x3800 
hat.

Wie kann ich das dem Linker beibringen? Ich hab schon gesucht, aber ich 
sehe es nicht. Die beschriebene Lösung würde auch Philipp helfen, denke 
ich.

Danke im Voraus
Ulrich

Autor: Martin (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
So hab nun wieder ein paar Fragen ;)

Angenommen ich benutze einen Meg128 mit 128kB Flash. Wie schaut das dann 
im Hex File aus??

Im Hex File kann die Adresse bis FFFF = 64kB gehen. Wie kann man das 
lösen??

Wie sind die Flashbytes im Ausgangszustand?? Auf 0 oder FF?? Es ist ja 
sicher sinnvoll, bzw eiin Muss, die restlichen Bytes zu überschreiben, 
oder??

Mein Bootloader bietet derzeit auch die Option den Flash auszulesen und 
daraus eine Hexfile erzeugen. Doch derzeit ist das noch umständlich... 
Denn angenommen ich hab einen Mega128 mit 4kB Code im Flash, dann 
erzeugt mir mein Programm ein Hexfile das den ganzen Inhalt des Flashs 
beschreibt.

Kann man irgendwo im Avr oder im geflashten Hexfile auslesen wieviel 
Code sich im Flash befindet??

Kann man beim Avr die ID des jeweiligen Bausteins auslesen??
Gibt es wo eine Tabelle wo man sieht welche ID welcher µC ist??

Danke im Voraus

Gruß Martin

Autor: Martin (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hat jemand Ahnung?

Autor: Martin (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Gibt es eine Liste, wo alle Avrs aufgelistet sind, die eine Bootloader 
Section haben?

Gruß Martin

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Alle Megas >=8kB

außer Mega103

Peter

Autor: Martin (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Danke,

Und wie siehts mit den ATinys?? Die haben keine?
Und AT90er Serie? zB die USB und PWM Reihe?

Wie schauts nun aus bei Hexfiles > 64kB??

Kann mann irgendwie per RS232 oder anderswärtig (aber nicht über ISP) 
die Device ID auslesen?

Steht im Avr irgendwo, wie groß die geflashte File ist?

Gruß Martin

Autor: Tim S. (suxx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
hi

die funktion könnte ganz nützlich sein für dich.

Beitrag "Hexastring konvertieren"

Autor: Martin (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Keiner eine Ahnung?

Autor: Martin (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi, hab noch immer keine Lösung gefunden. Weiß da jemand mehr?

Autor: kosmonaut pirx (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
hallo,

>Und wie siehts mit den ATinys?? Die haben keine?

keine ahnung, bei atmel schauen.

>Und AT90er Serie? zB die USB und PWM Reihe?

die 90er CAN haben. ansonsten: siehe oben.

>Wie schauts nun aus bei Hexfiles > 64kB??

schau dir an, wie hex-files aufgebaut sind. google ist dein freund.
z.b. da:
http://en.wikipedia.org/wiki/Intel_HEX
meines wissens nach wird ein "02, Extended Segment Address Record" 
verwendet, wenn man bei 'FFFF' ankommt, und dann geht's wieder bei 
'0000' los. hab aber grad kein beispiel-hex-file parat, aber schon mal 
gesehen sowas.

>Kann mann irgendwie per RS232 oder anderswärtig (aber nicht über ISP)
>die Device ID auslesen?

das soll nicht gehen.

>Steht im Avr irgendwo, wie groß die geflashte File ist?

nicht dass ich wüsste, und warum sollte es auch.

bye kosmo

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.