WARP Project Forums - Wireless Open-Access Research Platform

You are not logged in.

#1 2016-Dec-20 08:59:27

gmkim
Member
Registered: 2016-Jul-19
Posts: 27

.

.

Last edited by gmkim (2020-Aug-17 20:04:35)

Offline

 

#2 2016-Dec-20 09:55:39

murphpo
Administrator
From: Mango Communications
Registered: 2006-Jul-03
Posts: 5159

Re: .

You must modify the new pcore's MPD file to specify interrupt properties of the pcore's interrupt outputs.

Every pcore has an MPD file that describes the core's ports and properties. The MPD file is located in the pcore's data folder; for the buffers core it's "<xps_proj>/pcores/w3_warplab_buffers_axiw_vX/data/w3_warplab_buffers_axiw_v2_1_0.mpd".

When a pcore has an output that is used as interrupt, that output must be marked as an interrupt source in the pcore's MPD. Unfortunately System Generator does not support interrupts in its automatic MPD file generation. Sysgen correctly creates a PORT for the interrupt output but does not include the required interrupt-specific flags.

After generating the updated buffers pcore from System Generator, you must modify the new core's MPD file to include the interrupt properties on the two interrupt outputs "rf_rx_iq_rssi_int" and "rf_tx_iq_int". Look at the MPD file for the buffers core in the reference design for an example. The snippet below is taken from the w3_warplab_buffers_axiw_v2_1_0.mpd file in the v7.7.1 ref design:

Code:

# Interrupt propterties added manually after Sysgen export
PORT rf_rx_iq_rssi_int = "", DIR = OUT, SIGIS = INTERRUPT, SENSITIVITY = EDGE_RISING
PORT rf_tx_iq_int = "", DIR = OUT, SIGIS = INTERRUPT, SENSITIVITY = EDGE_RISING

Offline

 

#3 2016-Dec-21 08:02:52

gmkim
Member
Registered: 2016-Jul-19
Posts: 27

Re: .

.

Last edited by gmkim (2019-Jul-17 06:13:11)

Offline

 

#4 2016-Dec-21 09:40:42

gmkim
Member
Registered: 2016-Jul-19
Posts: 27

Re: .

.

Last edited by gmkim (2019-Jul-17 06:13:21)

Offline

 

#5 2016-Dec-22 06:33:07

murphpo
Administrator
From: Mango Communications
Registered: 2006-Jul-03
Posts: 5159

Re: .

To solve remained errors, I choose "WARP_HW_VER 3.10.a" and "WARP_ip_udp 1.00.b".
This reduce errors more, but below error remain.
To solve this, I add supported library named "WARPxilnet 3.04.a"

This is not correct. The current WARPLab Ref Design only uses the WARP_HW_VER and WARP_ip_udp libraries. The WARPxilnet library is deprecated and no longer used.

The WARPLab Ref Design C code makes specific assumptions about the BSP configuration. I would strongly recommend starting with a known-good SDK project from the reference design archive, then applying the same BSP settings to the BSP in your custom project.

Offline

 

#6 2016-Dec-22 07:22:05

gmkim
Member
Registered: 2016-Jul-19
Posts: 27

Re: .

.

Last edited by gmkim (2019-Jul-17 06:13:32)

Offline

 

#7 2016-Dec-22 07:48:56

murphpo
Administrator
From: Mango Communications
Registered: 2006-Jul-03
Posts: 5159

Re: .

Another question, when I did generate linker script, I should choose three things.

Again, please refer to the reference SDK project. The WARPLab C code requires a special linker script that cannot be created with the Generate Linker Script tool. You should use the linker script (lscript.ld) from the reference project.

Offline

 

#8 2016-Dec-26 20:48:23

gmkim
Member
Registered: 2016-Jul-19
Posts: 27

Re: .

.

Last edited by gmkim (2017-Nov-23 01:12:22)

Offline

 

#9 2016-Dec-28 10:13:09

murphpo
Administrator
From: Mango Communications
Registered: 2006-Jul-03
Posts: 5159

Re: .

When you ran the Generate Bitstream process in XPS, did the process run for a while (30+ minutes)?

In the SDK were there any compilation errors when you imported the application and BSP projects? In the Program FPGA dialog box did you select the w3_WARPLab_v7_2rf.elf application for the MicroBlaze CPU? What happened when you programmed the FPGA (UART output? hex displays? etc.).

Offline

 

#10 2017-Jan-02 02:32:02

gmkim
Member
Registered: 2016-Jul-19
Posts: 27

Re: .

.

Last edited by gmkim (2017-Nov-23 01:12:51)

Offline

 

#11 2017-Jan-02 13:45:05

chunter
Administrator
From: Mango Communications
Registered: 2006-Aug-24
Posts: 1212

Re: .

I think you should try to decouple problems with the tools from your changes to the design. I'd suggest the following the debugging steps.

1. Try to import the existing SDK workspace in the release zip without any changes. Can you successfully import, generate a download.bit and program the board without any changes to the design?
2. Assuming you are able to program the board and it operates just like the provided bitstreams in the release zip, try to make a simple change to the C-code and verify that change worked. For example, change one of the at-boot prints and make sure that design flow is working for you.
3. Having verified the SDK side of your workflow, you can then try to export the System Generator project without any changes. You can then try some simple changes like adding a register.
4. Finally, you can make your more substantial changes to the design.

Layering the complexity on like that will help you figure out where the problem is coming from-- your changes to the design or use of the tools.

Offline

 

Board footer