Ethernet AVR mikrovezérlővel - hibás csomagfogadás

Hálózati eszközök

Sziasztok!

AVR mikrovezérlőre fejlesztek Ethernet kapcsolatot, az alábbi libet használom:

http://www.mil.ufl.edu/~chrisarnold/components/microcontrollerBoard/AVR…

Az ethernet vezérlő egy ENC28J60 chip. A fenti linken látható netstack.c péda kódot próbálom használni. Az UDP csomag küldés része rendesen működik, Wireshark-al látom a gépemen, hogy ideért a csomag.

Viszont a fordított irány, tehát a csomag fogadás az AVR oldalon furcsán viselkedik. Beálíltottam, hogy a fogadott csomagokat egy az egyben dumpolja ki a soros portjára, ez itt található: (10 db csomag, DHCP és ARP) http://molnarp.pastebin.com/m2e4f9220

Ugyanezen csomagok Wireshark-al készített dumpja itt: http://molnarp.pastebin.com/m4c458c95

(Ugyanolyan sorrendben, egy ethernet hubra kötve, tehát ténylegesen ugyanaz van minkét logban)

Amit észre lehet venni, hogy minden csomag elején van 35 byte, amit nem tudok hova tenni, nem értem, hogyan kerül oda. Utána rendesen elkezdődik a csomag. Viszont mivel az első 35 byte "szemét", rosszul érzékeli a csomag hosszát, így mindig 590 byte-ot olvas. (576 byte, +14 byte ethernet header, vagyis 590 byte méretű a csomag fogadó puffer).

Szerintetek hol itt a hiba, mit csinálok rosszul?

üdv,
Petya

  • 2494 megtekintés

( tselmeci | 2009. 07. 23., cs – 15:22 )

Igazából fogalmam sincs.

Netrádió alkalmazás embedded Linuxra fejlesztése során láttunk olyat, hogy ha wifin csatlakoztunk az internetre, akkor minden rendben volt, ha 3G-n keresztül, akkor pedig minden egyes csomag végéhez hozzácsapott valaki vagy valami egy pár "hulladék" bájtot. Az okát máig nem tudjuk.

A másik, de ezt méginkább zárójelben és halkan: az AVR-es ethernet MAC címe nekem egy kicsit furcsa, ilyet még nem láttam. Jártam már úgy fejlesztés során, hogy a hülyén megadott MAC cím miatt egyáltalán nem működött az ethernet, mint olyan. "Rendes" címet adva neki megjavult. Ha esetleg te ezt kézzel adtam meg neki (ahogy tettem én is anno), akkor érdemes lehet egy másik címmel próbálkozni, pl. nézd meg a PC-d MAC-jét és mondjuk az utolsó bájtot módosítva alkalmazd az AVR-en.

Amúgy milyen AVR-ről van szó? ATmega?
--
Selmeci Tamás
http://tselmeci.nop.hu

Hello!

Ez a MAC address csak hasraütéssel lett megadva, az itteni hálózaton ilyen nincs, de mindjárt keresek egy döglött hálókártyát, és annak a MAC címét adom neki. Köszönöm a tippet!

Amúgy igen, ez egy ATMEGA16. Ha nagyon nem férek bele a TCP-vel, (meg azért az 1K RAM is elég kevésnek tűnik) akkor lehet hogy ATMEGA32-re váltok.

Petya

Hello!

Döglött hálókártyát nem találtam, de átírtam valós MAC címre. Ugyanúgy hibásan olvas, de most más az első 35 byte:

AVR: http://molnarp.pastebin.com/m204bacb6

Wireshark: http://molnarp.pastebin.com/m18387919

Ez most csak két DHCP csomag, de gondolom a lényeg látszik.

Petya

Egy ilyet találtam: 

3. Module: Memory (Ethernet Buffer)
   The receive hardware maintains an internal Write
   Pointer which defines the area in the receive buffer
   where bytes arriving over the Ethernet are written.
   This internal Write Pointer should be updated with
   the value stored in ERXST whenever the Receive
   Buffer Start Pointer, ERXST, or the Receive Buffer
   End Pointer, ERXND, is written to by the host
   microcontroller. Sometimes, when ERXST or
   ERXND are written to, the exact value, 0000h, is
   stored in the internal receive Write Pointer instead
   of the ERXST address.

Megnézem azt a drivert, hátha ez a baja. Egyébként hogyan lehet megtudni a chip revision number-ét?

Petya

Köszi, megnézhettem volna, még a driver is le tudja kérdezni:

RevID: 0x0004

Ezek alapján B4-es verzió, ebben ugyanúgy benne van az a pointeres hiba:

http://ww1.microchip.com/downloads/en/DeviceDoc/80257d.pdf

Egyébként az ERXST pointert csak az inicializáló függvényben használja most, ez így néz ki: 


NextPacketPtr = RXSTART_INIT;
enc28j60Write(ERXSTL, RXSTART_INIT&0xFF);
enc28j60Write(ERXSTH, RXSTART_INIT>>8);

Úgy látom, hogy ez megfelel az erratában lévő workaroudnak: 


Work around
Use the lower segment of the buffer memory for
the receive buffer, starting at address 0000h. For
example, use the range (0000h to n) for the
receive buffer and ((n + 1) – 8191) for the transmit
buffer.

Vagy rosszul gondolom?

Petya

( _Petya_ v | 2009. 07. 24., p – 03:20 )

Nos, sikerült megoldani a problémát, puffer túlcsordulás volt, mindössze csökkenteni kell a csomag fogadó puffer puffer méretét, és megy is szépen (nálam 512 lett, nagyobb számokra néha furán viselkedik, pl, egyre több pontosan puffer méretű, 0-val teli csomag jelenik meg)

Köszönöm mindenkinek a tippeket, ötleteket!

Petya