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

[Richard Peters]

Posted on May 01, 2017 at 08:57

I use the STM32F767 with ethernet (on the Nucleo-144 board), and I recognize almost everything you write. The only thing that surprises me is '

there is no output at the RMII RXD0, RXD1'. I haven't done any measurements, but I would expect that even in the presence of the ethernet bug that packets do get transferred over RXD0 and RXD1 to the MAC, and that at that point they are filtered out.

I have found a method that some could qualify as a workaround: When I see CRC error frames, I switch the RMII REF CLK pin configuration back to default (input pin, default speed, no alternate function), and then configure it again to its ethernet alternate function. This seems to have a 50% chance of fixing the problem. So after a few received frames, there's a good chance that ethernet frames can be reliably received.

Resetting the MAC, re-inserting the ethernet cable, or resetting anything other than the RMII REF CLK pin configuration does not seem to have any effect.

(By the way, does anyone know if/how/when I can get STM32F767 Nucleo's with the Z revision instead of the A revision?)

[Thanh Phan]

Posted on May 01, 2017 at 11:56

'

there is no output at the RMII RXD0, RXD1', I suspected this due to my computer stop sending out ping message after too many failures, at that time the LINK/ACT LED does not blink.

I could not understand why such critical, easy to reproduce bug got into production release. A major problem is when we order new chips, we have no idea if we will receive rev.Z or faulty rev.A. I tried to contact local ST representative to help on this issue, but no response yet.

This is disappointing!

[Lei Zong]

Posted on September 30, 2017 at 03:46

We are currently also running into the silicon revision issue for the STM32F777NI processor.  We needed to get revision Z, not revision A, due to the RMII issue in the errata.  When we ordered samples from Digikey, they were rev A.  We'll try Mouser next, but we don't have high hope for it.  We also have an Avnet rep that's working with us in parallel to get some ST's attention, but as usual, we are in a pinch for schedule.  Have you guys found a way to get the Rev Z silicon?  Any feedback is appreciated.

[Tesla DeLorean]

Posted on October 01, 2017 at 18:52

In the US you'd be better off talking directly with your local ST sales office, and get samples from your rep.

[howard n2wx]

Posted on October 02, 2017 at 17:56

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

ping: sendto: Host is down

That response suggests an attempt to ping a hostip lacking an arp map entry.    'arp -a -n' probably returns a record for the hostip in question as (incomplete) expired.

[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

[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.