STM32 Ethernet Demo

[Giovanni]

Hi,

Probably would be a good idea to create a standalone demo for the discovery+eth+lwip and include it in the distribution (an article for the web site would be nice too). Any idea on when lwIP 1.4.1 will be released?

Giovanni

[mabl]

Any idea on when lwIP 1.4.1 will be released?

Unfortunately not: http://lists.gnu.org/archive/html/lwip- ... 00162.html

[Jacon]

Hi Giovanni,

In my opinion, mac_lld.c from line 500 downwards should look like this:

Code: Select all

    if (!(rdes->rdes0 & (STM32_RDES0_AFM | STM32_RDES0_ES
#if STM32_IP_CHECKSUM_OFFLOAD
                       | STM32_RDES0_IPHCE | STM32_RDES0_PCE
#endif
        )) && (rdes->rdes0 & STM32_RDES0_FS)
           && (rdes->rdes0 & STM32_RDES0_LS)) {

in order to really use checksum offload in receive direction...

BTW. Checksum offload set to 3 and flying with 1.4.1's all soft checksum
settings set to 0

[Giovanni]

I merged this and also part of the other changes (except those related to lwIP 1.4.1). I noticed you increased buffers too, did you experience improvements with that?

Giovanni

[Jacon]

I noticed you increased buffers too, did you experience improvements with that?

Not tested performance yet - increased buffers just to almost fill that free 16kB RAM space

[rubenswerk]

Hello,

I activated the DHCP option and got a preprocessor error that MEMP_NUM_SYS_TIMEOUT is defined to small (the actual value is 3).
In an older example, I found this definition:
#define MEMP_NUM_SYS_TIMEOUT (4 + LWIP_DHCP + LWIP_DNS)
Maybe this is the better solution.

Another question:
In the main function, after starting the lwip thread: how is it ensured that all lwip initializations have finished before executing the further main() code?
For example, I rerserve a pbuf in the code line after starting the thread. What is done first? The lwip initialization, or the pbuf reservation in main? I don't want to run into a problem when ChibiOS schedules the main() function while the lwip initialization is running.

Bye, Ruwe

[mabl]

Couldn't you just do

Code: Select all

  chThdCreateStatic(wa_http_server, sizeof(wa_http_server), HIGHPRIO,
                    http_server, NULL);

Since wa_http_server lowers its priority afterwards?

[Giovanni]

Hi, mabl is correct about priorities, in the demos the LWIP thread is started with priority NORMALPRIO+1, the main is at priority NORMALPRIO so the initialization is already ensured.

The value "3" is what is defined in opt.h, lwIP has way to many settings to be able to verify them all, I just assumed that defaults are meaningful.

Giovanni

[rubenswerk]

Thanks for your explanation. I was not sure what's going to happen in an preemptive system even with different priorities. I think I have to take a closer look at the kernel doc

Of course I don't want to make you responsible for the endless configuration options. I just thought it might be helpful if someone encounters the same problem. The link up/down callback function works fine, a new DHCP request is triggered when the link goes up again. I just had to add something like the following in the lwipthread initialization:

Code: Select all

  netif_set_default(&thisif);
#if LWIP_DHCP
  dhcp_start(&thisif);
#endif
  netif_set_up(&thisif);

I have one problem with both the STM32F4 Discovery ethernet demo and the F107 demo (I use it on a custom board with DP83848):
I always have to do a warm-reset to make the demo running (pressing the reset button). A cold reset causes mii_find_phy() to run into chSysHalt():

Code: Select all

static void mii_find_phy(MACDriver *macp) {
  uint32_t i;
  for (i = 0; i < 31; i++) {
    macp->phyaddr = i << 11;
    ETH->MACMIIDR = (i << 6) | MACMIIDR_CR;
    if ((mii_read(macp, MII_PHYSID1) == (BOARD_PHY_ID >> 16)) &&
        ((mii_read(macp, MII_PHYSID2) & 0xFFF0) == (BOARD_PHY_ID & 0xFFF0))) {
      return;
    }
  }
  /* Wrong or defective board.*/
  chSysHalt();
}

I added quite a long wait loop (which is not a nice solution) in front of mii_find_phy, and now it works. It seems to take some time for the DP83848 to be ready to respond on MII communication after setting up the PHY clock.

Bye, Ruwe

[Giovanni]

Hi,

It looks like the PHY is not yet read to accept commands after a cold reset. It is reasonable to assume that its startup time is slower than the CPU.

You could try to implement a retry loop in mii_find_phy() so it would try to find the address for at least 100mS (example) before giving up and halt. This could be done using the real time counter in the HAL. Probably I will add this as a configuration option if it works in your case.

Giovanni