Nucleo 144 Ethernet, LAN8742A, CubeMX 4.13.1?

matthew23 · ‎2016-03-17

Posted on March 17, 2016 at 20:35

I needs some help. I recieved a Nucleo 144 and I have used CubeMX 4.13.1 to generate some test code to try out the on-board ethernet. Well I have had little success and cant seem to find the issue. They come with a LAN8742A phy setup in RMII. I am sure someone has used ethernet on these so any help would be great.

The CubeMX configuration is simple in that it only enables the ethernet module in RMII and LWIP with a fixed IP address of 192.168.1.2. The clock is defined as bypass @ 8Mhz and the system clock is configured for 180Mhz. No RTOS and MX_LWIP_Process() is placed in the main loop.

I have a STM32F4-disco on a break-out board with a DP83848 phy module in RMII with then exact same CubeMX configurations other than clock and everything works just fine.

If I ping to the Nucleo no response, if I ping to the Disco I get a response.

I am sure that the problem lies with the LAN8742A configuration but cannot seem to find the issue.

Any thoughts?

matthew23 · ‎2016-03-18

Posted on March 18, 2016 at 15:19

Wrong Forum?

Updated question and title.

matthew23 · ‎2016-03-18

Posted on March 18, 2016 at 16:48

The problem is with the default register alignment within CubeMX ETH configuration. It comes down to translation of the LAN8742A spec sheet terminology and ST CubeMX register terminology.

Also the PHY address is 0 on the Nucleo boards as the LAN8742A strap is pulled low.

Paolo Chiantore · ‎2017-03-27

Posted on March 27, 2017 at 10:16

The problem is with the default register alignment within CubeMX ETH configuration

What do you mean? Did you find a solution?

I have the same problem starting from scratch with CubeMx with Lwip enabled (no RTOS) andstatic IP address. I addedTCP echoserver example code copied from STM32756G_EVAL examples. Lwip Initialization completes without errors but I have no success pinging the NUCLEO board and I can't see any kind of packets with Wireshark. I do see activity on LAN8742A TXD and RXD pins.

There are

/external-link.jspa?url=http%3A%2F%2Fwww.st.com%2Fcontent%2Fccc%2Fresource%2Ftechnical%2Fdocument%2Ferrata_sheet%2Fgroup0%2F23%2Fa6%2F11%2F0b%2F30%2F24%2F46%2Fa5%2FDM00257543%2Ffiles%2FDM002575pdf%2Fjcr%3Acontent%2Ftranslations%2Fen.DM002575pdf

on ethernet RMII on STM32 F767 chip revision A, but I don't think they go as far as not seeing any kind of activity when pinging the board.

Nicholas Hemstreet · ‎2018-07-05

Posted on July 05, 2018 at 21:58

I'm having the exact same issue with an STM32F207VG Nucleo board.

I've found if I push the NRST button a few times (the amount of times seems arbitrary) the issue will resolve itself and LED2/nINT/nPME/nINTSEL is pulled low while not transmitting and receiving it is pulled high.

I checked the errata sheet and didn't see anything for the STM32F2xx Ethernet peripheral working with the LAN8742A-CZ-TR.

Did you ever find a solution?

Paolo Chiantore · ‎2018-07-06

Posted on July 06, 2018 at 10:45

Unfortunately not.

I also found that after an arbitrary number of resets the board will work.

Nicholas Hemstreet · ‎2018-07-09

Posted on July 09, 2018 at 20:51

I'm not sure what the above guy was saying about the register mappings. I looked at the datasheet for the LAN Phy

http://ww1.microchip.com/downloads/en/DeviceDoc/8742a.pdf

and couldn't find anything that even remotely resembles writing to the LAN phy (I checked the HAL_Ethernet/ethernetif/ethernet files), however because the example I found using the NETCONN sockets for the

evaluation board works as well as the fact that the board works sometimes I doubt that it is an issue at such a low level.

I've also noticed if you enable ICMP and turn the board on and off (or start debug or run) you will see two Multicast Listener Queries go out and fail. While this could just be chatter left on my local network, it happens everytime and I think there might be something messed up with that part of the config.

Could there be an LWIP issue I'm missing for the RAW API? Is there something that needs to be configured for the udp/tcp/icmp/arp modules to work outside of whats in the auto-generated MX_LWIP_INIT()?

You probably moved on from this issue long ago, but I was wondering if you had any input?