Hallo Leute!
Ich beschäftige mich im Moment mit dem Thema Bootloader und hab hier
deshalb die Beiträge zu diesem Thema durchgelesen.
Dabei ist mir die Idee gekommen ob es denn nicht möglich wäre via
Ethernet zu flashen, entweder mit oder ohne Bootloader? Den ENC25J60
z.B. kann man ja an die Pins auf denen auch ISP liegt anschließen (also
MOSI, MISO, SCK). Nur mit RESET müsste man sich noch was überlegen.
Wie sinnvoll das ganze ist ist dann halt auch noch die Frage...
Eine Upgradefunktion ähnlich wie bei einem Router, also per
"Browser-Upload" wäre sicherlich sinnvoller. Ist aber sicherlich nicht
ganz so einfach, sonst würde es ja schon jemand machen ;-)
Bin mal gespannt was ihr dazu so meint.
da hast du was falsch verstanden.
die pins miso, mosi, clock und ss sind pins der SPI - einer
standard-schnittstelle. µC's können über verschiedene schnittstellen
programmiert werden. jtag z.b. gibts auch, oder alternative serielle
schnittstellen.
der enc28j60 ist ein spi-slave-device, der wird von selbst bestimmt
nicht reden. und schon gar nicht so, dass er einfach daten, die über die
ethernet-schnittstelle kommen, an der spi ausgibt. schon allein deswegen
nicht, weil da mac-adressen, länge-byte, usw im datenstrom enthalten
sind.
was du machen kannst, ist einen bootloader zu schreiben, der die daten
über einen tcp- oder udp-stack oder ein andres paketformat vom enc28j60
bekommt, sie zum flashen passend zusammensetzt und dann entweder die
flash self-programming eigenschaft nutzt und sein eignes flash
beschreibt, oder die daten an der SPI an einen ziel-µc übergibt und den
damit flasht.
Das das noch keiner von den Webserver-Experten gemacht hat ???
Das ist bei ZILOG EZ8 Encore via Ethenet Brenner gemacht.
Besonders bei den neuen LAP-Tops ohne serielle-u. paralelle .
Das geht auch noch über W-Lan an den Router.
Guter Tip.
Gruss Holger
Danke für die schnelle Antwort!
Ich dachte mir schon dass es nicht geht und hatte auch nicht vor so
etwas zu bauen. Ehrlich gesagt wollte ich hauptsächlich eien Antwort auf
die Frage WIESO es nicht geht, und die kam ja prompt ;-)
Das mit einem zweiten Controller als "Übersetzer" geht war mir klar.
Würde es denn jetzt z.B. auch gehen im Programm selbst per tcp/udp Stack
die Daten zu empfangen und von dort aus die Flash self-programming
Eigenschaft zu nutzen. Also das ganze ohne Bootloader, da der ja nur
beim Neustart aktiv ist?
Ich frage nur um meine Kenntnisse aufzupolieren ;-)
Sab wrote:
> Das das noch keiner von den Webserver-Experten gemacht hat ???
Was soll das bringen? Ganz schön aufwendig. Außerdem müsste man dann
einen Webserver-Bootloader in den AVR implementieren, was die
Bootloader-size nicht zulässt.
Self Programming ohne Bootloader geht nicht, da du ja nicht Daten im
Flash überschreiben kannst, wenn dort gerade ein Programm heraus
ausgeführt wird.
Mit einem externen Speicher, etwa einem DataFlash, geht es sehr wohl.
Das Hauptprogramm inklusive TCP oder sonst einem Stack holt die Daten
vom ENC, schreibt sie (aufbereitet) in das externe Flash. Dann wird in
den Bootloader gesprungen, der dann nur noch eine Kopie vom DataFlash in
den AVR erledigen muß.
Also auch von mir ein Beitrag zu diesem qualitiativ und fachlich äußerst
anspruchsvollen Thread:
>Ich dachte mir schon dass es nicht geht
doch klar geht das. Hab ich letztens für nen Renesas gemacht,
dürfte beim ATMEGA grundsätzlich auch gehen, Der Flash-Code muss
eben nur im RAM laufen, der Rest (ENC-Treiber, UDP) kann ganz normal
ausgeführt werden. Code Größe bei mir ~4kB - nicht auf minimale Größe
getrimmt.
>Was soll das bringen? Ganz schön aufwendig
überleg mal selbst, was es wohl bringen könnte, wenn man netzwerkfähige
Embedded-Systeme auch über ein Netzwerk updaten kann.
>Mit einem externen Speicher...
son Quatsch
>da du ja nicht Daten im Flash überschreiben kannst, wenn dort>gerade ein Programm heraus ausgeführt wird.
doch, lagerst du Flash Agorithmus in RAM aus, geht es
Frank wrote:
> dürfte beim ATMEGA grundsätzlich auch gehen, Der Flash-Code muss> eben nur im RAM laufen, ...
Das will ich sehen, wie du einen ATmega dazu bekommst, Code aus dem RAM
auszuführen.
Chris wrote:
> Dabei ist mir die Idee gekommen ob es denn nicht möglich wäre via> Ethernet zu flashen, entweder mit oder ohne Bootloader? Den ENC25J60> z.B. kann man ja an die Pins auf denen auch ISP liegt anschließen (also> MOSI, MISO, SCK). Nur mit RESET müsste man sich noch was überlegen.
Wenn Du fit mit Ethernet bist, kannst Du Dir natürlich auch einen
Bootloader über Ethernet schreiben.
Ich hatte bisher weder die Notwendigkeit noch Zeit, sowas zu tun.
Ich mache das stinknormal über die UART (USB-UART-Konverter).
Es gibt auch keinerlei Größenbeschränkung für den Bootloader außer die
gesamte Flashgröße.
Es muß nur die eigentliche Schreibroutine im Bootbereich liegen und
Interruptcode, falls man Interrupts benutzt.
Der Rest des Bootloadercode kann auch unter dem Bootbereich liegen,
falls dieser nicht ausreicht.
> Eine Upgradefunktion ähnlich wie bei einem Router, also per> "Browser-Upload" wäre sicherlich sinnvoller.
Ich bin kein Fan von vielen Mausschubsen müssen.
Der Bootloader startet bei mir automatisch nach dem erfolgreichen
Compilieren ganz ohne jeden zusätzlichen (unnützen) Mausschubser.
Stupide Tätigkeiten sollte man sich besser ersparen.
Peter
>Das will ich sehen, wie du einen ATmega dazu bekommst, Code aus dem RAM>auszuführen.
Der eingebaute Bootloader kann flashen, also kann ein 2nd-Stage Loader
oder ein selbstgeschriebener Bootloader das auch - auch beim ATMEGA,
ob das nun über eine RAM-Routine geht oder anders is total egal, es geht
um das Konzept
basta!
Grössere AVRs haben Bootsections bis zu 8KB. Das sollte ausreichen, um
auch einen klassischen auf TFTP (=UDP) basierenden Bootloader gut darin
unterbringen zu können.
Frank wrote:
>>Das will ich sehen, wie du einen ATmega dazu bekommst, Code aus dem RAM>>auszuführen.> Der eingebaute Bootloader kann flashen, also kann ein 2nd-Stage Loader> oder ein selbstgeschriebener Bootloader das auch - auch beim ATMEGA,> ob das nun über eine RAM-Routine geht oder anders is total egal, es geht> um das Konzept> basta!
Ich habe nicht behauptet, dass es gar nicht geht, nur das was du
geschrieben hast war so, wie es dort stand, einfach Quatsch.
Überhaupt ging dein Post großteils daneben, denn das "Ich dachte mir
schon dass es nicht geht" bezog sich nicht auf einen Bootloader,
sondern darauf, den ATmega direkt über die ISP-Schnittstelle zu
programmieren (und das nur mit einem ENC25J60).
Wenn du schon rumstänkern willst, solltest du zumindest mal genau
lesen, worum es überhaupt geht.
Hallo,
das ist überhaupt kein Problem. Ich habe einen W5100 als Ethernet-Nic
und flashe einen Mega2560 via XCPoverEthernet. Lediglich die
Schreibroutinen für das Flash müssen im Bootloaderbereich liegen. Der
Rest kann im übrigen Flash liegen (RAM dient dann als Datenpuffer für
die Flashroutinen). Dann muss nur noch die Applikation so erstellt
werden, dass die Netzwerk- und Protokollroutineneinsprünge immer an
gleichen Adressen im Programmflash liegen. Dann kann man sogar
problemlos diese Teile überflashen.
Gruss
Thorsten
Bin zwar ein paar Tage zu spät für diesen Thread, was hier aber nicht
und nie erwähnt wurde ist bootp bzw. dhcp um firmware zu laden.
ein bootloader der einen bootp/dhcp server sucht und von dort seine
firmware holt & flasht. das wäre auch was nettes ohne großartig
mausklickereien zu bedürfen... bootp-server am pc starten, hex-file
angeben und da kann ja der compiler immer ein neues file dem bootp
server unterschieben. reset-drücken an der avr-schaltung, boot-loader
holt sich das neue file... viola.
wenn der avr dann z.b. ein <eigenemacadresse>.hex file anfordert könnte
man das auch recht praktisch bei mehreren schaltungen anwenden... :)
nur so eine idee... von der bootloaderprogrammierung bzw. anwendung vom
enc... habe ich noch keine ahnung, dachte mir aber schon ein paar mal
das das per bootp ja ganz nett wäre.
das ganze gibts bei sehr vielen routern/switches/... und funktioniert
dort eigentlich klaglos.
mfG, Martin.
Das ginge noch einfacher. Man macht einfach einen MINI-UDP-Stack.
Man stellt den Ethernet-Controller so ein, dass er die Bytes überprüft,
in denen drin steht, dass es ein UDP-Paket ist und der Port korrekt ist.
Broadcast-Pakete sollen verworfen werden. Dann nimmt man die ersten
Bytes der Daten als Blocknummer, und den Rest als Daten. Man flasht den
Mikrocontroller und überprüft den Block. Wurde er korrekt geschrieben,
so schickt man ein UDP-Paket zurück. Dazu vertauscht man einfach die
Absender und Ziel-Mac und IP-Adressen.
Am Rechner ist die Ansteuerung denkbar einfach. Zunächst macht man einen
manuellen ARP-Eintrag per arp-Befehl, dann schickt man die Daten per UDP
und wartet auf eine Antwort.
Man braucht dafür keinen ganzen TCP/IP-Stack oder gar einen Webserver.
Hallöchen,
hab den Thread hier herade erst gefunden, deshalb noch ne späte
Beteiligung.
Gibts denn hier jemanden, der Interesse hätte und technisch dazu in der
Lage wäre, sich an einem einfachen AVR Ethernet Bootloader zu
beteiligen?
Ich benötige nämlich einen solchen für meine Hausautomatisierung, denn
die Controller sitzen in den Wänden und sind über Ethernet verbunden. Da
gerät ein Firmwareupdate über ISP zur Geduldsprobe :)
Eckdaten wären:
-ENC28J60 über SPI an einem ATMega 644
-Update sollte von aussen angestossen werden können (spezielles UDP
Paket?)
-Update von FLASH und EEPROM über einfaches UDP-Protokoll möglichst ohne
Zwischenspeicherung (weil große Applikation / kein externer Speicher).
Werde das in nächster Zeit mal angehen, habe mich nur noch nie mit dem
AVR Bootloader-Konzept beschäftigt und wenig Zeit neben Job und Familie.
Deshalb meine Frage nach Bootloader / Ethernet erfahrenen Teilhabern :)
Hallo,
ich Idee hatte ich schon gehabt so einen Bootloader zu schreiben. Hatte
mir auch schon einige gedanken dazu gemacht.
Sollte kein Problem sein. Als Protokoll ist TFTP geeignet, es ist
einfach aufgebau und benutzt UDP. Beide Protokolle lassen sich mit wenig
aufwand Programmieren, b.z.w. ich habe die eigentlich schon fertig
programmiert für eine andere Anwendung. Ich habe letzt leider nicht im
Kopf wie viel Platz das ganze verbrauchen darf für einen Bootloader.
Aber ich denke mal 4-8Kbyte sollten okay sein.
CA Dirk.
>Ich dachte mir schon dass es nicht geht und hatte auch nicht vor so>etwas zu bauen. Ehrlich gesagt wollte ich hauptsächlich eien Antwort auf>die Frage WIESO es nicht geht, und die kam ja prompt ;-)
Also die einzige sinnvolle Möglichkeit, die mir einfällt, wäre ein
Ethernet <-> RS232 Modul (Kostet zw. 60 und 100 Euro).
Dann sollten die bewährten RS232 fähigen Bootloader funktionieren. Ein
TCP/IP Stack wird man wohl kaum allzuweit eindampfen können. Ausserdem
wäre der Overhead nicht gerade klein.
@Dirk
Und? Wie konkret ist dein Plan, so einen Bootloader umzusetzen?
Ich will jetzt wirklich mal loslegen :)
@Matthias
Viel zu kompliziert. Natürlich kann man einen TCP Stack (zumindest die
wesentlichen Teile) in wenigen KB programmieren. Schonmal was von uIP
gehört?
http://www.sics.se/~adam/uip/index.php/Main_Page
@Jan
Noch nicht wirklich, ich selber hatte mit den gedanken gespielt, weil
ich selber einen Controller mit Ethernet gebaut habe und ich es
natürlich schick finden würde den per Netzwerk zu flashen. Da ich aber
no keine Ahnung von Bootloadern habe aber vom rest der dann zum
Bottloader gehört, hatte ich micht nicht mehr ausführlich beschäftigt.
Da ich jetzt aber mit meinen Studium fertig bin würde ich glatt sowas in
angriff nehmen wollen.
Jan Krause wrote:
> Viel zu kompliziert. Natürlich kann man einen TCP Stack (zumindest die> wesentlichen Teile) in wenigen KB programmieren. Schonmal was von uIP> gehört?>> http://www.sics.se/~adam/uip/index.php/Main_Page
uip is einfach nur Bloat. Das ist für große Kisten mit Webservern
gedacht. Alles was man hier bräuchte wäre ein simples UDP-basiertes
Protokoll. Kein ARP, kein ICMP, nur UDP. Das sollte man in unter einem
Kilobyte hinbekommen.
@Dirk
Na das klingt doch gut. In die Hände gespuckt und losgelegt!
@Uwe
Hey, danke für den Link. Das Projekt kannte ich noch nicht. Klingt ja
ziemlich exakt nach dem Bootloader, den ich suche - werd mir dir Quellen
gleich mal genau anschauen.
@Christian
Ja, ich weiß. War auch nur als Beispiel für Matthias gedacht.
Ich finde uIP auch sehr unübersichtlich programmiert. Ich selbst setze
einen halb selbstgeschriebenen und halb zusammenkopierten Stack ein.
Stack klingt auch viel zu mächtig - letztlich sind es nur eine handvoll
Funktionen, die sich durch die layer gegenseitig aufrufen und die Pakete
nach und nach ein- bzw. auspacken.
Jan Krause wrote:
> Ja, ich weiß. War auch nur als Beispiel für Matthias gedacht.> Ich finde uIP auch sehr unübersichtlich programmiert.
Bitte was?!?! Übersichtlich ist was anderes.
Simon K. wrote:
> Jan Krause wrote:>> Ja, ich weiß. War auch nur als Beispiel für Matthias gedacht.>> Ich finde uIP auch sehr unübersichtlich programmiert.>> Bitte was?!?! Übersichtlich ist was anderes.
Das sagt doch der Jan. uIP ist so mit das unübersichtlichste was ich
kenne, und vor allem alles andere als einfach wenn man was damit
programmieren möchte :-).
CA Dirk
Jan Krause wrote:
> Wenn du nochmal genau hinschaust, wirst du sehen, dass ich> unübersichtlich schrieb !
Hehe, stimmt :-) Ich hab mal selber mit einem eigenen Stack angefangen,
der ganz einfach auf Funktionen aufgeteilt war. Um aber keine
Rechenleistung durch Aufrufe zu verschwenden, habe ich nachher alles
ge-inline-d. Hatte also im Endeffekt den gleichen Effekt wie bei uip.
(Okay, ich hab keine goto-s verwendet und wenn es gar nicht ging durch
Variablen angezeigt, wie später weiter verzweigt werden soll. Resultat:
Der Compiler bastelt mir die gotos rein und die Variablen wieder raus ;)
Hab allerdings beim TCP Stack aufgehört. Das ganze Retransmitting und
sowas ist mir zu komplex um mich damit freiwillig auseinanderzusetzen.
@Jan
ich werde am WE mal nen Wiki und ein SVN anlegen auf meinen Server wo
wir bastel können. Wenn dann fertig ist kann ja auf mikrocontroller.net
oder so.
Schick mal einfach ne email an sharandac(at)snafu.de. Dann können wir
mal das Projekte umschreiben.
CA Dirk
So, hab gerade mal wieder hier im Thread vorbeigeschaut und bin ganz
fasziniert welch großes Interesse es doch an diesem Thema gibt.
Ich hatte inzwischen beschlossen einen solchen Bootloader zu schreiben
und da ich dann Urlaub habe soll es nächste Woche losgehen. Ich habe
mich mit dem enc28j60 beschäftigt und bin inzwischen auch der Meinung
dass man nur einige Funktionen zur gesicherten Datenübertragung und
keinen richtigen "Stack" braucht um damit dann die Funkrionen der boot.h
mit Daten füttern zu können.
Ich würde mich also auch an eurem geplanten Projekt interessieren!
Das Projekt lässt sich ziemlich vereinfachen, wenn man einen Atmega8 zur
Abwicklung des Ethernetprotokolls nimmt und dieser dann die
ISP-Schnittstelle für einen beliebigen anderen Atmega bedient. Falls was
bei der Programmierung schief geht, dürfte dieses Konzept wesentlich
zuverässiger als mit nur einem Prozessor funktionieren.
Ergebnis==> Projekt gut machbar
ca. 2€ mehr Hardware
chris
Wir machen das in einem kommerziellen Projekt (bis zu 200 Geraete an
einem Server). ATMega128 unter anderem mit ENC28J60, inklusive PoE. Die
Daten werden in einem FLASH zwischengespeichert, wo sich auch Update
Daten fuer 2 weitere angeschlossene Geraete befinden.
Der Code haette zwar knapp in den Bootloaderflash Platz gehabt, aber
warum soll man sich so quaelen?
Beim Reset wird der CRC des ATMega geprueft, stimmt der nicht wird das
letzte im Flash befindliche File in den ATMega geschrieben.
Da muss man doch kein 10 Mann Projekt draus machen
Klar, mit einem separaten Controller ließe sich das natürlich ganz
geschmeidig lösen. Mein persönliches Problem ist aber, dass ich für
meine Haussteuerung 10 Geräte mit einem ATMega644 und ohne externen
Flash schon seit Längerem in den Wänden sitzen habe und deshalb auf die
Ein-Controller Lösung über den Bootloader angewiesen bin.
Ist aber auch kein Problem. Habe bereits unter massivem Einsatz der
DEL-Taste den IP-Stack und den Treiber für den ENC28J60 aufs
Allernötigste beschränkt und einen TFTP Client implementiert, dass
insgesamt nur ca. 3500 Byte Code belegt werden (also 1750 Words).
Den ATMega644 kann man sogar auf 4K Words Bootsection konfigurieren, so
dass noch ne Menge Platz bleibt. Möchte aber versuchen, die Größe auf 2K
zu beschränken.
Aktuell überlege ich, welches Dateiformat ich zur Übertragung nutze.
Praktisch wäre ja Intel Hex, dann müsste man Serverseitig nix
konvertieren. Allerdings bracuht der Intelhex Parser auf dem ATMega ne
Menge Platz.
Werde wohl einmal Intel Hex as 4k Version und ein eigenes Format, dass
sich Code-sparend parsen läßt für die 2k Version implementieren.
Jan
Ja, ich habe den Bootloader so gut wie fertig. Gesamtgröße auf dem
ATMega32 ist knapp unter 2K Words. Features:
-Treiber für den ENC
-sehr minimalistischer IP Stack
-TFTP Client
-Parser für INTEL HEX Format
-Flash Programmierroutine
Der Bootloader lädt IP und MAC Adressen sowie eine geräteabhängige ID
aus dem EEPROM und sendet einen TFTP Read Request an die Adresse
255.255.255.255 (Broadcast) ab. Antwortet ein TFTP Server im lokalen
Netz mit einer Firmwaredatei im Intel HEX Format, wird die Datei geparst
und ins Programm FLASH geschrieben. Antwortet kein Server, springt der
Code zur Applikation.
Wenn Interesse besteht, kann ich den Code hier oder in der Codesammlung
posten.
Gruß, Jan
Jan Krause wrote:
> Ja, ich habe den Bootloader so gut wie fertig. Gesamtgröße auf dem
Klasse!
> ATMega32 ist knapp unter 2K Words. Features:> [...]
Noch besser!
> Wenn Interesse besteht, kann ich den Code hier oder in der Codesammlung> posten.
Ich hätte Interesse! =)
Danke, Grüße, holli
SD-Fritze wrote:
> Interressemeld!> :-)>>> (Sorry für Einzeiler)
Nunja, wenn man nicht so streng ist, geht das auch als 2-Zeiler durch ;)
Nun zum wichtigsten:
HAB AUCH INTERESSE!!!
Ok, hier ist schonmal die aktuelle Arbeitversion. ist noch etwas
unaufgeräumt und enthält wahrscheinlich auch noch ein paar
Sourcedateien, die gar nicht mit kompiliert werden...
Zur Funktion:
Da ich kein Makefile Experte bin habe ich das Problem, dass ich den
Bootloader ja pro Gerät anders konfigurieren will (EEPROM)
möglicherweise etwas umständlich gelöst. Da bin ich für
Verbesserungsvorschläge dankbar!
Ich habe pro Konfiguration ein Unterverzeichnis erstellt, indem die
Dateien Config.h, eemem.c und das Makefile liegen. Die Sourcen liegen im
gemeinsammen übergeordneten Verzeichnis, in dem auch ein compile-bat
Script liegt, das für alle Unterverzeichnisse make aufruft und die
erstellten hex-files in einen gemeinsamen Ordner kopiert.
in eemem.c werden die Netzwerkeinstellungen und der Name der
Firmwaredatei konfiguriert, in config.h werden die Ports konfiguriert,
an denen der ENC angeschlssen ist (SPI und CS).
Gruß,Jan
Servus Jan
Bin zwar nicht dazu gekommen mir Dein Program anzuschauen; aber ich
finde es eine sehr gute Idee. Waere es da nicht besser, wenn Du Deinen
lezten Beitrag auch unter der Rubrik "Codesammlung" veröffentlichst?
Hier in dieser Rubrik ist die Gefahr, dass es untergeht, doch recht
gross.
MfG
Hallo Mehmet,
ja, wie gesagt, funktioniert zwar schon, ist aber noch nicht 100%
fertig. Wenn ich den Code nochmal aufgeräumt habe, werde ichs auch noch
mal in der Codesammlung einstellen.
*jan
Hallo Jan,
ich experimentiere gerade mit deinem Bootloader herum und würde ihn
gerne auf den ATMega644 / 644p verwenden. Jetzt steht in deinem Makefile
als Startadresse "BOOTLOADER_START = 0x7000". Bei 4k Bootloaderbereich
würde sich der Bootloader von 0x7000 bis 0x7FFF erstrecken. Jetzt frage
ich mich wie ich ein Programm mit 40K grösse in den 644 bekomme, wenn
doch der Bootloader irgendwo bei 28,6K anfängt. Ist es überhaupt möglich
den 644 mit ~60K zu beschreiben, wenn ich einen Bootloader von 4K
verwende? Sorry, wenn ich so blöd frage, aber mit dem Bootloader habe
ich bis jetzt noch gar nichst gemacht. Das Atmel Datenblatt verwirrt
mich ein wenig, denn zum einem gibt es eine Grafik wo der
Bootloaderbereich am ende des Flashspeichers eingezeichnet ist und zum
anderen gibt es die Tabelle wo der Startbereich des Bootloaders von
0x7000 - 0x7E00 beschrieben ist.
Gruß aus Köln
Frank
Hallo an alle!
Habe das Thema mit großer Aufmerksamkeit verfolgt, gibt es noch eine
neuere Version und weitere Infos? Ich selbst hab leider nicht wirklich
die Kenntnisse, um bei einem Projekt dieser Schwierigkeitsstufe
mitzuhelfen.
Beste Grüße und unfallfreies rutschen!
Euer Tom
Hallo liebe Leute.
Habe das Projekt schon seit einiger Zeit beobachtet.
Habt ihr nun endlich ein gut Dokumentierten und Sauberen Quellcode
erschaffen welcher auf einem Atmega32 laufen würde ??
Wäre nämlich sehr daran interessiert !!
THx.
Oliver
Hallöchen,
so, melde mich mal wieder aus der Versenkung. Bin leider in den letzten
Monaten nicht mehr dazu gekommen, an dem Projekt weiter zu arbeiten.
Tja, Kinder und ein Job sind doch recht zeitintensive Hobbies...
Wie schon geschrieben. Im Prinzip funktionierts, habe nur das Problem,
dass größere HEX-Dateien nicht komplett programmiert werden - da brichts
dann manchmal mitten drin ab. Ist wohl noch ein Bug.
Wenn also jemand Betatester spielen möchte, und am besten mir auch
direkt Patches für die Bugfixes mitliefert - immer gerne :)
Grüße von Jan
Moin!
Zufällig habe ich dieses Projekt gerade hier gefunden und bin darüber
sehr erfreut, da ich einen Ethernet-Bootloader auch brauche. Also habe
ich mir den vorhandenen Code mal runtergeladen und bin als erstes über
die Funktion hexToByte in der Datei etherflash.c gestolpert. Die sieht
z.Zt. so aus:
1
uint8_thexToByte(uint8_t*buf,uint16_tidx)
2
{
3
uint8_tval=0;
4
uint8_ti,t;
5
for(i=0;i<2;i++)
6
{
7
t=buf[idx+i];
8
if(t>=(uint8_t)'0'&&t<=(uint8_t)'9')
9
{
10
// digit
11
val=(val<<4)+t-(uint8_t)'0';
12
13
}elseif(t>=(uint8_t)'A'&&t<=(uint8_t)'F')
14
{
15
// hex digit a-f
16
val=(val<<4)+t-(uint8_t)'A'+10;
17
}
18
}
19
returnval;
20
}
Die umständliche Prüfung der erlaubten Zeichen ist an dieser Stelle
offensichtlich überflüssig, denn wenn es sich nicht um gültigen Hexcode
handelt, wird trotzdem ein falscher Wert zurückgegeben. Also kann man
das Verfahren auch abkürzen:
1
uint8_thexToByte(uint8_t*buf,uint16_tidx)
2
{
3
uint8_tval=0;
4
uint8_ti,t;
5
for(i=0;i<2;i++)
6
{
7
t=buf[idx+i];
8
if(t>(uint8_t)'9')
9
{
10
// hex digit a-f
11
val=(val<<4)+t-(uint8_t)'A'+10;
12
}else
13
{
14
// digit 1-9
15
val=(val<<4)+t-(uint8_t)'0';
16
}
17
}
18
returnval;
19
}
So belegt die Funktion im Flash nur noch etwa den halben Platz.
Wann immer ich Zeit habe, werde ich mir die restlichen Funktionen auch
noch ansehen und die Ergebnisse hier posten. Früher oder später sollten
wir so zu einem funktionierenden Code kommen.
Gruss
Andreas
Hallo Andreas,
super! endlich mal einer, der mitmacht :)
Ja, kann sein, dass ich das eine oder andere etwas umständlich mache -
komme eigentlich eher aus der C#-Ecke und mache Mikrocontroller nur so
hobbymäßig ab und zu mal...
Werde deine Änderung testen und übernehmen. Bei dem Projekt zählt jedes
Byte!
Gruß, Jan
Hallo Jan,
mein Beitrag sollte keine Kritik an Deinem Code sein. ;) Du hast schon
eine Menge Arbeit in dieses Projekt investiert, die ich keinesfalls
"schlechtreden" will.
Inzwischen habe ich das Projekt mal insgesamt compiliert und
festgestellt, dass der AVR-GCC (ich benutze die Version 20081205)
außerordentlich eigenwillig optimiert. Mit meinen Änderungen wird der
Code insgesamt nit kleiner, sondern größer, weil der Compiler die
Funktion hexToByte jetzt einmal als Funktion in den Code integriert, sie
aber an der Stelle, wo sie gebraucht wird (in processLineBuffer) doch
inline benutzt. Dusseliges Teil, das :(
Wenn man die Definition der Funktion ändert in
1
inlineuint8_thexToByte(uint8_t*buf,uint16_tidx)
kann man dem Compiler den Unfug austreiben.
Gruss
Andreas
Hallo Jan,
hier im Forum gibt - oder gab es zumindest - einen SVN-server mit trac.
Evtl wäre das ja was für dein Projekt.
@Andreas: Gibts svn noch? Der Server scheint noch dazusein, aber
irgendwie "geschlossen" zu sein. Das trac hab ich auch auf Anhieb nicht
gefunden. Könntest du mich vielleicht aufklären? =)
Danke,
Grüße,
holli
Hi Andreas,
habs auch nicht als Kritik empfunden. Und solange es konstruktiv zur
Sache geht, ist doch alles im Lack.
Hab mich gestern abend auch noch mal zwei Stunden dran gesetzt und ein
paar fiese Bugs eliminiert (wenn z.B. eine Paketgrenze genau zwischen
0x0A und 0x0D (Zeilenumbruch) fällt.
Ausserdem hat die aktuelle Versoin noch Probleme, wenn gleichzeitig
anderer Netzwerkverkehr stattfindet, der im Buffer des ENC landet. Da
bin ich gerade dabei.
@Holli:
Klar, wenns hier einen subversion Server gibt, nix dagegen. Am Anfang
hatte ja auch Dirk Broßwick mal Interesse bekundet - der hatte auch
einen eigenen subversion server dafür aufgesetzt, hab aber nix mehr von
ihm gehört.
Grüße, Jan
So, hier mal meine aktuelle Version. Läuft schon ganz gut bis auf
folgende Probleme:
1) Ab und zu gibts einzelne Bytes, die nach dem Flashen auf 0xFF stehen.
Möglicherweise muss da noch eine Verifizierung mit Neuprogrammierung
eingebaut werden.
2) Wenn man aus einer Applikation in den Bootloader springt, gibts noch
Probleme bei der Initialisierung (vermutlich von Variablen). Dann
funktioniert meistens der Empfang von Netzwerkpaketen nicht mehr.
Gruß, Jan
Jan Krause wrote:
> 2) Wenn man aus einer Applikation in den Bootloader springt, gibts noch> Probleme bei der Initialisierung (vermutlich von Variablen).
Nein, eher von Hardware-Registern. Wenn du zum Bootloader springst, wird
der dortige Startup-Code ausgeführt, so dass alle Variablen des
Bootloaders korrekt initialisiert werden. Es gibt da absolut keinen
Unterschied zu einem richtigen Reset. Bei den Hardware-Registern macht
es aber natürlich einen großen Unterschied, denn die werden bei einem
einfachen Sprung natürlich nicht zurückgesetzt.
Da müsste dann 0x3800 stehen.
Das würde dann möglicherweise auch erklären, warum Jan Probleme hat, von
der Applikation in den Bootloader zu springen.
Gruss
Andreas
Hallo zusammen,
>> Nein, denn "call" erwartet eine Wort Adresse.>Ah, ok, dann ist die Zeile darüber (für den ATmega32) falsch:>>#if defined (_AVR_ATmega32_)> #define pBootloader() asm volatile ("call 0x7000"::)>#endif>>Da müsste dann 0x3800 stehen.
Ups, da hast du recht. CALL erwartet eine WORD-Adresse - das würde
tatsächlich meine Probleme erklären - werde ich gleich mal ausprobieren!
@Frank:
Danke für den Hinweis. Probier ich auch gleich aus. Wobei ich schon
unter 2k Words Gesamtgröße angekommen bin. Passt also schon in eine
Mega32. Aber wenn ich jetzt noch eine Überprüfung des Flash nach dem
Programmieren einbaue, brauch ich wohl doch noch ein paar Byte.
Wegen Projekthosting hab ich Google-Code ins Auge gefasst. Die bieten
ein svn repository, einen einfachen Bugtracker und ein Wiki.
Grüße von Jan
Jan Krause wrote:
> Jetzt kann jeder mitmachen, der möchte!
Hmm, in der HowTo-Join steht:
> One of the project owners must use the project administration page to add> your Google account email address to the project.
Ich habe keinen Google account und will auch eigentlich keinen - die
Jungs sind mir zu gierig beim Datensammeln. Ich hoffe, ich darf trotzdem
weiter mitmachen. ;)
Gruss
Andreas
Naja, du könntest ja einen Account nur für das Projekt anlegen - musst
ja keine persönlichen Daten hinterlassen.
Aber ok, ich nehm auch gerne hier weitere Bugfixes und
Verbesserungsvorschläge an und checke sie dann ein :)
Wollte nur mal auf die Schnelle eine Möglichkeit schaffen, das alle
immer an den aktuellen Quellcode kommen, ohne dass ich hier immer
ZIP-Files anhängen muss!
Aber wieder zu den aktuellen Problemen.
CALL erwartet doch wohl eine WORD Adresse, oder?
Ich habe nämlich jetzt das Phänomen, dass auf meinem ATMega32 bei einem
CALL 0x3800 gar nix mehr passiert, bei einem CALL 0x7000 startet der
Bootloader und sendet sein TFTP Request ab - nur leider werden keine
eingehenden Pakete verarbeitet...
So, ein bisschen forschen in der .lss Datei bringt Foglendes zu Tage:
1
48e:0e94001ccall0x3800
Dass heißt, im Assemblercode wird die Adresse als Byteadresse angegeben
und der Assembler teilt das dann selber durch zwei und schreibts in den
Operanden (0x00 0x1c) = 0x3800 / 2.
Na da muss mal mal drauf kommen ...
Die Version hier ist also doch richtig (Mega32 mit 2k Bootloader):
Jan Krause wrote:
> Na da muss mal mal drauf kommen ...
In der Tat! Und weil ich jetzt völlig verwirrt bin, habe ich mal genauer
nachgeforscht:
Wenn man mit AVR-Studio ein Assemblerprojekt erzeugt, wird der Befehl
1
call 0x0200
zu folgendem Hexcode umgewandelt:
1
0E 94 00 02
Es wird also genau so übernommen, wie es da steht. Die Wirkung des
Befehls ist der Sprung zur Wortadresse 0x200, also zur Byteadresse
0x400.
Bei einem AVR-GCC-Projekt wird der Befehl:
1
asmvolatile("call 0x0200"::)
zu folgendem Hexcode gewandelt:
1
0e 94 00 01
D.h. der gcc teilt den Wert durch 2, so dass "call 0x0200" einen Sprung
zur Byteadresse 0x0200 bewirkt, und nicht zur Byteadresse 0x0400, wie
beim AVR-Studio-Assembler.
Ich habe zu diesem Umstand auf die Schnelle nirgendwo einen Hinweis
gefunden. Dass sollte aber dick unterstrichen in der avr-gcc-Doku
drinstehen, denn sonst kommt es permanent zu Fehlern.
Gruss
Andreas
Hi Andreas,
na das ist natürlich noch verwirrender, wenn der Assembler das auch noch
anders übersetzt als der avr-gcc...
Ich habe ehrlich gesagt auch nach intensiver Suche überhaupt keinen
Hinweis darauf gefunden, was der CALL Befehl für eine Adresse erwartet.
In den Datasheets steht nur, dass der Operand in den Program Counter
geladen wird. Und der zählt definitiv wortweise.
Naja, wieder ein bisschen schlauer geworden :)
Gruß, Jan
Hallo zusammen,
Ein sehr interessantes Projekt, genau das was ich gesucht habe! Respekt
fürs Schrumpfen!
Ich würde es auch gerne einsetzen.
Leider war ich bei dem Versuch trotz vieler Versuche nicht erfolgreich.
Kann mir jemand helfen?
Hier das was ich versucht habe:
AVR-NET-IO board von Pollin, das läuft auch nach den üblichen
Anfangsproblemen.
dann hab ich mir Google Code den aktuellen Code geholt
http://code.google.com/p/avr-etherboot/source/browse/#svn/branches/functable
(furchtbares tool, wenn man keinen Client einsetzt)
und diesen etwas angepasst:
device_001\config.h
#define USE_DHCP 0
#define DEBUG_TFTP 0 (passt sonst nicht in den Speicher wegen der
Strings)
device_001\eemem.c
Andere IP
device_001\makefile
F_CPU = 16000000
Dann das ganze übersetzt und geladen. Auf der RS232 kommt dann
Start
ETH_INIT
stack_init done
UDP_SendPacket
Soweit so gut, aber leider passiert auf dem PC nichts.
Dort habe ich den Tftpd von Ph. Jounin als Server gestartet, der lauscht
auf Port 69, aber es kommt anscheinend nichts.
Welchen tfdp-Server verwendt Ihr?
Hoffentlich hat einer eine Idee.
mfg Claus
Hallo Claus!
Du bist etwas zu früh dran, das Projekt ist noch nicht ganz fertig. Jan
und ich arbeiten daran, aber da es sich um ein Freizeitprojekt handelt,
können wir natürlich keine Fertigstellungstermine nennen.
Du hast Dir den Codeteil unter branches heruntergeladen. Dieser Zweig
ist eine Studie von Jan zum Thema Funktionszeiger, der möglicherweise
gar nicht lauffähig ist.
Der Code, den Du unter trunk findest ist zur Zeit am weitesten
entwickelt. Du musst dort nur in der eemem.h Deine IP-Adressen
einstellen. Alle anderen Parameter werden beim Aufruf von make abgefragt
bzw. automatisch berechnet. Der Code funktioniert mit einem TFTP-Server
unter Linux, aber wir haben bei weitem noch nicht alle Konstellationen
getestet, da wir noch mitten in der Entwicklung sind. Ich kann Dir also
nicht garantieren, dass der Code bei Dir funktioniert. Grundsätzlich ist
die Verwendung des AVR-NET-IO jedoch kein Problem, ich verwende dieses
Board auch zum testen.
Wenn Du Zeit und Lust zum Experimentieren hast, bist Du herzlich
eingeladen, Probleme und Debugausgaben hier zu posten. Ich werde
versuchen, Dir zu helfen.
Gruss
Andreas
Hallo Andreas,
vielen Dank für Deine Antwort und das Angebot zu helfen.
Zeit, ja das ist immer das Problem :-)
ich hatte den Code unter "functable" genommen, weil der unter "trunk"
sich bei mir nicht ohne weiteres übersetzen lässt.
wenn ich den Code unter "trunk" ohne Änderungen für einen ATmega32 16MHz
Small übersetzen lassen, dann gibt es folgende Fehlermeldung:
1
...
2
./config.h:26:5: warning: "BOOTLOADER_VERSION" is not defined
wenn man in der Compile.bat das make für device_001 aktiviert, dann gibt
es die Fehlermeldung nicht, aber der Code wird zu groß und beginnt bei
6D1A hex statt bei 7000 hex, das muss ich mir noch mal ansehen.
Zwischenzeitlich hatte ich nochmal mit dem Code experimentiert, der hier
weiter oben als Zip abgelegt ist. Nach dem ich in der Config.h
ENC28J60_CONTROL_PORT PORTD auf C geändert hab. hat er tatsächlich
etwas vom TFTP-Server geladen. Ich mußte auch einen anderen TFTP-Server
verwenden
http://www.brothersoft.com/free-tftp-server-download-21464.html. Aber
leider misslang auch dieser Versuch, denn der Bootloader hat zwar das
ganze file geladen, aber nur einen Teil ins Flash geschrieben.
, aber das sah schon sehr vielversprechend aus.
Ich melde mich noch mal wenn ich noch was heraus finde.
Bis dann Claus
Claus wrote:
> ./config.h:26:5: warning: "BOOTLOADER_VERSION" is not defined
Danke für den Hinweis, da wurde noch eine alter Name verwendet, den es
nicht mehr gibt. Ich habe das mal eben behoben.
> wenn man in der Compile.bat das make für device_001 aktiviert, dann gibt> es die Fehlermeldung nicht, aber der Code wird zu groß und beginnt bei> 6D1A hex statt bei 7000 hex, das muss ich mir noch mal ansehen.
Die Größe des Codes hängt davon ab, welche Variante du wählst und welche
Debugoptionen aktiv sind. Egal welche Größe der Code hat, Du kannst ihn
Flashen und er wird funktionieren, solange deine Anwendung nicht mehr
als den verbliebenen Platz verwendet.
Der Bootloader besteht grundsätzlich aus zwei Teilen: Der Kern ist im
wesentlichen nur die Funktion, die das Beschreiben des Flashspeichers
übernimmt. Dieser Teil steht immer in den letzen 1024 Bytes des
Flashspeichers. Du musst deshalb Deine Fusebits so setzen, dass die
Bootsection 512 Words groß ist. Dies geschieht noch nicht automatisch!
Der zweite Teil des Bootloaders steht unterhalb der Bootsection. Das
geht, weil dieser Teil ja nur "Hilfsdienste" erledigt (ENC ansteuern
etc.) und nicht ins Flash schreibt. Die Größe dieses zweiten Teils ist
variabel. Je größer er wird, desto weniger Platz bleibt für deine
Anwendung.
In der fertigen Version wird der Bootloader verhindern, dass du eine
Anwendung lädst, die zu groß ist und Teile des Bootloaders überschreibt.
Dies ist zur Zeit noch nicht implementiert, so dass du selber darauf
achten musst.
> Zwischenzeitlich hatte ich nochmal mit dem Code experimentiert, der hier> weiter oben als Zip abgelegt ist. Nach dem ich in der Config.h> ...> ganze file geladen, aber nur einen Teil ins Flash geschrieben.
Ja, der Fehler ist bekannt und in der Version, die im Trunk ist,
behoben.
Gruss
Andreas
Hallo Andreas,
Danke für Deine schnelle Antwort.
Ich hatte natürlich immer 2kWords Bootsektor angegeben. (Fuses)
Das heist, das der Code mittlerweile doch größer als 2kWords ist,
schade.
Ich hab natürlich Small gewählt und alle Debugausgaben auf 0
Ich werde wohl doch auf den ATmega644 umsteigen müssen.
beim Übersetzen der aktuellen Dateien aus "trunk" kommt bei mir immer
noch der Fehler:
aber auch wenn ich das anscheinend korrekt übersetze device_001 verwende
und 512kWord Bootsektor einstelle, dann funktioniert es leider nicht.
Zwar läuft der Code im ATmega nun anscheinend, aber der TFTP-Server
meint wohl nicht antworten zu müsssen, jedenfalls hab ich mit einem
Ethernet Analyzer gesehen, das da was auf port 69 reinkommt, nur
anwortet im PC niemand?
Ich muss mal sehen wann ich wieder zeit dafür finde.
Bis dann Claus
Claus wrote:
> Das heist, das der Code mittlerweile doch größer als 2kWords ist,> schade.
Ja, im Augenblick ist das so. Vieleicht gelingt es uns noch, die
Minimalversion wieder unter 2kWords zu drücken, aber versprechen kann
ich nichts.
> beim Übersetzen der aktuellen Dateien aus "trunk" kommt bei mir immer> noch der Fehler:
Ok, makefile in device_002 war nicht aktuell, ist behoben.
> Zwar läuft der Code im ATmega nun anscheinend, aber der TFTP-Server> meint wohl nicht antworten zu müsssen, jedenfalls hab ich mit einem> Ethernet Analyzer gesehen, das da was auf port 69 reinkommt, nur> anwortet im PC niemand?
Verwendest Du Wireshark? Kannst Du mir einen Mitschnitt schicken, damit
ich sehen kann, was schiefläuft?
Gruss
Andreas
Hallo,
so, nun hab ich mir noch mal etwas zeit für den Bootloader genommen.
wenn ich in der eemem.c
unsigned long EEMEM mlTFTPipEEP = IP(255,255,255,255);
einstelle und in der etherflash.c die zugehörige Abfrage auskommentiere
if (sock.DestinationIP != IP_packet->IP_Srcaddr)
dann funktioniert alles solange DEBUG_AV=1 ist.
Sobald ich das Debug ausschalte, dann nimmt der Bootloader die IP-Pakete
vom TFTP-Server nicht mehr an. Blos sieht man dann dummerweise nicht
nicht mehr woran es liegen könnte, da ja die Debugausgabe fehlt.
Ich hab die Befürchung, dass es daran liegt, dass der code größer als
die 2k Word ist und der Zugriff auf die Adressen außerhalb des
Bootbereiches während des Schreibens zum Halt führt. Aber so ganz 100%ig
hab ich das mit "RWW" und "NRWW" im Datenbaltt nicht verstanden.
Gruß Claus
Ja. ich hab auch mal einen Bootloader geschrieben, und gefunden sobald
man Flash und EEPROM, CRC gesichert uebertragen will und vielleicht noch
ein vernuenftiges Protokoll hinzupackt sehr schnell die 2k word eines
Mega32 gefuellt sind. Interrupts waeren wuenschbar gewesen, waren aber
nicht drin, zuviel war zu beachten. Man muss sich wirklich jeden Wunsch
zweimal ueberlegen, denn alles braucht Code. Am besten mit bedingter
Compilierung arbeiten, dann kann man gewisse Features wieder entfernen.
Bei einem Mega64 mit 4k Word Bootblock ist das Ganze etwas entspannter.
Claus wrote:
> wenn ich in der eemem.c> unsigned long EEMEM mlTFTPipEEP = IP(255,255,255,255);> einstelle und in der etherflash.c die zugehörige Abfrage auskommentiere> if (sock.DestinationIP != IP_packet->IP_Srcaddr)> dann funktioniert alles solange DEBUG_AV=1 ist.> Sobald ich das Debug ausschalte, dann nimmt der Bootloader die IP-Pakete> vom TFTP-Server nicht mehr an.
Offenbar gibt es irgendwo eine Stelle, an der erforderlicher Code
ausgeschlossen wird, wenn DEBUG_AV=0 ist. Ich werde mir das mal ansehen.
Gruss
Andreas
Hallo,
Malte worte:
>Ist zwar ein anderer Ethernet Controller, aber mich wundert es, dass>http://www.ethernut.de/en/eboot/index.html>noch nicht erwäht wurde.
genau, ist ein anderer Ethernet Controller, ethernut kenne ich aber mit
einem arm7, gibt es das auch mit einem ATmega32 ? auf der HP die Du
angegeben hast, steht was von einem ATmega 128.
Andreas Vogt wrote:
>Offenbar gibt es irgendwo eine Stelle, an der erforderlicher Code>ausgeschlossen wird, wenn DEBUG_AV=0 ist. Ich werde mir das mal ansehen.
Das glaube ich nicht, denn wenn ich nur den code
boot_page_erase (currentAddress-2); // Clear flash
boot_page_write (currentAddress-2); // Store buffer in flash page.
auskommentiere, dann wird die komplette Datei übertragen.
Ich hab mir jetzt 2 ATmega644 bestellt, und werde weitere Versuche erst
mit diesen starten.
Trotzdem schnonmal vielen Dank bis hier hin.
Claus
So, jetzt melde ich mich auch mal wieder zu Wort...
@Malte:
>Ist zwar ein anderer Ethernet Controller, aber mich wundert es, dass>http://www.ethernut.de/en/eboot/index.html>noch nicht erwäht wurde.
Stimmt, habe gerade mal kurz drübergeschaut. Problem ist
a) Anderer Ethernet Controller
b) Ist (logischerweise) sehr auf die Architektur des Ethernut-Projektes
ausgerichtet
@Claus
>Ich hatte natürlich immer 2kWords Bootsektor angegeben. (Fuses)>Das heist, das der Code mittlerweile doch größer als 2kWords ist,>schade.>Ich hab natürlich Small gewählt und alle Debugausgaben auf 0>Ich werde wohl doch auf den ATmega644 umsteigen müssen.
Naja, das heißt ja nicht, dass der Bootloader mit 2k Bootspace nicht
funktioniert, du hast halt nur etwas weniger Platz für die Applikation.
Ich bin mir aber sicher, dass wir mit der "Small"-Version wieder unter
die 2k-Grenze kommen werden (weil wir dort schon einmal waren).
>Ich hab die Befürchung, dass es daran liegt, dass der code größer als>die 2k Word ist und der Zugriff auf die Adressen außerhalb des>Bootbereiches während des Schreibens zum Halt führt. Aber so ganz 100%ig>hab ich das mit "RWW" und "NRWW" im Datenbaltt nicht verstanden.
Es ist nur wichtig, dass der Code, der schreibend auf das Flash zugreift
in der Bootloader-Section läuft (SPM Instruction).
Wenn du in der NRWW-Section schreibst, dann wird die CPU während des
Schreibvorgangs angehalten - das hat aber keinen Einfluss darauf, ob du
überhaupt schreiben darfs/kannst.
>>Offenbar gibt es irgendwo eine Stelle, an der erforderlicher Code>>ausgeschlossen wird, wenn DEBUG_AV=0 ist. Ich werde mir das mal ansehen.>Das glaube ich nicht, denn wenn ich nur den code> boot_page_erase (currentAddress-2); // Clear flash> boot_page_write (currentAddress-2); // Store buffer in flash page.>auskommentiere, dann wird die komplette Datei übertragen.
Ich werde mir das auch nochmal anschauen. Ich tippe auch eher auf einen
ordinären Programierfehler...
Gruß, Jan
Hallo, ich habe in den letzten Tagen den etherflash auf dem Pollin NetIO
board mit ATMEGA32 zum laufen bekommen. Es tauchten 3 Probleme auf, die
ich gelöst habe, und den fleissigen Programmautoren sowie der Welt nicht
vorenthalten möchte.
Den code hab' ich mir per svn von code.google geholt. Konfiguration
"small" eingestellt.
1. Zunächst wurde garnichts ins flash geschrieben. Vermutlich
funktioniert "boot_page_fill_safe()" nicht wenn der code dazu ausserhalb
der boot section liegt. Kann das sein? Ich habe die Funktion
"processLineBuffer()" in die boot section geschoben (die ich dazu auf 1k
x 16bit aufgebohrt habe), danach wurde immerhin der erste Block im flash
beschrieben.
2. In der Funktion writeFLASHPage() hab ich ein RWW_enable hinzugefügt:
1
boot_spm_busy_wait();// Wait until the memory is written.
2
boot_rww_enable();// <-- hier. Hab' ich beim ethersex abgeguckt.
Danach wurden schon 'ne ganze Menge Blöcke geflasht.
3. Aber nicht alle. Und nicht reproduzierbar. tcpdump, auf dem PC auf
dem der TFTP server läuft, hat mir geholfen, den Fehler zu finden. Es
lag an der UDP checksum. Funktion Checksum_16():
1
//Komplementbildung (addiert Long INT_H Word mit Long INT L Word)
Im generierten assembler code war tatsächlich nur eine 16 bit addition
zu sehen. (ich verwende avr-gcc 4.3.2). Mit den casts werden 32 bit
addiert, und das flash vollständig programmiert! BINGO!
Gruß, Dirk.
PS kenne mikrocontroller.net schon einige Jahre, dies ist mein
mitmach-Einstieg.
Hallo Dirk,
ausgezeichnete Arbeit, vielen Dank für Deinen Beitrag!
Dirk Armbrust wrote:
> 1. Zunächst wurde garnichts ins flash geschrieben. Vermutlich> funktioniert "boot_page_fill_safe()" nicht wenn der code dazu ausserhalb> der boot section liegt. Kann das sein?
Das hat mich erstmal gewundert, denn boot_page_fill_safe() benutzt zwar
den SPM-Befehl, schreibt aber nur in einen speziellen RAM-Bereich. Der
Flash-Speicher wird dabei noch gar nicht verändert. So gesehen scheint
es also keinen Grund zu geben, die Funktion nicht in der RWW-Section
anzusiedeln.
Ich habe dann nochmal die Dokumentation von Atmel zu Rate gezogen und
folgenden Satz gefunden:
"The Application section can never store any Boot Loader code since the
SPM instruction is disabled when executed from the Application section."
Offenbar ist es also so, dass der SPM-Befehl in keinem Fall
funktioniert, wenn er aus dem RWW-Bereich aufgerufen wird.
Dirk Armbrust wrote:
> boot_rww_enable(); // <-- hier. Hab' ich beim ethersex abgeguckt.
Ja, diese Zeile ist zweifellos nötig. Erstaunlich, dass das nicht schon
eher aufgefallen ist.
Dirk Armbrust wrote:
> Im generierten assembler code war tatsächlich nur eine 16 bit addition> zu sehen. (ich verwende avr-gcc 4.3.2). Mit den casts werden 32 bit> addiert, und das flash vollständig programmiert! BINGO!
Gut gesehen! Ich werde mir mal eine andere Testdatei zulegen. Bei meiner
ist der Überlauf zufällig nie aufgetreten.
Wir verwenden übrigens auch die Version avr-gcc 4.3.2
Ich habe Deine Korrekturen mal eingearbeitet und im svn eingecheckt.
Den Aufruf von boot_page_fill_safe() habe ich in eine eigene Funktion
verlegt, so dass die Größe der boot section wieder 1K x 8bit beträgt.
Also nicht vergessen, die Fuses zu ändern, wenn Du den aktuellen
svn-Code verwendest.
Gruss
Andreas
@Andreas
I am using Ubuntu 8.04 , and have svn checked out the source from
google.
I have some problems to get make work.
1:
I cd to device_001 , and do a "make clean" , it results in the following
Same for a "make"
2:
I noticed that the files were in "dos format" , meaning cr/lf at end
instead of lf. I ran dos2unix on all files.
And now i get this error , when doing a make.
I this is the yesorno() function in configure.sh.
I did lookup function in bash , and it seems like you either have to use
function yesorno {
}
or
yesorno()
{
}
What version of *nix are you using ? , or is it cygwin ?
I was wondering if i could just get a sample makefile.in.
Then i would expect that there is no need to call those scripts.
mfg
Bingo
@Bingo,
I first had similar problems (using debian etch).
I changed checksize.sh and configure.sh from dos to unix,
and made them executable (chmod u+x *.sh).
That helped for me.
@Andreas,
danke für die schnelle Bearbeitung. Puh, mitten in der Nacht.
Ich hab die neue Version gleich ausprobiert. Leider wird in Deiner
FillFlashPage() funktion die Addition der beiden Datenbytes offenbar nur
8 bit breit gemacht. jedenfalls ist jedes 2. byte im flash auf 0. daher:
damit funktionierts. Noch besser(?), Du addierst die beiden bytes schon
in processLineBuffer() und übergibst ein uint16_t . Seltsamerweise
braucht man dann keine casts. Der Compiler, das unbekannte Wesen...
@Bingo,
I changed all files to unix style in version r48. I hope this helps.
Just in case you still need it, here is a sample makefile.in:
1
MCU = atmega32
2
EMB_FLASHEND = 0x7FFF
3
EMB_BOOTLOADER_SECTION_START = 0x7C00
4
EMB_LINKER_SCRIPT = -T ../make.files/eth-avr5.x
5
F_CPU = 16000000
6
EMB_BOOTLOADER_FLAVOR = 1
@Dirk
Dirk Armbrust wrote:
> Der Compiler, das unbekannte Wesen...
Nee, der Compiler war ausnahmsweise nicht schuld. Ich habe einfach nur
die Klammern vergessen. Statt
@Dirk
Thank you for the ansvers :-)
But i have allready dint the dos2unix on all files , and have remembered
to do the chmod +x *.sh
@Andreas
Thank you for the makefile.in , it works with that one in the device_00?
directory.
I still got the error if did a make distclean , but i also got a hint
from the checksize.sh script , that was complaining about it was
supposed to be called from make. And it was being called from make.
It is the "Dos PATH hack , that FSCK's UP"
For the checksize i replaced
1
# check size of .text section, the linker will ignore an overflow
2
# we need to manipulate the PATH variable of the shell to be able
3
# to call a script that does not reside in the current directory
4
# this is a hack for the windows version of the GNU shell
Now i can do a make distclean and a make.
And will be prompted for the correct things.
Btw: I was actually expecting to see the Mega644 in there as a MCU
selection.
Thankyou for the quick support :-)
Ohh i use avr-gcc-4.2.2 from this thread (but i guess you can see why)
http://www.avrfreaks.net/index.php?name=PNphpBB2&file=viewtopic&t=42631
mfg
Bingo (Dänemark)
Du kannst die Zeile 26 in der Datei configure.sh ändern.
Du kannst aber auch einfach make aufrufen und bei der Abfrage "Please
select your device" den Namen eingeben: atmega644
Das Script merkt selbst, dass Du keinen vordefinierten Typ ausgewählt
hast, und versucht, die nötigen Daten zu dem Controller zu finden. Das
sollte in diesem Fall funktionieren.
Gruss
Andreas
Hallo,
nach einem Tag Rumprobieren habe ich das erfolgreich zum Laufen gebracht
- funktioniert ganz gut mit atmega644 und 644p auf dem Pollin board.
Danke für die Entwicklung, das war bestimmt ein ganzes Stück Arbeit!
Eine kleine (eigentlich offensichtliche) Tücke - wenn die geladene
Anwendung auch eeprom nutzt, kollidiert das mit den gespeicherten Daten
des Bootloaders - irgentwie kam ich da erst nach einigem Rätseln.
Sprich, das loaden geht genau einmal, wenn die Anwendung dann
irgendwelche Dinge in's Eeprom drüberschreibt (Small version).
Vielleicht schreibe ich das mal auf Flash um.
Grüsse
Axel
Hallo Axel,
ich hatte mal überlegt, die Config des Bootloaders ans Ende des EEPROMs
zu legen, um eben den Konflikt mit Anwendungsdaten zumindest zu
entschärfen.
Besteht da Interesse?
Gruß, Jan
Hallo Jan,
es besteht sogar großes Interesse daran. Ich möchte meine im ganzen Haus
verteilte Boards von Ullich Radig (atmega644p) damit flashen. Ist es
möglich, daß die Experten mal eine gut verständlichen Anleitung, wie
dabei vorzugehen ist, ins Forum stellen.
Vielen Dank für Euer großartiges Projekt!
Detlev
Hallo Jan,
ja, da besteht grosses Interesse auch von meiner Seite. Bin mit dem
Relozieren von Code im Flash noch nicht so firm, das würde bei meinen
Testmöglichkeiten Stunden dauern, so etwas zu realisieren (aushebeln des
644p, ins Eval-Board, flashen, aushebeln, in's Pollin Board ....). Wie
testest Du eigentlich ?
Vermutlich ist es recht einfach - wenn man denn weiss wie - aber allein
Deine Configure Skripte sind ein kleines Wunderwerk für sich. Ich wollte
erst alles in AVR Studio machen, habe die Platzierung im Flash aber
einfach nicht hinbekommen im Rahmen meiner Geduld.
Hallo Detlev,
unsere Projekte scheinen recht ähnlich - ich nutze auch den Radig
Webserver, gedacht zur Hausautomatisierung (nur muss das Haus noch
gebaut werden :-). Das Pollin-Bördchen kommuniziert dann mit IP-Symcon
zwecks Visualisierung über Ethernet sowie mit TTL Seriell (ich weiss -
gewagt) mit Binärein- und -ausgängen, welche jeweils mit einem Atmega16
realisiert sind. Z.B. 30 Binärausgänge im Hutschienengehäuse, welche
24V/16A Koppelrelais ansteuern zwecks Trennung von der Netzspannung.
Allerdings bei mir dann alles im Schaltschrank - kann ja noch Leitungen
legen wie ich möchte.
Grüsse
Axel
So, war jetzt ungeduldig - habe das ganze einmal umgeschrieben von
eeprom auf flash - funktioniert natürlich nur mit Version 'Small', d.h.
ohne Parameteränderung via DHCP und kann mit einem define in der
config.h von eeprom auf flash und vice versa gesetzt werden.
Damit lassen sich nun auch Programme mit eeprom Daten laden, ohne das es
zu einem Konflikt kommt. Zusätzlich habe ich noch eine Initialisierung /
Disable des Watchdog's eingebaut, damit es auch bei einem Softreset via
Watchdog zu keinem Problem kommt. Ohne diesen Zusatz funktionierte nur
ein Hard-Reset, aber der Softreset lief in eine Endlos Watchdog-Schleife
im Bootloader.
Grüsse
Axel
Hallo
Ich habe den Beitrag die ganze Zeit verfolgt und bin sehr gespannt auf
das Ergebnis. Könnt Ihr das Ergebnis mal Posten? Die Quellen würde ich
mir mal gern anschauen. Ich entwickle gerade eine neue Hardware mit
einem Atmega 2561! Da kommt mir Euer Projekt gerade recht!
Gruß Walter
Hallo Walter,
es gibt noch keine offizelle Version, der aktuelle Entwicklungsstand
sollte aber schon funktionieren.
Du kannst die Quellen mit einem SVN-Client unter der Adresse
http://code.google.com/p/avr-etherboot/ abrufen.
Gruß, Jan
Hi,
wäre jemand so nett, funktionierende hex+eep Files hier reinzustellen?
Ich habe zwar den Quellcode bereits unter Linux und Windows übersetzt
bekommen, jedoch keine Reaktion von meinem Pollin NET-IO Board erhalten.
Gruß
Björn
Das kann wie immer vielfältigste Ursachen haben (z.B. falsche IP Adresse
/ Subnetzmaske konfiguriert, kein TFPT Server, ...)
Hast du mal mit Wireshark geschaut, ob überhaupt was über den Draht
geht?
Gruß, Jan
Hi Jan,
habe mit iptables geschaut, da meine input policy auf drop steht. Es
kamen keine Pakete an. Ping hat auch nicht funktioniert, wobei ich hier
nicht sicher bin, ob das überhaupt beim Bootloader implementiert ist?
Gruß
Björn
Nein, Ping ist aus Platzgründen nicht implementiert.
Ich kann dir nur raten mit einem Netzwerkscanner zu arbeiten (Wireshark,
notfalls auch TCP Dump). Alles andere ist stochern im Dunkeln.
Gruß, Jan
Hallo an Alle,
Ich bin schon vor einiger Zeit auf den Beitrag gestoßen.
Nun habe ich auch einmal die Zeit gefunden, einen Versuch zu starten den
Code zum laufen zu gekommen.
Trunk [Rev.49] ausgecheckt. config.h und eemem.c angepast danach
übersetzt.
Small Version für Mega 32.
Keine Fehler - Super!
Rauf damit auf den AVR... Tftpd32 by Ph. Jounin gestartet und sehr
gespannt auf das Ergebnis...
Nichts....
Der Tftp-Server zeigt keine Reaktion!
Debug eingeschaltet, neu übersetzt, neu geflasht und Wireshark gestartet
...
Da kommen 5 mal der gleiche Frame:
Hallo Kai!
Das "arp_entry_search - FAILED" ist keine Überraschung, denn der
Bootloader kennt die MAC-Adresse Deines Servers nicht. Deshalb sendet er
das TFTP Paket zwar an die richtige IP-Adresse (192.168.1.2), setzt aber
für die MAC-Adresse den Broadcast-Wert ff:ff:ff:ff:ff:ff ein. An dem von
Dir geposteten Frame kann man das schön sehen.
1
Ethernet II, Src: MS-NLB-PhysServer-01_02:03:04:21 (02:01:02:03:04:21), Dst: Broadcast (ff:ff:ff:ff:ff:ff)
2
Internet Protocol, Src: 192.168.1.99 (192.168.1.99), Dst: 192.168.1.2 (192.168.1.2)
Das Problem ist: Dein TFTP-Server antwortet nicht!
Nach mehreren Fehlversuchen mischt sich dann ein anderer Rechner (oder
Dein Router?) mit der IP-Adresse 192.168.01.01 ein und sendet einen
ARP-Request, um endlich die MAC-Adresse des Rechners mit der IP-Adresse
192.168.01.02 herauszubekommen:
Darauf antwortet niemand. Der Rechner, auf dem Dein TFTP-Server läuft,
ist in Deinem Netzwerk unbekannt. Hast Du auf diesem Rechner eine
Firewall laufen?
Gruss
Andreas
Hallo Andreas!
Danke für deine Antwort.
Also Firewall und Virusscanner sind aus.
Liegt es an meinem TFTP-Server? Ich verwende den TFTPD32 in Version
"v3.35 Build Sep 15 2009 21:19:12".
Netzwerkboot von Laptop-BISO (PXE-Boot) aus geht wunderbar damit.
Ja Du hast recht das war mein Router. Okay also neuer Versuch:
Laptop - IP geändert 192.168.1.2 - direkt LAN-Verbindung (gekreutztes
Kabel) - TFTP-Server instaliert - Wireshark installiert!
Aber auch kein Erfolg!
Über RS232 sended der Mega:
Okay das zweite Packet ist ein Browserpacket. (siehe Wireshark Bild)
Aber auf die TFTP Packete reagiert der Server wieder nicht. Welchen
TFTP-Server verwendes du? Wie bzw. was hast Du konfigurierend?
Ich bin ratlos! (sämtliche Sicherheiteinstellungen sind ausgeschalten)
Was kann ich noch versuchen? Habt ihr noch ein Tip?
Danke
Hallo Kai!
Deine eemem.c sieht OK aus, so sollte es eigentlich funktionieren.
Hast Du einen zweiten Rechner, mit dem Du den TFTP-Server testen kannst?
Dort könntest Du unter WinXP in der Eingabeaufforderung folgenden Befehl
eingeben.
1
tftp -i 192.168.1.2 GET tst.hex
Dann wüssten wir zumindest schon mal, auf welcher Seite vom Draht wir
das Problem suchen müssen.
Gruss
Andreas
741 63.153431 192.168.1.2 192.168.1.7 TFTP Data Packet, Block: 2
5
.....
TFTP-Server sagt:
1
Connection received from 192.168.1.7 on port 1800 [18/12 19:35:31.004]
2
Read request for file <tst.hex>. Mode octet [18/12 19:35:31.004]
3
Using local port 2015 [18/12 19:35:31.004]
4
<tst.hex>: sent 168 blks, 85530 bytes in 0 s. 0 blk resent [18/12 19:35:31.333]
tftp -i 192.168.1.2 GET tst.hex
Übertragung erfolgreich: 85530 Bytes in 1 Sekunden, 85530 Bytes/s
Also das geht... und jetzt??
Hast Du noch eine Idee was ich machen kann? Vieleicht noch ein paar
Debugmeldungen einbauen? Nur wo?
Danke Kai.
Hallo Kai,
probier doch bitte mal, die IP Adresse des TFTP Servers in der eeprom.c
durch die Broadcast Adresse zu ersetzen:
mlTFTPipEEP = IP(192,168,1,255);
oder alternativ:
mlTFTPipEEP = IP(255,255,255,255);
Ich bin nämlich nicht sicher, ob das mit der Broadcast MAC
ff:ff:ff:ff:ff:ff so funktioniert...
Grüße von Jan
Hallo Jan,
erstmal Danke für den Tip!
Also als erstes habe ich es versucht mit 192.168.1.255. Und es sieht
schon mal etwas besser aus. :-)
Der Server will den Transfer starten bleibt aber bei 0% stehen, weil der
AVR
Hallo,
Haben ich die Sache mit Shellscript auflösen.
Aber leider habe ich die gleiche Problem als Kai Werner.
Alles ist identisch.
Ist vielleicht bereits eine Lösung für diese Problem?
Vielen Dank,
Zdenko.
Mal eine Frage in dem Zusammenhang: Die Routinen aus dem Bootloader z.
B. für UDP werden ja in der Regel auch im USER-Programm benötigt.
Gibt es eine Möglichkeit, dem User Programm beim Kompilieren
mitzuteilen, dass es die UDP Routinen im Bootloader nutzen soll ?
Die liegen ja doort auf festen Adressen.
Gruss
Axel
@Axel,
ja, das ist möglich und auf Dauer auch geplant. Ich möchte diverse
Funktionen, die den Netzwerkstack betreffen von der Applikatino aus
nutzbar machen. Es ist ja auch eh schon so, dass Teile des Bootloaders
in der APP SECTION liegen.
Aber leider verhindert der akute Zeitmangel regelmäßig das Weiterführen
des Projektes - und Freiwilligenmeldungen waren bisher auch eher rar :)
Gruß, Jan
So, habe das jetzt halbwegs zum Laufen bekommen. D. h. das Programmieren
habe ich noch nicht getestet, aber das abholen vom TFTP server klappt.
Allerdings habe ich einiges geändert, so dass ich wirkliche Ursache noch
mal suchen muss.
Allerdings sind mir zwei Dinge aufgefallen:
1. Der ENC*** wird auf Full Duplex konfiguriert. Das wird mit den
meisten Switches nicht klappen, weil die Autonegotiation machen und
dann, wenn sie mit einem Gerät gekoppelt werden, was das nicht kann, in
den Halbduplex Modus wechseln. Wenn der ENC im FullDuplex ist, gibt das
Scherereien. Kann klappen, muss aber nicht.
2. Und die MAC Adressen scheinen mir irgendwie durcheinander gekommen zu
sein. Die sind im ENC*** nicht nur rückwärts sondern völlig verdreht.
Kann man aber umgehen, indem man ein:
enc28j60Write(ERXFCON, 0);
im enc28j60Init einbaut. Dann lässt der alles durch.
Gruss
Axel
Axel schrieb:
> 1. Der ENC*** wird auf Full Duplex konfiguriert. Das wird mit den> meisten Switches nicht klappen, weil die Autonegotiation machen und> dann, wenn sie mit einem Gerät gekoppelt werden, was das nicht kann, in> den Halbduplex Modus wechseln. Wenn der ENC im FullDuplex ist, gibt das> Scherereien. Kann klappen, muss aber nicht.
Hier hat man leider nur die Wahl zwischen Pest und Cholera. Der
Halbduplex-Mode funktioniert beim Enc eher schlecht. Wenn man das Errata
liest, wird einem da schwindelig.
An den von mir getesteten Switches hatte ich bis jetzt mit dem
Vollduplex keine Probleme. Aber Du hast natürlich Recht, dass das bei
manchen Modellen auch schief gehen kann. Die beste Alternative scheint
mir zu sein, den entsprechenden Port des Switches auf Vollduplex
festzunageln (so der Switch konfigurierbar ist).
> 2. Und die MAC Adressen scheinen mir irgendwie durcheinander gekommen zu> sein. Die sind im ENC*** nicht nur rückwärts sondern völlig verdreht.> Kann man aber umgehen, indem man ein:> enc28j60Write(ERXFCON, 0);
Das ist mir noch nicht aufgefallen. Ich werde das mal prüfen, wenn ich
Zeit habe.
Gruss
Andreas
Hallo zusammen,
ich habe den Bootloder auf dem Original-Pollin-Board (AVR-NET-IO) nahezu
problemlos zum laufen bekommen.
Meine Versuche, den Bootloader danach für den ATMega644 für mein
Steckboard (U. Radigs-Veriante des Ethernet-Anschlusses) mit dem
Bootloader zum laufen zu bekommen scheiterten. Nicht ein einziges
IP-Paket wird an an den TFT-Server gesendet.
Zurück zum Pollin-Board, Austausch ATmega32 raus, ATmega644 rein,
nochmal kompiliert und überspielt und es funktioniert ebenso wenig.
Fuses und so weiter sind ok. Was mir aufgefallen ist, in der
device_001.lss liegt das Programm auf 0xfc00, lt. AVR-Studio liegt
allerdings die Boot-Start-Adress auf 0x7e00 (bei 512 Words). Ist das
unerheblich wg. der Wortadressierung oder kann hier ein Fehler vorliegen
?
Hat jemand ähnliche Probleme mit dem ATmega644 schon gelöst und evtl.
einen Tipp für mich ?
Grüße
Ralf
Zu obiger Anfrage eine kleine Ergänzung:
Der Atmega644 lässt sich im Pollin-Board über meinen ISP-Adapter und dem
AVR-Studio sauber programmieren und funktioniert auch tadellos. Nur halt
nicht mit dem Bootloader.
Grüße
Ralf
Mein oben geschildertes Problem hat sich endlich geklärt.
Ich hatte immer den Typ ATmega64 ausgewählt.
Erst der Tipp von Andreas Vogt vom 18.05.2009 hat mir weitergeholfen:
"Du kannst aber auch einfach make aufrufen und bei der Abfrage "Please
select your device" den Namen eingeben: atmega644."
Grüße
Ralf
Hi Leute,
vielen Dank für die großartige Arbeit! Da ich mich gerade auch mit der
Automatisierung meines Eigenheims beschäftige, kommt mir so ein
LAN-Bootloader gerade recht. Ich habs auch schon per svn geholt und
konnte device_001 fehlerfrei compilieren (mit win-avr).. aber bevor ich
es jetzt per isp aufspiele... mal ne blöde frage, wie gehts dann weiter?
Ich nehme an der AVR (bei mir eine atmega644p im pollin net-io) wird
dann beim ersten einschalten versuchen die test.hex Datei per TFTP zu
holen (soweit alles klar, hab schon mit tftp gearbeitet) und wirds dann
wohl auch einflashen aber ich frage mich (hab gestern Nacht das ganze
Thread gelesen aber ich erinnere mich nicht diese Sachen gelesen zu
haben):
1.) muß das per tftp zu flashende image irgendwie speziell
vorbereitet/angepaßt sein für diese Flashmethode oder tuts jedes
beliebige Image, das auch sonst per ISP eingespielt werden kann? Ich
nehme an die Größe sollte nicht den ganzen Flash ausfüllen sondern den
vom bootloader benutzten Bereich freilassen?
2.) was passiert nach dem flashen:
a) bootet der AVR dann selbständig nochmal und führt dann ab sofort nur
noch den neuen Code aus? Ist der Ethernet-Bootloader dann überhaupt noch
da und benutzbar oder muß ich selbst dafür sorgen daß der
tftp-bootloader im neuen Image bereits mit eingebaut wird damit es
wiederholt benutzt werden kann?
b) springt der Bootloader nach dem Flashen ohne Boot den neuen Code an,
aber bei einem Reset wird erneut versucht per tftp zu booten?
Sorry daß ich das jetzt nochmal raufhole aber ich denke das Thema an
sich ist zu interessant für alle, um nunmehr 7 Monate versunken zu
bleiben! Da sich nix mehr getan hat nehme ich an daß entweder alle schon
ganz gut zurechtkommen damit, die es benutzen? Oder haben alle anderen
aufgegeben und nur der Jan benutzt es für sich?
viele Grüße,
Ethan
>1.) muß das per tftp zu flashende image irgendwie speziell>vorbereitet/angepaßt sein für diese Flashmethode ...
Nein, ein normales Hex File reicht.
>Ich nehme an die Größe sollte nicht den ganzen Flash ausfüllen sondern den>vom bootloader benutzten Bereich freilassen?
Richtig
>2.) was passiert nach dem flashen:>a) bootet der AVR dann selbständig nochmal und führt dann ab sofort nur>noch den neuen Code aus?
Ja, es wird in das geladene Programm gesprungen.
>Ist der Ethernet-Bootloader dann überhaupt noch>da und benutzbar
Ja.
> oder muß ich selbst dafür sorgen daß der>tftp-bootloader im neuen Image bereits mit eingebaut wird damit es>wiederholt benutzt werden kann?
Du solltest die Fuses so setzen, dass das neue Image den Bootloader
nicht überschreiben kann.
>b) springt der Bootloader nach dem Flashen ohne Boot den neuen Code an,>aber bei einem Reset wird erneut versucht per tftp zu booten?
Wenn er über TFTP kein Hex-File findet, springt er den vorhandenen Code
an. Aber das muss in den Fuses entsprechend gesetzt werden.
Gruss
Axel
Danke Axel,
also wird nach der Installation des Bootloaders bei jedem Reset versucht
von TFTP ein neues Image zu holen, und wenn nicht, dann das vorhandene
Image gestartet? Dann sollte man ggf. den TFTP-Timeout von 30sek auf
5sek runtersetzen sonst dauert das Starten unnötig lange oder? Ich denke
5 Sek sollten ausreichen um von einem bereits laufenden TFTP Server eine
Antwort zu bekommen?
Hast Du zufällig eine Übersicht wie die Fuses hierfür gesetzt werden
sollten, kurz zur Hand? Wäre echt klasse :-)
Gruß,
Ethan
Habs inzwischen selbst gefunden:
You have to programm both the FLASH (hex-file) and EEPROM (eep-file).
You have to programm the following fuses:
* BOOTSZ0 = 1 (not programmed), BOOTSZ1 = 1 (not programmed) to
select bootsize 512 words.
* BOOTRST = 0 (programmed) to jump to the bootloadercode after reset
and power on.
Nach dem Fuse calculator http://www.engbedded.com/fusecalc ergeben sich
die AVRDUDE Parameter: (für den ATMEGA644P)
-U lfuse:w:0xbf:m -U hfuse:w:0xc6:m -U efuse:w:0xfd:m
Hi Ethan,
den Timeout habe ich bei mir sogar länger gesetzt, weil der ENCxxxx
Ethernet Controller teilweise sehr lange (über eine Minute) braucht, um
das erste Paket zu empfangen. Habe die Ursache dafür aber noch nicht
gefunden, wer einen Tip hat kann sich gerne melden :-).
Fuses hängen natürlich vom Controller ab, weis gerade nicht wie ich das
habe, weis aber noch, dass ich da auch ein bischen geknobelt habe.
Gruss
Axel
Hm, also leider hab ich nach einigen Versuchen noch kein Ergebnis... hab
die Fuses entsprechend gesetzt, nochmal geflasht, verify ok, den Chip in
den Net-Io gesetzt, die LAN-LED's blinken normal (wobei ich annehme das
würden sie auch ohne laufenden AVR tun), aber es kommt kein IP-Paket
beim TFTP-Server an. Hab die IP Adressen im eemem.c angepaßt (Board =
192.168.1.147, Server=192.168.1.106) und Wireshark auf dem Server laufen
lassen, nichts. tftp vom notebook aus getestet --> geht. Kein ARP
Eintrag im Server der auf den NET-IO hindeutet.
Was mich etwas stutzig macht, hab ich nicht geändert:
// remember to update TFTPReqStrSize in eemem.h if you ever change this
TFTPREQ maTFTPReqStr EEMEM = {0x0100, "tst.hex\0octet"};
Die Länge dieses Strings ist 13 (wenn ich das "octet" mitzähle, sonst 8)
aber in der eemem.h steht hierfür:
#define TFTPReqStrSize 16
müßte das nicht 13 bzw. 8 heißen?
Gruß,
Ethan
Scheint mir jetzt auch ein bischen komisch, ist bei mir aber ähnlich.
Da heisst es dann:
memcpy((void*)udpSendBuffer, "heizung_web.hex\0octet", TFTPReqStrSize);
und:
config.h:#define TFTPReqStrSize 24 // stupid compiler does not want to
calculate
passt also.
Letzlich sind die zwei zu viel hier nicht kritisch, man konnte aber ein
paar Bytes im Flash sparen.
Gruss
Axel
Hallo Ethan,
nein, die Länge von maTFTPReqStr ist tatsächlich 16 Bytes:
TFTPREQ maTFTPReqStr EEMEM = {0x0100, "tst.hex\0octet"};
Die ersten zwei Bytes sind der TFTP Read Request 0x01 0x00.
Dann folgen 7 Bytes Dateiname, ein 0-Byte, 5 Bytes für den String octet
und das abschließende 0-Byte. Macht zusammen genau 16 Byte :-)
ich habe jetzt so spontan auch keine Idee, warum dein AVR nix sendet -
bzw. dein Wireshark nix anzeigt. Da gibt es leider ca. 1 Millionen
Möglichkeiten.
Gruß, Jan
Ja, zumal leider der serielle port nix sinnvolles ausgibt, nur
Kauderwelsch... sieht aus wie falsche speed aber ich hab schon alles
durchprobiert, von 2400 bis 57600 aber nix klappt... liegt evtl an den
noch falschen 10µF Elkos am max232? Aber daß sich das so krass auswirkt
daß man echt kein sinnvolles Zeichen übertragen bekommt?
Danke für die Erklärung Jan :-) den Nullbyte am Ende hatte ich
vergessen.
OK, Ich check das nochmal.
Ja, ein mühsames unterfangen im Moment, da ich leider nur durchs
Umstecken in den Pollin-Experimentierboard proggen kann... und auch noch
jedesmal das Netzteil umschrauben muß weil ich nur ein funktionierendes
da habe (hab mindestens 10 in der Bastelkiste aber da ich gerade
umgezogen bin... hab ich gerade darauf keinen Zugriff :-( also heute
schon 25 mal hin und hergesteckt... naja in ein Paar Tagen kommt mein
USB-ISP progger und dann gehts hoffentlich etwas zeit- und
materialschonender ;-)
Aber wo ich Dich grad "dran" hab: Nebenbei würd ich mir wünschen, daß
der DHCP client sich ein Hostname "wünscht" beim DHCP Server, den man
definieren kann (z.B. OPEN-MCP :-) dann könnte man (wenn der Server auch
DNS macht, was ja oft der Fall ist) auch das Board mit Namen ansprechen
statt IP. Ich hab mal etwas gegooglt und ich glaube es ist eine DHCP
Option die man nur einbauen müßte...
EDIT: Sorry jetzt bin ich etwas durcheinander geraten... das war
eigentlich für jemand anders gemeint (der den OPEN-MCP Webserver
geschrieben hat)
Gruß,
Ethan
Jaaaaaaaa ich hab die Fuses geändert auf:
-U lfuse:w:0xe6:m -U hfuse:w:0xd6:m -U efuse:w:0xfc:m
Und jetzt.... kommt gar nix mehr am RS232 :-( aber dafür wird beim TFTP
Server die Datei angefragt! freu
schnell die (absichtlich noch nicht bereitgestellte) Image hinkopiert
und.... DET GEHT! Jo leckmicham.... DET GEHT! megafreu
Also mal wieder ein weiterer Fuse-Opfer auf der Liste ;-) ich hatte mich
nach den Original Pollin NET-IO Vorgaben gerichtet, jetzt aber nach den
OPEN-MCP Vorgaben (ich lad ja dann auch ein OPEN-MCP Image) und jetzt
gehts freu
Vielen Dank Jan für die super Arbeit! Jetzt brauch ich den ISP Progger
eigentlich erstmal gar nicht mehr ;-)
Jetzt könnt ich mich ja mal auf die "medium" Stufe wagen... mit DHCP und
so...
Also momentan kämpfe ich noch mit meinem DHCP Server daß der dem AVR die
richtige TFTP-Server-Adresse mitteilt... ich hab wohl vergessen wo das
steht :-( Die dhcp-option 67 (boot filename) funzt auf anhieb, wenn ich
das ändere dann wird auch direkt nach dem richtigen namen verlangt. aber
der tftp-request wird immer an die 192.168.1.1 gesendet statt an die
1.106 :-(
dhcp-option=66,192.168.1.106
dhcp-option=67,avrboot.hex
dhcp-option=128,192.168.1.106
dhcp-option=150,192.168.1.106
Michael: Welche denn? Im AVR, im router oder im Server?
Es stimmt generell schon überall, könnte höchstens im AVR irgendwo was
übersehen haben...
aus meiner eemem.c:
unsigned long EEMEM mlIpEEP = IP(192,168,1,99);
unsigned long EEMEM mlNetmaskEEP = IP(255,255,255,0);
unsigned long EEMEM mlGatewayEEP = IP(192,168,1,1);
unsigned long EEMEM mlDNSserverEEP = IP(192,168,1,1); //0x0302a8c0;
#ifdef FIXED_TFTP_SRV
unsigned long EEMEM mlTFTPipEEP = IP(192,168,1,106);
#endif
Jetzt wollte ich DEBUG_AV einschalten aber dann sind eine Menge
Variablen nicht definiert :-( UCSRB etc... schade.
Ich hab inzwischen den Verdacht daß die dhcp-option "tftp-server-name"
gar nicht ausgewertet wird, sondern einfach angenommen wird daß der
dhcp-server auch der tftp-server ist? kann das sein?
Seufz, selbst mit diesen Einstellungen will er unbedingt von der
192.168.1.1 die TFTP-Datei holen:
unsigned long EEMEM mlIpEEP = IP(192,168,1,99);
unsigned long EEMEM mlNetmaskEEP = IP(255,255,255,0);
unsigned long EEMEM mlGatewayEEP = IP(0,0,0,0);
unsigned long EEMEM mlDNSserverEEP = IP(0,0,0,0);
Habe mit Wireshark weiter geforscht und die DHCP Pakete mitgelesen, es
wird zwar richtigerweise die Option 66 (filename) und Option 67 (Server
Host Name = 192.168.1.106) übersandt, aber leider auch eine "next server
ip" die falsch ist (192.168.1.1) und das scheint der DHCP Server (mein
DD-WRT Router) eigenmächtig zu machen. Man könnte zwar einen next-server
Eintrag machen aber dies geschieht normalerweise Host-Bezogen, ich weiß
nicht ob ich das global hinbekomme...
JAWOLL!!!!! Endlich folgende Angabe gefunden wie man unter DNSMASQ (das
benutzt nämlich der DD-WRT Router statt DCHPD) den next-server global
festlegt: "dhcp-boot=meinfilename.hex,meinhostname,192.168.1.106"
("meinhostname" kann irgendwas sein, bei mir klappts jedenfalls auch
wenn was falsches drinsteht)
Jetzt kann ich endlich ins Bett gehen :-)
So nachdem mich einige Leute unbedingt aus den Bett klingeln mußten, bin
ich schon wieder dran.... leider war die Freude von kurzer Dauer, denn
nach dem ersten Erfolg hörte der Webserver nach einigen Minuten auf zu
funktionieren und auch ein Reboot zeigte keinen Muckser mehr, keine DHCP
oder TFTP Anfrage. Dachte mir, ok die Schaltung wird jetzt wohl
heißgelaufen sein, probierste morgen nochmal, aber leider heute morgen
auch nicht besser.
Müssen die Fuses für die "medium"-Version anders gesetzt werden? In der
Readme steht ja, für "small" werden 4k Byte gebraucht und für "medium" 6
kByte, aber dennoch soll man für "small" den Bootloaderbereich auf 512k
Words setzen...(?) und für "medium"...?
Hi Ethan,
ist schon ein Weilchen her, dass ich an dem Projekt gearbeitet habe.
Soweit ich mich erinnern kann, verwendet der Bootloader auch FLASH
ausserhalb der BOOT SECTION. Du musst die Größe der BOOT SECTION also
bei allen Varianten auf 512 setzen, der Rest landet dann knapp darunter
im Applikationsbereich.
Gruß, Jan
Hi Jan und andere Mitstreiter,
Also, ich habs gerade nochmal nachvollzogen, wenn ich die Medium Version
aufspiele und dann boote dann wird jedesmal ca. 2 Sekunden nach
Einschalten per TFTP korrekt gebootet (bzw. versucht, da die gewünschte
Datei umbenannt war), 3x versucht, soweit ok. Kriegt er aber die Hex
Datei (150kB laut Windows-Explorer, 3411 Zeilen) dann startet einmalig
das Hauptimage aber beim nächsten Reset tut sich gar nix mehr. Beim
make'en des Hauptimage hab ich leider nur folgenden Anhaltspunkt für die
Größe:
Size after:
text data bss dec hex filename
54314 226 1317 55857 da31 main.elf
Überschreibt evtl. das Image einen Teil des Bootloaders im
Programmflash?
Gruß,
Ethan
Hi Ethan,
ja, das sieht ganz so aus.
Entweder, du hast noch einen Bug in der Flash-Routine entdeckt, oder
dein Image ist zu groß.
Da ist leider keine Prüfung der Grüße drin und da der Bootloader
teilweise im AppFlash liegt, hilft da auch keine Protection über
Fuses...
Gruß, Jan
Wie kann ich denn die genaue Größe des Images ermitteln? Geht das mit
einfachen Bordmitteln (WINAVR)? Wird der Flash byteweise geschrieben
oder blockweise, d.h. gibt es eine bestimmte Grenze die nicht
überschritten werden darf obwohl eigentlich noch Platz wäre?
Hi Ethan,
Flash wird immer blockweise gelöscht/geschrieben, Blockgröße weiß ich
grad nicht ausm Kopf, ist aber im Bereich weniger Bytes - musst du mal
im Datasheet nachschauen.
Ja, WinAVR hat ein Tool, dass die Größe anzeigt. Müsste auch in einer
der Ausgabedateien stehen, die beim Kompilieren erzeugt werden.
Bei Flash muss man immer aufpassen, ob die Angaben Bytes oder Words (=
zwei Bytes) sind!
>Und noch was, wenn das Hauptimage den EEPROM beschreibt, kann es da>Probleme geben beim nächsten Reboot?
Oh ja, natürlich :) Der Bootloader legt ja auch ein paar Bytes dort ab.
Wenn die Anwendung die überschreibt, wirst du Probleme bekommen.
Gruß, Jan
Ich hatte mal einen Bug in de Flashroutine entdeckt, wenn zu grosse
Dateien geladen werden.
Ich dachte allerdings, dass der mitlerweile gefixt war and hatte den
deswegen nicht gepostet.
Kann ich heute abend mal posten.
Gruss
Axel
Ich hab den Webserver nochmal abgespeckt kompiliert und bin nun bei ca.
45k statt vorher rund 55k. Trotzdem funktioniert das Ganze nur einmal,
nach dem Laden des Hauptimage führt das nächste Reset zum Totalausfall.
Das Eeprom wird natürlich auch benutzt. Wie kann ich sicherstellen daß
sich die beiden Programme nicht ins Gehege kommen? Vielleicht ist das ja
das ganze Problem. Legt der Bootloader seine Daten nicht ganz "oben" im
Eeprom ab?
Hier der Ausschnitt aus etherflash.c:
" case 0x02: // extended segment address record
// if bytes are in the page buffer, first write the buffer
if (bytesInBootPage > 0)
{
writeFLASHPage(currentAddress);
}
baseAddress =
(uint32_t)(((uint32_t)(lineBuffer[4]) << 8) + (uint32_t)(lineBuffer[5]))
<< 4;
break;
case 0x03: // start segment address record
case 0x05: // start linear address record
// ignore, we know where to go after the flash
break;
case 0x04: // extended linear address record
// will never show up on smaller devices
(ATmega32, ATmega644) since
// flash address fits in 16 bits, but in case we
have a device with
// more than 64k flash we need to set the upper
adress word here
// if bytes are in the page buffer, first write the buffer
if (bytesInBootPage > 0)
{
writeFLASHPage(currentAddress);
}
baseAddress =
(uint32_t)(((uint32_t)(lineBuffer[4]) << 8) + (uint32_t)(lineBuffer[5]))
<< 16;
break;
}
"
Die Änderung sind die beiden "(unint32_t) bei den zweim Zuweisungen der
baseAddress. Ohne wird anscheinend was oben angeschnitten.
Richtig erklären kann ich das nicht, aber damit geht es bei mir.
Anscheinend rechnet avr_gcc da intern mit signed int so dass bei 32kByte
Schluss ist.
Gruss
Axel
Hi,
ich habe gerade 'mal versucht, etherboot Rev 51 mit Ubuntu 10.04 mit
avr-gcc 4.3.4 zu compilieren.
Dabei gab es folgende Probleme:
1) Permission-Problem (bereits erwähnt)
user@grate:~/esx/avr-etherboot-read-only/device_002# make
makefile:46: makefile.in: No such file or directory
PATH=$PATH:../make.files; . configure.sh avr-gcc ../make.files 0x3ff
../make.files/configure.sh: 61: Syntax error: "(" unexpected
make: *** [makefile.in] Error 2
Fix: chmod +x make.files/*.sh und den "." vor dem Aufruf der Scripte in
makefile weg
2) Compiler-Fehlermeldung
Calculate code size: device_002.sizeelf
avr-gcc -mmcu=atmega32 -I. -gdwarf-2 -DF_CPU=16000000UL
-DBOOTLOADER_FLAVOR=1 -DBLSECSTRT=0x3ff -Os -funsigned-char
-funsigned-bitfields -fpack-struct -fshort-enums -Wall
-Wstrict-prototypes -mcall-prologues -Wa,-adhlns=etherflash.o -I. -I..
-std=gnu99 -Wundef -MMD -MP -MF .dep/device_002.sizeelf.d etherflash.o
checksum.o ethernet.o arp.o enc28j60.o spi.o udp.o dhcpc.o eemem.o
--output device_002.sizeelf -Wl,--defsym=app_start=0
-Wl,-Map=device_002.map,--cref -lm
-Wl,--defsym=app_start=0xEMB_LINKER_SCRIPT = -T ../make.files/eth-avr5.x
-Wl,--section-start=.text=0xEMB_LINKER_SCRIPT = -T
../make.files/eth-avr5.x -Wl,--section-start=.bootloader=0x0000
avr-gcc: =: No such file or directory
avr-gcc: =: No such file or directory
make: *** [device_002.sizeelf] Error 1
Ursache dafür war, dass "dc" (benötigt von configure.sh) nicht
installiert war und dadurch das Offset-define falsch gesetzt ist, was
wiederum diesen auf den ersten Blick komischen Folgefehler verursacht.
3) Fehlermeldung
Size before:
avr-size: unrecognized option '--mcu=atmega32'
"avr-size" (GNU size (GNU Binutils) 2.20) unterstützt die Option --mcu
nicht.
Lösung dafür habe ich noch nicht...
Viele Grüße,
Olli
Ich hab avr-gcc 4.3.2 aus WinAVR-20090313 benutzt unter Win7 x64 und
hatte keine solchen Probleme, weder mit device 001 noch 002.
Welche Revision ich allerdings habe weiß ich nicht, wüßte nicht wo ich
das nachsehen könnte, und alle Dateien haben leider das download-datum
erhalten, habs aber per SVN am 12.12.10 geholt.
Hi,
Wäre es möglich die EEPROM-Daten (gut 100 Bytes) ans Ende des EEPROMs zu
verlegen und somit die Wahrscheinlichkeit verringern daß die gebootete
Applikation die Daten überschreibt?
Gruß,
Ethan
Hab ein wenig rumprobiert und festgestellt daß die Größe des gebooteten
Images scheinbar deutlich unter 60k sein muß:
Connection received from 192.168.1.146 on port 65466 [25/12
12:43:02.517]
Read request for file <othername.hex>. Mode octet [25/12 12:43:02.517]
Using local port 55748 [25/12 12:43:02.517]
TIMEOUT waiting for Ack block #323 [25/12 12:43:21.804]
Ein wenig reduziert und es klappt:
Connection received from 192.168.1.146 on port 65466 [25/12
12:54:25.703]
Read request for file <othername.hex>. Mode octet [25/12 12:54:25.703]
Using local port 54180 [25/12 12:54:25.703]
<othername.hex>: sent 301 blks, 153660 bytes in 4 s. 0 blk resent [25/12
12:54:29.712]
Was ich noch festgestellt hab, ist daß eine eingesteckte MMC Karte
stört, ich hab sie laut Pollin NET-IO Vorgaben angeschlossen (an SDI/SDO
sowie den Card sensor an PD7 und CS an PB3) und sobald die Karte
drinsteckt geht das Netbooten nicht mehr. Aber später einstecken erkennt
dann der Webserver nicht mehr :-(
Gruß,
Ethan
@Ethan,
bringe mal in den Sourcen irgendwo unter das CS (PB3) auf High gesetzt
wird, dann geht es auch mit MMC. Wenn das nicht passiert versucht die
MMC auch auf den SPI zu schreiben/lesen und der ENC28j60 auch, und das
geht dann schief.
CA Dirk
Hi Dirk,
Nach dem Setzen des "Pos" auf 256 legt openmcp jetzt die config dort ab,
wird nicht mehr vom netboot config überschrieben und somit klappt das
netbooten endlich auch mehrfach. Danke!
Aber das MMC Problem hab ich immer noch:
Also bei der Hardware-Init vom Etherboot (etherflash.c) ist drin:
DDRB = 0;
DDRC = 0;
DDRD = 0;
PORTB = 0;
PORTC = 0;
PORTD = 0;
Ich hab probehalber mal DDRB=8 und PORTB=8 draus gemacht (1 ist doch
"high" oder?) aber es hilft leider nix. Muß mal gucken ob woanders im
Source PORTB benutzt wird (mich wunderts eh daß die Init so knapp
ausfällt, das SPI liegt doch auch auf PORTB?)
Gruß,
Ethan
Juchuu es klappt jetzt!
Folgende Änderungen:
etherflash.c in der initializeHardware():
DDRB = 8; //EA set PB3 as output to deselect CS on MMC card
DDRC = 0;
DDRD = 0;
PORTB = 8; //EA set PB3 high --> MMC card not selected
PORTC = 0;
PORTD = 0;
spi.c in der SPI_init():
// set mosi, sck as output
SPI_DDR |= (1<<MOSI) | (1<<SCK);
SPI_PORT |= (1<<MOSI) | (1<<SCK);
und alle anderen SPI_DDR und SPI_PORT befehle auskommentieren
Cool :-) Dankeschön!
EDIT: Wäre es vom design her (seitens Pollin) nicht sinnvoller gewesen,
das CS für die MMC mit einem Pullup statt einem Pulldown zu versehen?
Dann würden solche Sachen nicht passieren, wenn der Port als Imput
geschaltet ist. Ausserdem meine ich mal gelesen zu haben daß ein
Output-Pin besser gegen Masse zieht als gegen VCC?
Michael:
Daß es generell machbar ist, war mir schon klar. Die Frage war eher
unterschwellig an Dirk gerichtet, dem Autor von OpenMCP, vielleicht hat
er ja da schon was in der Schublade liegen... denn eine komplett eigene
Portierung aus einem anderen Projekt übersteigt leider meine
(derzeitigen) Fähigkeiten.
Ethan Arnold schrieb:> Daß es generell machbar ist, war mir schon klar. Die Frage war eher> unterschwellig an Dirk gerichtet, dem Autor von OpenMCP, vielleicht hat
Aachso, jetzt hab ichs verstanden.
Ich dachte, du suchst einfach nur fertige Implementierungen.
@Ethan,
die Idee hatte ich schon im Kopf, hat aber für mich keine Priorität, so
das ich es erst einbauen werde wenn ich für mich bedarf sehe. Und der
ist derzeit nicht da. Es steht aber jeden anderen frei das einzubauen
:-).
CA Dirk
Hallo Zusammen,
ein großartiges Projekt habt ihr da auf die Beine gestellt.
Leider stehe ich mit meiner Mikrocontroller-Erfahrung noch ziemlich am
Anfang, so daß ich hier eure Unterstützung benötige. Leider bekomme ich
den Bootloader nicht zum Laufen:
Einsetzen möchte ich den Bootloader auf einem AVR-NET-IO von Pollin. Das
Board arbeitet einwandfrei.
Als Compiler setze ich unter Debian avr-gcc 4.3.2 ein.
Ausgecheck mittels svn habe ich Rev. 51.
- Mikrocontroler Atmega 32-16PU
- Die Fuse-Bits sind wie folgt gesetzt:
1
avrdude:Devicesignature=0x1e9502
2
avrdude:safemode:lfusereadsasFF
3
avrdude:safemode:hfusereadsas99
Das Pollin AVR-NET-IO arbeitet mit 16 MHz.
Im Verzeichnis device_001 habe ich in der config.h nur das Debuging
eingeschaltet, sonst ist das File unverändert.
1
#define DEBUG_AV 1
2
#define DEBUG_ENC_BUFFER_DATA 1
Die eemem.c wurde nur bei den IP-Adressen angepasst
1
unsignedlongEEMEMmlIpEEP=IP(192,168,5,134);// IP vom AVR-NET-IO ?
2
unsignedlongEEMEMmlTFTPipEEP=IP(192,168,5,48);// IP vom TFT-Server ?
Mittels make habe ich die Parameter auf simple / atmeg32 und 16000000
eingestellt:
makefile.in passt zu den gemachten Angaben:
1
MCU=atmega32
2
EMB_FLASHEND=0x7FFF
3
EMB_BOOTLOADER_SECTION_START=0x7C00
4
EMB_LINKER_SCRIPT=-T../make.files/eth-avr5.x
5
F_CPU=16000000
6
EMB_BOOTLOADER_FLAVOR=1
Angaben nach dem make:
1
Sizeafter:
2
AVRMemoryUsage
3
----------------
4
Device:atmega32
5
6
Program:5048bytes(15.4%Full)
7
(.text+.data+.bootloader)
8
9
Data:783bytes(38.2%Full)
10
(.data+.bss+.noinit)
11
12
EEPROM:114bytes(11.1%Full)
13
(.eeprom)
Das compile.bat kann ich unter linux nicht nutzen, somit haben ich
mittels make programm das device_001.hex zum avr übertragen.
Nun erwartungvoll den atmega32 vom Eval-Board in den avr-net-io
umgestellt und ... nichts.
Am seriellen Port keine Reaktion (38400 Baud), keine Anfragen am
tftd-Server mittels tcpdump feststellbar, die ip-Adresse wird auch nicht
eine MAc-Adresse zugeordnet. Was mache ich falsch? Freu mich über jeden
Hinweis.
Ich schreibe gerne, wenns läuft, ein HowTo, für weitere Interessierte.
Grüße und schönen Sonntag noch,
Detlev.
Läuft der TFPTD Server auf einem Windows-PC oder unter Unix? Firewall
mal probehalber geöffnet? Meine Fuses (auch pollin net-io) sind: L=E6
oder A6, H=D6, E=FC.
Hallo Ethan,
ich arbeitet komplett unter linux, aber bis zum tftpd komme ich gar
nicht.
Arbeitets Du mit einem atmega32?
GIbt es die Fuse E nicht nur beim 644?
Grüße Detlev.
Sorry, hab übersehen daß Du einen Mega32 benutzt, da können die Fuses
natürlich anders sein. Ja ich benutze einen 644p, und nachdem ich die
Fuses hinbekommen hatte hat das booten per tftpd auch auf anhieb
geklappt. Meistens liegts an den Fuses wenn was nicht hinhaut (ich nehme
an Du hattest keine Compilerfehlermeldungen?)
Wenn Du noch gar nicht zum tftpd gekommen bist, wo sniffst Du denn dann
ob Pakete an den Server gesendet werden? Ich würde auf jeden Fall am
Server selbst sniffen und auch einen tftpd starten, zur Sicherheit,
damit der auch auf den entsprechenden Ports hört.
Hallo Ethan,
ich bin ziemlich ratlos, heute gab es eine kurze Aktivität im Netzwerk,
via tcpdump konnte ich an meinem tftp-Server Netzwerkverkehr beobachten.
Die MAC-Adresse war korrekt in die ARP-Tabelle eingetragen, aber das war
es dann auch. Dannach keinerlei Aktivitäten mehr. Sollte ich denn
debug-Ausgaben auf der seriellen Schnittstelle sehen?
Die schweigt, bei 38400.
Grüße Detlev.
boni27 schrieb:> Sollte ich denn> debug-Ausgaben auf der seriellen Schnittstelle sehen?
Ja, wenn DEBUG_AV gesetzt ist, erfolgt gleich beim Programmstart eine
Ausgabe. Ich nehme an, dass Deine HFuse falsch ist. Bei einem Reset muss
der Bootloader gestartet werden, folglich sollte BOOTRST programmiert
(also 0) sein. D.h., Deine HFuse sollte meiner Meinung nach 98 lauten,
nicht 99.
Gruss
Andreas
Hallo Andreas,
habe endlich wieder Zeit gefunden mich meinem Mikrocontroller Projekt zu
widmen.
Danke für die Info, ich habe die Fuse-Bits entsprechend geändert, leider
ohne Erfolg.
Am Wochende erwarte ich eine Lieferung mit einem ATMega 644, vielleicht
habe ich Damit
mehr Erfolg. Es würde mich aber trotzdem interessieren wo der Fehler
liegt.
Ich halte euch auf dem Laufenden.
Grüße Detlev.
Gib doch mal auf http://www.engbedded.com/fusecalc die Fuses ein, das
ist ein sehr hilfreiches Tool um die konfig zu veranschaulichen.
Ich hatte ja meine funktionierenden Fuses für den 644p weiter oben
angegeben, wenn Du die eingibst und die Konfig notierst und dann auf
deinen 32 umstellst, müßtest Du die richtigen Werte für Deinen Chip
erhalten.
Wer lesen kann ist klar im Vorteil, steht alles oben im Zitat:
--section-start=.bootloader=$blss
das ist kein gültiger Syntax und führt dann eben zu sowas:
missing argument(s) to option "--section-start"
Hallo,
ich bin an diesem Netzwerk-Bootloader sehr interesiert. Ich verwende
einen AT90Can128 Baustein. Deswegen möchte ich den Bootloader gerne
anpassen. Ich verwende das AVR Studio 4.0 oder 6.0.
Leider kenne ich mit den Makefile nicht so aus. Kann mir jemand beim
"Portieren" des Projekts in ein AVR Studio helfen oder zu Verfügung
stellen ?
Gruss Harald
ja okay, das geht, aber ich müsste dann "zu Fuss" in dem Makefile mein
At90can128 reinbasteln. Da kenne ich mich eben nicht so aus. Mir wäre
ein AVR Studio Projekt doch lieber :D.
Muss ich da in den Memory Settings eigentlich den Bootloader Bereich
einstellen ?
Harald Stinus schrieb:> ja okay, das geht, aber ich müsste dann "zu Fuss" in dem Makefile mein> At90can128 reinbasteln. Da kenne ich mich eben nicht so aus.
Dann musst du eben dazulernen.
Die Vorlagen gibts doch hier fix und fertig.
> Muss ich da in den Memory Settings eigentlich den Bootloader Bereich> einstellen ?
nicht mit dem richtigen externen makefile =)
Hallo zusammen,
auch wenn hier schon einige Zeit vergangen ist, ich versuche gerade
DEBUG_AV in avr-etherboot mit einem mega644 zu benutzen. Allerdings sind
dafür wohl die Definitionen der Register falsch. :( Wie auch Ethan
weiter oben schon bemerkte:
<< Jetzt wollte ich DEBUG_AV einschalten aber dann sind eine Menge
Variablen nicht definiert :-( UCSRB etc... schade.
>>
Gibt es da noch irgendwelche configs oder defines welche ich bisher
übersehen habe?
Danke und Gruß,
Manfred
Manfred schrieb:> Gibt es da noch irgendwelche configs oder defines welche ich bisher> übersehen habe?
Nein, gibt es nicht. Das Debugging fand damals auf einem Mega32 statt,
ich glaube, das steht auch in einem Kommentar am Anfang der main(). Um
den Mega644 verwenden zu können, musst Du die Registernamen selbst
anpassen - sind nicht viele, sollte also kein Problem sein.
Ein Ethernetbootloader ist sicherlich cool, aber ich frage mich, ob man
das wirklich will.
Wie sicherst du den Bootloader gegen kriminelle Nutzung ab?
Oder kann bald jeder über das Internet meine Kaffeemaschine neu flashen?
Hallo Leute,
erstmal saubere Arbeit! Hab mir die naechte mir e6 um die Ohren gehauen,
ohne erfolg. Alles was ich wollte ist ein ethernet bootloader und dhcp.
Dann bin ich auf diesen Thread gestoszen, bootloader unter 2K, awesome!
Mein plan ist, einen 328p damit zu bestuecken.
Ich bin auf debian unterwegs, beim kompilleren schmeiszt avr-gcc
folgenden fehler:
1
2
kautzz@hal:~/code/avr/avr-etherboot-read-only/device_001$ make
3
makefile:46: makefile.in: No such file or directory
Ich hab configure.sh und checksize.sh ausfuehrbar gemacht, wie Bingo
beschrieb. Beitrag "Re: Atmega via Ethernet flashen"
Auch den trick mit der win/unix formatierung hab ich ausprobiert.
(obwohl das seit r48 gefixed sein sollte)
Den "DOS-path-hack" habt ihr ja scheinbar auch schon umgebaut.
Beitrag "Re: Atmega via Ethernet flashen"
Habt ihr sonst noch Ideen?
Verwende avr-gcc 4.7.2
grusz
mrv schrieb:> avr-etherboot-read-only
Wenn das Verzeichnis wirklich read only ist, kanns nicht funktionieren,
denn es werden natürlich Dateien erzeugt.
mrv schrieb:> ethernet bootloader und dhcp.
[...]
> bootloader unter 2K
Jaaaa, aber...
Unter 2K (Worte) hat der Code leider nur ohne DHCP. Mit sind es 3K.
Andreas Vogt schrieb:> Wenn das Verzeichnis wirklich read only ist, kanns nicht funktionieren,> denn es werden natürlich Dateien erzeugt.
Hab nochmal nachgeschaut, schreibrechte sind da. Read-only hat in diesem
fall nur was mit svn zu tun, glaub ich.
> Jaaaa, aber...> Unter 2K (Worte) hat der Code leider nur ohne DHCP. Mit sind es 3K.
3k ist auch verdammt klein, da habt ihr euch muehe gegeben :D
Also ich hab jetzt das makefile.in selbst angelegt.
1
MCU=atmega328p
2
EMB_FLASHEND=0x7FFF
3
EMB_BOOTLOADER_SECTION_START=0x7C00
4
EMB_LINKER_SCRIPT=-T../make.files/eth-avr5.x
5
F_CPU=8000000
6
EMB_BOOTLOADER_FLAVOR=2
Dabei fiel mir auf warum es "leider 3k sind".
Kann es sein, dass der 328p eine maximale 'boot flash section size' von
2k hat?
Verstaendnissfrage: warum ist die boot section auf 2k limitiert, wenn
der 328p einen flash von 16k hat?
Nochmal zu der makefile.in:
EMB_FLASHEND ist das ende des bootloaders? Das wird dann bestimmt von
checksize.sh gesetzt?!
Was sind die unterschiede zwischen den eth-avr files in make.files/?
Entschuldigt die wahrscheinlich banalen fragen, bin einsteiger auf dem
gebiet der avrs und hab bis jetzt nur mit arduino gearbeitet. (der
umstieg ist durch die grosze abstraktion von wiring recht schwer, haette
gleich mit puren avrs beginnen sollen)
Da nehm ich dann wohl lieber den 644...
okay... jetzt scheints durchzulaufen.
der 'dos path hack' existiert doch noch, in der eemem.c.
hab die beiden zeilen wie hier beschrieben geaendert:
Beitrag "Re: Atmega via Ethernet flashen"
nun wird auch das makefile.in generiert.
der 328p taucht da nicht explizit auf, kann ich einfach den atmega32
auswaehlen?
Stichwort Ethernet: Das muss ja längst nicht IP/UDP und schon gar nicht
TCP heißen. Gerade beim erwähnten Hausbus ist der eigentliche Vorteil
von TCP/IP nämlich Routingfähigkeit möglicherweise weder erwünscht noch
benötigt. Warum also nicht Datenaustausch (inkl. flashen) per Ethernet.
Meine Antwort darauf: Leider immer schwieriger, man möchte ja auch per
Computer an der Kommunikation teilnehmen. Unter MAC OS oder Linux nicht
wirklich problematisch aber Windows erfordert in den neueren Versionen
signierte Treiber um Raw-Ethernet zu fahren. Keine schöne Entwicklung.
Cube_S schrieb:> Meine Antwort darauf: Leider immer schwieriger, man möchte ja auch per> Computer an der Kommunikation teilnehmen. Unter MAC OS oder Linux nicht> wirklich problematisch aber Windows erfordert in den neueren Versionen> signierte Treiber um Raw-Ethernet zu fahren. Keine schöne Entwicklung.
Und winpcap (http://www.winpcap.org/) funktioniert bei Dir nicht?
fchk
Hallo!
Hat das schon wer auf dem mega2560 probiert?
Könnte mir jemand mit den fuses und ports (config.h) helfen?
Ich bin da technisch nicht so fit.
Robert
Thread beobachten
Seitenaufteilung abschalten