STM32F767 Nucleo: ethernet not working

yzhang1985 · ‎2016-07-25

Posted on July 25, 2016 at 12:18

Has anyone got ethernet working on the STM32F767 or similar board? I didn't see any examples for this board, so I used the CubeMX tool to generate the initialization code with ethernet on. Then I adapted the LWIP example from another board. Basically, I copied all the HAL_ETH_* calls and am testing transmit only (HAL_ETH_TransmitFrame()). But I never get a TX complete interrupt or even the generic interrupt, ETH_IRQHandler().

Here's what I found so far:

1. The code generator got the PHY address (ETH_InitTypeDef::PhyAddress) wrong. Should be 0 instead of 1. No wonder HAL_ETH_ReadPHYRegister() was returning 0xffff.

2. Using a DSO Quad oscilloscope, I can detect configuration register activity (MDIO and MDC pins).

3. PHY doesn't generate any reference clock cycles. This is the most obvious thing wrong. I've done a lot of debugging:

a. set oscilloscope to one shot trigger mode to capture any momentary clock pulses - nothing.

b. According to the PHY (LAN8742A) and Nucleo 144 documentation, the PHY should be configured to generate a 50MHz clock on pin 14 from a 25Mhz crystal. This is done by setting nINTSEL (pin 2) low during power-on-reset by. Verified.

c. I also probed the 2 pins connected to the 25MHz oscillator, but no signs of life detected. It's not clear if I'm supposed to detect anything. On the one hand, my scope is only good for up to 7 MHz. But I should at least see a heavily aliased, noisy signal, but instead I'm seeing a flat signal. Or is the reason I don't see anything because the impedance of the scope completely attenuates the oscillator?

thanks for any help

#ethernet

Walid FTITI_O · ‎2016-07-26

Posted on July 26, 2016 at 15:13

Hi Yale,

Yes indeed. There is ressource with STM32F769 board which compatible with STM32F767. I recommend you to the LWIP example in

http://www.st.com/content/st_com/en/products/embedded-software/mcus-embedded-software/stm32-embedded-software/stm32cube-embedded-software/stm32cubef7.html

at this path:

STM32Cube_FW_F7_V1.4.0\Projects\STM32F769I_EVAL\Applications\LwIP

Compare the code there with your own , to identify what is wrong .

-Hannibal-

yzhang1985 · ‎2016-07-27

Posted on July 27, 2016 at 20:59

OK, after some further digging, here's what I found:

1. Both TX and RX are working - I probed the actual PHYs lines instead of just the ref. clock. After getting stuck on making TX work, I switched to testing RX with a packet generator and sure enough, I was getting RX completion interrupts. Then I went back to testing TX by not waiting for a completion interrupt, so that there's enough TX activity to see it on the scope.

2. If TX and RX are working, then ref. clock must be working. Earlier, I claimed I just saw a flat signal, but I guess 50MHz must be so beyond the bandwidth of my 7MHz scope that it gets low pass filtered into DC.

3. Still no TX completion interrupts.

The manual says for the interrupt to happen, bit 31 (TDES1[31]) in the TX descriptor needs to be set.

I didn't see it done in HAL_ETH_TransmitFrame(), so I thought aha, that must be why. But adding it still has no effect.

I don't see bit 31 of TDES 1 officially documented (says it's reserved). Also, I didn't see HAL_ETH_TxCpltCallback() being used anywhere in the example apps.

So does that mean this is a hardware errata?

For now, I have a work around. Instead of waiting for a TX completion. I just wait until there's a free request descriptor (OWN bit is 0) before generating a packet and calling HAL_ETH_TransmitFrame().

Amel NASRI · ‎2016-09-23

Posted on September 23, 2016 at 18:09

Hi,

We acknowledge the Ethernet issue faced on STM32F767 devices.

This limitation is under investigation. We will keep you informed as soon as we have more details on this regard.

Sorry for any inconvenience this may create for you.

-STM32 Forums Moderator

To give better visibility on the answered topics, please click on Accept as Solution on the reply which solved your issue or answered your question.

Amel NASRI · ‎2016-10-20

Posted on October 20, 2016 at 12:59

Hi,

The Ethernet limitations are described in

http://www.st.com/content/ccc/resource/technical/document/errata_sheet/group0/23/a6/11/0b/30/24/46/a5/DM00257543/files/DM00257543.pdf/jcr:content/translations/en.DM00257543.pdf

.

Please note that a new device revision will be available to fix these limitations.

For more details, please contact your FAE or distributor.

-STM32 Forums Moderator

To give better visibility on the answered topics, please click on Accept as Solution on the reply which solved your issue or answered your question.

Joerg Wagner · ‎2017-01-20

Posted on January 20, 2017 at 10:58

I have 8 Nucleo-F767ZI Rev. A boards with different behaviour.

After startup (reset or power on), the ARP request fails most of the time to get the MAC of the destination.

My workaround is to use a static ARP entry with this example code:

ip_addr_t server_ip;

struct eth_addr MAC;

IP4_ADDR(&server_ip, 192,168,0,100);

MAC.addr[0]=0x38;

MAC.addr[1]=0xc9;

MAC.addr[2]=0x86;

MAC.addr[3]=0x08;

MAC.addr[4]=0xef;

MAC.addr[5]=0x11;

etharp_add_static_entry(&server_ip, &MAC);

It's works for M2M in LAN.

Daniel Squires · ‎2017-01-23

Posted on January 23, 2017 at 13:28

I think I am seeing same or related issue using the STM32F769NIH6 on a custom board.

I've got several applications using FreeRTOS derived from examples where Ethernet works. But now I am making a bootloader and tried starting with the CubeMX code generator to make a baremetal - noOS project. I too had to change the PHY address to 0.

It receives packets, and at one point whilst debugging the debugger crashed and it left the board responding! but normally after boot it will not even respond to ping or arping.

I'll try to make sense of the errata and proposed workarounds.

Edit : I had initially thought the etharp_add_static_entry suggestion above had made it work but it turns out the code worked without it 4 out of 10 attempts.

Edit2 : The problem I have may not be related. It's the link state not always being detected leading to timeout ETH_TIMEOUT_LINKED_STATE. if i call HAL_ETH_DeInit followed by HAL_ETH_Init until success it works either next go or after a few tries :\

Amel NASRI · ‎2017-01-23

Posted on January 23, 2017 at 14:28

Hi

Squires.Daniel

‌,

If you are using revision 'Z' of the chip, this means that you aren't in same conditions as the described limitation.

So, I recommend you create a new discussion in which you state clearly the issue you are facing.

-Amel

To give better visibility on the answered topics, please click on Accept as Solution on the reply which solved your issue or answered your question.

Daniel Squires · ‎2017-01-31

Posted on January 31, 2017 at 18:20

The parts I have are Rev. A.

Also I noticed re the refclock signal that it only applies to MII and not the RMII interface used by the LAN8742A when using the CubeMX tool - whether this is a limitation of the CubeMX tool or the MCU I don't know. It was just an observation. Edit : This is not true - I think i must have mixed this up with the rx err signal - clearly the ref clk signal is needed!

I haven't investigated the problem any further at present, I have been continuing with other areas of the project.