Use of ETH_RMII_CRS_DV

janvi2 · ‎2010-06-17

Posted on June 17, 2010 at 17:49

#stm32f107 #rmii

mdevilliers · ‎2011-05-17

Posted on May 17, 2011 at 13:54

I have the same question at the moment, so I am bumping this post.

I am not sure where CRS_DV on the PHY should be connected to. It is connected to PA0 on the eval kit, which is according to my understanding only used in MII mode, therefore left unused in RMII mode. It would however make more sense to connect it to PA7, RMII_CRS_DV, as in the reference manual, but PA7 in turn is connected to RX_DV on the eval kit, which would make sense only for MII mode (PA7 is also MII_RX_DV).

The only reason I can think of that the eval kit is connected like it is is because the Carrier Sense is not being used and therefor the CRS_DV line is connected to the RX_DV line which provides the RMII Receive Data Valid indication independent of Carrier Sense.

I would appreciate it if someone could give some clarity on this.

js23 · ‎2011-05-17

Posted on May 17, 2011 at 13:54

I had the same problem a few months ago, had to design a RMII only board. Even after reading the documentation 50 times it was not clear to me and I finally ''solved'' it by optionally mounting a 0ohm resistor...

My connections look like this:

* RX_DV (Pin 39 on PHY) is connected to PA7

* CRS_DV (Pin 40) is not connected at all.

IMHO connecting CRS_DV to PA7 and leaving RX_DV unconnected should work, too. But I never tried.

Hope this helps.

Regards,

Johannes

mdevilliers · ‎2011-05-17

Posted on May 17, 2011 at 13:54

Thanks for your response. I also decided to make provision for both situations by placing 0Ohms's. One reason I read in the docs where one would need to connect to CRS_DV line rather than the RX_DV line is if you need to support half duplex operation, but I don't know if that would be necessary.

Anyway, I'll try both ways once the hardware is built and post the results here.

js23 · ‎2011-05-17

Posted on May 17, 2011 at 13:55

I already did some tests with the PHY forced to 10Mbit half duplex with success so this should not be the problem when using RX_DV. Maybe there have to be collisions to run into problems - but collisions should not occur on nowadays switched TP ethernet.

The reason why I tried RX_DV at first was that I wanted to stay close to the eval board and have some known working firmware. Especially because I am not sure if some config register has to be changed if CRS_DV is used. But using CRS_DV might be the cleaner solution because of the (non existent?) collision problem.