Page 15 of 26
Re: STM32 Ethernet Demo
Posted: Tue Apr 17, 2012 8:20 am
by 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.
Re: STM32 Ethernet Demo
Posted: Tue Apr 17, 2012 8:42 am
by Giovanni
Hi,
I added the timeout setting on PHY detection, do you mind testing the latest commit? (4105)
Giovanni
Re: STM32 Ethernet Demo
Posted: Tue Apr 17, 2012 5:01 pm
by 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.
Re: STM32 Ethernet Demo
Posted: Tue Apr 17, 2012 6:00 pm
by 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
Re: STM32 Ethernet Demo
Posted: Wed Apr 18, 2012 9:26 pm
by 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
Re: STM32 Ethernet Demo
Posted: Thu Apr 19, 2012 8:36 pm
by Jacon
rubenswerk wrote: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
Re: STM32 Ethernet Demo
Posted: Mon Apr 30, 2012 11:56 pm
by 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.
Re: STM32 Ethernet Demo
Posted: Tue May 01, 2012 8:18 am
by 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
Re: STM32 Ethernet Demo
Posted: Tue May 01, 2012 5:15 pm
by mabl
rubenswerk wrote: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 ma
c_lld_get_receive_descriptor?
Re: STM32 Ethernet Demo
Posted: Tue May 01, 2012 5:54 pm
by 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