Ethernet on STM32F746V.

[rew]

My boards for the STM32F750 are now populated with STM32F746: Less differences with the "discovery kit" where i can test my code.

My board has an DP83848 PHY instead of the LAN on the discovery kit. Initialization of the HAL will initialize that and detect my PHY. Good.

But then: when lwipInit () is called.... the code hangs in:

Code: Select all

  /* Check because errata on some devices. There should be no need to
     disable flushing because the TXFIFO should be empty on macStart().*/
#if !defined(STM32_MAC_DISABLE_TX_FLUSH)
  /* Transmit FIFO flush.*/
  ETH->DMAOMR   = ETH_DMAOMR_FTF;
  while (ETH->DMAOMR & ETH_DMAOMR_FTF)
    ;
#endif

I don't understand why this could happen, even if I botched my hardware.....

And my hardware isn't that bad, as communication with the PHY works to retrieve the correct PHY_ID values....

Example projects on the internet show precisely the same signals connected.....

Any idea why the code could hang here?

[Giovanni]

Hi,

This happened to me too, the problem was wrong GPIO/clock settings, you should verify that. Also make sure there is not an errata, I don't remember which device had problems with that. You may try to just disable it and see if you hit more problems.

Giovanni

[rew]

OK. I removed that and now it boots so that I get my CDC_ACM interface.

This opens up a bunch of programmed debug options.

[rew]

So far I had just wired up all signals that "howto's" indicated were necessary and expected it to work. Started reading about what I'm actually doing....

OK. So there is this "REF_CLK" signal. It should be 50MHz. I don't see it wobling at all.

Now the debugging from the inside allows me:

Code: Select all

ch> showmode pa1
PA1: mode: AF, otype: PP, ospeed: HI, pupd: none, idr: 1, ord: 1, AFR: 11, 

which to me says that it should be working. Do you see something worng?

[mikeprotts]

How much difference is there between your board and the discovery kit. It may be worth using STM32CubeMX to see if the mappings, DMA assignments etc. don't cause conflicts with your configuration.

Mike

[rew]

My board has a 100 pin chip, no ULPI on the second USB OTG. The discovery board has external RAM, a ~200 pin chip.

The discovery board has a LAN8742 PHY, my board has a DP83848.

It looks as if my PHY is in MII mode instead of in RMII mode. That can very well explain why it isn't working. On the other hand, I think there is a second problem with the STM because I should see the clock output on the PA1 pin.

[Giovanni]

MII requires 25MHz if I remember well, do you have a dedicated oscillator?

Giovanni

[mikeprotts]

I should see the clock output on the PA1 pin.

The clock should be turned on by rccEnableETH called from the hal_mac_lld code. It turns on briefly, then off at initialisation time, and then on when the peripheral starts to be used.

Mike

[mikeprotts]

Now the debugging from the inside allows me:

Code: Select all

ch> showmode pa1
PA1: mode: AF, otype: PP, ospeed: HI, pupd: none, idr: 1, ord: 1, AFR: 11, 

Would you be able to share that debugging code please? It would help with my debugging, and save me writing something rather similar.

Mike

[rew]

Code: Select all

void * gpio_ports[] = {GPIOA, GPIOB, GPIOC, GPIOD, GPIOE, 
                       GPIOF, GPIOG, GPIOH, GPIOI, GPIOJ};

void cmd_showmode (BaseSequentialStream *chp, int argc, char **argv) // Debug: pint hw pin mode.
{
  char *p;
  int i;
  stm32_gpio_t *gpp;
  int bn, pn;
  static char *modes[] = {"IN", "OUT", "AF", "ANA"};
  static char *otypes[] = {"PP", "OD"};
  static char *ospeeds[] = {"LOW", "MED", "LOW", "HI"};
  static char *pupd[] = {"none", "pup", "pdn", "res"};

  if (argc < 1) {
    chprintf (chp, "need a pin.\r\n");
    return;
  }

  for (i=0;i<argc;i++) {
    p = argv[i];
    if (*p == 'p') p++;
    if (*p == 'P') p++;
    
    pn = (*p - 'A') & 0xf; // cheap tolower
    bn = atoi (p+1);
    gpp = gpio_ports[pn];
    
    chprintf (chp, "P%c%d: ", 'A'+pn, bn);
    chprintf (chp, "mode: %s, ", modes[(gpp->MODER >> (2*bn))&3]);
    chprintf (chp, "otype: %s, ", otypes[(gpp->OTYPER >> bn)&1]);
    
    chprintf (chp, "ospeed: %s, ", ospeeds[(gpp->OSPEEDR >> (2*bn))&3]);
    chprintf (chp, "pupd: %s, ", pupd[(gpp->PUPDR >> (2*bn))&3]);
    chprintf (chp, "idr: %d, ", (gpp->IDR >> (1*bn))&1);
    chprintf (chp, "ord: %d, ", (gpp->ODR >> (1*bn))&1);
    
    if (bn<8) chprintf (chp, "AFR: %d, ", (gpp->AFRL >> (4* bn   ) ) &0xf);
    if (bn>7) chprintf (chp, "AFR: %d, ", (gpp->AFRH >> (4*(bn-8)) ) &0xf);
    chprintf (chp, "\r\n");
  }

}

It is possible that this was written a while ago. I see "cubeMX" list the expected IOspeed as "very high", where mine just goes up to "hi".
Why I didn't declare the ports array correctly I don't remember. Instead of the array, a calculation should to work too.
(stm32_gpio_t *)(((uint32)GPIOA) + pn*0x400)