FreeRTOS+CLI for ZC702 example requires numeric IP & sends malformed packet

mdesm2005 wrote on Sunday, June 18, 2017:

I’m trying out the FreeRTOS example for the Xilinx Zynq using a ZC702 evaluation board. I found two small issues. I recommmend put them in the documentation (at least). One is that you must use a numerical IP with a UDP client (such as YAT) to connect with the command line interface (CLI) UDP server. This is odd, because I can ping using the name “RTOSDemo”. I got the numerical IP that DHCP assigned to my ZC702 via ping BTW. Another thing that’s odd is that a TCP client on my PC can connect with the FreeRTOS TCP echo task using the name “RTOSDemo”. It’s just the UDP clients that can’t. I tried YAT and I tried a home made client in Python. Same behavior. A second issue is that the CLI server always returns a carriage return first, and in one packet. And Wireshark flags this as a “[malformed packet CPFI]”. I don’t know if this is a problem. Finally , the YAT example shown in the documentation shows and outdated version of YAT. You should pick the “UDP/IP client” option, not “UDP/IP socket” and you only need to enter the server port (5001).

rtel wrote on Sunday, June 18, 2017:

I’m trying out the FreeRTOS example for the Xilinx Zynq using a ZC702
evaluation board. I found two small issues. I recommmend put them in the
documentation (at least). One is that you must use a numerical IP with a
UDP client (such as YAT) to connect with the command line interface
(CLI) UDP server. This is odd, because I can ping using the name
“RTOSDemo”.

As I recall I have been using the name, rather than the IP address, with
YAT.

I got the numerical IP that DHCP assigned to my ZC702 via

ping BTW. Another thing that’s odd is that a TCP client on my PC can
connect with the FreeRTOS TCP echo task using the name “RTOSDemo”. It’s
just the UDP clients that can’t. I tried YAT and I tried a home made
client in Python. Same behavior. A second issue is that the CLI server
always returns a carriage return first, and in one packet. And Wireshark
flags this as a “[malformed packet CPFI]”. I don’t know if this is a
problem. Finally , the YAT example shown in the documentation shows and
outdated version of YAT. You should pick the “UDP/IP client” option, not
“UDP/IP socket” and you only need to enter the server port (5001).

Yes - I think that was pointed out recently on an email thread. The
page needs updating.

mdesm2005 wrote on Monday, June 19, 2017:

I’m including several screen shots showing the process I follow with YAT to open a socket. It works with the IP address, but not the name.

mdesm2005 wrote on Monday, June 19, 2017:

Details on the malformed packet returned by the CLI (it’s always the 1st return, it contains only a carriage return)

heinbali01 wrote on Monday, June 19, 2017:

Hi Marc,

This is odd, because I can ping using the name “RTOSDemo”.

That is indeed strange.

I have not worked with YAT YET :slight_smile:

/* Include support for LLMNR: Link-local Multicast Name Resolution */
#define ipconfigUSE_LLMNR					( 1 )

/* Include support for NBNS: NetBIOS Name Service (Microsoft) */
#define ipconfigUSE_NBNS					( 0 )

When you use Wireshark, maybe you can see if YAT uses LLMNR or NBNS (or both) to resolve the name. In case it uses NBNS, you may want to enable NBNS.

A second issue is that the CLI server always returns a carriage
return first, and in one packet. And Wireshark flags this as a
“[malformed packet CPFI]”.

I do not think it is really mal-formed. The CPFI protocol happens to use UDP port numbers 5000/5001.
Could you change the port numbers to something high and random, e.g. 67890 ?

mdesm2005 wrote on Tuesday, June 20, 2017:

It may only be YAT that can’t use the name “RTOSDemo”. I wrote a simple UDP client in Python and it successfully connected to the CLI UDP server using the name “RTOSDemo”. My UDP client uses LLMNR. So does Ping. It seems the YAT doesn’t even try when a name is given. It just pops up a error dialog. I’m using YAT version 1.99.52

mdesm2005 wrote on Tuesday, June 20, 2017:

I changed the CLI’s port from 5001 to some value below 64K (above 64K, the python library has an exception). The warning “malformed packquet” does indeed go away. I’ve included the code for my client, the output , and the Wireshark output.

Next, I need to figure out how to properly add a BSP and H/W platform from scratch (from a Vivado bit stream of my own) as opposed to using the one that comes from the demo. Please let me know if this is documented somewhere.

heinbali01 wrote on Tuesday, June 20, 2017:

above 64K, the python library has an exception

because a port number is 16 bits :slight_smile:

I tend to treat the BSP as a library that is part of my project. Moving to a different Xylinx BSP always take a lot of effort, either because functions are broken or their usage has changed.

Note that the modules for Ethernet and for SDIO ( SD-card ), have been changed heavily along with their supporting modules.

The H/W platform is something different. I am not sure how that whole process works. That is also more a Xilinx question.

Regards.