STM32F777 revision A RMII errata symptoms

[Thanh Phan]

Posted on April 29, 2017 at 06:38

Ethernet section of my custom board is the same as the STM32F746 discovery board. The same code (start ethernet and reply to ping) works reliably on the discovery board. But on my board (at all speed and duplex modes):

(1). Sometime after reset it works fine, I could ping continuously for several hours without any packet lost

(2). Sometime after reset it does not work or misses lot of ping. No ethernet interrupt fired. The MMCRFCECR has non-zero values.

(3). I am using macOS to ping, some time it responses

ping: sendto: Host is down

In this case, there is no output at the RMII RXD0, RXD1. 

Questions:

- Anyone knows in case (3) the computer will not send out any packet or computer does send but my board could not received?

- Are these symptoms caused solely by the RMII errata of revision A silicon? My main concern is PCB/schematic error, I want to fix as early as possible if there are.

- Is there anyway to recover from this error state by software? (reset the MAC?)

#ethernet #stm32f7

[Lei Zong]

Posted on October 03, 2017 at 04:44

Laurent,

Thanks for the info. We ordered 20 pieces from Digikey last week and they were all of rev A. When we contacted Digikey, they informed us that they can provide a date code of when the part is manufactured, but not really a silicon revision number. If we provide you the date code, can you tell us which rev it is?

Lei

[Laurent VERA]

Posted on October 03, 2017 at 09:55

Dear Lei,

Please send to my mail box (community mail) the date code as well athe exact commercial product code, we will then let you know the silicon revision.

Thank you.

Laurent

[marco sulliotti]

Posted on October 04, 2017 at 17:16

Hi everybody,

The following is my analysis and a proposed workaround about the RMII bug in STM32F7 rev A.

Analysis.

The problem is due to the lack of synchronization between the 50MHz ref clock sync divider and the MAC internal state machines.

At start up the sync divider starts randomly in the ''right'' or in the ''wrong'' way.

If it starts in the ''wrong'' way the packets received are not passed correctely from the PHY  to the MAC and this is  detected by the crc calculation: as a result the packets are dropped and the crc error count in the MMCRFCECR register is increased.

If it starts in the ''right'' way everything works fine.

Proposed workaround.

The following is an automatization of the tip proposed by Richard Peters in this thread.

Thank you Richard :)

1) Init the Ethernet peripheral.

2) Set the PHY in local loopback, I.E. set bit 14 in PHY_BCR register.

3) Read the MMCRFCECR register and store it contents.

4) Transmit a packet with the first six bytes set to 0xFF, I.E. a broadcast.

5) Wait a while, E.G. 100uS.

6) Read the MMCRFCECR register and compare it with the previously saved value.

7) If it is equal jump to point ''12'' else procede to the next point.

8) Switch the RMII_REF_CLK pin to normal input, I.E. disconnect it from the sync divider.

9) Switch the RMII_REF_CLK pin back to the ethernet alternate function, I.E. riconnect it to the sync divider.

         Point 8 and 9 gives to the sync divider the chance to restart in the ''right'' way.          After few tries it will synchronize in the ''right'' way and everythings will work fine. 10) Go to point ''3''

11) Disable PHY local loopback, I.E. clear bit 14 in PHY_BCR register, to allow normal functionality.

12) The bug has been patched, we can go on.

Any comment is welcome.

Regards

Marco

[marco sulliotti]

Posted on October 04, 2017 at 17:47

Points '2' and '11' refer to the LAN8742A PHY.

Marco

[Lei Zong]

Posted on October 04, 2017 at 18:01

We found silicon revision Z from Arrow Tech’s webstore. You’ll want date code 1714+ when you order.

Thanks all,

Lei

________________ Attachments : image001.jpg : https://st--c.eu10.content.force.com/sfc/dist/version/download/?oid=00Db0000000YtG6&ids=0680X000006HyOX&d=%2Fa%2F0X0000000b70%2FuwIUOhQKOSpPLIv.4qr5EKnRZeKzCzgGO5ek0wC2Wck&asPdf=false

[Daniel Glasser]

Posted on October 07, 2017 at 01:12

Though your reference may be to a LAN8742A PHY, many (most?) other PHYs will have the same definition for bit 14 in the BCR (Basic Control Register), as this is pretty much part of the generic register set for 802.3 (R)MII PHYs accessed over MDIO or internal to some SOCs.  I've never run across a modern PHY that didn't have this feature controlled via this same bit in this same register.