Good news. This morning it unexpectedly began to work! I am not sure exactly what I did that made this happen as I have been busy double checking many things and have not always been testing after each and every change.
But when I add some printf() statements, it then does not work, so there are unstable mysteries.
I did get some ethernet interrupts when I had DMA memory misconfigured. These were to report the "DMA error" status. Once I fixed the DMA memory setup, these went away and I never saw another interrupt. My attention may have been diverted from testing via ping to watching for interrupts.
I found the code that polls the PHY chip status and watched this change This is in LWIP/Target/ethernetif.c
8742 link state: 1 -- 8742 link up: 0 8742 link state: 2 -- 8742 link up: 1The transiton from 1 to 2 is as follows:
#define LAN8742_STATUS_LINK_DOWN ((int32_t) 1) #define LAN8742_STATUS_100MBITS_FULLDUPLEX ((int32_t) 2)Seeing the link detected properly as 100 Mbit full duplex gave me confidence that I had the PHY pins correctly configured.
I wrote some code to print the state of the ethernet MACCR register:
MACCR 40028000 3830e000 MACCR 40028000 3830e003The last 2 bits show that the Tx and Tx are enabled. They actually get enabled after the PHY status changes.
ethernetif_input - payload at 30003e60 tot_len, len = 60 60 ethernetif_input - payload at 30003840 tot_len, len = 60 60 ethernetif_input - payload at 30003220 tot_len, len = 60 60 ethernetif_input - payload at 30002c00 tot_len, len = 60 60 ethernetif_input - payload at 30004480 tot_len, len = 711 711 ethernetif_input - payload at 30003e60 tot_len, len = 60 60 ethernetif_input - payload at 30003840 tot_len, len = 60 60It looks like 5 Rx buffers are set up in a ring.
Rx - payload at 30002c00 tot_len, len = 711 711 Rx - payload at 30004480 tot_len, len = 711 711 Rx - payload at 30003e60 tot_len, len = 60 60 Rx - payload at 30003840 tot_len, len = 60 60 Rx - payload at 30003220 tot_len, len = 60 60 Rx - payload at 30002c00 tot_len, len = 711 711 Rx - payload at 30004480 tot_len, len = 98 98 Tx - payload at 30004096 tot_len, len = 42 42 Rx - payload at 30003e60 tot_len, len = 60 60 Tx - payload at 3000401a tot_len, len = 98 98 Rx - payload at 30003840 tot_len, len = 98 98 Tx - payload at 3000401a tot_len, len = 98 98 Rx - payload at 30003220 tot_len, len = 98 98 Tx - payload at 3000401a tot_len, len = 98 98 Rx - payload at 30002c00 tot_len, len = 98 98 Tx - payload at 3000401a tot_len, len = 98 98A short way into this experiment, it stops responding to ping! The packets with size of 98 seem to be the ICMP messages. When it stops responding, the packets are still being received, but no replies are getting sent.
I press the board "reset" button and now it goes for quite a long time, but eventually fails. Indeed, every time I press the reset button, it will be "fixed" for some duration. I may get only 5 or 6 ping responses or I may get quite a few.
Packet reception never stops, but no responses get sent. When a failure occurs, I see several (24) 98 byte sized packets received. But after that I see the message on the linux side of Destination Host Unreachable and no more 98 byte packets seem to be received.
Drivers - a big collection of every driver imaginable Middlewares/Third_Party/LwIP - full source for LwIP LWIP - the handful of files customized for LwIP Core - a handful of project specific files build - you will find Net1.elf hereI had little need to venture outside of Core and LWIP. I added printf() primarily to Core/Src/main.c and LWIP/Target/ethernetif.c
That the board can properly function for some amount of time shows me that I can both send and receive packets, In other words the overall ethernet hardware setup is correct.
I plan to take a look with wireshark and see just what the packet traffic looks like.
Tom's software pages / tom@mmto.org