cancel
Showing results for 
Search instead for 
Did you mean: 
Highlighted
Observer
Observer
11,553 Views
Registered: ‎08-31-2012

S00_AXI_BASEADDR 0xFFFFFFFF

I am using Vivado 2015.3 and have created a new IP using IP package tool. The address edidtor shows a correct base address for this IP after instantiation.

 

I exported the hardware including the bit file to the SDK. In SDK, the xparameters.h indicates the value 0xFFFFFFFF for the base address: 

#define XPAR_AXI_DBG_DESERIAL_0_DEVICE_ID 0
#define XPAR_AXI_DBG_DESERIAL_0_S00_AXI_BASEADDR 0xFFFFFFFF
#define XPAR_AXI_DBG_DESERIAL_0_S00_AXI_HIGHADDR 0x00000000

 

The following link shows that it was a bug in a old version. What is the next step to solve my issue?

 

https://forums.xilinx.com/t5/Zynq-All-Programmable-SoC/Bram-parameters-in-Xparameters-h/m-p/555182/highlight/true#M5042

 

0 Kudos
18 Replies
Highlighted
Anonymous
Not applicable
11,544 Views

Re: S00_AXI_BASEADDR 0xFFFFFFFF

The xparameters.h is populated by the TCL file in the data folder of the driver. Have you added this correctly in SDK.

You need to use the Xilinx tool -> Repo, and point to the folder that contains the driver.

 

 

0 Kudos
Highlighted
Observer
Observer
11,531 Views
Registered: ‎10-05-2012

Re: S00_AXI_BASEADDR 0xFFFFFFFF

Hello!

 

Seeing the same problem (2015.3) - create a brand-new peripheral via Vivado's Create and Package IP dialog, edit the IP, package and export, add to a block diagram, auto-assign address, create bitstream, then export. The xparameters.h as created by a BSP in the SDK does indeed have a section for the custom peripheral, meaning the TCL script was invoked and the repo was found successfully, but it's using the default baseaddress and highaddress instead of the one assigned by Vivado's address editor. Interestingly, if I manually set the baseaddress in my C project to the address editor's definitions, it works great - so Vivado is working right, it's just something that is wrong in the export process that doesn't allow the SDK to generate the BSP correctly.

0 Kudos
Highlighted
Observer
Observer
11,530 Views
Registered: ‎10-05-2012

Re: S00_AXI_BASEADDR 0xFFFFFFFF

Additionally, did try to add the driver repo for my peripheral in the SDK - no change.
0 Kudos
Highlighted
Contributor
Contributor
11,308 Views
Registered: ‎03-02-2010

Re: S00_AXI_BASEADDR 0xFFFFFFFF

I'm seeing the same thing in Vivado 2015.4. I've tried many things to isolate the issue but I can't figure it out. I've also recreated the IP core and deleted the entire sdk directory and did a fresh import (actually, like an insane person, I've done this quite a few times). No matter what I do, the imported HDF display shows the correct address but the xparameters.h assignment is 0xFFFFFFFF. It's only one one core out of 21 but there is nothing special about the AXI interface on this one core.

 

Summary is: 

 

2015.4

microblaze design

AXI LITE custom IP core

xparameters.h BASEADDR for this one core is 0xFFFFFFFF. All other cores assigned correctly

 

 

0 Kudos
Highlighted
Visitor
Visitor
10,962 Views
Registered: ‎03-20-2014

Re: S00_AXI_BASEADDR 0xFFFFFFFF

Hi everyone,

 

Did any one solve this issue??? Xilinx peoples some one please help !!!

I have the same issue with at least 2 of my custom peripherales and it's anoing to change the address manualy each time the tool changes it and if you forget to do so...waist of time.

 

So the probleme is that in exported hdf file my custom peripherale shows the correct assigned address but xparametrs.h assignes 0xFFFFFFFF

 

Waiting to Xilinx geniuses ;-)

0 Kudos
Highlighted
Visitor
Visitor
10,736 Views
Registered: ‎12-27-2015

Re: S00_AXI_BASEADDR 0xFFFFFFFF

Hello,

I have exactly the same issue with Vivado 2015.4.

In system.hdf, the address is correct, and is the same as defined in the address editor. In xparameters.h, the Base Address is 0xFFFF_FFFF

 

I assign the address now maunally, but this is error-prone, and not a proper way. When will this bug be fixed?

 

Kind regards

STG

0 Kudos
Highlighted
Visitor
Visitor
10,106 Views
Registered: ‎01-31-2016

Re: S00_AXI_BASEADDR 0xFFFFFFFF

Do the steps in the following link.

<http://www.xilinx.com/support/answers/66479.html>

0 Kudos
Highlighted
Adventurer
Adventurer
9,856 Views
Registered: ‎10-20-2011

Re: S00_AXI_BASEADDR 0xFFFFFFFF

I stil have the issue in Vivado 2015.4.1 and script.tcl doesn't fix it in my environment.

I hope for a fix of this bug soon...

V-italiano

0 Kudos
Highlighted
Observer
Observer
9,554 Views
Registered: ‎12-18-2013

Re: S00_AXI_BASEADDR 0xFFFFFFFF

I'm joining the crowd here, I also have the described problem. I can set the adress manually in my C code in SDK but it feels dirty.

 

The Link provided earlier does not work (anymore)?

 

I hope they at least fix that in the upcoming version of vivado. Does anybody have a workaround?

 

 

0 Kudos
Highlighted
5,659 Views
Registered: ‎04-27-2016

Re: S00_AXI_BASEADDR 0xFFFFFFFF

I have the same issue, I've run through the tutorials now at least 5 times ensuring I have everything correct. It seems whenever I generate the BSP the addresses dont match those in the register. 

#define XPAR_PWM_W_INT_0_S00_AXI_BASEADDR 0xFFFFFFFF
#define XPAR_PWM_W_INT_0_S00_AXI_HIGHADDR 0x00000000

 

In addtion the interupt definitions aren't generated and appear to not work if I hack them in to the SDK code.

I was on vivado 2015.4 and then upgraded to 2016.1 with the hope this might fix the problem, but no joy.

0 Kudos
Highlighted
4,888 Views
Registered: ‎02-26-2016

Re: S00_AXI_BASEADDR 0xFFFFFFFF

Hello!

 

I have the same issues in Vivado 2015.3. I usually solve the address problem by first letting Vivado assign an address for my custom IP and then hard code it in the component.xml file in the ip folder at entries C_S00_AXI_BASEADDR and  C_S00_AXI_HIGHADDR. But for the interrupt I have not found any solution. I can deduce the correct value but is not always working and sometimes the interrupt does not occur at all. Has anyone found a workaround? 

0 Kudos
Highlighted
Visitor
Visitor
843 Views
Registered: ‎07-24-2019

Re: S00_AXI_BASEADDR 0xFFFFFFFF

I know that is an old topic, but I am facing the same problem in Vivado 2019. Some address are 0xFFF.... and some interrupts ID are wrong....Any ideas?

0 Kudos
Highlighted
Moderator
Moderator
814 Views
Registered: ‎09-12-2007

Re: S00_AXI_BASEADDR 0xFFFFFFFF

0xfffffff is the default if the p parameter is not found. Can you share your driver and I'll have a look?

0 Kudos
Highlighted
Visitor
Visitor
774 Views
Registered: ‎07-24-2019

Re: S00_AXI_BASEADDR 0xFFFFFFFF

Hi!

I have chose generic as driver and the problem was solved. But I have another probem and I have no idea how to solve it.

When I generated bsp, I obtain:

#define XPAR_FABRIC_TIMERS_FIT_TIMER_1HZ_INTERRUPT_INTR 0U
#define XPAR_FABRIC_TIMERS_FIT_TIMER_2HZ_INTERRUPT_INTR 1U
#define XPAR_FABRIC_TIMERS_FIT_TIMER_5HZ_INTERRUPT_INTR 2U
#define XPAR_FABRIC_TIMERS_FIT_TIMER_10HZ_INTERRUPT_INTR 3U
#define XPAR_FABRIC_TIMERS_FIT_TIMER_20HZ_INTERRUPT_INTR 65U
#define XPAR_FABRIC_TIMERS_FIT_TIMER_50HZ_0_INTERRUPT_INTR 4U
#define XPAR_FABRIC_TIMERS_FIT_TIMER_100HZ_1_INTERRUPT_INTR 67U

As you can see, only two timers has correct interrupt ID, That could be happening?

 

The desing is quite simple, some timers to a concat, to the IRQ_F2P port.

0 Kudos
Highlighted
Moderator
Moderator
770 Views
Registered: ‎09-12-2007

Re: S00_AXI_BASEADDR 0xFFFFFFFF

Can you share your HDF?

0 Kudos
Highlighted
Visitor
Visitor
764 Views
Registered: ‎07-24-2019

Re: S00_AXI_BASEADDR 0xFFFFFFFF

yes, sure.

Just one thing, I have used Vivado 2018 to do this, because I thought that the problem was the vivado 2019 version.

Thanks a lot!

0 Kudos
Highlighted
Visitor
Visitor
751 Views
Registered: ‎07-24-2019

Re: S00_AXI_BASEADDR 0xFFFFFFFF

After several test, I have found why is happening, but I don´t know how to solve it.

The interrupts are connected to two concats, one goes to IRQ_F2P, and the other goes to INTC, which is connected to Core1_nIRQ port. In Vivado 2014 this works perfectly, but in this new version not. If I remove INTC connection, the IDs of the interrupts appears perfect:

/* Definitions for Fabric interrupts connected to ps7_scugic_0 */
#define XPAR_FABRIC_TIMERS_FIT_TIMER_1HZ_INTERRUPT_INTR 61U
#define XPAR_FABRIC_TIMERS_FIT_TIMER_2HZ_INTERRUPT_INTR 62U
#define XPAR_FABRIC_TIMERS_FIT_TIMER_5HZ_INTERRUPT_INTR 63U
#define XPAR_FABRIC_TIMERS_FIT_TIMER_10HZ_INTERRUPT_INTR 64U
#define XPAR_FABRIC_TIMERS_FIT_TIMER_20HZ_INTERRUPT_INTR 65U
#define XPAR_FABRIC_TIMERS_FIT_TIMER_50HZ_0_INTERRUPT_INTR 66U
#define XPAR_FABRIC_TIMERS_FIT_TIMER_100HZ_1_INTERRUPT_INTR 67U

 

Any ideas?

0 Kudos
Highlighted
Moderator
Moderator
717 Views
Registered: ‎09-12-2007

Re: S00_AXI_BASEADDR 0xFFFFFFFF

You are correct. The issue is related to having two interrupt controllers connected:

concat.PNG

 

The root cause can be seen in the ::hsi::utils::get_interrupt_id proc. This will call the line:

set intc_periph [::hsi::utils::get_connected_intr_cntrl $ip_name $port_name]

This will return both interurpt controllers; axi_intc_0, and ps7_scugic_0. The code doesnt expect this. I have updated the proc, to

check if there is more than one intc detected, to loop and find the scugic:

#added by stephenm to address the fact that there could be more than 1 intc
if {[llength $intc_periph] > 1} {
   foreach intc $intc_periph {
      set intc_type [common::get_property IP_NAME $intc]
      if {[string match -nocase $intc_type "ps7_scugic"]} {
         set intc_periph $intc
      }
   }
}

I have tested this on my end, with a simple script to generate the BSP in HSI:

SCRIPT.PNG

 

Here, I am using a local copy of the scugic driver with the mods mentioned above applied to it. If I look at the resulting xparameters.h

Then I see the expected result:

/* Definitions for Fabric interrupts connected to ps7_scugic_0 */
#define XPAR_FABRIC_TIMERS_FIT_TIMER_1HZ_INTERRUPT_INTR 61U
#define XPAR_FABRIC_TIMERS_FIT_TIMER_2HZ_INTERRUPT_INTR 62U
#define XPAR_FABRIC_TIMERS_FIT_TIMER_5HZ_INTERRUPT_INTR 63U
#define XPAR_FABRIC_TIMERS_FIT_TIMER_10HZ_INTERRUPT_INTR 64U
#define XPAR_FABRIC_TIMERS_FIT_TIMER_20HZ_INTERRUPT_INTR 65U
#define XPAR_FABRIC_TIMERS_FIT_TIMER_50HZ_0_INTERRUPT_INTR 66U
#define XPAR_FABRIC_TIMERS_FIT_TIMER_100HZ_1_INTERRUPT_INTR 67U
#define XPAR_FABRIC_UARTS_ARM0_AXI_UARTLITE_0_INTERRUPT_INTR 68U
#define XPAR_FABRIC_UARTS_ARM0_AXI_UARTLITE_1_INTERRUPT_INTR 84U
#define XPAR_FABRIC_UARTS_ARM0_AXI_UARTLITE_2_INTERRUPT_INTR 85U
#define XPAR_FABRIC_UARTS_ARM0_AXI_UARTLITE_3_INTERRUPT_INTR 86U
#define XPAR_FABRIC_UARTS_ARM0_AXI_UARTLITE_4_INTERRUPT_INTR 87U
#define XPAR_FABRIC_UARTS_ARM0_AXI_UARTLITE_5_INTERRUPT_INTR 88U
#define XPAR_FABRIC_UARTS_ARM0_AXI_UART16550_0_IP2INTC_IRPT_INTR 89U

 

To test, make a local copy of the scugic (this can be copied from your SDK install):

SDK\2018.3\data\embeddedsw\XilinxProcessorIPLib\drivers\scugic_v3_10

Create a file directory as follows:

repo/XilinxProcessorIPLib/drivers and copy the scugic_v3_10 here. Copy the scugic.tcl attached here into the data folder to replace the existing one.

Then in SDK. Go to Xilinx -> Repositories and add the repo folder:

repo.PNG

 

Then if you create the BSP, the xparams should be correct too:

sdk.PNG

 

Note: you might need to create a new project from scratch to pickup changes.

0 Kudos