Trying to get lwIP to work Topic is solved

[Pethead]

Ok thanks, found this thread as well where you say that the PLL introduces too much jitter and that I need an external oscillator, is that really the case?

[Giovanni]

I never experimented with it, it was something found on an ST datasheet or application note.

Giovanni

[Pethead]

I have re-checked the PIN setup multiple times and I can't find any problems in that setup, the reference clock is 50 MHz and I can't find anything about any specific PHY initialization in the LAN8720A datasheet (maybe I'm just bad at reading datasheets...?).

I'm using this MCU board (With an 8 MHz external crystal) and the LAN8720A transceiver mentioned above (which is also present in the schematic).

I'm using a STM32F407

(I've attached the full project and a picture of the reference clock for the LAN8720A chip, if anyone has the time and effort to actually look at it)

The is the pin configuration I am using:

PA2  - ETH_MDIO         (alternate 11)
PA7  - ETH_RMII_CRS_DV  (alternate 11)
PA8  - MCO1             (alt 0 configured with PLL to 50 MHz)
PB10 - RXER             (input, optional)
PB11 - ETH_RMII_TXEN    (alternate 11)
PB12 - ETH_RMII_TXD0    (alternate 11)
PB13 - ETH_RMII_TXD1    (alternate 11)
PB14 - nINT             (output)
PC1  - ETH_MDC          (alternate 11)
PC4  - ETH_RMII_RXD0    (alternate 11)
PC5  - ETH_RMII_RXD1    (alternate 11)

The program gets stuck during the initialization in the mac_lld_start() function in mac_lld.c at the following section and just loops there endlessly, and I have no idea of to make it get past the start function.

Code: Select all

/* Transmit FIFO flush.*/
  ETH->DMAOMR   = ETH_DMAOMR_FTF;
  while (ETH->DMAOMR & ETH_DMAOMR_FTF)
  ;

I don't know if the reference clock looks okay, but it is a 50 MHz signal as you can see in the picture.

Would appreciate if someone could take a look at it but I guess that requires some effort.

[Giovanni]

Hi,

Without HW to test it is pointless to look at the code. Is MCO programmed for maximum speed? that 50MHz signal does not look like a square wave, an HW issue is also possible.

One option is to get one of the supported boards and compare with your board.

Giovanni

[Pethead]

Okay, I just thought that someone might run it on their board to see if they have the same problem, if they just had the time to re-configure the pins. Was just wondering since I don't have any other board available right now. I only have an STM32F4-Discovery but I don't have an external ethernet PHY to test it against, still waiting on it.

Yes the MCO1 PIN is configured for high speed "PIN_OSPEED_HIGH(GPIOA_MCO1)" in board.h

Yes I was a bit skeptical regarding the 50 MHz reference clock signal. Worse case I'll replace the 8 MHz crystal with a 25 MHz one and see if it looks better, but hopefully that is not the problem, but who knows...

[Giovanni]

The new Nucleo144 boards have Ethernet and are really cheap, you may consider one of those as "reference".

Giovanni

[Pethead]

Okay I found the problem for why it was getting stuck... When I decided to use MCO1 instead of ETH_RMII _REF_CLK as the reference clock out from the MCU I disabled the ETH_RMII_REF_CLK pin function since I thought I could use either one of those out from the MCU as the reference clock, I did not think that the ETH_RMII_REF_CLK was actually needed as a reference clock for the mac driver...

Gonna try and see if I can get the webserver demo working.

[Pethead]

The webserver works (Yay!). However, it only works if I clear the Ethernet MAC clock enable bit BEFORE the call to lwipInit(NULL); So my guess is that there is some conflict with some other peripheral that I have configured.

[Giovanni]

This is not required in other demos, very strange.

Giovanni

[Pethead]

I cleared the whole RCC_AHB1ENR peripheral clock enable register and apparently that made it work since I had configured PC1 for ADC sampling in some ADC sampling code that I was testing and still had running on the MCU but wasn't really being used for anything, so there was a conflict between the ADC pin configuration and the Ethernet pin configuration since PC1 was used for ETH_MDO... So yea, just stupid problems.