STM32F4DISCOVERY and DP83848 Pocket loss at ~40%

[[email protected]]

Hi ALL!

First of all thank you for bringing the ethernet functionality to Chibios/RT. It's very useful.
I have a couple o STM32F4DISCOVERY boards and a DP83848 connected to one of them.

I have started with ARMCM4-STM32F407-LWIP example changing it as described 3 posts earlier to let this work with my DISCOVERY board.
It was piece of cake. Everything have compiled, uploaded to MCU and started as it should.

The example page is available as it should. But unfortunately the amount of lost package is at about 40%. I have tested it with many examples:
1. simple pinging w/o any spiecial parameters
2. embeeded site request from my PCs web browser
3. written another example, which was requesting a HTTP GET from MCU to external server

A simple ping result of command: #ping 192.168.1.20 (NO EXTRA ARGS, just basic test):
--- 192.168.1.20 ping statistics ---
546 packets transmitted, 329 received, 39% packet loss, time 545002ms
rtt min/avg/max/mdev = 0.073/0.124/2.841/0.161 ms

In all cases the problem was exacly same: it is working fluently for ex. 10 seconds, then for 5 secs. nothing (pocket loss), again ok for some seconds, then again nothing form some seconds and all over again.
When everything is working ok- no packet loss (20s max), then it is working very fast.

I have tested it using the latest trunk of Chibios/RT and both LWIP 1.4.0 and .1.4.1. Whatever i do i am having very same problem: pocket flood, nothing, pocket flood, nothing......
It doesn't seem to be a hardware problem I think.

Any ideas what to check? How to debug?
BTW. This is a copy of the post from Ethernet development topic, as Giovanni requested.

Greetings
Piotr Klimczak

[Giovanni]

Hi,

I try to redo the ping test, I already did it in the past but I didn't notice anomalies until I started to do packet serious flooding (20 pings in parallel with no interval and very large packets).

Could it be a problem related yo your PHY or the clock driving it?

Giovanni

[[email protected]]

To check is it a PHY hardware problem I have to buy another one. This is what i want to avoid as i will make a use only for one PHY.
I am using this module: http://arduinosolutions.com/index.php?r ... uct_id=235

Unfortunately i do not understand what do you mean "the clock driving".

Thanks for your help.

[[email protected]]

One more thing:

This is what i have changed in lwipconf.h file in comparison to the original one from the example:

Code: Select all

Index: lwipopts.h
===================================================================
--- lwipopts.h  (revision 4948)
+++ lwipopts.h  (working copy)
@@ -943,7 +943,7 @@
  * TCP_SND_BUF: TCP sender buffer space (bytes). 
  */
 #ifndef TCP_SND_BUF
-#define TCP_SND_BUF                     256
+#define TCP_SND_BUF                     2048
 #endif
 
 /**

This is because of lwip 1.4.1 sanity check complaint.

[iggarpe]

Suggestion: modify lwipthread.c and change the link status polling interval (which is 5s by default). Set it to 3s, for example, and see if the problem you're experiencing varies its periodicity. If it does, it means that either the link status check code is broken for your PHY or that your design has some hardware problem that makes your PHY bring the link down every time it is polled.

At least you'll narrow your debugging.

[iggarpe]

Forgot. This is the code you need to modify:

/* Setup event sources.*/
evtInit(&evt, S2ST(5));
evtStart(&evt);


Change the '5'.

[[email protected]]

HI iggarpe,

Thanks for your help!

Changing this value makes a difference!
The freeze time is a multiply of the link status polling interval.
When i set it to 1 freezes occur more often (each 3-6s) but ware shorter 1-4s.
When i set it to 10 freezes occurs each 30-40s but ware taking 10s or 20s.

How come?
What now?

Greetings,
Piotr Klimczak

[Giovanni]

Not sure how to proceed, the polling of PHY never created problems in the past including DP83848.

Could it be a clock quality issue? how are you clocking your PHY?

About lwIP 1.4.1, I will try to integrate it during vacations. That for fixing that setting.

Giovanni

[[email protected]]

I have done some investigation.

It fails here:

Code: Select all

bool_t mac_lld_poll_link_status(MACDriver *macp) {
  uint32_t maccr, bmsr, bmcr;

  maccr = ETH->MACCR;

  /* PHY CR and SR registers read.*/
  (void)mii_read(macp, MII_BMSR);
  bmsr = mii_read(macp, MII_BMSR);
  bmcr = mii_read(macp, MII_BMCR);

  /* Check on auto-negotiation mode.*/
  if (bmcr & BMCR_ANENABLE) {
    uint32_t lpa;

    /* Auto-negotiation must be finished without faults and link established.*/
    if ((bmsr & (BMSR_LSTATUS | BMSR_RFAULT | BMSR_ANEGCOMPLETE)) !=
        (BMSR_LSTATUS | BMSR_ANEGCOMPLETE))
      return macp->link_up = FALSE; ///////////////////////////HERE

The value of BMSR is 25088 which in binary is: 110001000000000

Values for BMSR are:

Code: Select all

#define BMSR_ERCAP              0x0001  /**< Ext-reg capability.            */
#define BMSR_JCD                0x0002  /**< Jabber detected.               */
#define BMSR_LSTATUS            0x0004  /**< Link status.                   */
#define BMSR_ANEGCAPABLE        0x0008  /**< Able to do auto-negotiation.   */
#define BMSR_RFAULT             0x0010  /**< Remote fault detected.         */
#define BMSR_ANEGCOMPLETE       0x0020  /**< Auto-negotiation complete.     */
#define BMSR_MFPRESUPPCAP       0x0040  /**< Able to suppress preamble.     */
#define BMSR_RESV               0x0780  /**< Unused.                        */
#define BMSR_10HALF             0x0800  /**< Can do 10mbps, half-duplex.    */
#define BMSR_10FULL             0x1000  /**< Can do 10mbps, full-duplex.    */
#define BMSR_100HALF            0x2000  /**< Can do 100mbps, half-duplex.   */
#define BMSR_100FULL            0x4000  /**< Can do 100mbps, full-duplex.   */
#define BMSR_100BASE4           0x8000  /**< Can do 100mbps, 4k packets.    */

So 110001000000000 means:

#define BMSR_100HALF 0x2000 /**< Can do 100mbps, half-duplex. */
#define BMSR_100FULL 0x4000 /**< Can do 100mbps, full-duplex. */

But there is a problem with 9th bit- in docs it is said that it is always 0 as it is reserved bit.

Should I start thinking about buying a new PHY?

Greetings
Piotr

[[email protected]]

Hi Giovanni,

Accoring to clocking, question- everything works on defaults just like in LWIP demo example. I was trying to change as little as possible to eliminate possible failure causes- which is me and my code . I just wanted to be sure that that it is not my fault
It has a 50MHz oscillator onboard.

According to my previous post, where i have written that i am receiving a value on reserved bmsr bit, there is a small chance that it occurs because of clocks- i hope. Otherwise I have to buy another one .

Thanks in advance.