www.mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik Atmega via Ethernet flashen


Autor: Chris (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Michael H* (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Simon K. (simon) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Oh gott, wenn du schon so etwas fragst, dann kannst du die Idee sicher 
erstmal wieder verwerfen.

Autor: Sab (Gast)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
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

Autor: Chris (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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 ;-)

Autor: Simon K. (simon) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Knut Ballhause (Firma: TravelRec.) (travelrec) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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ß.

Autor: Michael H* (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
geht auch, wenn genügend platz im eigenen flash ist

Autor: Frank (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Stefan Ernst (sternst)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Frank (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>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!

Autor: Andreas K. (a-k)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Stefan Ernst (sternst)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: thorsten (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Martin S. (smartinick)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Christian Berger (casandro) Flattr this
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Jan Krause (jeangonzales)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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 :)

Autor: Dirk Broßwick (sharandac)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Matthias (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>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.

Autor: Jan Krause (jeangonzales)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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

Autor: Dirk Broßwick (sharandac)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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.

Autor: Uwe Berger (boerge) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
vielleicht hilft dieser Link in den Gedankenspielen weiter: 
http://www.ethersex.de/tiki-index.php?page=EtherSex

Uwe

Autor: Christian Berger (casandro) Flattr this
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Jan Krause (jeangonzales)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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.

Autor: Simon K. (simon) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Jan Krause (jeangonzales)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wenn du nochmal genau hinschaust, wirst du sehen, dass ich 
unübersichtlich schrieb !

Autor: Dirk Broßwick (sharandac)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Simon K. (simon) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Dirk Broßwick (sharandac)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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

Autor: Jan Krause (jeangonzales)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Dirk
Email ist raus.
Bin ja mal gespannt, ob da was draus wird :)

Autor: Chris (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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!

Autor: TheRealChris (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Peter Birkenstock (atmelfriend)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Jan Krause (jeangonzales)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Gast (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Gibt es schon Neuigkeiten zu dem Projekt?

Autor: Jan Krause (jeangonzales)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Michael H* (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: SD-Fritze (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Interressemeld!
:-)


(Sorry für Einzeiler)

Autor: Julian W. (julian-w) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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!!!

Autor: Jan Krause (jeangonzales)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Dominik (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
geile sache, vielen dank

Autor: Mehmet Kendi (mkmk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Jan Krause (jeangonzales)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Frank aus Köln (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Gast (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

ich denke mal das die Angabe in Words gemacht wird, und da ein Word 2 
Byte umfasst geht die rechnung schon auf.

Autor: Tom (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Oliver S. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Jan Krause (jeangonzales)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Andreas (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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:
uint8_t hexToByte(uint8_t *buf, uint16_t idx)
{
  uint8_t val = 0;
  uint8_t i, t;
  for (i=0; i<2; i++)
  {
    t = buf[idx+i];
    if (t >= (uint8_t)'0' && t <= (uint8_t)'9')
    {
      // digit
      val = (val<<4) + t - (uint8_t)'0';
      
    } else if (t >= (uint8_t)'A' && t <= (uint8_t)'F')
    {
      // hex digit a-f
      val = (val<<4) + t - (uint8_t)'A' + 10;
    }
  }    
  return val;
}

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:
uint8_t hexToByte(uint8_t *buf, uint16_t idx)
{
  uint8_t val = 0;
  uint8_t i, t;
  for (i=0; i<2; i++)
  {
    t = buf[idx+i];
    if (t > (uint8_t)'9')
    {
      // hex digit a-f
      val = (val<<4) + t - (uint8_t)'A' + 10;
    } else
    {
      // digit 1-9
      val = (val<<4) + t - (uint8_t)'0';
    }
  }    
  return val;
}
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

Autor: Jan Krause (jeangonzales)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Andreas (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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
inline uint8_t hexToByte(uint8_t *buf, uint16_t idx)
kann man dem Compiler den Unfug austreiben.

Gruss
Andreas

Autor: Michael H* (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Jan Krause (jeangonzales)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Jan Krause (jeangonzales)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Stefan Ernst (sternst)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Andreas Vogt (tico)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Jan Krause wrote:
> So, hier mal meine aktuelle Version.

Hallo Jan,

auf die schnelle fällt mir die neue Definition in etherflash.h auf:
#if defined (__AVR_ATmega644__)
  #define pBootloader()      asm volatile ("call 0x7000"::)
#endif

Ich denke, da müsste 0xE000 statt 0x7000 stehen, der ATmega644 hat ja 
64k Flash.

Gruss
Andreas

PS: Ich habe mich jetzt mal hier angemeldet ;)

Autor: Stefan Ernst (sternst)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Andreas Vogt wrote:

> Ich denke, da müsste 0xE000 statt 0x7000 stehen, der ATmega644 hat ja
> 64k Flash.

Nein, denn "call" erwartet eine Wort Adresse.

Autor: Andreas Vogt (tico)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Stefan Ernst wrote:
> 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.

Das würde dann möglicherweise auch erklären, warum Jan Probleme hat, von 
der Applikation in den Bootloader zu springen.

Gruss
Andreas

Autor: Frank aus Köln (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo zusammen,

noch eine Idee um den Code noch kleiner zu bekommen.
Werft doch die math.c raus und legt statt dessen folgendes macro an:
#define htons(A) ((((A) & 0xff00) >> 8) | (((A) & 0x00ff) << 8))
#define htonl(A) ((((A) & 0xff000000) >> 24) | (((A) & 0x00ff0000) >> 8) | \
                 (((A) & 0x0000ff00) << 8) | (((A) & 0x000000ff) << 24)) 
#define ntohs htons 
#define ntohl htonl
Statt mit ChangeEndian wird dann zum Beispiel so gewandelt:
sock.Bufferfill = htons (UDP_packet->UDP_Datalenght) - UDP_HEADER_LENGHT;
Das spart dann noch ein paar Bytes.
Die Idee stammt nicht von mir sondern von  Stefan Ernst. (Danke nochmal)

Gruß aus Köln

Frank

Autor: Stefan Ernst (sternst)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Frank aus Köln wrote:

> Die Idee stammt nicht von mir sondern von  Stefan Ernst. (Danke nochmal)

???
Meinst du jemand anderen mit dem gleichen Namen?

Autor: Jan Krause (jeangonzales)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Frank aus Köln (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Stefan,

ich denke das du das warst: 
Beitrag "Re: Tut gelesen und trotzdem Problem mit Strings im Flash"

Gruß aus Köln

Frank

Autor: Frank aus Köln (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Stefan,

sorry das war Stefan B.

Gruß aus Köln

Frank

Autor: Jan Krause (jeangonzales)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
So, habe mal bei Google-Code ein Projekt geöffnet:

http://code.google.com/p/avr-etherboot/

Jetzt kann jeder mitmachen, der möchte!

Grüße von Jan

Autor: Andreas Vogt (tico)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Jan Krause (jeangonzales)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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:
48e:  0e 94 00 1c   call  0x3800

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):
#if defined (_AVR_ATmega32_)
  #define pBootloader()      asm volatile ("call 0x7000"::)
#endif

Autor: Andreas Vogt (tico)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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
call 0x0200
zu folgendem Hexcode umgewandelt:
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:
asm volatile ("call 0x0200"::)
zu folgendem Hexcode gewandelt:
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

Autor: Jan Krause (jeangonzales)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Claus (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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/brow...
(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

Autor: Andreas Vogt (tico)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Claus (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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:
...
./config.h:26:5: warning: "BOOTLOADER_VERSION" is not defined
...
Calculate code size: device_002.sizeelf
avr-gcc -mmcu=atmega32 -I. -gdwarf-2 -DF_CPU=16000000UL -DBOOTLOADER_FLAVOR=1 -D
BLSECSTRT=0x3ff -Os -funsigned-char -funsigned-bitfields -fpack-struct -fshort-e
nums -Wall -Wstrict-prototypes -mcall-prologues -Wa,-adhlns=etherflash.o -I. -I.
. -std=gnu99 -Wundef -MMD -MP -MF .dep/device_002.sizeelf.d etherflash.o checksu
m.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,--de
fsym=app_start=0xEMB_LINKER_SCRIPT = -T ../make.files/eth-avr5.x -Wl,--section-s
tart=.text=0xEMB_LINKER_SCRIPT = -T ../make.files/eth-avr5.x  -Wl,--section-star
t=.bootloader=0x0000
avr-gcc: =: No such file or directory
avr-gcc: =: No such file or directory
make: *** [device_002.sizeelf] Error 1
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-downlo.... 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

Autor: Andreas Vogt (tico)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Claus (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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:
Calculate code size: device_002.sizeelf
avr-gcc -mmcu=atmega32 -I. -gdwarf-2 -DF_CPU=16000000UL -DBOOTLOADER_FLAVOR=1 -D
BLSECSTRT=0x3ff -Os -funsigned-char -funsigned-bitfields -fpack-struct -fshort-e
nums -Wall -Wstrict-prototypes -mcall-prologues -Wa,-adhlns=etherflash.o -I. -I.
. -std=gnu99 -Wundef -MMD -MP -MF .dep/device_002.sizeelf.d etherflash.o checksu
m.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,--de
fsym=app_start=0xEMB_LINKER_SCRIPT = -T ../make.files/eth-avr5.x -Wl,--section-s
tart=.text=0xEMB_LINKER_SCRIPT = -T ../make.files/eth-avr5.x  -Wl,--section-star
t=.bootloader=0x0000
avr-gcc: =: No such file or directory
avr-gcc: =: No such file or directory
make: *** [device_002.sizeelf] Error 1

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

Autor: Andreas Vogt (tico)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Claus (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: JaaWaa (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Andreas Vogt (tico)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Malte __ (malte) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ist zwar ein anderer Ethernet Controller, aber mich wundert es, dass
http://www.ethernut.de/en/eboot/index.html
noch nicht erwäht wurde.

Autor: Claus (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Jan Krause (jeangonzales)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Dirk Armbrust (tuxbow)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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:
boot_spm_busy_wait();   // Wait until the memory is written.
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():
//Komplementbildung (addiert Long INT_H Word mit Long INT L Word)
while (checksum.nWordAcc.DataH)
//checksum.lLongAcc = checksum.nWordAcc.DataL + checksum.nWordAcc.DataH;
// ohne die casts wird 16 bit addition gemacht, ohne carry.
checksum.lLongAcc =
 (uint32_t) checksum.nWordAcc.DataL + (uint32_t) checksum.nWordAcc.DataH;
return ~(checksum.nWordAcc.DataL);
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.

Autor: Andreas Vogt (tico)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Bingo (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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"
usr@arwen:~/avr/etherboot/avr-etherboot-read-only/device_001$ make clean
makefile:46: makefile.in: No such file or directory
PATH=$PATH:../make.files; . configure.sh avr-gcc ../make.files 0x3ff
: not foundes/configure.sh: 9: 
: not foundes/configure.sh: 17: 
: not foundes/configure.sh: 18: 
: not foundes/configure.sh: 20: 
: not foundes/configure.sh: 24: 
: not foundes/configure.sh: 27: 
: not foundes/configure.sh: 30: 
: not foundes/configure.sh: 33: 
: not foundes/configure.sh: 37: 
: not foundes/configure.sh: 38: 
: not foundes/configure.sh: 60: 
: not foundes/configure.sh: 61: 
../make.files/configure.sh: 62: Syntax error: "(" unexpected
make: *** [makefile.in] Error 2

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.

usr@arwen:~/avr/etherboot/avr-etherboot-read-only/device_001$ 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

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

Autor: Dirk Armbrust (tuxbow)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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:
void FillFlashPage(uint32_t currentAddress, uint8_t loByte, uint8_t hiByte)
{  // All SPM instructions must be in the NRWW section
  boot_page_fill_safe(currentAddress, (uint16_t)loByte + (uint16_t)(hiByte << 8));
}
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...
void FillFlashPage(uint32_t currentAddress, uint16_t dddd)
{  // All SPM instructions must be in the NRWW section
  boot_page_fill_safe( currentAddress, dddd );
}
void processLineBuffer(uint8_t bytes)
....
FillFlashPage (currentAddress, lineBuffer[i+4+0] + (lineBuffer[i+4+1]<<8));
....

natürlich auch den prototypen in etherflash.h entsprechend ändern.

Gruß, Dirk.

Autor: Andreas Vogt (tico)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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:
MCU = atmega32
EMB_FLASHEND = 0x7FFF
EMB_BOOTLOADER_SECTION_START = 0x7C00
EMB_LINKER_SCRIPT = -T ../make.files/eth-avr5.x
F_CPU = 16000000
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
boot_page_fill_safe(currentAddress, loByte + hiByte << 8);
muss es natürlich heißen:
boot_page_fill_safe(currentAddress, loByte + (hiByte << 8));
War doch schon zu spät gestern... ;)

Gruss
Andreas

Autor: Bingo (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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
# check size of .text section, the linker will ignore an overflow
# we need to manipulate the PATH variable of the shell to be able
# to call a script that does not reside in the current directory
# this is a hack for the windows version of the GNU shell
  PATH=$$PATH:$(SCRIPTPATH) && . $(SCRIPTCHECK) $(FCODESIZE) $(STAT_BLSECSIZE) $(EMB_BOOTLOADER_SECTION_START)

With
# check size of .text section, the linker will ignore an overflow
# we need to manipulate the PATH variable of the shell to be able
# to call a script that does not reside in the current directory
# this is a hack for the windows version of the GNU shell
  $(SCRIPTPATH)/$(SCRIPTCHECK) $(FCODESIZE) $(STAT_BLSECSIZE) $(EMB_BOOTLOADER_SECTION_START)

For the makefile.in i replaced
makefile.in :
# we need to manipulate the PATH variable of the shell to be able
# to call a script that does not reside in the current directory
# this is a hack for the windows version of the GNU shell
  PATH=$$PATH:$(SCRIPTPATH); . $(SCRIPTFILE) $(CC) $(SCRIPTPATH) $(STAT_BLSECSIZE)

With
makefile.in :
# we need to manipulate the PATH variable of the shell to be able
# to call a script that does not reside in the current directory
# this is a hack for the windows version of the GNU shell
  $(SCRIPTPATH)/$(SCRIPTFILE) $(CC) $(SCRIPTPATH) $(STAT_BLSECSIZE)


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&f...

mfg
Bingo (Dänemark)

Autor: Bingo (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
The avr-gcc-4.2.2 reports this for size

Size after:
AVR Memory Usage
----------------
Device: atmega32

Program:    4782 bytes (14.6% Full)
(.text + .data + .bootloader)

Data:        783 bytes (38.2% Full)
(.data + .bss + .noinit)

EEPROM:      114 bytes (11.1% Full)
(.eeprom)

mfg
Bingo

Autor: dabuze (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Was muss man ändern, damit auch der ATMega 644 in der Auswahl 
auftaucht??

Autor: Andreas Vogt (tico)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Axel Ro. (axelroro)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Jan Krause (jeangonzales)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: devo (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Axel Ro. (axelroro)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Axel Ro. (axelroro)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Walter Dick (walter56)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Jan Krause (jeangonzales)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Walter Dick (walter56)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Danke! Tolle Arbeit! :-))

Autor: Björn B. (elmo)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Jan (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Björn B. (elmo)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Jan (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Kai Werner (kai_werner)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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:
351  8.903331  192.168.1.99  192.168.1.2  TFTP  Read Request, File: tst.hex\000, Transfer type: octet\000
Frame 351 (60 bytes on wire, 60 bytes captured)
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)
Internet Protocol, Src: 192.168.1.99 (192.168.1.99), Dst: 192.168.1.2 (192.168.1.2)
User Datagram Protocol, Src Port: 65466 (65466), Dst Port: tftp (69)
  Source port: 65466 (65466)
  Destination port: tftp (69)
  Length: 24
  Checksum: 0x5b36 [validation disabled]
    Good Checksum: False
    Bad Checksum: False
Trivial File Transfer Protocol
  Source File: tst.hex
  Opcode: Read Request (1)
  Source File: tst.hex
  Type: octet

Auf der Console vom Mega sehe ich:
***********************
Start
ETH_INIT
enc28j60WriteBuffer start
000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
enc28j60WriteBuffer end
enc28j60WriteBuffer start
000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
enc28j60WriteBuffer end
stack_init done
arp_entry_search
c0a80102
arp_entry_search - FAILED
enc28j60WriteBuffer start
ffffffffffff02010203042108004500002c000140004011b70ac0a80163c0a80102ffba004500185b3600017473742e686578006f6374657400
enc28j60WriteBuffer end
UDP_SendPacket
TFTP RRQ sent
TFTP timeout
arp_entry_search
c0a80102
arp_entry_search - FAILED
enc28j60WriteBuffer start
ffffffffffff02010203042108004500002c000240004011b709c0a80163c0a80102ffba004500185b3600017473742e686578006f6374657400
enc28j60WriteBuffer end
UDP_SendPacket
TFTP RRQ sent
TFTP timeout
arp_entry_search
c0a80102
arp_entry_search - FAILED
enc28j60WriteBuffer start
ffffffffffff02010203042108004500002c000340004011b708c0a80163c0a80102ffba004500185b3600017473742e686578006f6374657400
enc28j60WriteBuffer end
UDP_SendPacket
TFTP RRQ sent
TFTP timeout
arp_entry_search
c0a80102
arp_entry_search - FAILED
enc28j60WriteBuffer start
ffffffffffff02010203042108004500002c000440004011b707c0a80163c0a80102ffba004500185b3600017473742e686578006f6374657400
enc28j60WriteBuffer end
UDP_SendPacket
TFTP RRQ sent
enc28j60ReadBuffer start
ffffffffffff001f3fad688308060001080006040001001f3fad6883c0a80101000000000000c0a80102432061757468656e74696361746900000000abac97d3
enc28j60ReadBuffer end
TFTP timeout
arp_entry_search
c0a80102
arp_entry_search - FAILED
enc28j60WriteBuffer start
ffffffffffff02010203042108004500002c000540004011b706c0a80163c0a80102ffba004500185b3600017473742e686578006f6374657400
enc28j60WriteBuffer end
UDP_SendPacket
TFTP RRQ sent
TFTP timeout
TFTP timeout
enc28j60ReadBuffer start
ffffffffffff0016e68b78450800450000e55c82000080115934c0a80102c0a801ff008a008a00d15a2211028035c0a80102008a00bb00002045494550454e454643414341434143414341434143414341434143414341434100204542464345434546454a4645464445484643464646414641454643414341424e00ff534d422500000000000000000000000000000000000000000000000000000011000021000000000000000000e803000000000000000021005600030001000000020032005c4d41494c534c4f545c42524f57534500010080fc0a00484f4d450000000000006400000000000501031001000f0155aa009c474fef
enc28j60ReadBuffer end
No funktion for this packet found - discarded
TFTP timeout
TFTP timeout
TFTP timeout
TFTP timeout
TFTP timeout
TFTP timeout
TFTP timeout
TFTP timeout
enc28j60ReadBuffer start
ffffffffffff001f3fad688308060001080006040001001f3fad6883c0a80101000000000000c0a801023a30205d0074000024000e000000000000003fb0b076
enc28j60ReadBuffer end
TFTP timeout
TFTP timeout
TFTP timeout

Was mache ich falsch?

c0a80102 ist doch 192.168.1.2 und da läuft mein Tftp-Server.
Aber immer
arp_entry_search - FAILED
 - also keine Antwort - Oder?
Filename sollte doch "tst.hex" sein - Oder?

Könnt Ihr mir bitte helfen und einen Tip geben?


Danke

Autor: Andreas Vogt (tico)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.
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)
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:
enc28j60ReadBuffer start
ffffffffffff001f3fad688308060001080006040001001f3fad6883c0a80101000000000000c0a80102432061757468656e74696361746900000000abac97d3
enc28j60ReadBuffer end
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

Autor: Kai Werner (kai_werner)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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:
***********************
Start
ETH_INIT
enc28j60WriteBuffer start
000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
enc28j60WriteBuffer end
enc28j60WriteBuffer start
000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
enc28j60WriteBuffer end
stack_init done
arp_entry_search
c0a80102
arp_entry_search - FAILED
enc28j60WriteBuffer start
ffffffffffff02010203042108004500002c000140004011b70ac0a80163c0a80102ffba004500185b3600017473742e686578006f6374657400
enc28j60WriteBuffer end
UDP_SendPacket
TFTP RRQ sent
enc28j60ReadBuffer start
ffffffffffff000d607f38cb0800450000ed02cd00008011b2e1c0a80102c0a801ff008a008a00d9d66b11028044c0a80102008a00c3000020454a4543454e4650454d45424641464a4341
434143414341434143414341414100204142414346504650454e4644454346434550464846444546465046504143414200ff534d4225000000000000000000000000000000000000000000
00000000000011000029000000000000000000e80300000000000000002900560003000100010002003a005c4d41494c534c4f545c42524f575345000c00e0930400415242454954534752
55505045000080030a001000800080f87f49424d5f4c41505900b4c0b0e2
enc28j60ReadBuffer end
No funktion for this packet found - discarded
TFTP timeout
arp_entry_search
c0a80102
arp_entry_search - FAILED
enc28j60WriteBuffer start
ffffffffffff02010203042108004500002c000240004011b709c0a80163c0a80102ffba004500185b3600017473742e686578006f6374657400
enc28j60WriteBuffer end
UDP_SendPacket
TFTP RRQ sent
TFTP timeout
arp_entry_search
c0a80102
arp_entry_search - FAILED
enc28j60WriteBuffer start
ffffffffffff02010203042108004500002c000340004011b708c0a80163c0a80102ffba004500185b3600017473742e686578006f6374657400
enc28j60WriteBuffer end
UDP_SendPacket
TFTP RRQ sent
TFTP timeout
arp_entry_search
c0a80102
arp_entry_search - FAILED
enc28j60WriteBuffer start
ffffffffffff02010203042108004500002c000440004011b707c0a80163c0a80102ffba004500185b3600017473742e686578006f6374657400
enc28j60WriteBuffer end
UDP_SendPacket
TFTP RRQ sent
TFTP timeout
arp_entry_search
c0a80102
arp_entry_search - FAILED
enc28j60WriteBuffer start
ffffffffffff02010203042108004500002c000540004011b706c0a80163c0a80102ffba004500185b3600017473742e686578006f6374657400
enc28j60WriteBuffer end
UDP_SendPacket
TFTP RRQ sent
TFTP timeout
TFTP timeout
TFTP timeout
TFTP timeout
TFTP timeout
....

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

Autor: Kai Werner (kai_werner)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hier mal meine eemem.c. Vieleicht habe ich ja da einen Fehler?
#include "config.h"
#include "eemem.h"

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); //0x0201a8c0;

#ifdef FIXED_TFTP_SRV
unsigned long EEMEM mlTFTPipEEP = IP(192,168,1,2);
#endif

//************
// remember to update TFTPReqStrSize in eemem.h if you ever change this
TFTPREQ maTFTPReqStr EEMEM = {0x0100, "tst.hex\0octet"};
//************
// remember to update TFTPErrStrSize in eemem.h if you ever change this
TFTPERR maTFTPErrStr EEMEM = {0x0500, 0x0500, "Sorry, wasn't talking to you!"};
....

Danke im Voraus

Gruß Kai

Autor: Andreas Vogt (tico)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.
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

Autor: Kai Werner (kai_werner)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Andreas!

Das ist ein gute Idee. gleich ausprobieren.

Laptop an und start....
738  63.099960  192.168.1.7  192.168.1.2  TFTP  Read Request, File: tst.hex\000, Transfer type: octet\000
739  63.151550  192.168.1.2  192.168.1.7  TFTP  Data Packet, Block: 1
740  63.153077  192.168.1.7  192.168.1.2  TFTP  Acknowledgement, Block: 1
741  63.153431  192.168.1.2  192.168.1.7  TFTP  Data Packet, Block: 2
.....
TFTP-Server sagt:
Connection received from 192.168.1.7 on port 1800 [18/12 19:35:31.004]
Read request for file <tst.hex>. Mode octet [18/12 19:35:31.004]
Using local port 2015 [18/12 19:35:31.004]
<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.

Autor: Jan Krause (jeangonzales)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Kai Werner (kai_werner)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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
Ignoring packet from wrong server
 macht.

Hier mal den RS232-Log vom Mega:
***********************
Start
ETH_INIT
enc28j60WriteBuffer start
000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
enc28j60WriteBuffer end
enc28j60WriteBuffer start
000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
enc28j60WriteBuffer end
stack_init done
arp_entry_search
c0a801ff
arp_entry_search - FAILED
enc28j60WriteBuffer start
ffffffffffff02010203042108004500002c000140004011b60dc0a80163c0a801ffffba004500185a3900017473742e686578006f6374657400
enc28j60WriteBuffer end
UDP_SendPacket
TFTP RRQ sent
TFTP timeout
arp_entry_search
c0a801ff
arp_entry_search - FAILED
enc28j60WriteBuffer start
ffffffffffff02010203042108004500002c000240004011b60cc0a80163c0a801ffffba004500185a3900017473742e686578006f6374657400
enc28j60WriteBuffer end
UDP_SendPacket
TFTP RRQ sent
enc28j60ReadBuffer start
0201020304210016e68b78450800450002206dfc00008011471bc0a80102c0a8016304deffba020ce950000300013a3130303030303030304339343236313030433934343331303043393434333130304339343330313435300d0a3a3130303031303030304339343433313030433934343331303043393434333130304339344345323037390d0a3a3130303032303030304339343433313030433934343331303043393434333130304339343433313030340d0a3a3130303033303030304339343433313030433934434431313043393434333130304339343433313036390d0a3a3130303034303030304339343433313030433934343331303043393434333130304339343433313045340d0a3a3130303035303030304339343433313034373635373432303530344634453437334132303235363935310d0a3a3130303036303030324532353639324532353639324532353639304430413030343535323532344630440d0a3a3130303037303030353230443041304430413030353236353631363437393044304130443041303044440d0a3a3130303038303030304430413030344535343530323034353732373232453044304130303437353733420d0a3a3130303039303030323032303230323533313639324532353331363932453235333136393245323531340d0a3a3130303041303030333136393044304130303444343135333442323032353331363932453235333131300d0a3a31303030423030303639324532353331624ee350
enc28j60ReadBuffer end
tftp_get()
Ignoring packet from wrong server
enc28j60ReadBuffer start
0201020304210016e68b78450800450002206ec5000080114652c0a80102c0a8016304deffba020ce950000300013a3130303030303030304339343236313030433934343331303043393434333130304339343330313435300d0a3a3130303031303030304339343433313030433934343331303043393434333130304339344345323037390d0a3a3130303032303030304339343433313030433934343331303043393434333130304339343433313030340d0a3a3130303033303030304339343433313030433934434431313043393434333130304339343433313036390d0a3a3130303034303030304339343433313030433934343331303043393434333130304339343433313045340d0a3a3130303035303030304339343433313034373635373432303530344634453437334132303235363935310d0a3a3130303036303030324532353639324532353639324532353639304430413030343535323532344630440d0a3a3130303037303030353230443041304430413030353236353631363437393044304130443041303044440d0a3a3130303038303030304430413030344535343530323034353732373232453044304130303437353733420d0a3a3130303039303030323032303230323533313639324532353331363932453235333136393245323531340d0a3a3130303041303030333136393044304130303444343135333442323032353331363932453235333131300d0a3a31303030423030303639324532353331048df8ef
enc28j60ReadBuffer end
tftp_get()
Ignoring packet from wrong server
enc28j60ReadBuffer start
ffffffffffff00184d951bb30800450000e5dd7700008011d839c0a80107c0a801ff008a008a00d173fd1102805bc0a80107008a00bb000020454d45424641464545504641434e454a4543454e43414341434143414341434100204542464345434546454a4645464445484643464646414641454643414341424e00ff534d422500000000000000000000000000000000000000000000000000000011000021000000000000000000e803000000000000000021005600030001000000020032005c4d41494c534c4f545c42524f57534500010080fc0a004c4150544f502d49424d0000300038000501031001000f0155aa0018cbebc2
enc28j60ReadBuffer end
No funktion for this packet found - discarded
TFTP timeout
arp_entry_search
c0a801ff
arp_entry_search - FAILED
enc28j60WriteBuffer start
ffffffffffff02010203042108004500002c000340004011b60bc0a80163c0a801ffffba004500185a3900017473742e686578006f6374657400
enc28j60WriteBuffer end
UDP_SendPacket
TFTP RRQ sent
enc28j60ReadBuffer start
0201020304210016e68b78450800450002206ef800008011461fc0a80102c0a8016304e9ffba020ce945000300013a3130303030303030304339343236313030433934343331303043393434333130304339343330313435300d0a3a3130303031303030304339343433313030433934343331303043393434333130304339344345323037390d0a3a3130303032303030304339343433313030433934343331303043393434333130304339343433313030340d0a3a3130303033303030304339343433313030433934434431313043393434333130304339343433313036390d0a3a3130303034303030304339343433313030433934343331303043393434333130304339343433313045340d0a3a3130303035303030304339343433313034373635373432303530344634453437334132303235363935310d0a3a3130303036303030324532353639324532353639324532353639304430413030343535323532344630440d0a3a3130303037303030353230443041304430413030353236353631363437393044304130443041303044440d0a3a3130303038303030304430413030344535343530323034353732373232453044304130303437353733420d0a3a3130303039303030323032303230323533313639324532353331363932453235333136393245323531340d0a3a3130303041303030333136393044304130303444343135333442323032353331363932453235333131300d0a3a3130303042303030363932453235333112fedc92
enc28j60ReadBuffer end
tftp_get()
Ignoring packet from wrong server
enc28j60ReadBuffer start
0201020304210016e68b78450800450002206f00000080114617c0a80102c0a8016304deffba020ce950000300013a3130303030303030304339343236313030433934343331303043393434
....

Verstehe ich auch den in der etherflash.c steht ja:
if (sock.DestinationIP != IP_packet->IP_Srcaddr)
  {  // other TFTP-Server is sending data - ignore it.
...
  putpgmstring("Ignoring packet from wrong server\r\n");
...
    return;
  }


In Wireshark sieht es so aus:
9  12.216325  192.168.1.99  192.168.1.255  TFTP  Read Request, File: tst.hex\000, Transfer type: octet\000
...

10  12.269316  192.168.1.2  192.168.1.99  UDP  Source port: payrouter  Destination port: 65466
  Frame 10 (558 bytes on wire, 558 bytes captured)
  Ethernet II, Src: Giga-Byt_8b:78:45 (00:16:e6:8b:78:45), Dst: MS-NLB-PhysServer-01_02:03:04:21 (02:01:02:03:04:21)
  Internet Protocol, Src: 192.168.1.2 (192.168.1.2), Dst: 192.168.1.99 (192.168.1.99)
  User Datagram Protocol, Src Port: payrouter (1246), Dst Port: 65466 (65466)
    Source port: payrouter (1246)
    Destination port: 65466 (65466)
    Length: 524
    Checksum: 0xe950 [validation disabled]
  Data (516 bytes)
    Data: 000300013A31303030303030303043393432363130304339...
    Length: 516
107  20.269322  192.168.1.2  192.168.1.99  UDP  Source port: payrouter  Destination port: 65466
...

112  31.777718  192.168.1.99  192.168.1.255  TFTP  Read Request, File: tst.hex\000, Transfer type: octet\000
  Frame 112 (60 bytes on wire, 60 bytes captured)
  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)
  Internet Protocol, Src: 192.168.1.99 (192.168.1.99), Dst: 192.168.1.255 (192.168.1.255)
  User Datagram Protocol, Src Port: 65466 (65466), Dst Port: tftp (69)
    Source port: 65466 (65466)
    Destination port: tftp (69)
    Length: 24
    Checksum: 0x5a39 [validation disabled]
  Trivial File Transfer Protocol
    Source File: tst.hex
    Opcode: Read Request (1)
    Source File: tst.hex
    Type: octet

113  31.830381  192.168.1.2  192.168.1.99  UDP  Source port: shockwave2  Destination port: 65466
  Frame 113 (558 bytes on wire, 558 bytes captured)
  Ethernet II, Src: Giga-Byt_8b:78:45 (00:16:e6:8b:78:45), Dst: MS-NLB-PhysServer-01_02:03:04:21 (02:01:02:03:04:21)
  Internet Protocol, Src: 192.168.1.2 (192.168.1.2), Dst: 192.168.1.99 (192.168.1.99)
  User Datagram Protocol, Src Port: shockwave2 (1257), Dst Port: 65466 (65466)
    Source port: shockwave2 (1257)
    Destination port: 65466 (65466)
    Length: 524
    Checksum: 0xe945 [validation disabled]
  Data (516 bytes)
    Data: 000300013A31303030303030303043393432363130304339...
    Length: 516

114  35.269734  192.168.1.2  192.168.1.99  UDP  Source port: payrouter  Destination port: 65466
  Frame 114 (558 bytes on wire, 558 bytes captured)
  Ethernet II, Src: Giga-Byt_8b:78:45 (00:16:e6:8b:78:45), Dst: MS-NLB-PhysServer-01_02:03:04:21 (02:01:02:03:04:21)
  Internet Protocol, Src: 192.168.1.2 (192.168.1.2), Dst: 192.168.1.99 (192.168.1.99)
  User Datagram Protocol, Src Port: payrouter (1246), Dst Port: 65466 (65466)
    Source port: payrouter (1246)
    Destination port: 65466 (65466)
    Length: 524
    Checksum: 0xe950 [validation disabled]
  Data (516 bytes)
    Data: 000300013A31303030303030303043393432363130304339...
    Length: 516

121  39.830410  192.168.1.2  192.168.1.99  UDP  Source port: shockwave2  Destination port: 65466
...

135  54.830816  192.168.1.2  192.168.1.99  UDP  Source port: shockwave2  Destination port: 65466
...

Aber Schritt für Schritt geht es vorwärts dank Eures Supports.

Danke Kai.

Autor: Zdenko Gacar (blisk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Zdenko Gacar (blisk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

Heute habe ich noch weitere test machen.

Makefile.in:
MCU = atmega128
EMB_FLASHEND = 0x1FFFF
EMB_BOOTLOADER_SECTION_START = 0x1FC00
EMB_LINKER_SCRIPT = -T ../make.files/eth-avr51.x
F_CPU = 14745600
EMB_BOOTLOADER_FLAVOR = 1


Compile:
Size after:
AVR Memory Usage
----------------
Device: atmega128

Program:    4638 bytes (3.5% Full)
(.text + .data + .bootloader)

Data:       1383 bytes (33.8% Full)
(.data + .bss + .noinit)

EEPROM:      114 bytes (2.8% Full)
(.eeprom)

//---------------------------------------------------------------------- 
--
Zuerst habe ich versuchen mit andere Rechner (192.168.50.50) mit direkte 
LAN Verbindung mit Befehle tftp -i 192.168.1.2 GET tst.hex
mit meine TFTP Server (192.168.50.20) zu binden. Alles O.K.:

No.     Time        Source                Destination           Protocol 
Info
   1532 42097.094062 192.168.50.50         192.168.50.20         TFTP 
Read Request, File: tst.hex\000, Transfer type: octet\000

Frame 1532 (60 bytes on wire, 60 bytes captured)
Ethernet II, Src: Giga-Byt_83:e6:f4 (00:16:e6:83:e6:f4), Dst: 
Inventec_50:ea:ef (00:1e:33:50:ea:ef)
    Destination: Inventec_50:ea:ef (00:1e:33:50:ea:ef)
        Address: Inventec_50:ea:ef (00:1e:33:50:ea:ef)
        .... ...0 .... .... .... .... = IG bit: Individual address 
(unicast)
        .... ..0. .... .... .... .... = LG bit: Globally unique address 
(factory default)
    Source: Giga-Byt_83:e6:f4 (00:16:e6:83:e6:f4)
        Address: Giga-Byt_83:e6:f4 (00:16:e6:83:e6:f4)
        .... ...0 .... .... .... .... = IG bit: Individual address 
(unicast)
        .... ..0. .... .... .... .... = LG bit: Globally unique address 
(factory default)
    Type: IP (0x0800)
    Trailer: 0000
Internet Protocol, Src: 192.168.50.50 (192.168.50.50), Dst: 
192.168.50.20 (192.168.50.20)
    Version: 4
    Header length: 20 bytes
    Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00)
        0000 00.. = Differentiated Services Codepoint: Default (0x00)
        .... ..0. = ECN-Capable Transport (ECT): 0
        .... ...0 = ECN-CE: 0
    Total Length: 44
    Identification: 0x05ae (1454)
    Flags: 0x00
        0... = Reserved bit: Not set
        .0.. = Don't fragment: Not set
        ..0. = More fragments: Not set
    Fragment offset: 0
    Time to live: 128
    Protocol: UDP (0x11)
    Header checksum: 0x4f7c [correct]
    Source: 192.168.50.50 (192.168.50.50)
    Destination: 192.168.50.20 (192.168.50.20)
User Datagram Protocol, Src Port: bnetgame (1119), Dst Port: tftp (69)
    Source port: bnetgame (1119)
    Destination port: tftp (69)
    Length: 24
    Checksum: 0xf4b0 [validation disabled]
        [Good Checksum: False]
        [Bad Checksum: False]
Trivial File Transfer Protocol
    [Source File: tst.hex]
    Opcode: Read Request (1)
    Source File: tst.hex
    Type: octet

Die TFTP Server sofort die erste Data Packet, und danach auch die 
übrige.

//---------------------------------------------------------------------- 
--
Mit Atmega ist keine Reaktion von TFTP Server:

No.     Time        Source                Destination           Protocol 
Info
   2303 43881.645760 192.168.50.50         192.168.50.20         TFTP 
Read Request, File: tst.hex\000, Transfer type: octet\000

Frame 2303 (60 bytes on wire, 60 bytes captured)
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)
    Destination: Broadcast (ff:ff:ff:ff:ff:ff)
        Address: Broadcast (ff:ff:ff:ff:ff:ff)
        .... ...1 .... .... .... .... = IG bit: Group address 
(multicast/broadcast)
        .... ..1. .... .... .... .... = LG bit: Locally administered 
address (this is NOT the factory default)
    Source: MS-NLB-PhysServer-01_02:03:04:21 (02:01:02:03:04:21)
        Address: MS-NLB-PhysServer-01_02:03:04:21 (02:01:02:03:04:21)
        .... ...0 .... .... .... .... = IG bit: Individual address 
(unicast)
        .... ..1. .... .... .... .... = LG bit: Locally administered 
address (this is NOT the factory default)
    Type: IP (0x0800)
    Trailer: 0000
Internet Protocol, Src: 192.168.50.50 (192.168.50.50), Dst: 
192.168.50.20 (192.168.50.20)
    Version: 4
    Header length: 20 bytes
    Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00)
        0000 00.. = Differentiated Services Codepoint: Default (0x00)
        .... ..0. = ECN-Capable Transport (ECT): 0
        .... ...0 = ECN-CE: 0
    Total Length: 44
    Identification: 0x0002 (2)
    Flags: 0x04 (Don't Fragment)
        0... = Reserved bit: Not set
        .1.. = Don't fragment: Set
        ..0. = More fragments: Not set
    Fragment offset: 0
    Time to live: 64
    Protocol: UDP (0x11)
    Header checksum: 0x5528 [correct]
    Source: 192.168.50.50 (192.168.50.50)
    Destination: 192.168.50.20 (192.168.50.20)
User Datagram Protocol, Src Port: 65466 (65466), Dst Port: tftp (69)
    Source port: 65466 (65466)
    Destination port: tftp (69)
    Length: 24
    Checksum: 0xf954 [validation disabled]
        [Good Checksum: False]
        [Bad Checksum: False]
Trivial File Transfer Protocol
    [Source File: tst.hex]
    Opcode: Read Request (1)
    Source File: tst.hex
    Type: octet

//---------------------------------------------------------------------- 
--
Die einzige Unterschiede sind:
Ethernet II, Src: Giga-Byt_83:e6:f4 (00:16:e6:83:e6:f4), Dst: 
Inventec_50:ea:ef (00:1e:33:50:ea:ef)
Gegen:
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)

Und

Flags: 0x00
    0... = Reserved bit: Not set
          .0.. = Don't fragment: Not set
            ..0. = More fragments: Not set
Gegen:
    Flags: 0x04 (Don't Fragment)
        0... = Reserved bit: Not set
        .1.. = Don't fragment: Set
        ..0. = More fragments: Not set

//---------------------------------------------------------------------- 
--
Danach habe ich  ETH_packet->ETH_destMac[i] = pDestMac?pDestMac[i]:0xff; 
mit fix Mac von meine PC gewechselt (00 1e 33 50 ea ef).
Die TFTP Server bekommen ein Request und starten File transfer. Aber 
sofort ist die Timeout gemeldet:

No.     Time        Source                Destination           Protocol 
Info
   2369 47354.014677 192.168.50.50         192.168.50.20         TFTP 
Read Request, File: tst.hex\000, Transfer type: octet\000

Frame 2369 (60 bytes on wire, 60 bytes captured)
Ethernet II, Src: Giga-Byt_83:e6:f4 (00:16:e6:83:e6:f4), Dst: 
Inventec_50:ea:ef (00:1e:33:50:ea:ef)
    Destination: Inventec_50:ea:ef (00:1e:33:50:ea:ef)
        Address: Inventec_50:ea:ef (00:1e:33:50:ea:ef)
        .... ...0 .... .... .... .... = IG bit: Individual address 
(unicast)
        .... ..0. .... .... .... .... = LG bit: Globally unique address 
(factory default)
    Source: Giga-Byt_83:e6:f4 (00:16:e6:83:e6:f4)
        Address: Giga-Byt_83:e6:f4 (00:16:e6:83:e6:f4)
        .... ...0 .... .... .... .... = IG bit: Individual address 
(unicast)
        .... ..0. .... .... .... .... = LG bit: Globally unique address 
(factory default)
    Type: IP (0x0800)
    Trailer: 0000
Internet Protocol, Src: 192.168.50.50 (192.168.50.50), Dst: 
192.168.50.20 (192.168.50.20)
    Version: 4
    Header length: 20 bytes
    Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00)
        0000 00.. = Differentiated Services Codepoint: Default (0x00)
        .... ..0. = ECN-Capable Transport (ECT): 0
        .... ...0 = ECN-CE: 0
    Total Length: 44
    Identification: 0x0003 (3)
    Flags: 0x04 (Don't Fragment)
        0... = Reserved bit: Not set
        .1.. = Don't fragment: Set
        ..0. = More fragments: Not set
    Fragment offset: 0
    Time to live: 64
    Protocol: UDP (0x11)
    Header checksum: 0x5527 [correct]
    Source: 192.168.50.50 (192.168.50.50)
    Destination: 192.168.50.20 (192.168.50.20)
User Datagram Protocol, Src Port: 65466 (65466), Dst Port: tftp (69)
    Source port: 65466 (65466)
    Destination port: tftp (69)
    Length: 24
    Checksum: 0xf954 [validation disabled]
        [Good Checksum: False]
        [Bad Checksum: False]
Trivial File Transfer Protocol
    [Source File: tst.hex]
    Opcode: Read Request (1)
    Source File: tst.hex
    Type: octet


Die TFTP Server Antwort mit Broadcast:
   2369 47354.014677 192.168.50.50         192.168.50.20         TFTP 
Read Request, File: tst.hex\000, Transfer type: octet\000
   2370 47354.065720 Inventec_50:ea:ef     Broadcast             ARP 
Who has 192.168.50.50?  Tell 192.168.50.20
   2371 47355.284352 Inventec_50:ea:ef     Broadcast             ARP 
Who has 192.168.50.50?  Tell 192.168.50.20


Vielleicht helfen das Problem zu abschaffen.
Haben sie noch eine Idee, was können ich noch probiere?

Vielen Dank,
Zdenko.

Autor: Axel (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Jan Krause (jeangonzales)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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

Autor: Axel (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Andreas Vogt (tico)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Ralf Schulz (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Ralf Schulz (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Ralf Schulz (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Ethan Arnold (arnolde)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Axel (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>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

Autor: Ethan Arnold (arnolde)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Ethan Arnold (arnolde)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Axel (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Ethan Arnold (arnolde)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Axel (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Jan Krause (jeangonzales)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Ethan Arnold (arnolde)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Jan Krause (jeangonzales)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Kauderwelsch auf der RS232?

Das klingt nach falschem Takt! Ich würde nochmal ganz gründlich alle 
Fuses und den Oszillator checken.

Gruß, Jan

Autor: Ethan Arnold (arnolde)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Ethan Arnold (arnolde)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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...

Autor: Ethan Arnold (arnolde)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Michael H. (michael_h45)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ethan Arnold schrieb:
> der tftp-request wird immer an die 192.168.1.1 gesendet statt an die
> 1.106 :-(
Stimmt deine Netzmaske?

Autor: Ethan Arnold (arnolde)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Ethan Arnold (arnolde)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: Ethan Arnold (arnolde)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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...

Autor: Ethan Arnold (arnolde)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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 :-)

Autor: Ethan Arnold (arnolde)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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"...?

Autor: Jan (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Ethan Arnold (arnolde)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Jan (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Ethan Arnold (arnolde)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: Ethan Arnold (arnolde)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Und noch was, wenn das Hauptimage den EEPROM beschreibt, kann es da 
Probleme geben beim nächsten Reboot?

Autor: Jan (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Axel (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Ethan Arnold (arnolde)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: Axel (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Oliver Wagner (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Ethan Arnold (arnolde)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Andreas Vogt (tico)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Oliver Wagner schrieb:
> ich habe gerade 'mal versucht, etherboot Rev 51 mit Ubuntu 10.04 mit
> avr-gcc 4.3.4 zu compilieren.

Bei Ubuntu 10.04 gibt es ein Problem mit avr-size. Hast Du mal die 
Hinweise unter diesem Link
http://hackaday.com/2010/09/01/how-to-fix-avr-size...
probiert?

Gruss
Andreas

Autor: Ethan Arnold (arnolde)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Ethan Arnold (arnolde)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Dirk Broßwick (sharandac)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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

Autor: Ethan Arnold (arnolde)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Ethan Arnold (arnolde)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: Ethan Arnold (arnolde)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Jetzt bräuchte ich nur noch ne Möglichkeit übers LAN an die MMC-Karte 
ranzukommen ^^ wäre zufällig ein (t?)ftp server machbar?

Autor: Michael H. (michael_h45)
Datum:

Bewertung
0 lesenswert
nicht lesenswert

Autor: Ethan Arnold (arnolde)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Michael H. (michael_h45)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Dirk Broßwick (sharandac)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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

Autor: boni27 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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:
avrdude: Device signature = 0x1e9502
avrdude: safemode: lfuse reads as FF
avrdude: safemode: hfuse reads as 99

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.
#define DEBUG_AV                                1
#define DEBUG_ENC_BUFFER_DATA   1

Die eemem.c wurde nur bei den IP-Adressen angepasst
unsigned long EEMEM mlIpEEP = IP(192,168,5,134); // IP vom AVR-NET-IO ?
unsigned long EEMEM mlTFTPipEEP = 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:
MCU = atmega32
EMB_FLASHEND = 0x7FFF
EMB_BOOTLOADER_SECTION_START = 0x7C00
EMB_LINKER_SCRIPT = -T ../make.files/eth-avr5.x
F_CPU = 16000000
EMB_BOOTLOADER_FLAVOR = 1

Angaben nach dem make:
Size after:
AVR Memory Usage
----------------
Device: atmega32

Program:    5048 bytes (15.4% Full)
(.text + .data + .bootloader)

Data:        783 bytes (38.2% Full)
(.data + .bss + .noinit)

EEPROM:      114 bytes (11.1% Full)
(.eeprom)

Das compile.bat kann ich unter linux nicht nutzen, somit haben ich 
mittels make programm das device_001.hex zum avr übertragen.
avrdude -p atmega32 -P /dev/ttyS0 -c ponyser    -U flash:w:device_001.hex 

avrdude: AVR device initialized and ready to accept instructions

Reading | ################################################## | 100% 0.00s

avrdude: Device signature = 0x1e9502
avrdude: NOTE: FLASH memory has been specified, an erase cycle will be performed
         To disable this feature, specify the -D option.
avrdude: erasing chip
avrdude: reading input file "device_001.hex"
avrdude: input file device_001.hex auto detected as Intel Hex
avrdude: writing flash (32760 bytes):

Writing | ################################################## | 100% 12.87s

avrdude: 32760 bytes of flash written
avrdude: verifying flash memory against device_001.hex:
avrdude: load data flash data from input file device_001.hex:
avrdude: input file device_001.hex auto detected as Intel Hex
avrdude: input file device_001.hex contains 32760 bytes
avrdude: reading on-chip flash data:

Reading | ################################################## | 100% 11.58s

avrdude: verifying ...
avrdude: 32760 bytes of flash verified

avrdude: safemode: Fuses OK

avrdude done.  Thank you.

Zum Schluß noch das device_001.eep zum avr
avrdude -p atmega32 -P /dev/ttyS0 -c ponyser -U eeprom:w:device_001.eep:i

avrdude: AVR device initialized and ready to accept instructions

Reading | ################################################## | 100% 0.00s

avrdude: Device signature = 0x1e9502
avrdude: reading input file "device_001.eep"
avrdude: writing eeprom (114 bytes):

Writing | ################################################## | 100% 1.03s

avrdude: 114 bytes of eeprom written
avrdude: verifying eeprom memory against device_001.eep:
avrdude: load data eeprom data from input file device_001.eep:
avrdude: input file device_001.eep contains 114 bytes
avrdude: reading on-chip eeprom data:

Reading | ################################################## | 100% 0.04s

avrdude: verifying ...
avrdude: 114 bytes of eeprom verified

avrdude: safemode: Fuses OK

avrdude done.  Thank you.

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.

Autor: Ethan Arnold (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: boni27 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Ethan Arnold (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: boni27 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Andreas Vogt (tico)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: boni27 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Ethan Arnold (arnolde)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Olli (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Nabend,

ich wollte das auch gerade mal mit einem ATmega32 probieren, scheitere 
aber schon am Kompilieren.

die makefile.in hat folgenden Inhalt:
MCU = atmega32
EMB_FLASHEND = 0x7FFF
EMB_BOOTLOADER_SECTION_START = 0x7C00
EMB_LINKER_SCRIPT = -T ../make.files/eth-avr5.x
F_CPU = 16000000
EMB_BOOTLOADER_FLAVOR = 1

Bei dem Aufruf von make gibt's aber den Fehler:

inking: device_001.elf
blss=`gawk '/BL_CODE_START:space:+:xdigit:+/ {print $2}' 
size.txt`; 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_001.elf.d etherflash.o 
checksum.o ethernet.o arp.o enc28j60.o spi.o udp.o dhcpc.o eemem.o 
--output device_001.elf -Wl,--defsym=app_start=0 
-Wl,-Map=device_001.map,--cref     -lm -Wl,--defsym=app_start=0x7C00 
-Wl,--section-start=.text=0x7C00 -T ../make.files/eth-avr5.x 
-Wl,--section-start=.bootloader=$blss
/usr/lib/gcc/avr/4.3.5/../../../avr/bin/ld: missing argument(s) to 
option "--section-start"
make: *** [device_001.elf] Fehler 1


Kann mir bitte jemand helfen? Danke!
Windows nutze ich nur ungern ;-) (Nutze Ubuntu 10.10)

Autor: Ethan Arnold (arnolde)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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"

Autor: Harald Stinux (hasti)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Michael H. (michael_h45)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Du kannst im Atmel-/AVR-Studio bei den Project options einstellen, dass 
ein externes makefile verwendet werden soll.

Autor: Harald Stinux (hasti)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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 ?

Autor: Michael H. (michael_h45)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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 =)

Autor: Manfred (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Andreas Vogt (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Marek Walther (ma_wa)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
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?

Autor: Michael H. (michael_h45)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Marek Walther schrieb:
> aber ich frage mich, ob man
> das wirklich will.

ich frage mich, ob du lesen kannst...

Autor: mrv (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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:
 
kautzz@hal:~/code/avr/avr-etherboot-read-only/device_001$ make
makefile:46: makefile.in: No such file or directory
PATH=$PATH:../make.files; . configure.sh avr-gcc ../make.files 0x3ff
sh: 62: ../make.files/configure.sh: Syntax error: "(" unexpected
make: *** [makefile.in] Error 2

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

Autor: Andreas Vogt (tico)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: mrv (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Yport (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Dann debugge die configure.sh Zeile für Zeile....

Autor: mrv (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Also ich hab jetzt das makefile.in selbst angelegt.
MCU = atmega328p
EMB_FLASHEND = 0x7FFF
EMB_BOOTLOADER_SECTION_START = 0x7C00
EMB_LINKER_SCRIPT = -T ../make.files/eth-avr5.x
F_CPU = 8000000
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...

Autor: mrv (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Und mit dem makefile.in kompilliert er zumindest schon mal etwas.
Schmeiszt am Ende allerdings einen fehler...
Calculate code size: device_001.sizeelf
avr-gcc -mmcu=atmega328p -I. -gdwarf-2 -DF_CPU=8000000UL -DBOOTLOADER_FLAVOR=2 -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_001.sizeelf.d etherflash.o checksum.o ethernet.o arp.o enc28j60.o spi.o udp.o dhcpc.o eemem.o --output device_001.sizeelf -Wl,--defsym=app_start=0 -Wl,-Map=device_001.map,--cref     -lm -Wl,--defsym=app_start=0x7C00 -Wl,--section-start=.text=0x7C00 -T ../make.files/eth-avr5.x -Wl,--section-start=.bootloader=0x0000
avr-size -x -A device_001.sizeelf  > size.txt
PATH=$PATH:../make.files && . checksize.sh size.txt 0x3ff 0x7C00
This script is designed to be invoked by make.

=> End script <=
make: *** [device_001.sizeelf] Error 1

Sieht das fuer euch richtig aus?
kautzz@hal:~/code/avr/avr-etherboot/trunk/device_001$ cat size.txt 
device_001.sizeelf  :
section            size       addr
.text             0x308     0x7c00
.bootloader      0x153c        0x0
.bss              0x340   0x800100
.eeprom            0x6e   0x810000
.stab             0xa8c        0x0
.stabstr          0x171        0x0
.comment           0x11        0x0
.debug_aranges    0x218        0x0
.debug_info      0x2dc9        0x0
.debug_abbrev     0xf66        0x0
.debug_line       0xacd        0x0
.debug_frame      0x51c        0x0
.debug_str        0xa05        0x0
.debug_loc       0x15fc        0x0
.debug_ranges     0x198        0x0
Total            0x98c9

Autor: mrv (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: Cube_S (Gast)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
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.

Autor: Frank K. (fchk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Robert Walli (rwalli)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: c-hater (Gast)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
Robert Walli schrieb:

> Ich bin da technisch nicht so fit.

Dann ändere das. Keine Arme -> keine Kekse.

Antwort schreiben

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

Wichtige Regeln - erst lesen, dann posten!

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

Formatierung (mehr Informationen...)

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




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

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