STM32 Ethernet Demo

[Giovanni]

Hello Giovanni,

I didn't have a look at the updatet trunk yet, have you already corrected the name in the #if statement? I think it should start with STM32_xxx

#if !defined(MAC_BUFFERS_SIZE) || defined(__DOXYGEN__)
#define STM32_MAC_BUFFERS_SIZE 1518
#endif

Bye, RuWe

I missed this post...

I opened a ticket about this, fixed in the repository.

Giovanni

[Giovanni]

hi
i want to port the ethernet demo to the stm32f207.The stm32f207 use RMII on my board.The mac phyter is dp83848i. ...
if i connect my board with 10M network with firmware of Chibios. it is OK.but it can't work on 100M network. Then can anyone give me advice about it?Thanks

It's impossible to use MCO output from STM32F2 or F4 for driving DP83848I in RMII - 100M mode.
Signal quality is not so good. There was long discussion about that in this thread before...

I agree, this was confirmed by several developers. Anyway, is your PHY initialized in auto-negotiation mode?

Giovanni

[ninesunsz]

I agree, this was confirmed by several developers. Anyway, is your PHY initialized in auto-negotiation mode?
yes ,The PHY should be initialized in auto negotiation mode

It's impossible to use MCO output from STM32F2 or F4 for driving DP83848I in RMII - 100M mode.
Signal quality is not so good. There was long discussion about that in this thread before...
Yes ,I aslo consider the poor clock from STM32F2 MCO pin may be reason to cause such problem before.But if i use the sample firmware provide by ST named STM32F2x7_ETH_LwIP_V1.0.2 .it can work OK with use same clock source. may this error was cuased by different version of lwip? I will change the clock soure as external oscillator to prove this for next step

[mabl]

Yes ,I aslo consider the poor clock from STM32F2 MCO pin may be reason to cause such problem before.But if i use the sample firmware provide by ST named STM32F2x7_ETH_LwIP_V1.0.2 .it can work OK with use same clock source. may this error was cuased by different version of lwip?

There is basically no way lwip is responsible for this behavior. In your case I'd have a look at the PHY initialization as suggested by Giovanni.

[botdream]

Hi guys,

I been following your discussion for a while and got pretty excited with your development on getting LwIP to work with ChibiOS.

I've noticed that some of you are using Olimex dev board to run the tests, but I only have a STM32F4 DISCOVERY board.
This week I received a DP83848 RMII Ethernet module and would like to know if it's possible to connect it to the Discovery to start playing with some Ethernet sutff.

So, my question is, can I solder some wires between the STM32F4 DISCOVERY and the DP83848 module to make this work ? I haven't initially thought about the noise generated on the connections and wires .

If it's possible, I've tracked down the pins on the discovery, can someone please confirm if this is correct:
RMII_TXD1 = PB13
RMII_TXD0 = PB12
RMII_TX_EN = PB11
RMII_REF_CLOCK = PA1
ETH_MDIO = PA2
ETH_MDC = PC1
RMII_RXD1 = PC5
RMII_RXD0 = PC4
RMII_CRS_DV = PA7

Final question, is any other hardware that is sharing this that I need to disconnect from the DISCOVERY board for the Ethernet stuff to work ?

Regards,
Nelson Neves.

[Giovanni]

Hi Nelson,

This thread is very long but there are at least two persons that connected that PHY to the Discovery, do a little search inside here.

If I remember well there is something to unsolder on the Discovery because a pin conflict. I am sure others will post more details.

Giovanni

[rubenswerk]

This weekend I did some performance tests with the F4 lwip demo.
It's based on a echo service, which sends back all reveived packets. I use the maximum packet size, 1472 bytes net payload. Hardware checksum is active.

In the first try, my Windows test program waits for the reply before sending a new packet, so this is only kind of a half duplex transmission.
I was disappointed about the result, I can send ~2 megabytes/s (and of course, I also receive the same amount of data as a response).
The theoretical maximum for half duplex 100mbit echo would be >5mb/s.
I don't know why IÄ use so much performance here.
On the F107, I get ~1.5mb/s.

In the second try, my Windows test program sends continuous packets at maximum media speed without waiting for a response. The packet reception is done in an own thread. So this is a full duplex scenario.

With the default lwip buffer configuration (2 TX bufs, 4 RX bufs), ~95% of the frames are dropped. They simply get lost due to buffer overruns.
Increasing the buffers to 16 RX and 16 TX bufs dramatically improves the performance. The result has big variations, but 30%...90% of the packets are successfully replied. This comes close to the theoretical maximum throughput.

In summary, the MAC itself doesn't seem to be a blocking point. Give it enough buffers (there's a lot of RAM on the F4), and you'll get a great performance.

I'll have a closer look at the poor half duplex performance and the reason for the big variations in full duplex performance.


@botdream
No, there is nothing to unsolder on the Discovery. Follow my links in this thread, and you'll find connection schemes. I had no problems caused by long wires.

[Giovanni]

Good findings, probably it would be a good idea to give all the last 16K of RAM to the MAC driver.

Is 50% RX + 50% TX buffers an optimal balance? it is possible that a different balance could improve performance a bit more, I would try more RX than TX for example.

Giovanni

[Jacon]

No, there is nothing to unsolder on the Discovery.

Only if you don't use "USB-FS in Host mode" parallel with Ethernet connection...

[rubenswerk]

No, I don't think that 50%/50% is the optimum balance. I also assume that RX buffer size has a bigger impact. I didn't go into the details yet, the 16/16 configuration was just a try with very big buffers.

I don't need much throughput, so in a real project I wouldn't spend 50kbytes on Ethernet buffers. I prefer to use the half duplex transmission, so the 2/4 default configuration is more than enough. I just wanted to see how much traffic this controller is able to handle. I guess with a little bit of optimization, a 100mbit full duplex connection can be driven at its limit.

My half duplex test delivers a very reproduceable result - always a throughput of 2041 kilobytes/s plus/minus 1 kb. When I moved the MAC buffer into this 16kb RAM region, the throughput decreased (reproduceable) to 2020 kb/s. Funny thing. According to the datasheet, all memories are accessed with zero wait states.