STM32 Ethernet Demo

[rubenswerk]

Hello Giovanni,
as a quick workaround, I enclosed the for loop into an endless loop. So there's no timeout, but anyway, if the PHY cannot be found (which is a severe hardware fault), it makes no sense for my application to start up.

[Giovanni]

Hi,

I added the timeout setting on PHY detection, do you mind testing the latest commit? (4105)

Giovanni

[rubenswerk]

I did a test and it works great in my environment. Maybe a return value would be nice so that the calling function can evaluate if a PHY was found by mii_find_phy().
Now, the system will always shut down, so there's not a great benefit between the timeout and an endless search loop. If the function would return with an error code, the application could do some kind of fault reaction or debug output.

[Giovanni]

The difference is that chSysHalt() is a weak symbol and can be redefined, also, it is a single place where to put a breakpoint so it is convenient for testing.

Returning an error from the xxxStart() functions is something I strongly agree on because there are several device driver types where the initialization can fail, for example xxxStart() functions could fail to allocate DMAs in a DMA sharing scenario, or simply the peripheral could fail to startup, the problem is that it should be done consistently in all drivers so it is not a small effort.

Giovanni

[rubenswerk]

Hello,

I tried to activate the hardware checksum, but my board doesn't receive frames any more. I see an outgoing DHCP request with correct checksum, but no further communication.

I set STM32_IP_CHECKSUM_OFFLOAD to 3, and all checksum options in lwipopts.h to 0. Since I'm still using the original lwip 1.4.0 with the ICMP checksum problem (which only affects the ping), I also modified icmp.c and set outgoing checksum to 0, as described by mabl in this thread.

Jacon, do you have a hint what else I should consider?
Thanks, RuWe

[Jacon]

Jacon, do you have a hint what else I should consider?
Thanks, RuWe

Hmmm...

Just checked my lwIP demo - exactly the same behaviour as yours:
ping OK, web server not answering
Even with restored backup copy from 4'th April - which worked perfectly then...
Have absolutely no idea, what the Hell is going on
That's a result of 2 weeks break in tests & focus (Easter,travels etc. )

Will start more deeply debugging, but have limited time resources now

Jacon

[rubenswerk]

The checksum offload mode can be configured with STM32_IP_CHECKSUM_OFFLOAD. This mode is stored in bits 22-23 of tdes0 in the stm32_eth_tx_descriptor_t structure.
I cannot see where bits 22-23 of tdes0 are used. Is it converted into another data type, passed as a pointer?

According to page 830 ("Transmit Checksum Offload"), bits 27-28 in TDES1 are responsible for setting the offload mode.
However, in the description of TDES0 on page 861, the checksum is controlled via bits 22-23.

I think they got something mixed up in the manual.

[Giovanni]

At line 472, the macro STM32_TDES0_CIC() does that.

I think bits 22:23 are the correct ones, there is an error in page 830 of the RM.

Giovanni

[mabl]

I tried to activate the hardware checksum, but my board doesn't receive frames any more. I see an outgoing DHCP request with correct checksum, but no further communication.

Ok, I had some time for debugging this afternoon. It is caused by the way the driver checks the checksum of incoming packages. The IPHCE and PCE bits in the receive descriptor indecate a checksum error but are only valid if the package is a IP package as indicated by the Framtype bit. See also table 214 in the F107 documentation.

So applying this patch fixes the error for me:

Code: Select all

diff --git a/os/hal/platforms/STM32/mac_lld.c b/os/hal/platforms/STM32/mac_lld.c
index 15f9cd1..8584b46 100644
--- a/os/hal/platforms/STM32/mac_lld.c
+++ b/os/hal/platforms/STM32/mac_lld.c
@@ -505,12 +505,13 @@ msg_t max_lld_get_receive_descriptor(MACDriver *macp,
   /* Iterates through received frames until a valid one is found, invalid
      frames are discarded.*/
   while (!(rdes->rdes0 & STM32_RDES0_OWN)) {
-    if (!(rdes->rdes0 & (STM32_RDES0_AFM | STM32_RDES0_ES
+    if (!(rdes->rdes0 & (STM32_RDES0_AFM | STM32_RDES0_ES))
 #if STM32_IP_CHECKSUM_OFFLOAD
-                       | STM32_RDES0_IPHCE | STM32_RDES0_PCE
+        && !(rdes->rdes0 & STM32_RDES0_FT & (STM32_RDES0_IPHCE |
+                                             STM32_RDES0_PCE))
 #endif
-        )) && (rdes->rdes0 & STM32_RDES0_FS) &&
-              (rdes->rdes0 & STM32_RDES0_LS)) {
+        && (rdes->rdes0 & STM32_RDES0_FS) &&
+           (rdes->rdes0 & STM32_RDES0_LS)) {
       /* Found a valid one.*/
       rdp->offset   = 0;
       rdp->size     = ((rdes->rdes0 & STM32_RDES0_FL_MASK) >> 16) - 4;

One other thing: I think there is a typo: Shouldn't max_lld_get_receive_descriptor be named mac_lld_get_receive_descriptor?

[Giovanni]

Hi mabl,

Thanks for fixing this, I committed the change.

One other thing: I think there is a typo: Shouldn't max_lld_get_receive_descriptor be named mac_lld_get_receive_descriptor?

Fixed this as well, strange I never noticed it before.

Giovanni