Ethernet TX Timeout?

Panowie/panie... męczę się tu troszkę za długo z pewnym urządzeniem,
więc postanowiłem doradzić się speców-elektroników, spytać o pomoc.

Mam tu płytkę uruchomieniową z prockiem klasy MIPSII, a konkretnie
jest to cały system on chip, zintegrowany mikrokontroler 32-bitowy.
Ma to docelowo pracować z Windows CE i wszystko pięknie ładnie tylko
jak przyjdzie do próby połączenia się z pecetem po Ethernecie to
dostaję komunikat "Ethernet TX Timeout".

Nie jestem w 100% pewny, ale problem wygląda raczej na softwareowy,
gdyż ROM Monitor, taki nazwijmy to BIOS, do którego się ta płytka
bootoje zanim w ogóle podejmie się próby załadowania jakiegoś osa
działa z serwerem TFTP przez sieć i jestem w stanie ściągnąć z hosta
bootloader Windows CE i uruchomić go. Wygląda mi to jakby bootloader
miał problemy z siecią, gdyż gdy bootloader wysyła broadcast do
255.255.255.255 o treści BOOTME i spodziewa się że to zapytanie
podchwyci mój pecet z Platform Builderem/Debuggerem dla Windows CE
nic się nie dzieje: pecet nie widzi BOOTME a urządzenie skarży się
na timeouty transmittera.

I teraz pytanie do znawców Ethernetu: czy transmisja taka jest
jakoś z "handshake"? Bo śmierdzi mi ten komunikat podobną sprawą
przy porcie szeregowym, gdy odbiornik nie wystawi linii sterujących
i nadajnik wisi za długo z nadajnikiem kończąc z błedem TX-timeout.
Gdzie mogę szukać problemu z tym Ethernetem? Wydawało mi się, że
Ethernet pracuje bez linii handshake, w trybie full duplex... Pomocy!

W ethernecie pakiet jest wysylany bez zadnych potwierdzen itp.
Tym zajmuja sie warstwy wyzsze protokolw sieciowych.

A twoj blad moze sie pojawic w sumie w 2 przypadkach:
gdy sieciowka nie moze wyslac pakietu bo jest uwalona albo nie ma
polaczenia z medium transmisyjnym.

albo gdy software nie umie poprawnie obsluzyc karty i tym samym
poprawnie nadac pakietu.

Panowie/panie... męczę się tu troszkę za długo z pewnym urządzeniem,
więc postanowiłem doradzić się speców-elektroników, spytać o pomoc.
Mam tu płytkę uruchomieniową z prockiem klasy MIPSII, a konkretnie
jest to cały system on chip, zintegrowany mikrokontroler 32-bitowy.
Ma to docelowo pracować z Windows CE i wszystko pięknie ładnie tylko
jak przyjdzie do próby połączenia się z pecetem po Ethernecie to
dostaję komunikat "Ethernet TX Timeout".

On Wed, 21 May 2003 15:10:38 -0500, Pszemol wrote:

Panowie/panie... męczę się tu troszkę za długo z pewnym urządzeniem,
więc postanowiłem doradzić się speców-elektroników, spytać o pomoc.
Mam tu płytkę uruchomieniową z prockiem klasy MIPSII, a konkretnie
jest to cały system on chip, zintegrowany mikrokontroler 32-bitowy.
Ma to docelowo pracować z Windows CE i wszystko pięknie ładnie tylko
jak przyjdzie do próby połączenia się z pecetem po Ethernecie to
dostaję komunikat "Ethernet TX Timeout".

A dobrze ci radzilismy - Linux, a nie Microsoft Problems :-)

A dobrze ci radzilismy - Linux, a nie Microsoft Problems :-)

A dobrze ci radzilismy - Linux, a nie Microsoft Problems :-)

Przynajmniej tcpdumpa mozna uzyc :-)

Wlasnie - Pszemol, wepnij tam gdzies linuxa,

-) nie mam czasu na takie zabawy...

zapusc mu tcpdumpa
i patrz, czy PCet odpowiada na BOOTME

- jesli nie, to przypatrz sie poszczegolnym bajtom
tego pakietu. Moze byc cos z adresami,
moze cos z ARPem nie tak...

zapusc mu tcpdumpa
i patrz, czy PCet odpowiada na BOOTME

Gdyby widział BOOTME to widziałbym urzadzenie po stronie pc.
A nie widze.

Pszemol wrote:

zapusc mu tcpdumpa
i patrz, czy PCet odpowiada na BOOTME

Gdyby widział BOOTME to widziałbym urzadzenie po stronie pc.
A nie widze.

A ten twoj windows ma wogole serwer DHCP lub cokolwiek innego co obsluguje
te zapytania (skoro sa wysylane przez sieciowke...) ?
W koncu jest chyba jakis snifer pod windows zeby nim zobaczyc co sie dzieje
w sieci a i netstat-em mozna zobaczyc czy cos slucha na porcie bootps
(proto UDP port nr. 68). Zawsze to szybciej niz debugowac caly kod a moze
pomoc.

Po stronie peceta siedzi sobie MS Platform Builder (dla Windows CE)
który własnie ma nasłuchiwać czy jakieś urządzenie zgłasza rządania
BOOTME.

Pszemol wrote:
[.]

Po stronie peceta siedzi sobie MS Platform Builder (dla Windows CE)
który własnie ma nasłuchiwać czy jakieś urządzenie zgłasza rządania
BOOTME.

Tak myslalem ale czy na pewno to robi ?

Pszemol wrote:
[.]

Po stronie peceta siedzi sobie MS Platform Builder (dla Windows CE)
który własnie ma nasłuchiwać czy jakieś urządzenie zgłasza rządania
BOOTME.

Tak myslalem ale czy na pewno to robi ?

Ewidentnie zatem problem
leży po stronie tego urządzenia na MIPSowym CPU... Szukam dalej...

• byc moze wtedy jest tx timeout wyswietlany.

To ze pisze 'tx timeout' nic nie znaczy - w ethernecie NIE DA SIE
sprawdzic czy pakiet doszedl.

Chyba, ze masz w LANie jakies stormy
(cos wysyla pakiety tak, ze juz zadne inne urzadzenie nie moze nic wyslac) -
- byc moze wtedy jest tx timeout wyswietlany.

Ale da sie sprawdzic ze nie wyszedl - tzn nastapilo 16 kolizji przy
kolejnych probach transmisji.

Chyba, ze masz w LANie jakies stormy
(cos wysyla pakiety tak, ze juz zadne inne urzadzenie nie moze nic
wyslac) - - byc moze wtedy jest tx timeout wyswietlany.

Np switch fulldupleks, a urzadzenie nie.

Chyba, ze masz w LANie jakies stormy
(cos wysyla pakiety tak, ze juz zadne inne urzadzenie nie moze nic wyslac)
- - byc moze wtedy jest tx timeout wyswietlany.

Np switch fulldupleks, a urzadzenie nie.