cancel
Showing results for 
Search instead for 
Did you mean: 
Highlighted
Scholar
Scholar
2,653 Views
Registered: ‎06-23-2014

Having update issues

Jump to solution

I'm using Vivado 2018.1

 

I built the hello world example fine.  Now I'm trying to expand, and information isn't updating forward, I don't believe.  Specifically:

 

  1. I added a second AXI GPIO to my block diagram in Vivado.  Vivado default named it to "axi_gpio_1".  I configured it to have 32 fixed output bits on channel 1 and 32 fixed input bits on channel 2.  I made those external connections.  I had already moved base_mb_wrapper.vhd down a layer and created my own Top.sv to invoke it.  So now, with the new gpio bits, in my Top.sv I assigned the 32 input bits going back to the block diagram to equal the 32 output bits coming out.  That is, I looped this axi_gpio_1 bits back into itself.
  2. I clicked Auto Assign Address in the Address Editor tab, and my new axi_gpio_1 shows up at address 0x4001_0000, the original axi_gpio_0 having been at 0x4000_0000.  I also clicked on Generate Block Design and Generate Bitstream.  After successful bitstream generation, I selected File / Export / Export Hardware.  Having done this a few times already, I also existed the SDK and then from Vivado did File / Launch SDK.
  3. Over in the SDK, I don't think it knows about my axi_gpio_1.  While a previous XGpio_Initialize(*,0) worked for axi_gpio_0, a cloned XGpio_Initialize(*,1)  returns a failure code of 2.  Also, a previous XGpio_LookupConfig(0) gave good info, while a cloned XGpio_LookupConfig(1) returns a null pointer.  So the SDK definitely is NOT aware of the new gpio.
  4. Meanwhile, I notice the folder ...\HelloWorld_bsp\microblaze_0\include contains a number of .h files.  They're all dated yesterday when I first created this project.  Should they have been updated today when I added the second gpio?  I ask because I have found xparameters.h contains the following:
    /* Definitions for driver GPIO */
    #define XPAR_XGPIO_NUM_INSTANCES 1
    
    /* Definitions for peripheral AXI_GPIO_0 */
    #define XPAR_AXI_GPIO_0_BASEADDR 0x40000000
    #define XPAR_AXI_GPIO_0_HIGHADDR 0x4000FFFF
    #define XPAR_AXI_GPIO_0_DEVICE_ID 0
    #define XPAR_AXI_GPIO_0_INTERRUPT_PRESENT 0
    #define XPAR_AXI_GPIO_0_IS_DUAL 0
    which seems to not know about my second gpio.  It ought to have *2* instances plus definitions for AXI_GPIO_1.

I did the hardware export from Vivado.  Should that have updated xparameters.h?  Something's wrong here...

 

[EDIT: I found I had 3 hardware platforms in the project explorer, partially due to my pushing the block diagram down a level and adding a new top.  I looked at them.  I deleted all but the one corresponding to my current top in Vivado.  THen I found system.mss in HelloWorld_bsp.  I clicked the Re-generate BSP Sources button.  This created a newly dated xparameters.h.  HOWEVER, it still only refers to a single gpio, and debugging my code the second gpio access continues to fail.  So now it seems that there's something missing when the new xparameters.h or other stuff is generated.]

 

[EDIT: After much ado it's better.  I created a second Application Project within the same SDK folder, copied source code contents, deleted the original HelloWorld project.  Now this new application project has an xparameters.h that recognizes both AXI_GPIO_0 and AXI_GPIO_1, and that both are dual.  Simply Re-generating BSP Sources button wasn't enough to really get the xparameters.h up to date.  If I have this trouble again after growing my block diagram even further, it's going to become a problem...]

0 Kudos
1 Solution

Accepted Solutions
Highlighted
Observer
Observer
3,265 Views
Registered: ‎09-10-2016

Re: Having update issues

Jump to solution

Hi @helmutforren,

What u see is normal behavior of SDK and how .mss file updates it self,

when u first create BSP it will look up hardware file and finds out what exists out there, but when u update ur HW without making a new BSP(or proper change in .mss file) the BSP only looks for changes in peripherals that it is aware of(Those which were previously existed in its list(i.e. .mss file)), this approach also shows up when u migrate from one sdk version to another, then if new sdk does'nt now the driver or library version defined in old .mss SDk simply wont build,

This is the behavior right now, and if u want to work with SDK this is what u should know about ur environment, but whether this is the best approach or it can be changed is up to Xillinx guys,

Regards,

Hessam

View solution in original post

10 Replies
Highlighted
Observer
Observer
3,266 Views
Registered: ‎09-10-2016

Re: Having update issues

Jump to solution

Hi @helmutforren,

What u see is normal behavior of SDK and how .mss file updates it self,

when u first create BSP it will look up hardware file and finds out what exists out there, but when u update ur HW without making a new BSP(or proper change in .mss file) the BSP only looks for changes in peripherals that it is aware of(Those which were previously existed in its list(i.e. .mss file)), this approach also shows up when u migrate from one sdk version to another, then if new sdk does'nt now the driver or library version defined in old .mss SDk simply wont build,

This is the behavior right now, and if u want to work with SDK this is what u should know about ur environment, but whether this is the best approach or it can be changed is up to Xillinx guys,

Regards,

Hessam

View solution in original post

Highlighted
Scholar
Scholar
2,601 Views
Registered: ‎06-23-2014

Re: Having update issues

Jump to solution

Thanks @hessam2013 for letting me know this.

 

With this now known, is there a best way to deal with it?  That is, it did NOT seem that simply clicking on Re-generating BSP  Sources was always enough.  There was also the automatic reconcile message that I got.  I'm sorry I don't recall the exact language.  Once when I got it, not much happened.  Another time when I got it, a lot happened as it successfully rebuilt everything.  Perhaps what I need to do is just watch all this very closely and make sure that it *always* does a lot, for either the automatic or the Regenerate SBP Source button.  If ever it does *not* do a lot, yet I know I changed something notable in the Vivado block diagram, then I will immediately know it is out of sync again and needs dedicated attention.

0 Kudos
Highlighted
Scholar
Scholar
2,595 Views
Registered: ‎06-23-2014

Re: Having update issues

Jump to solution

So, indeed, it has already gotten itself out of sync again, and I need better understanding to get it back in sync.

 

PREVIOUSLY, in the SDK, the Project Explorer showed my firmware project "MYF", as well as "MYF_bsp" and "MYF_Top_hw_platform_0".  All was good.

 

THEN over in the Vivado I modified the block diagram to include an additional external output.  I built the bitstream and exported the hardware.

 

NOW, in the SDK, the Project Explorer shows an additional "MYF_Top_hw_platform_1".  Note how this ends in a "1" rather than a "0".  However, when I double click on the MYF_bsp/system.mss I get a summary that says the "Hardware Specification: ...MYF.sdk\MYF_Top_hw_platform_0\system.hdf".  This tells me that MYF_bsp is still referring to the old platform 0 and not the new platform 1.  I need to update this to platform 1.  Furthermore, if I were to click on the toolbar Program FPGA button, it defaults to platform 0, which I hope will default to platform 1 after I modify the MYF_bsp to refer to it. [EDIT: Note that the MYF_Top_hw_platform_0\MYF_Top.bit is dated yesterday, while MYF_Top_hw_platform_1\MYF_Top.bit is dated a few minutes ago.  This informs me of which is which.] [EDIT: Note that the MYF itself in Project Explorer, when I right click and select properties, shows Project References that include checkboxes for MYF_bsp and MYF_Top_hw_platform_0.  I tried manually changing this to platform 1.  I closed and reopened MYF_bsp\system.mss, but it didn't change its Hardware Specification to platform 1.  I didn't expect this to work.  I need to somehow modify properties of MYF_bsp...]

 

I don't find anything about this in the doc I have.  I don't find easily where to change this association between MYF_bsp and the hardware platform.  When I click on Modify this BSP's Settings, I see no place to set this, while I do see it being referenced.

 

I read elsewhere about having to create a new project.  But if I'm progressively growing my block diagram, that would mean I have to recreate this project over and over and over again, which is too painful.  I am hoping there is a GUI or else under the covers way to update MYF_bsp to refer to the correct platform...

 

[EDIT: In the folder MYF\MYF.sdk\MYF_bsp is a file ".sdkproject" with only 4 lines and that refers to platform 0.  I closed system.mss in the SDK, then edited .sdkproject.  When I reopened system.mss, it now said Hardware Specification was platform 1.  So I believe this is the under-the-covers place that needs changing.  Now re-generate BSP Source ran, and hopefully did it correctly.  My changes in block diagram weren't big enough [yet] to see for sure.  Meanwhile, over in MYF properties, the checkboxes also needed to be changed to platform 1.  I did a clean just in case, and it automatically rebuilt.  Program FPGA now defaulted to platform 1, as expected.  Soon I'll go make a bigger change, like add a third AXI GPIO.  Then I'll know for certain if this under-the-covers method works.  (To summarize, I edited .sdkproject and changed checkboxes for the C folder (MYF) in the Project Explorer.)]

 

[EDIT: I added a third GPIO in Vivado.  After generate bitstream and export hardware, I returned to existing running SDK.  It noticed the change and tried to catch up.  Note that this time it did NOT create a new platform, which would have been 2, having followed 0 and 1.  Also, the MYF_bsp/microblaze_0/include/xparameters.h was already updated to 3 GPIOs.  So I didn't have to run Re-generate BSP Sources.  This thing might be a little inconsistent because it's not really designed for this kind of use, where I change the hardware frequently in Vivado and expect the SDK to deal with it appropriately.  Note to self:  The third AXI GPIO along with additional (Master) port of AXI Connect cost 132 LUTs and 416 FFs.  Something I need to know to make later organizational decisions.]

0 Kudos
Highlighted
Observer
Observer
2,528 Views
Registered: ‎09-10-2016

Re: Having update issues

Jump to solution

Hi @helmutforren

I'm going to elaborate some of the experiments you had, how ever i should say i did not correctly understand what you have written

You can export hardware platform in 2 ways, the first one is to hit launch sdk button in vivado, This is good if it is the first time u want to export and make a sdk, but doing this when sdk is built just makes u end up with several hw_platforms projects all ending with 0,1,2 and so on(if u see tcl console launch sdk does more than opening sdk, it does create a hw platform project for u each time). The second way is that u just hit export and dont launch sdk from vivado, but rather open it manually, this way your existing hw will be updated(from experience best practice is to have sdk open when u export hardware so u can see the hw changes)

These two experiment are what u have mentioned in ur writing, so no magic should be there,

If I was at ur position what i do is simply taking the second approach and leave sdk to handle all other things, so next time u change ur hardware first open the sdk and then just export the hw and let sdk detect changes, then it will update it self and must reflect all ur changes in ur new design, (it wont do it if u launch sdk from vivado), 

At last always have in mind that sdk will at least once in while will leave u surprised about what is happening, from bsp not being referenced correctly or bsp not being updated, getting familiar with .mss file and 2 .*project files in main project folder will help u solve these problems faster

Regards,

Hessam

 

 

 

 

0 Kudos
Highlighted
Observer
Observer
2,553 Views
Registered: ‎09-10-2016

Re: Having update issues

Jump to solution

Hi @helmutforren

I'm going to elaborate some of the experiments you had, how ever i should say i did not correctly understand what you have written

You can export hardware platform in 2 ways, the first one is to hit launch sdk button in vivado, This is good if it is the first time u want to export and make a sdk, but doing this when sdk is built just makes u end up with several hw_platforms projects all ending with 0,1,2 and so on(if u see tcl console launch sdk does more than opening sdk, it does create a hw platform project for u each time). The second way is that u just hit export and dont launch sdk from vivado, but rather open it manually, this way your existing hw will be updated(from experience best practice is to have sdk open when u export hardware so u can see the hw changes)

These two experiment are what u have mentioned in ur writing, so no magic should be there,

If I was at ur position what i do is simply taking the second approach and leave sdk to handle all other things, so next time u change ur hardware first open the sdk and then just export the hw and let sdk detect changes, then it will update it self and must reflect all ur changes in ur new design, (it wont do it if u launch sdk from vivado), 

At last always have in mind that sdk will at least once in while will leave u surprised about what is happening, from bsp not being referenced correctly or bsp not being updated, getting familiar with .mss file and 2 .*project files in main project folder will help u solve these problems faster

Regards,

Hessam

 

 

 

 

0 Kudos
Highlighted
Scholar
Scholar
2,540 Views
Registered: ‎06-23-2014

Re: Having update issues

Jump to solution

@hessam2013 Thanks for this info.  Please let me slowly parse what you are saying...

 

"but doing this when sdk is built just makes u end up with several hw_platforms projects all ending with 0,1,2 and so on".  Yes, that must be how I got the second hw_platform.  I didn't understand WHY you said that.  I always do (1) Build bitstream in Vivado, (2) Export Hardware.  The first time, of course, I did (3) Launch SDK, but after that the SDK is normally already running.  Sometimes I'll close the SDK on purpose and do the Launch SDK again.  So WHICH of these steps is creating the extra hw_platform, and therefore the step I need to avoid?  If it's doing "Launch SDK", when how am I supposed to get back into the correct project's SDK if I ever exit the SDK, such as after a reboot (maybe Windows 10 update)?  Are you saying that "Launch SDK" will ***always*** create a new hw_platform?

 

"The second way is that u just hit export and dont launch sdk from vivado, but rather open it manually" probably answers above.  How do I open SDK manually?  Can I click on a project file like I can do for an .xpr to open Vivado?  When I run SDK from the Windows [menu], it asks for a workspace but later does NOT have an open recent projects.  Ha ha.  Now my SDK is closed and I can't figure out how to open it on the correct project without doing Launch SDK from Vivado.  I search the Vivado project folder and the MyF.sdk folder below that, and I don't see a file with a special icon that implies opening it will open the SDK.  HOW?  Please answer soon! Thanks.

 

"getting familiar with .mss file and 2 .*project files in main project folder will help u solve these problems faster".  **this** I am good at, looking under the covers to see what is happening.  I actually find 5 different .project files, one for each project, I guess, in the Project Explorer of the SDK.  I can't look right now to confirm because I don't know how to safely run it!  Anyway, I see that

  1. MyF\.project mentions MyF_bsp and MyF_Top_hw_platform_0.  But I thought I was on platform 1.  I will keep an eye out. 
  2. Meanwhile MyF_bsp\.project looks like mostly static info.  
  3. MyF_Top_hw_platform_0\.project also looks like mostly static stuff, except for a filter id 1526934014060 that I don't know if it's static or not.  Probably is.  There are three of these in there.  I probably don't care.
  4. ZC702_hw_platofrm\.project, well this folder doesn't belong somehow.  I'm using KC705.  Maybe it's vestigial from something.
  5. RemoteSystemsTempFiles\.project ... who cares, not much.

Then for .mss files, there's only one in MyF.sdk\MyF_bsp\system.mss.  I've looked at this one before.  It outlines the IP Integrator placed modules.  But if that's wrong, I know I can't manually fix, because there also have to be a bunch of .h file with special content.

 

So, actually, I don't think I'll go manually changing .project or .mss.

 

The clue about NOT using Launch SDK is a good take home.  But now how do I get the SDK running again on my project?  Is there an easy click way?  I think I might need to pick the correct workspace up front.  The original from Launch SDK is NOT in the recent workspace list.

 

 

 

 

0 Kudos
Highlighted
Scholar
Scholar
2,535 Views
Registered: ‎06-23-2014

Re: Having update issues

Jump to solution

I was wondering if the MyF\MyF.sdk was the workspace folder that SDK via eclipse wanted to use, but I wasn't sure.  After reading the post at https://forums.xilinx.com/t5/Embedded-Development-Tools/How-do-I-launch-SDK/td-p/803389 I find that it is.

 

Remember, when I ran SDK before, the Recent Workspaces was EMPTY or a user default.  My prior Vivado Launch SDK did *not* insert an entry into Recent Workspaces.  Therefore I was uncertain.  So I ran the SDK by hand again, and provided it with my MyF\MyF.sdk folder name as the workspace.  It seems to have come up correctly.  Also, subsequent manual loads now remember that one.  So now I know how to do it.  And when I change to a whole other project, I'll do one Vivado Launch SDK.  Then later I'll load SDK by hand.  When I get asked for workspace, I may or may not remember the first time.  But the next time I will, and the nature of the default presented will clue me in as to how to select the correct new one.

 

HEY XILINX: It would be nice if Vivado Launch SDK would punch whatever necessary so that the next manually load of SDK will know the recent workspace from that launch, both suggesting it as default as well as showing it in the Recent Workspaces.  It does not right now.

0 Kudos
Highlighted
Scholar
Scholar
2,459 Views
Registered: ‎06-23-2014

Re: Having update issues

Jump to solution

@hessam2013 or others, I'm still having trouble with this.  Can you please help me get past this specific problem I'm having now...

 

Please see red WARNING at end first, this may be key.  Is the hardware export doing nothing?  What's up?

 

  1. I manually loaded the SDK on the correct workspace at MyF\MyF.sdk
  2. I loaded Vivado 2018.1 on the project at MyF\MyF.xpr.
    1. I made changes to the block design, including among other things a manual change to the Offset Address for axi_gpio_0 from 0x40000000 to 0x42000000.
    2. I Generated Bitstream
    3. I did File / Export / Export Hardware (with include bitstream) and chose Yes to override the exiting export file
  3. Note that the SDK was still running during all of the above
    1. However, after the Export Hardware, the SDK didn't react.  I believe in the past it has automagically detected a change.  It didn't detect a change.  So now I'm trying to force the SDK to handle the change.
    2. I'm able to test if the SDK has handled things properly by looking at Project Explorer / MyF_BSP / microblaze_0 / include / xparameters.h.  This file has a line in it like "#define XPAR_AXI_GPIO_0_BASEADDR 0x40000000".  Because it's not 0x42000000 I know that things ARE NOT CORRECT.
    3. I double click on Project Explorer / MyF_BSP / system.mss in order to open system.mss, and then click on "Re-generate BSP sources".  Indeed the time/date stamp on xparameters.h gets changed, so I know the file was recreated.  However, the content still has the wrong address for axi_gpio_0.  Therefore I'm still missing something in the "path" of the information from Vivado to SDK.
    4. WARNING: Well, I am now searching the whole MyF folder for the effect of Vivado / File / Export / Export Hardware.  Using Windows 10 file explorer, I search for "date:today".  No files are changed after 10:10am.  I run the export at 10:17am.  I refresh the search, nothing changed after 10:10am.  Huh?  I told the export to overwrite.  But no file timestamps changed?
0 Kudos
Highlighted
Scholar
Scholar
2,452 Views
Registered: ‎06-23-2014

Re: Having update issues

Jump to solution

I am now providing some info that helps with my parallel post at https://forums.xilinx.com/t5/Embedded-Development-Tools/Having-update-issues/m-p/859412/highlight/false#M45623 about using JTAG UART.

 

I continue to have problems keeping in sync.  I change my block diagram in Vivado, generate a bitstream, and export hardware.  Even though the SDK was already manually loaded and running, it does NOT automagically notice a change and update.  I tried and tried and tried, and couldn't get things sync'd up.


Finally, I gave up on trying to keep it clean.  I exited the SDK and then from Vivado did a Launch SDK.  This launched the SDK, but also had the unwanted side effect of creating YET ANOTHER hw_platform in the SDK Project Explorer tab.  I had to just go with it and let that happen. (In my case, I now have three, count 'em, three hw_platforms, numbered 0, 1, and 2.)

 

Unfortunately, the board support package STILL DID NOT update.  So I selected main menu File / New / Board Support Package. This created yet another bsp.  (In my case, I now have two, count 'em, two bsp's, named MyF_bsp and MyF_bsp_2.  I have the new one the _2 suffix to match the hw_platform_2.  Be sure to select the latest hw_platform when making the new bsp.)


So now I have two bsp's and three hw_platform's, and the C project doesn't point to either correct one!  The top folder icon in the Project Explorer is the C project folder.  Right click on it and select Properties.  Next, select "Project References".  You'll see a list of bsp's and hw_platforms.  Uncheck the wrong ones and check the right ones.  (I don't have RemoteSystemsTempFiles checked. Only one bsp and one hw_platform.)


It may have recomplied, but if not just twiddle your source or otherwise cause a recompile.

 

Viola.  953 easy steps to get it sync'd again... not so easy.

0 Kudos
Highlighted
Scholar
Scholar
1,769 Views
Registered: ‎06-23-2014

Re: Having update issues

Jump to solution

Yet more...

 

MAYBE the case is this.  The running SDK will only detect changes if it's somehow connected to the running Vivado.  If the SDK is loaded from Vivado via Launch SDK, it gets so connected.  The first time, a new hw_platform is unfortunately created.  Subsequently, though, a new export hardware from Vivado triggers SDK to notice it changed.

 

Contrast this with loading the SDK manually in order to avoid the new hw_platform.  Doing this, it seems that the SDK is *not* connected to Vivado.  So a new export hardware from Vivado does *not* trigger SDK to notice it changed.  Darn.

 

So one must have Vivado and SDK running FOREVER in order for things to stay sync'd.  But if, for example, Windows 10 reboots your computer overnight due to an windows update, you're hosed.  You must reload Vivado, and then either suffer having an extra hw_platform made in order to automatically stay sync'd, or manually load SDK and have a hard time keeping sync'd.

 

ARGH!

0 Kudos