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?
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.
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.
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.
AXI LITE custom IP core
xparameters.h BASEADDR for this one core is 0xFFFFFFFF. All other cores assigned correctly
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 ;-)
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?
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?
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.
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?