Hi,
mir ist aufgefallen, dass der Bootloader bei mir immer etwa 5s wartet,
nachdem er mit dem Download und Flashen fertig ist. Ich benutze hierbei
immer bootp statt tftpomatic (vorkonfigurierte IP/TFTP-Server-Adresse).
Ich vermute, dass dies ein Bug in services/tftp/tftp-bootload.c Zeile
226 ist,
Hi,
ich lassse bei mir die Initialisierung über YPORT machen und ändere dann
im control6 einfach nur die Framesize:
// Set USART to 8E2
UCSR0C|=_BV(UPM01)|_BV(USBS0);
(Atmega 1284p mit 20 Mhz)
Viele Grüße,
Olli
___
Ethersex-devel mailing lis
Hi,
ich glaube, ich habs gefunden:
tftp-bootload.c Zeile 217:
base = TFTP_BLOCK_SIZE * (HTONS(pk->u.ack.block) - 1);
Beides ints, ergo 64k overflow, ergo wird ab 64k wieder ab Adresse 0
geflasht...
Mit
base = (uint32_t)TFTP_BLOCK_SIZE *
((uint32_t)HTONS(pk->u.ack.block) - 1);
On 11.01.2012 22:53, Michael Rakowski wrote:
> Wenn der per Bootloader zu ladende Code auch nur ein Tick größer als 64k ist,
> sehe ich im Log des stftpd das die FW übertragen wird, aber dann passiert
> nichts mehr :-(
Ich habe exakt dasselbe Problem hier mit gcc 4.4.3, auch mit git per
Stand h
Hi,
Wenn sich jetzt mein net-io mit dem tftpd verbindet bekomme folgende
Fehlermeldungen:
Hier keine Probleme mit
Ubuntu 11.10
ii tftpd-hpa
5.1-2ubuntu1HPA's tftp server
Config:
root@grate:/etc/default# cat tftpd-hpa
# /etc/default
Hi,
nur zur Sicherheit -- der git MASTER-Stand enthält diesen Patch aber
noch nicht in dieser Form, oder?
Viele Grüße,
Olli
On 18.04.2011 22:13, taru wrote:
> Ich habe einen Patch zusammengefasst, siehe Anhang. Hoffentlich ist
> alles reingekommen (ich bin mit git noch nicht so firm):
___
Hi,
wegen des 1w-Verdachts will ich mal ergänzen:
> -- mit Atmega 32 + USB-5V-Netzteil -- Problem tritt anscheinend _nie_ auf
Ein 1w-Sensor (powered), alle 5 Minuten abgefragt.
> -- mit Atmega 644 + Pollin-Resterampen LiteOn-Netzteilblock mit direkten
> 5V und 3.3V-Ausgängen -- Problem tritt etw
Hi,
ich habe hier NET-IOs in den folgenden Konfigurationen:
-- mit Atmega 32 + USB-5V-Netzteil -- Problem tritt anscheinend _nie_ auf
-- mit Atmega 644 + Pollin-Resterampen LiteOn-Netzteilblock mit direkten
5V und 3.3V-Ausgängen -- Problem tritt etwa alle 4 Tage auf
-- mit Atmega 644 + Meanwell 5
Hi,
nachdem ich weiterhin auch das Umschalten der Data-Direction nach dem
Lesevorgang deaktiviert habe, ist das Problem anscheinend final weg.
Viele Grüße,
Olli
___
Ethersex-devel mailing list
Ethersex-devel@list.zerties.org
https://list.zerties.org/cg
Hi,
ich habe zwischenzeitlich mal in meine Installationen einen Watchdog
eingebaut -- da diese eh regelmäßig vom Hausserver wegen Cacti u.ä.
abgefragt werden, wird überwacht, ob längere Zeit kein ECMD-Request mehr
angekommen ist. Falls dies der Fall ist, wird einmal versucht, den ENC
mittels
Hi,
ich habe hier bei zwei NET-IOs mit 644, an die jeweils ein Powertip PC
1604-A LCD per 4-Bit Schnittstelle mit RW angeschlossen ist, ein
seltsames Problem: Die Ansteuerung de LCDs funktioniert grundsätzlich
eigentlich gut, nur manchmal gibt es Störungen bei der Datenübertragung:
So wird das Dis
Hi,
der Patch mit pgm_get_far_address() funktioniert bei mir übrigens nicht,
obwohl er, nach allem, was ich so gelesen habe, eigentlich tun sollte.
Leider verstehe ich zu wenig von avr-gcc, um das zu durchblicken...
Der Umweg über das SRAM geht bei mir.
Viele Grüße,
Olli
___
So, dank eku und rdnzl denke ich, dass die Ursache identifiziert ist.
Das Problem mit den FAR-Pointern (siehe Udo1s Patch in tftp) gibt es
nämlich nochmal, und zwar in hardware/ethernet/ethernet_config.c Zeile
38 bei der Initialisierung der MAC.
Das wiederum hat eine ganz drollige Auswirkung abhä
> ich hab mal einen für das net-io gebaut. Versuch den mal.
Danke. Der tut hier interessanterweise auch nicht.
Viele Grüße,
Olli
___
Ethersex-devel mailing list
Ethersex-devel@list.zerties.org
https://list.zerties.org/cgi-bin/mailman/listinfo/ethersex-
Hi,
Udo1 wrote:
> müsste a1d2ffa3ff73e36b5e382fe7c9c4f29789ae50e0 sein.
Danke. Ich habe nun explizit diesen Stand probiert, ebenfalls ohne Erfolg.
Sicherheitshalber habe ich nun auch mal die Toolchain komplett neu
compiliert (gemäß c't-Anleitung), mit avr-gcc 4.4.3 und avrlib 1.7.1,
leider ebenf
Danke für die .config. Zur Sicherheit, mit welchem Git-Stand läuft denn
das bei Dir?
Viele Grüße,
Olli
___
Ethersex-devel mailing list
Ethersex-devel@list.zerties.org
https://list.zerties.org/cgi-bin/mailman/listinfo/ethersex-devel
Hallo Udo,
vielen Dank für den Patch. Leider hilft er mir erstmal nicht, da ich
irgendwie gar nicht bis zum tftp-Request komme (Ich habe es aber
sicherheitshalber einmal mit fixer IP probiert)
Könntest Du mir Deine .config für den Bootloader einmal schicken? Danke!
Viele Grüße,
Olli
_
Hi,
ich versuche aktuell, den Ethersex-Bootloader mit einem NET-IO mit
Atmega 1284p auf 20 Mhz zum Laufen zu kriegen, ohne Erfolg. Mit einem
644 (auf 20 Mhz) läuft der Bootloader auf der Platine einwandfrei.
Ethersex als Applikation läuft auf dem 1284p schon, nur halt der
Bootloader nicht.
Sympto
Hi,
ich habe auch exakt den von Florian beschriebenen Effekt: Inbound geht
nix mehr (kein TCP, kein ICMP, kein UDP), ausgehend UDP geht aber noch.
Viele Grüße,
Olli
___
Ethersex-devel mailing list
Ethersex-devel@list.zerties.org
https://list.zerties.o
19 matches
Mail list logo
