STM32 Ethernet Demo

[Jacon]

Just compare your board with "STM3220G-EVAL" board from ST :

http://www.st.com/internet/evalboard/product/250374.jsp

for which we have board files in trunk repository.
And start from there
STM32F407-Discovery demo may be helpful, too...

[Giovanni]

The driver works and the lwIP demo works too but I am hitting a strange problem with lwIP, in the mini web server (web.c) the following code fails:

Code: Select all

static const char http_index_html[] = "<html><head><title>Congrats!</title></head><body><h1>Welcome to our lwIP HTTP server!</h1><p>This is a small test page.</body></html>";
...
      /* Send our HTML page */
      netconn_write(conn, http_index_html, sizeof(http_index_html)-1, NETCONN_NOCOPY);

Apparently netconn_write() only sends the first 128 bytes of the string (which is 133 bytes long), the web browser receives an incomplete page. The error is not inside the driver because the AT91 driver and demo does exactly the same. It appears that lwIP prepares an incomplete pbufs chain for that string, the last element of the chain is missing for some reason, the driver sends the pbufs chain as it receives it: incomplete.

Any idea about the possible cause? lwIP bug? lwIP configuration error? integration problem?

Giovanni

[Giovanni]

I propose to replace the code above with

Code: Select all

    eventmask_t mask = chEvtWaitAny(ALL_EVENTS);
    if (mask & PERIODIC_TIMER_ID) {
      bool_t current_link_status;
      current_link_status = macPollLinkStatus(&ETH1);

      if (current_link_status != netif_is_link_up(&thisif)){
        if (current_link_status)
          tcpip_callback_with_block( (tcpip_callback_fn) netif_set_link_up, &thisif, 0);
        else
          tcpip_callback_with_block( (tcpip_callback_fn) netif_set_link_down, &thisif, 0);
      }

I merged this code in the trunk but I am not sure of how test it.

Anyway, now the driver and the demo appear to work perfectly, the problem was caused by a lwIP misconfiguration. I also centralized the lwIP-related code under /os/various/lwip_bindings in order to not have duplicated code in the various demos.

Giovanni

[Jacon]

Just got my DP83848-Ethernet-Board from China - in perfect visual condition

So I will start tests with STM32F407-Discovery, but not know when
- very busy now

[Giovanni]

Hi Jacon,

Let me know how it goes, I haven't receiver much feedback yet.

Giovanni

[rubenswerk]

Hi,

when playing around with the Olimex board, I see a strange behaviour.
My client test application registers an UDP receiver (raw API). The client sends an answer immediately in the receiver callback function (using udp_sendto).
My Windows host application sends a small UDP packet every 50ms. If there comes no answer from the client (Olimex board) within 5ms, the host retries to send an UDP packet.

Usually, this works quite precise, the answer from the Olimex board is received within <3ms.
But sometimes, the Olimex board does not answer for a long time (in the example screenshot: 50ms), which means that the hosts retries to send 10 packets. After 50ms, I get 10 Olimex answers in a row within <1ms.

In the screenshot, there's no filter active. It shows the complete network traffic.

I don't know what's happening. Does the software on the Olimex board delay the transfer (LWIP? ChibiOS?), or is it caused by the network switch between PC and board?
Do I have to flush the LWIP send buffer? Or is the packet sent immediately when calling udp_sendto?

Thanks for helping,
Ruwe

[Giovanni]

Hi,

STM32 demo or AT91SAM7X demo?

Anyway, the lwIP demo performs a PHY status check every 5 seconds, is it possible this is what you are experiencing? the status check could delay your UDP traffic while the thread exchanges data with the PHY.

If this is the case, you may look in lwipthreads.c and reduce the check frequency or remove it entirely (make it perform just one check at start).

Giovanni

[rubenswerk]

Hello Giovanni,

that's a very good idea, I will check this weekend if this explains my problem.
I'm talking about the STM32 demo.

However, I wonder if polling the link status really takes that long. The communications blocks for up to ~50ms, which is a lot of time for a serial communication to take place.

Furthermore, sometimes it takes only 2 or 3 (15ms) retries for the communication to come back. The picture above with 10 repetitions is the worst case I saw.

Is it possible that the sniffer protocol is wrong? I don't know where the measured packet timestamps come from and if they're relyable. I assume that they're generated by the network adapter, because Windows is not a realtime OS at all.

I will keep you informed about my results.

Bye, Ruwe

[rubenswerk]

Ok I checked the software with a modified link status polling interval, but it makes no difference. The delayed answer to the UDP requests of the host happens several times per second.
Sometimes, a random number (2...10) of packets is buffered before the answer for them is sent all at once.

But still I'm not sure if it is correct what Wireshark (Windows version) shows me. I have no experience with the pcap driver and if the timestamps are relyable.

Maybe I'll create an instrumented firmware, where the STM32 puts a hardware generated timestamp into each reply packet.

However I don't know how much time it takes from calling the udp_sendto function until the packet is actually transmitted. Maybe there is some kind of buffering in the MAC driver.

Bye, Ruwe

[Giovanni]

The MAC driver can store 2 TX packets max and 4 RX packet max using the default configuration.

Try a ping utility that stores min/max values and let it run for a while, I tried this and the ping is always < 1mS. I the demo ping packets are handled by the same thread that handles TCP and UDP packets.

Giovanni