STM32 Ethernet Demo

[botdream]

Thanks, actually I did miss one important link from @rubenswerk:
http://www.mikrocontroller.net/topic/243066#2477720

Got the pins right and also the correct DP83848 PHY module, will give it a run tonight!

There is a mention for removing R50 (0 Ohm) resistor, not sure if it applies to me!

I'll be running my Discovery board just to test Ethernet, may think later connecting an SD card to deploy some html files. (if possible)

Regards,
Nelson.

[rubenswerk]

In mac_lld.h line 126 and 133, the #if should start with STM32_xxx (if it is not already fixed with the last ticket):

#if !defined(STM32_MAC_TRANSMIT_BUFFERS) || defined(__DOXYGEN__)
#define STM32_MAC_TRANSMIT_BUFFERS 2
#endif

#if !defined(STM32_MAC_RECEIVE_BUFFERS) || defined(__DOXYGEN__)
#define STM32_MAC_RECEIVE_BUFFERS 4
#endif

[Giovanni]

It is fixed in trunk.

Giovanni

[rubenswerk]

Let's completely forget the benchmark I did - I'm afraid there's still a problem in the driver when it comes to big packets.

We already talked about the payload limit of 1470bytes. Giovanni fixed that by increasing STM32_MAC_BUFFERS_SIZE from 1518 to 1522.

When I do the full duplex test and send for example 1000 packets with a size close to the MTU 1472bytes. This works for maybe 500 packets, but suddenly, no further packets are received. My UDP callback function isn't called any more. When the driver is in this corrupt state and I reduce the packet size to 1246bytes, my callback function works again. With 1248bytes, it is not called.
If I keep the maximum packet size at <=1246bytes from the very beginning, the driver never goes into this corrupt state.

Increasing STM32_MAC_BUFFERS_SIZE has no impact (I tried 1800).
The number of receive buffers STM32_MAC_RECEIVE_BUFFERS has no impact. I even set it to 1, and the network performance is the same as with 16!!!
86% of the packets are echoed, no matter what value STM32_MAC_RECEIVE_BUFFERS has. Very strange! Are the additional buffers not used? The rate of 86% is very constant if I keep packet size below 1246bytes.

I did too few testcases yesterday, and it looked as if there was a correlation between STM32_MAC_RECEIVE_BUFFERS and performance, but this is wrong. At least I found the reason for the big variations in my last test session. Sometimes it takes 300 packets until the driver stalls, sometimes 860 packets. With a packet size of 1246 bytes (does anyone know this magic number?) there are no variations any more, always ~860 packets out of 1000 replied.

I can successfully run the half duplex test for hours with full packet size. I have to stress the driver with continuous packets to make it stall. Maybe the driver goes into the corrupt state once an overrun happened.

Edit:
The same applies for ICMP. I can ping the stalled driver with standard ping size, but it fails if I force big ping packets.
I have a F107 board with the old lwip demo based on ST driver, and it doesn't stall with full size packets.

[Giovanni]

I'll give it a try in the weekend, I want to try to make concurrent pings on the interface and increase the number until it starts losing packets, this worked well when I debugged the AT91 MAC driver.

Could you verify if this triggers the problem as well? A single ping doesn't trigger it, I performed that continuously for hours.

Giovanni

[Giovanni]

Ok, I couldn't wait...

I am testing 10 concurrent continuous pings of 1472 bytes with no delays, but the driver does not lose any packet. Testing on the Olimex STM32-P407. It is running for 30 minutes now.

High traffic does not trigger the problem, at least not ICMP traffic.

Giovanni

[Giovanni]

It starts losing packets when I start the 14th pinger at that point it loses ALL packets, all pingers stop receiving, when I kill one of them pinging restarts.

It is like that the driver or the MAC stops working past a certain bandwidth threshold. I am not sure if this is an HW issue or it depends on the driver. It seems to recover however.

Giovanni

[rubenswerk]

Thanks for your quick response.
The problem is, most ping utilities wait for a reply before sending the next packet. So this is kind of a half duplex operation, even if you run 10 of those pings in parallel.
In my test application, it takes a few hundred packets in a row to make the driver stall.
If I insert a 2ms (minimum Windows resolution) pause every 15 packets in my application, it runs perfectly.

I found hrping for Windows which uses seperate processes for send & reply. After several tries, I was able to reproduce it with this ping tool, so it is not linked to the UDP callback function.

I do it like that:

hrping -l 1472 -n 10 -s 0 -q 192.168.0.222
-l is the packet size
-n is the number of packets to send
-s is the time interval between packets
-q quiet, because the concole output increases time between packets

I can run it with -n 10 as often as I like, no problems
Then I change n to 10000. It usually needs some tries, but after a while, the driver stalls, resulting in 100% package loss.

Also if I go back to n=10, there are no replies. It does not recover. The board needs a reset to reply on big packets again.
However, I get a reply on pings with l=1246.

Let me post a console log what happens after starting up the board and doing some pings. Test was done with RX_BUF=4, TX_BUF=2.
In the n=10000 ping, there are lots of identical error messages (I posted only 3 of them) which cannot be suppressed with the -q option. The tool has a problem with the 0ms interval.

Code: Select all

*********************************************************
C:\ARM>hrping -l 1472 -n 10 -s 0 -q 192.168.0.221
This is hrPING v3.13 by cFos Software GmbH -- http://www.cfos.de

Source address is 0.0.0.0; using ICMP echo-request
Pinging 192.168.0.221
with 1472 bytes data (1500 bytes IP):


Statistics for 192.168.0.221:
  Packets: sent=10, rcvd=10, error=0, lost=0 (0.0% loss) in 0.002094 sec
  RTTs of replies in ms: min/avg/max/dev: 0.869 / 1.197 / 1.638 / 0.260
  Bandwidth in kb/sec: sent=7163.323, rcvd=7163.323

  
*********************************************************
C:\ARM>hrping -l 1472 -n 10000 -s 0 -q 192.168.0.221
This is hrPING v3.13 by cFos Software GmbH -- http://www.cfos.de

Source address is 0.0.0.0; using ICMP echo-request
Pinging 192.168.0.221
with 1472 bytes data (1500 bytes IP):

send failed: Error 10035: Ein nicht blockierender Socketvorgang konnte nicht sof
ort ausgeführt werden.

send failed: Error 10035: Ein nicht blockierender Socketvorgang konnte nicht sof
ort ausgeführt werden.

send failed: Error 10035: Ein nicht blockierender Socketvorgang konnte nicht sof
ort ausgeführt werden.


Statistics for 192.168.0.221:
  Packets: sent=8789, rcvd=789, error=0, lost=8000 (91.0% loss) in 0.307388 sec

  RTTs of replies in ms: min/avg/max/dev: 0.777 / 2.685 / 12.651 / 1.846
  Bandwidth in kb/sec: sent=42888.792, rcvd=3850.182


*********************************************************
C:\ARM>hrping -l 1472 -n 10 -s 0 -q 192.168.0.221
This is hrPING v3.13 by cFos Software GmbH -- http://www.cfos.de

Source address is 0.0.0.0; using ICMP echo-request
Pinging 192.168.0.221
with 1472 bytes data (1500 bytes IP):


Statistics for 192.168.0.221:
  Packets: sent=10, rcvd=0, error=0, lost=10 (100.0% loss) in 0.000000 sec


*********************************************************
C:\ARM>hrping -l 1246 -n 10 -s 0 -q 192.168.0.221
This is hrPING v3.13 by cFos Software GmbH -- http://www.cfos.de

Source address is 0.0.0.0; using ICMP echo-request
Pinging 192.168.0.221
with 1246 bytes data (1274 bytes IP):


Statistics for 192.168.0.221:
  Packets: sent=10, rcvd=10, error=0, lost=0 (0.0% loss) in 0.001852 sec
  RTTs of replies in ms: min/avg/max/dev: 0.690 / 1.019 / 1.388 / 0.219
  Bandwidth in kb/sec: sent=6879.049, rcvd=6879.049


*********************************************************
C:\ARM>hrping -l 1472 -n 10 -s 0 -q 192.168.0.221
This is hrPING v3.13 by cFos Software GmbH -- http://www.cfos.de

Source address is 0.0.0.0; using ICMP echo-request
Pinging 192.168.0.221
with 1472 bytes data (1500 bytes IP):


Statistics for 192.168.0.221:
  Packets: sent=10, rcvd=0, error=0, lost=10 (100.0% loss) in 0.000000 sec

[Giovanni]

I am using an old utility UOTrace that is capable of pinging without delays, I attached it somewhere in this thread.

So far I am not sure if there is a problem or this is a normal behavior, if there is a problem it could be any of those:
1) Windows stack problem.
2) My router problem.
3) STM32 HW problem.
4) Problem in the driver.
5) Problem in lwIP.

It would be a good idea to make the same test using the wrapper driver, this could give us an hint.

Giovanni

[rubenswerk]

Last night I was unable to reproduce the problem. Finally I found out that it only happens if I do at least one warm reset (pressing the reset button on the Discovery), but never directly after a cold reset.

I also thought about problems with external components, so I did the following test:

- warm reset the board
- connect to my PC using a 100mbit switch
- send 1472 byte pings until there is no reply anymore (using hrping)
- keep the board (which is now in the corrupt state) powered and connect it to my Notebook using a direct point-to-point connection
- ping with >= 1248 bytes -> fails
- ping with <= 1246 bytes -> succeeds

Once the problem is present, the board does not react on frames >1246 bytes any more.
Let me do some further testing, also with my old F107 board and the ST wrapper.

What would be a good function to toggle a LED - the MAC interrupt? I could check if it is still called.

Sorry for only reporting problems without having any solutions... Both lwip and the MAC are black boxes to me.


Edit:
Today I took the latest trunk 4227 in order to start from scratch. Took the Olimex P407 lwip demo and did the minimum changes to make it running on the Discovery. No problems so far, stable after heavy ping attacks the whole evening The problem must be caused by my own modifications. Will try to figure out.
Sorry for giving a false alarm.