Failed to find device: cf-ad9361-lpc.

Hi, I was following the tutorial https://ww2.mathworks.cn/help/supportpkg/xilinxzynqbasedradio/examples/hw-sw-co-design-qpsk-transmit-and-receive-using-analog-devices-ad9361-ad9364.html HW/SW Co-Design QPSK Transmit and Receive Using Analog Devices AD9361/AD9364.

When I run the software interface model in "normal" mode, I got the error as follows:

Environment:

ZC706 and FMCOMMS5, windows10, Matlab R2019a, vivado 2018.2.

Add-ons:

• Communication Toolbox Support Package for Xilinx Zynq-Based Radio
• Embedded Coder Support Package for Xilinx Zynq Platform
• HDL Coder Support Package For Xilinx Zynq Platform
• Embedded Coder Support Package for Arm Cortex-A Processors
• Analog Devices Board Support Packages
• Embedded Coder Interface to QEMU Emulator

I have also finished "Harware Setup" step, but the error still exists.

I'm a beginner to this kind of platform. Looking forward to your reply! Thanks a lot!

Answer 1

[Martin Enderwitz]

Hi,

There are a few things to consider to resolve the issues you are seeing:

1. The example you are working with demonstrates HW/SW Co-Design, where the model zynqRadioHWSWQPSKAD9361AD964SL_UDP_interface is used to generated C code that executes on the ARM processing system of the Zynq SoC. Therefore, it cannot be run in "Normal" mode, and instead must either be fully deployed or run using "Monitor and Tune". Please ensure you follow the example instructions exactly, and in particular the sections Setting up the software model to run on the ARM processor and Running the Software and Hardware on the Zynq board
2. Since you are working with the FMCOMMS5, you need to replace the AD946x Transmitter and AD936x Receiver blocks in the model with their FMCOMMS5 counterparts, FMCOMMS5 Transmitter and FMCOMMS5 Receiver. The "Failed to find device: cf-ad9361-lpc" error you are seeing is because the FMCOMMS5 does not contain this device; that exists on the FMCOMMS2/3/4 only.

If you follow the example steps precisely, and replace the receiver/transmitter blocks, you should be able to run the example without issue.

Regards,

Martin

[Xiaoxiao Liu]

Hi, Martin. Thanks for your reply!

I replaced the receiver/transmitter blocks with FMCOMMS5 Transmitter and Receiver, and followed the example steps to configure the model. When I run the model in "External" mode, it no longer reported errors, and the progress bar indicated that the model was running:

However, there were some other problems:

• I can't see the result in the diagnostic viewer, which is mentioned in the step "Running the Software and Hardware on the Zynq board". Instead, the information displayed in diagnostic viewer was stucked at: "Establishing connection to hardware":

Did that mean that simulink cannot connect to hardware?

• I tried to double-click the switch in the model to change the transmission source, but the switch didn't change:

Did I misunderstand something in the example? If not, How to check the decoded data? Thanks for your constant help!

[Martin Enderwitz]

Hi,

Glad you were able to make some progress!

• The information in the diagnostic viewer looks correct - the model has connected to the hardware and started running in External mode, as indicated by the progress bar. If you inspect the blocks underneath the Descramble and Print/For Iterator Subsystem subsystems, you will see a UDP send block that is sending the received and decoded messages back to the host computer via UDP packets.
• There is a companion model, zynqRadioHWSWQPSKAD9361AD9364SL_UDP_HostPrintout that you need to run at the same time as the previous model. It contains a UDP receiver block that will receive these UDP packets and then display the decoded QPSK messages in the diagnostic viewer.
• When you double-click the switch to change the transmission source, you should observe that the decoded message will change, as the messages sent from the FPGA PL and ARM PS are different. The appearance of the switch block may not render instantly, and if you double-click it multiple times before it can render it may appear that it isn't changing, but the decoded messages should give you a clear indication that this is working.

I hope this helps,

Regards,

Martin

[Xiaoxiao Liu]

Hi, Martin.

I have solved the former problem with your help. Now I can check the result in diagnostic viewer, but when I double-clicked the switch to change the transmission source, the decoded messages didn't change at all.

It doesn't look like a rendering problem, does it?

[Martin Enderwitz]

I'm looking into this to see if I can reproduce the same issue you are seeing, but in the meantime you can use the following models:

• zynqRadioHWSWQPSKAD9361AD964SL_UDP_interface
• zynqRadioHWSWQPSKAD9361AD964SL_UDP_SourceSelect

As before, zynqRadioHWSWQPSKAD9361AD964SL_UDP_interface contains a UDP send block that will send the decoded QPSK messages to the host for displaying.

It also contains a UDP receive block, and zynqRadioHWSWQPSKAD9361AD964SL_UDP_SourceSelect contains the corresponding UDP send block - in this instance, it will send the register value (1 or 0) to the Zynq board via UDP.

[Xiaoxiao Liu]

It works well to control the logic using UDP blocks, I can see the change of the decoded data. So what's the difference between them?

[Martin Enderwitz]

When you use "Monitor and Tune", the generated code will run as an executable on the ARM PS, but a connection ("External mode") between the executable and the Simulink model running on the host is maintained to facilitate some data and control in either direction (e.g. tuneable parameters). When you change the value via the switch, it is this External mode connection that is sending the data to the ARM PS to write the corresponding AXI-Lite register value. You can read more about Monitor and Tune/External mode here:

https://www.mathworks.com/help/supportpkg/arduino/ug/remotely-monitoring-and-controlling-an-application-on-hardware.html

The UDP model does not make use of this "External mode" connection to send these values to the ARM PS, instead relying on standard UDP protocols.

Now, the reason the UDP model is working is because that model is running in Normal mode (i.e. fully on the host with no connection to the hardware) and the switch block is changing state correctly when you double-click it. For some reason, the switch block is not registering a state change when running the original model in Monitor and Tune mode. I'm still investigating this issue and will reply once I know more.

[Martin Enderwitz]

To confirm, I have been able to reproduce the issue you have observed, where the switch does not toggle when you double-click on it. This is a previously reported issue in R2019a, that has been resolved in R2019b.

In the meantime, you can resolve this issue by running the following command:

set_param('zynqRadioHWSWQPSKAD9361AD9364SL_interface','DefaultParameterBehavior','Tunable')

That should re-enable the ability to toggle the switch value when running in External mode.

Regards,

Martin

[Xiaoxiao Liu]

It works well now! Thank you very much!

Best regards!