STM32 Ethernet Demo

[santatanta]

Ok, USART communication works fine now, but I can't get the IP stack running.
As the RJ45 LEDs are active, I guess that initialization of PHYS is successful.

[santatanta]

Hello,

I'm still not able to ping my Olimex board
If I disconnect the board from network, it takes approx. 15 seconds until the LED's start blinking after a reset.

I put a watchpoint into the main loop of lwip_thread(void *p):

Code: Select all

  while (TRUE) {
    eventmask_t mask = chEvtWaitAny(ALL_EVENTS);
    if (mask & PERIODIC_TIMER_ID)
      (void)macPollLinkStatus(&ETH1);
    if (mask & FRAME_RECEIVED_ID) {
      struct pbuf *p;
      while ((p = low_level_input(&thisif)) != NULL) {
        struct eth_hdr *ethhdr = p->payload;
        switch (htons(ethhdr->type)) {
        /* IP or ARP packet? */
        case ETHTYPE_IP:
        case ETHTYPE_ARP:
#if PPPOE_SUPPORT
        /* PPPoE packet? */
        case ETHTYPE_PPPOEDISC:
        case ETHTYPE_PPPOE:
#endif /* PPPOE_SUPPORT */
          /* full packet send to tcpip_thread to process */
==> *** WATCHPOINT ***
          if (thisif.input(p, &thisif) == ERR_OK)
            break;
          LWIP_DEBUGF(NETIF_DEBUG, ("ethernetif_input: IP input error\n"));
        default:
          pbuf_free(p);
        }
      }
    }
  }

This watchpoint is reached ~1second after reset when a network cable is plugged in.
If I connect the network 15 seconds after start (when the blinker thread starts), the watchpoint is never reached.
A router & PC is connected to my network.

Did the example simply work out of the box in your case - which toolchain did you use? I use rev 2871 of the stm32_ethernet_wrapper branch with the CodeSourcery gcc. I modified lwipthread.h with a suitable IP & gateway, and changed the tool path in the makefile. That's all I did.

Is mabl's / Giovanni's correction included in the branch? In my software, SYS_ARCH_TIMEOUT is defined as 0xffffffffUL. The creation of the HTTP thread in the main function is commented out in the branch I have.
But as far as I understood, a simple ping should work anyway.

I would appreciate any hint how to get this example started.

Thanks!

[Giovanni]

Hi,

I am not following the STM32 Ethernet wrapper branch much because I am currently busy with other developments.

Are you using ChibiOS from the repository trunk? because the version on the repository uses lwIP1.4.0 all released versions are still using lwIP1.3.0, there are differences.

I recommend that you checkout the version from the repository with lwIP 1.4.0 then you have to:
1) Integrate the driver with the wrapper from the branch.
2) Create your application, using an existing Ethernet demo as template.
3) Make sure to use the configuration files from the latest version (chconf.h, halconf.h, mcuconf.h).

I hope somebody will post a zip file with a working demo for your board but it is possible they are in vacation and not reading the board often.

Giovanni

[mabl]

Hello santatanta,

sorry for the late answer. I'm a bit in a hurry at the moment. Attached you can find a small demo project with fully working ethernet. It is against SVN revision 3168, so it's 10 days old, and the STM32F2 changes have not been applied yet. If you want to use a newer revision, you'll have to change the makefiles.

The demo itself contains all the ethernet drivers, so the only thing you'll have to do is to extract the stm32lib and lwip. In the demo you will have to adapt the chibios path. For IPs you'll have to change lwipthread.h - I'm sure you know all this already.

Once it is up'n'running, you can ping the board. There are also two services (from lwip contrib module) running:

chargen on port 19 TCP
shell on port 1024 TCP

I hope this helps you getting started.

MaBl

[brian360]

This watchpoint is reached ~1second after reset when a network cable is plugged in.
If I connect the network 15 seconds after start (when the blinker thread starts), the watchpoint is never reached.
A router & PC is connected to my network.

Regarding this issue, the driver in the wrapper branch is still very much incomplete and will not detect when the Ethernet cable is inserted/removed. That might be the reason your watchpoint isn't reached.

Thanks,
Brian

[santatanta]

Thanks to all for your hints.

The shell in MaBl's example is working fine, and I successfully added an UDP echo service using the raw API.
The ping still isn't working; I haven't found the reason for that yet.
But I'm happy that the upper layer services seem to be running fine.

Bye, Andy

[santatanta]

Hello,

although the UDP communication is fine, I still want to get the PING working as well.
As I didn't get any reply package in my switched network, I now etablished a point-to-point connection between my PC and the board.
Now the sniffer shows me the ping response packet sent from the board, but it has a wrong ICMP checksum (0x0000). The IP header checksum is correct.
The checksum is always missing, independant from hardware checksum calculation active or not.

I wonder why you don't have this problem; doesn't your switch/network card care about the wrong checksum?
Do I need another netif->output handler? Any help is welcome how to get rid of this problem.

Thanks!

[mabl]

Hellp santatanta,

I made a quick test as well, and you are right - the ICMP checksum field is zero (see attachment).

I wonder why you don't have this problem; doesn't your switch/network card care about the wrong checksum?

The ICMP checksum is above the network layer of switch/network card and therefor ignored. Maybe the Linux ping implementation is ok with a wrong Checksum where as Windows will ignore the packages.

I'll try to dig deeper, but I think the checksum should be calculated when the ICMP part of the packages is generated.

EDIT:
Echo ICMP messages are generated in line 186 in file icmp.c. When checking with the debugger iecho->chksum is indeed set to a value different from zero but this is not seen with wireshark.
EDIT2:
I just found a windows computer, windows does indeed ignore the ICMP ECHO REPLY messages....
EDIT3:
iecho->chksum is even calculated correctly and matches the value calculated by wireshark (bytes must be swaped)
EDIT4:
I have no idea why this happens. The icmp checksum is set correctly. And as far as i can see, the correct package get's transmitted via ip_output_if(p, ip_current_dest_addr(), IP_HDRINCL, ICMP_TTL, 0, IP_PROTO_ICMP, inp); Where IP_HDRINCL basically just tells ip_output_if to forward the package directly to wire. I have no idea where the checksum could have gone missing, as it is just a byte between many others in the IP payload.
EDIT5:
I also tried out the most recent version from git - same issue.
EDIT6:
For debugging I just added iecho->code = 255; after the checksum calculation. The value gets transmitted AND the checksum code is now 0xff00! So I guess this is indeed a problem of the ethernet driver. Maybe the mac does add a wrong checksum. The manual says that the STM32 Mac "calculates and inserts IPv4 header checksum and TCP, UDP, or ICMP checksum in frames transmitted in Store-and-Forward mode".

[mabl]

According to the STM32 manual:

Note that: for ICMP-over-IPv4 packets, the checksum field in the ICMP packet must
always be 0x0000 in both modes, because pseudo-headers are not defined for such
packets. If it does not equal 0x0000, an incorrect checksum may be inserted into the
packet.

Setting the checksum field to zero indeed fixes the problem.

[santatanta]

Hello mabl,

thank you very much for your quick and detailed analysis.
Yes I'm using a Windows based system, so that's the reason why our pings have different behaviour.

I wonder why I couldn't see the corrupt ping response packet on Wireshark when I used the switched network. I only see the incorrect response with a point-to-point connection.

In another discussion board I read that the original ST demo (with lwip 1.3.2 on a STM3210C board) has no ping problem, even with Windows.

However, with your suggested solution, the ping works just fine.
Thanks a lot for your investigation!