arty a7 lwip slow start

[jarvis]

I'm on an Arty A7 35T and I have a microblaze with the standard SDK lwip examples running. When the app runs, I very quickly see the normal echo server printout stuff: "link speed: 100, Board IP: 192.168...blah blah. TCP echo server started @ port 1022"

Despite seeing no error messages, when I try to ping the board from my PC, I get absolutely no responses for about 60 seconds, but then it clears up and ping/TCP starts working fine. Maybe one out of every 6 bootups, it never clears up and I have to hit the reset button and try again.

Any ideas what might be going wrong? I'm just running example design stuff so I haven't manipulated code.

[JColvin]

Hello,

I got the lwIP Echo Server example working for Arty A7-35 in 2023.1. There were a couple of gotchas that I ran into that you may have already addressed, but I'll list them anyways.

- In the Vivado block design, I forgot to connect the AXI EthernetLite interrupt, which caused problems getting an IP addressed assigned via DHCP
- In Vitis, I needed to fix the conflicting status error. Basically, comment out the “u16_t status;” line 399 in
/design_1_wrapper/microblaze_0/standalone_microblaze_0/bsp/microblaze_0/libsrc/lwip213_v1_0/src/contrib/ports/xilinx/netif/xadapter.c
save, then rebuild the project. I learned this from Adam Taylor's mention of it on his tweet here: https://twitter.com/ATaylorFPGA/status/1666347512687411200.
- I modifying the Platform BSP settings to have lwip213 → temac_adapter_options → py_link_speed be set to 100 Mbps rather than autoconfig (needed if you are not using a DHCP server such a router and are instead manually connecting)

After that, I was able to build the project, open up a Telnet connection on port 7 and then had data echo back to me. The longest waiting was for getting the DHCP to assign the IP address, but that didn't take more than 5 seconds or so.

Let me know if you have any questions.

Thanks,
JColvin

 

[JColvin]

Hi @jarvis,

I'm a little surprised to hear that the TCP echo server is starting at port 1022 since from my knowledge the lwIP echo server template used in Xilinx SDK/Vitis is port 7

The long delay sounds symptomatic of two potential problems. One is that there is a delay function in place whose time base is off by a few orders of magnitude. The other, which seems more likely to me based on the 60 second timing, is that the echo server reaches an internal timeout and resets itself.

I'm working on creating a MicroBlaze based design to test the Echo Server in 2023.1 to see what results I get.

Thanks,
JColvin

[jarvis]

Thanks for looking into this. I will definitely try out this change.

[jarvis]

Which file in the ports/xilinx/netif folder did you modify?

[JColvin]

HI @jarvis,

I modified the xadapter.c as that was the file Vitis showed as having the error. (updated my post to clarify that file as it wasn't listed originally)

I attached my Vitis export and a pdf view of the corresponding block design for convenience.

Thanks,
JColvin

AA35-EchoServerBD.pdf vitis_export_archive.ide.zip

[jarvis]

Awesome @JColvin, thanks again!

[jarvis]

I'm still having issues, and I don't see any glaring difference. Are you able to call out the frequencies of the different clocks used in your block design? Did you have to add the BACKBONE constraint to get through implementation?

[JColvin]

Hello,

I used the Digilent board files and largely followed our Getting Started Guide, https://digilent.com/reference/programmable-logic/guides/getting-started-with-ipi, for setting up the block design; I put the clocking wizard downstream of the UI clock as recommended and added the Ethernet peripheral from the board tab at the same point I added the GPIO peripherals in the guide and edited the .xdc as needed to account for my sys_clk_i and the eth_ref_clk (you'll see them as the uncommented lines in the .xdc)

UI clock is at the 81 MHz or so (whatever is listed in the dropdown) and is connected to the clocking wizard, which is configured to output 25 MHz. (note that there is a rounding error bug in Vivado that will report slightly different frequencies are being generated, rather than the exact frequencies).

Regardless, I attached my archived Vivado project to this message so you can compare. It won't have the run results completed as that would have more than doubled the size of the file, but the corresponding .xsa is the vitis_export_archive a couple messages above. 

Thanks,
JColvin

AA35-EchoServer-23.1-notBuilt.xpr.zip

[jarvis]

Have you been able to get this application to boot up from QSPI and run properly? After a cold boot, I'm required to either manually press the re-config button once, or I have to hold down the reset button while I apply power, keep it held for a few seconds, and then let go. If I just plug in USB cable for power and do nothing else, I can tell that the fabric is configured and running, but looks like the Microblaze gets stalled. Any ideas?