2016-09-17 10:47 AM
Hi All,
I have noticed that the Stm32F767 Nucleo does not always start Ethernet reliably. For testing I used one of the example on the STM32Cube_FW_F7_V1.4.0 for the STM32F746ZG-Nucleo base of LWIP. I set up a dos windows to ping the board and from every 10 resets of the board about half of them fail to respond to the pings.I am evaluating the Stm32F767 and Lan8720A and I am a bit disappointed at this reliability issue.I also wrote a small program using Keil Rtos and also have the same problem. The link leds are both on and the activity led blinks but no ping response. Looking at the Ethernet MMC register just the receive crc error register increments.Any ideas on how to debug this? #ethernet-reliability2016-09-19 06:49 AM
Hi neves.alfredo
,
STMicroelectronics acknowledge such issue and is working on the analysis for fixing it.Sorry for the inconvenience that brought to you.
-Hannibal-2016-09-19 06:50 PM
Hi Hannibal,
We have found the similar issue, We have a production board using a STM32F746 with RMII connection to the LAN9303 with the interface clock from the LAN9303, and that works fine, we have hundreds in the field without issue.However we needed more flash space and therefore decided to replace the STM32F746 with a STM32F767, thinking it would be basically a drop the chip in. However we now experience the connection issue with the LAN9303, we have double checked all the straps, the settings etc. But we have intermittent issues with initial connection to the LAN9303. We are using lwip 1.4Some of the micros seem to work every time and others almost wont work at all, and everything in-between.When it does not work, we get CRC fault in peripheral. Strangely some of the micros can send packets that make it to the network, but not receive any valid packets, it seems the packet received is very corrupt.Do you have any idea what the issue is? we have been pulling our hair out try to resolve the issue. As the STM32F746 works without issue, we assumed it must have been a pin on the edge of operation, but double checking everything seems we have everything correct.Is this issue solely with the STM32F767? or is it across other F7 micros's?If you have any information regarding this issue we would like to hear about it if possible.Thanks2016-09-23 09:15 AM
Hi Justin,
We confirm the issue using RMII on STM32F767 devices only.As already said, 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 ModeratorTo give better visibility on the answered topics, please click on Accept as Solution on the reply which solved your issue or answered your question.
2016-10-20 02:32 AM
2016-10-20 03:50 AM
Hi,
The Ethernet limitations are described in the new errata sheet.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 ModeratorTo give better visibility on the answered topics, please click on Accept as Solution on the reply which solved your issue or answered your question.
2016-10-21 06:24 AM
Hello,
So I bought a NUCLEO-F767ZI with unusable Ethernet from Radiospares, what can I do? Those boards are out of stock from both Radiospares and Farnell (expected despatch on 27/10/2016). Will these boards have a new device revision or should I cancel my order before receiving another unusable one? Thanks in advance for your answer2016-10-26 03:10 AM
Hello,
now revision 4 of the F76x Errata sheet is out, stating a new revision Z. A remarkable number of 3 (!) issues is stated as fixed for revision Z, including the RMII issue. But I guess there is no way that you can make sure you get a Rev.Z on the Disco/Nucleo Board...2016-11-02 10:07 AM
Just received another NUCLEO-F767ZI from Radiospares (RS P/N 123-1052) with chip rev. A. I will send it back for a refund.
Arrow has 2 references for both STM32F767ZIT6 and NUCLEO-F767ZI (seehttp://components.arrow.com/part/link/na/en/STM32F767ZIT6/STMicroelectronics
) but no details about device revision.