TCP Stack error decoding

[Ozflip]

Hi,

How do I go about figuring out the meaning of the stack errors?

Specifically: "Error (provider/code/cause) 61/4/0"

Thanks!

Phil.

[Andy Brown]

Hi Phil,

The provider codes can be found in lib/include/error/ErrorProvider.h. The enumeration starts at zero and counts up so I can see that 61 is ERROR_PROVIDER_NET_DHCP. I should explicitly number that enumeration so it's easier to cross-reference. I didn't want to compile in text strings for the provider names because of the increased flash usage that would cause.

The provider-specific 'code' for DHCP can be found in lib/include/net/application/dhcp/DhcpClient.h. Again, it's an enumeration and 4 corresponds to E_FAILED which is raised when the DHCP transaction times out without a response from the DHCP server.

To debug this you'll need Wireshark. Set it up with a filter of 'bootp' and you'll see the DHCP transaction packets because DHCP is a broadcast UDP protocol so all stations on the network get to see it. The default MAC address used by stm32plus is 02-00-00-00-00-00 and this can be used to filter out stm32plus traffic from any other DHCP noise on your subnet.

Regards,
- Andy

[Ozflip]

Thanks Andy. I think my issue is the pinout on my Ethernet PHY, but while trying to fix it I got a bit confused about how to decode error codes.

I did a wireshark trace and saw nothing from that MAC address, or a different randomly generated MAC address, which is why I think the issue is at the PHY level. I'm using a new dev board (a WaveShare XCore407I) and I'm working through trying to understand how your alternate pin mapping works. I'm a C++ noob, so I'm using your code to challenge myself! 

Thanks again - Phil.

[Andy Brown]

Hi Phil,

I may be able to help you get this working. The DP83848 is definitely a supported PHY.

On your board, is it wired for MII or RMII?

Which set of pins is it wired to and are they a match for the pins in net/datalink/mac/MacDefaultPinPackage.h or net/datalink/mac/f4/MacRemapPinPackage.h? Note that there were errors in the f4 RMII remap package that I corrected in the recent 3.5.0 release.

If your PHY is wired differently then that's no problem, you can create a struct like one of the two I referenced above with the correct pinout and use its type name in your stack's DatalinkLayer declaration, e.g.

Code Select Expand


template<class TPhysicalLayer>
using MyRmiiInterface=RmiiInterface<TPhysicalLayer,MyFunkyPinPackage>;
typedef DatalinkLayer<MyPhysicalLayer,MyRmiiInterface,Mac> MyDatalinkLayer;


Which station number is your PHY listening on? The default is "1". If your PHY is on a different address then you can change it in the stack's parameters structure: params.phy_address=whatever;

[Ozflip]

I was right - the issue is that the PHY was in RMII mode but was on the alternate pin mapping. It just so happened that the alternate mapping was wrong and you had just fixed it - after I upgraded to 3.5.0 and changed the stack call to use the alternate mapping it all worked properly.

Is throwing a DHCP error the expected behaviour in this scenario? Not a complaint, just a question for self education as I try to understand the stack code.

By the way: Kudos on the best stack implementation out there for STM32 (maybe for any micro) - both in terms of functionality and ease of use. Way better than LWIP and uIP, and you did it all yourself? Amazing....

Phil

[Andy Brown]

I agree that getting as far as the DHCP client initialisation seems too far on in the process to be picking up a pinout error. I guess that the PHY initialisation appeared to return meaningful register bits even though those bits were probably just random. I'll take a look at the PHY registers in more detail some time to see if there's something that can be read that positively identifies the PHY as present and correct, such as a manufacturer ID code. This would catch MDC/MDIO pin errors but you do have to try to transmit/receive something to realise you've got the MII/RMII pins wrong.

Yes all the stack code with the exception of the init sequence for ST's MAC is original work. I've been working with IP networks more or less constantly since the early 90's so it's not that much of a stretch to apply that knowledge to creating a firmware stack. The language helps; a TCP/IP stack is naturally layered and object based and so lends itself well to an OO implementation.