STM32 Ethernet Demo

[mabl]

Hello Santatana,

I guess this is probably related. I still have not found out more, except that this is probably related to DMA. My personal theory is that the MAC is stalled at one descriptor, but the driver frees an other one, so that the driver is stalled somehow.

This MAC driver thing is really a complex topic and somehow I doubt that the current wrapper will work properly in the near future...

[mabl]

After 4 evenings of tiring search for the problems with the Ethernet driver I finally found the error - it was literary one single bit wrongly set.

Basically if the MAC receives two frames where the second frame does not fit in the MAC FIFO, it does not disregard the second frame because the DFRF (Disable flusing on recieved frames) was set in DMAOMR. This stalls all execution since we rely on the mac to resume writing to the recieve descriptors once an end of frame is detected.

Now, this bit is set by default in the ST Ethernet library which is probably an error because of the inverted logic.
ETH_InitStruct->ETH_FlushReceivedFrame = ETH_FlushReceivedFrame_Disable;

where ETH_FlushReceivedFrame_Disable is defined as ((uint32_t)0x01000000). So adding
ethinit.ETH_FlushReceivedFrame = ETH_FlushReceivedFrame_Enable;
in configure_eth_struct will fix all stalls


I now know the STM32 ethernet documentation by heart... maybe if I have to much spare time I will complete the official ChibiOS Ethernet driver.

[Giovanni]

Great, give it a try, a lot of the code is already there, buffers initialization for example.

Before stop working on it I was thinking to how to handle the PHY initialization, I decided to not do that in the driver but in board.c because it is board-dependent, the driver would assume an already initialized PHY to work with.

Giovanni

[mabl]

I just discovered that Olimex exchanged the PHY in revision B of the P107 board. The code might need some changes...

[likewise]

Hello guys,

thanks for sharing and finding all the lwIP/ChibiOS/RT issues so far.

I experimented with zero-copy on an AVR32 platform (i.e. DMA directly into pbuf buffers) and IP, UDP and TCP worked on the inbound path, but ICMP did not. I have done a lwIP code investigation and I do not think that zero-copy will work throughout the stack reliably in all code paths (i.e. the rare paths). Really lwIP was not designed with zero-copy in mind.

There is someone else who did a similar partial analysis and wrote it on the wiki: http://lwip.wikia.com/wiki/Writing_a_de ... ce_drivers

I once suggested to develop lwIP-ng with RTOS and zero-copy in mind, but then myself I got sidetracked by embedded Linux development. lwIP is still one of my pet projects though.

Maybe we should start ChibiTCP/IP

Regards,

Leon.

[Giovanni]

Hi Leon,

lwIP become much better with 1.4, so many less integration problems. The problem I see in its architecture is that pbufs are allocated from and freed to lwIP itself, probably it should be the Ethernet driver handling pbufs internally and have them returned after use. This would allows to map pbufs to physical buffers in those architectures allowing that. Basically would allow the driver to optimize the exchange of data, the TCP/IP stack should only define the interface for pbuf chains, implementation would be hidden.

This would basically avoid the necessity to copy data from physical buffers (DMA buffer chains or similar) to pbufs.

About a ChibiOS-specific version, that would be extra cool, there are several overlapping mechanisms between lwIP and ChibiOS, the primitives abstraction layer would also disappear, the net result would be a thinner and more efficient stack. This is something I was thinking to do soon or later (I remember you already suggested this a while ago, probably in the old forum).

Of course such a component would also have a commercial value so the thing could be discussed also under that point of view.

Giovanni

[rubenswerk]

Hello all,

I'm an absolute beginner when it comes to RTOS, but it was quite simple to make this project running in my Olimex board (revision with old PHY). Thanks for this nice example!

As far as I understood the sourcecode and the concept of ChibiOS, the basic idea of this example is that the main loop of the lwip thread is waiting for events:

- a timer event every 5s to check the link status
- an event generated by the mac hardware (interrupt driven?) when a new packet is available

Is it correct that the ChibiOS scheduler is called every 1ms? This would mean, that the maximum throughput is limited to 1000 packets per second. If we talk about UDP packets for example, this would be 1000*1472 = ~1.5MByte per second. Of course this is a lot, but I guess both Ethernet and the STM32 could manage even higher throughput if there wouldn't be such a limitation.

Is my analysis correct, is there currently such a limitation? Is there a way to increase the performance without decreasing the SysTick period? Because I guess chaning the SysTick will cost higher CPU consumption for the OS itself and the timebase for OS timers would be incorrect.

Greetings Ruwe

[Giovanni]

Hi,

The throughput is not limited by the system tick rate, the scheduler is automatically invoked also on exit of interrupt handlers, this means that the thread waiting for events is made runnable just after the MAC interrupt is generated (few microseconds).

The system tick only affects the resolution of the chThdSleep() API and the resolution of timeout callbacks. You usually don't need to increase it, you may want to reduce it if you don't need 1mS resolution.

Giovanni

[Giovanni]

Hi,

Just a note, I resumed the work on the native driver and I started committing updates. Please feel free to comment and make suggestions based on your experience working with the wrapper. This includes changes required to lwipthread in order to make it more a standard component, if I remember well there was an issue regarding a lwip notification.

Another sub-project I am considering is some kind of web server based on lwIP allowing dynamic content generation through callbacks and streams.

Giovanni

[rubenswerk]

Thanks for your explanation, Giovanni.
This is perfect, I can achieve maximum throughput with the current project.

Nevertheless, to get even higher performance, I'm looking forward to using the STM32F4. There's an Ethernet extension board for the cheap STM32F4 discovery board, and I'd like to see how it performes.

Has anyone already tried the combination STM32F4xx + ChibiOS + Ethernet?

Regards Ruwe