I cannot receive from udp

Hi

I run Pulse-Doppler Radar Using Xilinx RFSoC Device or GNRCellSearchUsingXilinxRFSoCDeviceExample

I do exactly the links said https://www.mathworks.com/help/soc/ug/rangedopplerradarusingxilinxrfsocdevice.html

and succesfully run Monitor & Tune however host udp app cannot connect to the Board when I run soc_rangedoppler_host_run_CPI I see this message

Timed out!

Timed out waiting for response from target.

I also set the IP board on this file.

also the other example I face the same problem UDP don't receive anything

could you please help me

Answer 1

[Hassaan]

@joshua dori In such scenarios I often follow these guidelines as they may help to narrow down the issue. If after these steps you're still facing issues, it might be helpful to provide more detailed information about your network setup, the versions of the tools you are using (MATLAB, RFSoC firmware, etc.), and any specific error messages or behaviors you observe.

1. Check Network Configuration

• Correct IP Address: Ensure the IP address set in your MATLAB script (soc_rangedoppler_host_run_CPI or any relevant script for the example you are running) matches the IP address of the RFSoC board. This is a common issue where the board's IP might have changed due to network settings or it was not correctly set in the MATLAB script.
• Subnet Mask: Verify that the subnet mask of your computer and the RFSoC board allows them to communicate. If they are on different subnets, they might not be able to see each other.
• Firewall and Antivirus [Personaly faced this in one of my client's project]: Temporarily disable the firewall and antivirus software on your host PC to rule out these as the causes of the connectivity issue. Sometimes, these programs block the UDP ports needed for communication.

2. Validate Board Setup

• Firmware and Software: Ensure that the firmware on the RFSoC board and the software version of your Xilinx tools and MATLAB/Simulink are compatible. Incompatibilities here can lead to unexpected behaviors.
• Power Cycle: Simple but often effective — power cycle your RFSoC board and restart your host PC to reset the state of both devices.

3. Network Utilities

• Ping Test [Important]: From your host PC, try pinging the RFSoC board's IP address to ensure basic connectivity. If the ping fails, there is a fundamental network issue that needs to be addressed.
• UDP Test Tool [Helpfull]: Use a basic UDP test tool (there are many free ones available online) to send and receive UDP packets from your host PC to the RFSoC board's IP address using the same port numbers as your application. This can help confirm if the issue is within the MATLAB application or the network configuration.

4. MATLAB Specific

• MATLAB Version: Ensure your MATLAB and SOC Blockset versions are up to date and compatible with your hardware. Sometimes, bugs are fixed in later releases.
• Jumbo Frames: If your application sends large UDP packets, ensure that your network adapter settings on the host PC and the settings on the RFSoC board support jumbo frames. This is often overlooked and can cause packet loss.
• MATLAB Network Objects: If your script uses MATLAB's network objects or functions for UDP communication, ensure they are correctly configured, especially the timeout settings and the buffer sizes.

5. Documentation/Support Forums

• Xilinx and MATLAB Forums: Both Xilinx and MathWorks have active user forums where you might find others who have encountered and solved similar issues.
• Technical Support: If you continue to face issues, consider reaching out to MathWorks Technical Support for assistance. They might offer specific advice based on the version of the tools you are using and more detailed inspection of your setup.

---------------------------------------------------------------------------------------------------------------------------------------------------

If you find the solution helpful and it resolves your issue, it would be greatly appreciated if you could accept the answer. Also, leaving an upvote and a comment are also wonderful ways to provide feedback.

Professional Interests

• Technical Services and Consulting
• Embedded Systems | Firmware Developement | Simulations
• Electrical and Electronics Engineering

Feel free to contact me.

Answer 2

[joshua dori]

Hi, Thanks

other HDL simulink RFSOC examples work fine except udp's

ubuntu 20 is my OS's pc with no firewall I also check ip in dhcp or static ip with same netmask on both systems.

zcu111> ifconfig:

eth0 Link encap:Ethernet HWaddr FA:EF:59:2A:1F:14

inet addr:192.168.1.100 Bcast:192.168.1.255 Mask:255.255.255.0

inet6 addr: fe80::f8ef:59ff:fe2a:1f14/64 Scope:Link

UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1

RX packets:2096 errors:0 dropped:51 overruns:0 frame:0

TX packets:1516 errors:0 dropped:0 overruns:0 carrier:0

collisions:0 txqueuelen:1000

RX bytes:399499 (390.1 KiB) TX bytes:148606 (145.1 KiB)

Interrupt:17

pc ifconfig

eno1: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500

inet 192.168.1.3 netmask 255.255.255.0 broadcast 192.168.1.255

inet6 fe80::cb9e:6263:7209:110a prefixlen 64 scopeid 0x20<link>

ether 58:11:22:b8:34:0f txqueuelen 1000 (Ethernet)

RX packets 271297 bytes 320523246 (320.5 MB)

RX errors 0 dropped 76 overruns 0 frame 0

TX packets 162170 bytes 39103246 (39.1 MB)

TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0

zcu111> netstat

Active Internet connections (w/o servers)

Proto Recv-Q Send-Q Local Address Foreign Address State

tcp 0 0 192.168.1.100:ssh 192.168.1.3:46304 ESTABLISHED

tcp 1 0 localhost:8082 localhost:38542 CLOSE_WAIT

tcp 0 0 localhost:tproxy localhost:53504 CLOSE_WAIT

Active UNIX domain sockets (w/o servers)

Proto RefCnt Flags Type State I-Node Path

unix 6 [ ] DGRAM 15663 /dev/log

unix 2 [ ] DGRAM 15743

unix 2 [ ] DGRAM 11453

unix 2 [ ] DGRAM 16502

unix 2 [ ] DGRAM 16478

zcu111> netstat -l

Active Internet connections (only servers)

Proto Recv-Q Send-Q Local Address Foreign Address State

tcp 0 0 0.0.0.0:time 0.0.0.0:* LISTEN

tcp 0 0 0.0.0.0:echo 0.0.0.0:* LISTEN

tcp 0 0 0.0.0.0:daytime 0.0.0.0:* LISTEN

tcp 0 0 0.0.0.0:tproxy 0.0.0.0:* LISTEN

tcp 0 0 0.0.0.0:8082 0.0.0.0:* LISTEN

tcp 0 0 0.0.0.0:ftp 0.0.0.0:* LISTEN

tcp 0 0 0.0.0.0:ssh 0.0.0.0:* LISTEN

tcp 0 0 0.0.0.0:telnet 0.0.0.0:* LISTEN

tcp 0 0 0.0.0.0:1534 0.0.0.0:* LISTEN

tcp 0 0 :::www :::* LISTEN

tcp 0 0 :::ssh :::* LISTEN

tcp 0 0 :::30431 :::* LISTEN

udp 0 0 0.0.0.0:echo 0.0.0.0:*

udp 0 0 0.0.0.0:daytime 0.0.0.0:*

udp 0 0 0.0.0.0:time 0.0.0.0:*

udp 0 0 192.168.1.100:ntp 0.0.0.0:*

udp 0 0 localhost:ntp 0.0.0.0:*

udp 0 0 0.0.0.0:ntp 0.0.0.0:*

udp 0 0 0.0.0.0:1534 0.0.0.0:*

udp 0 0 fe80::f8ef:59ff:fe2a:1f14:ntp :::*

udp 0 0 localhost:ntp :::*

udp 0 0 :::ntp :::*

Active UNIX domain sockets (only servers)

Proto RefCnt Flags Type State I-Node Path

zcu111> ss -l

Netid State Recv-Q Send-Q Local Address:Port Peer Address:Port

nl UNCONN 0 0 rtnl:ntpd/1754 *

nl UNCONN 0 0 rtnl:kernel *

nl UNCONN 0 0 tcpdiag:kernel *

nl UNCONN 0 0 xfrm:kernel *

nl UNCONN 0 0 audit:kernel *

nl UNCONN 0 0 fiblookup:kernel *

nl UNCONN 0 0 connector:kernel *

nl UNCONN 0 0 uevent:kernel *

nl UNCONN 0 0 genl:kernel *

tcp LISTEN 0 128 *:time *:*

tcp LISTEN 0 128 *:echo *:*

tcp LISTEN 0 128 *:daytime *:*

tcp LISTEN 0 3 *:tproxy *:*

tcp LISTEN 0 3 *:8082 *:*

tcp LISTEN 0 128 *:ftp *:*

tcp LISTEN 0 128 *:ssh *:*

tcp LISTEN 0 128 *:telnet *:*

tcp LISTEN 0 16 *:1534 *:*

tcp LISTEN 0 128 :::www :::*

tcp LISTEN 0 128 :::ssh :::*

tcp LISTEN 0 16 :::30431 :::*

Monitor & tune in soc_range_doppler_top_sw simulink logs:

Model reference Accelerator, SIL, or PIL modes do not support logging data with a Scope block configured to save data to the workspace. Logging with a To Workspace block in model reference Accelerator mode is only supported for Timeseries format, and is not supported for model reference SIL or PIL mode. Model 'soc_range_doppler_proc' contains an unsupported logging combination of model reference simulation mode and Scope block or To Workspace block configuration. Data is not being logged to the workspace. To avoid this message, set the 'Configuration Parameters > Diagnostics > Model Referencing > Unsupported data logging' parameter to 'none'.

Component:Simulink | Category:Block diagram warning

### Code for the model reference code generation target for model soc_range_doppler_proc is up to date because no functional changes were found in referenced model. ### Model reference code generation target for soc_range_doppler_proc is up to date. Build Summary 0 of 1 models built (1 models already up to date) Build duration: 0h 0m 3.1108s

For referenced models, external mode simulations do not support the following:

• The use of blocks to view signals from the target application.

• Tuning or uploading of model parameters.

Component:Simulink | Category:Model warning

No data has been selected for uploading.

I also see that wireshark shows no activity from 192.168.1.100 to 192.168.1.3(pc) in udp protocol except 192.168.1.100 -> 192.168.1.255 (1534)

[Hassaan]

@joshua dori Did you try the ping test to the board underconsideration.

---------------------------------------------------------------------------------------------------------------------------------------------------

If you find the solution helpful and it resolves your issue, it would be greatly appreciated if you could accept the answer. Also, leaving an upvote and a comment are also wonderful ways to provide feedback.

Professional Interests

• Technical Services and Consulting
• Embedded Systems | Firmware Developement | Simulations
• Electrical and Electronics Engineering

Feel free to contact me.

Answer 3

[joshua dori]

Yes I have ping from pc and board without any problem, and succesfully load bitstream and other software with soc builder

[joshua dori]

Hi @Hassaan

I change the host IP in the processor and successfully run OFDMTransmitReceive and RangeDopp;erRADAR RFSOC example and see data sending from board to HOST in udp but in the GNRCellSearchUsingXilinxRFSoCDeviceExample I do the same but processor does not send from board to PC do you know why?

Thanks