cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
Highlighted
Observer
Observer
301 Views
Registered: ‎03-17-2020

VITIS v2020.1.0 hello world application (standalone, microblaze, custom board)

Jump to solution

I have defined a custom board with peripherals, and can do standalone application development quite well in Vivado 2020, and also VITIS 2020. I was thinking all was well and moved onto complicated projects, and then found that for some reason, on my current project, Vitis imported the platform .XSA file and then created folders automatically, and not where they are supposed to be. So, for this brand new project (it is a new block design, with GPIO, UART, SPI axi modules) I cannot even compile the Hello World application. Sounds so simple, but it is annoying. Here are some details, and I am requesting help on why this happened, and it is a bug or a feature?

I first noticed the problem in the console output:

 

13:17:45 **** Build of configuration Debug for project a_oledrgb1 ****
make all 
'Building file: ../src/helloworld.c'
'Invoking: MicroBlaze gcc compiler'
mb-gcc -Wall -O0 -g3 -c -fmessage-length=0 -MT"src/helloworld.o" -IC:/Users/Eva/ttllc_xilinx_projects/vitis/v_oledrgb1/p_oledrgb1/export/p_oledrgb1/sw/p_oledrgb1/standalone_domain/bspinclude/include -mno-xl-reorder -mlittle-endian -mxl-barrel-shift -mxl-pattern-compare -mcpu=v11.0 -mno-xl-soft-mul -Wl,--no-relax -ffunction-sections -fdata-sections -MMD -MP -MF"src/helloworld.d" -MT"src/helloworld.o" -o "src/helloworld.o" "../src/helloworld.c"
../src/helloworld.c:50:10: fatal error: xil_printf.h: No such file or directory
   50 | #include "xil_printf.h"
      |          ^~~~~~~~~~~~~~
compilation terminated.
'Finished building: ../src/helloworld.c'
' '
'Building file: ../src/platform.c'
'Invoking: MicroBlaze gcc compiler'
mb-gcc -Wall -O0 -g3 -c -fmessage-length=0 -MT"src/platform.o" -IC:/Users/Eva/ttllc_xilinx_projects/vitis/v_oledrgb1/p_oledrgb1/export/p_oledrgb1/sw/p_oledrgb1/standalone_domain/bspinclude/include -mno-xl-reorder -mlittle-endian -mxl-barrel-shift -mxl-pattern-compare -mcpu=v11.0 -mno-xl-soft-mul -Wl,--no-relax -ffunction-sections -fdata-sections -MMD -MP -MF"src/platform.d" -MT"src/platform.o" -o "src/platform.o" "../src/platform.c"
../src/platform.c:33:10: fatal error: xparameters.h: No such file or directory
   33 | #include "xparameters.h"
      |          ^~~~~~~~~~~~~~~

The files are actually where they are supposed to be, and prior to this, on other applications (similar block diagrams) I can compile quite well. 

 

Then I noticed in the VITIS Log

 

13:17:45 ERROR	: Failed to openhw "C:/Users/Eva/ttllc_xilinx_projects/vitis/v_oledrgb1/p_oledrgb1/export/p_oledrgb1/hw/oledrgb1_wrapper.xsa"
Reason: ERROR: [Common 17-39] 'hsi::open_hw_design' failed due to earlier errors.

13:17:45 ERROR	: Failed to update application flags from BSP for 'a_oledrgb1'. Reason: null
java.lang.NullPointerException
	at com.xilinx.sdx.sw.internal.SDxSwPlatform.<init>(SDxSwPlatform.java:302)
	at com.xilinx.sdx.sw.internal.SDxSwPlatform.create(SDxSwPlatform.java:211)
	at com.xilinx.sdx.sdk.core.util.SdkPlatformHelper.getSwPlatform(SdkPlatformHelper.java:60)
	at com.xilinx.sdx.sdk.core.build.SdkMakefileGenerationListener.getSwPlatform(SdkMakefileGenerationListener.java:160)
	at com.xilinx.sdx.sdk.core.build.SdkMakefileGenerationListener.syncAppFlags(SdkMakefileGenerationListener.java:78)
	at com.xilinx.sdx.sdk.core.build.SdkMakefileGenerationListener.preMakefileGeneration(SdkMakefileGenerationListener.java:48)
	at com.xilinx.sdk.managedbuilder.XilinxGnuMakefileGenerator.notifyPreMakefileGenerationListeners(XilinxGnuMakefileGenerator.java:91)
	at com.xilinx.sdk.managedbuilder.XilinxGnuMakefileGenerator.regenerateMakefiles(XilinxGnuMakefileGenerator.java:75)
	at org.eclipse.cdt.managedbuilder.internal.core.CommonBuilder.performMakefileGeneration(CommonBuilder.java:1006)

Then I went to the local hard drive to search for the .xsa file:

C:\Users\Eva\ttllc_xilinx_projects\vitis\v_oledrgb1\p_oledrgb1\hw>dir
 Volume in drive C is Windows
 Volume Serial Number is 3AA0-A21B

 Directory of C:\Users\Eva\ttllc_xilinx_projects\vitis\v_oledrgb1\p_oledrgb1\hw

06/15/2020  01:11 PM    <DIR>          .
06/15/2020  01:11 PM    <DIR>          ..
06/15/2020  01:11 PM    <DIR>          board
06/15/2020  01:11 PM    <DIR>          drivers
06/15/2020  01:16 PM           538,956 oledrgb1_wrapper.bit
06/15/2020  01:16 PM             1,657 oledrgb1_wrapper.mmi
06/15/2020  01:04 PM           323,922 oledrgb1_wrapper.xsa

So, per the full directory tree shown below the HW subdirectory was placed in the wrong location, or depending upon the developers, in the right location (WHICH ONE) and the code is looking in the wrong location. Which one?

C:\Users\Eva>cd C:\Users\Eva\ttllc_xilinx_projects\vitis\v_oledrgb1\p_oledrgb1\hw

C:\Users\Eva\ttllc_xilinx_projects\vitis\v_oledrgb1\p_oledrgb1\hw>tree
Folder PATH listing for volume Windows
Volume serial number is 3AA0-A21B
C:.
├───board
│   └───spartanedgeacceleratorboard1v0
└───drivers
    └───PmodACL2_v1_0
        ├───data
        ├───examples
        └───src

C:\Users\Eva\ttllc_xilinx_projects\vitis\v_oledrgb1\p_oledrgb1\hw>cd ..

C:\Users\Eva\ttllc_xilinx_projects\vitis\v_oledrgb1\p_oledrgb1>tree
Folder PATH listing for volume Windows
Volume serial number is 3AA0-A21B
C:.
├───.log
├───bitstream
├───export
│   └───p_oledrgb1
│       └───sw
│           └───p_oledrgb1
│               ├───boot
│               └───standalone_domain
├───hw
│   ├───board
│   │   └───spartanedgeacceleratorboard1v0
│   └───drivers
│       └───PmodACL2_v1_0
│           ├───data
│           ├───examples
│           └───src
├───logs
├───microblaze_0
│   └───standalone_domain
│       └───bsp
│           └───microblaze_0
│               ├───code
│               ├───include
│               ├───lib
│               └───libsrc
│                   ├───bram_v4_4
│                   │   └───src
│                   ├───cpu_v2_11
│                   │   └───src
│                   ├───gpio_v4_6
│                   │   └───src
│                   ├───intc_v3_11
│                   │   └───src
│                   ├───PmodACL2_v1_0
│                   │   └───src
│                   ├───standalone_v7_2
│                   │   └───src
│                   │       ├───arm
│                   │       │   ├───ARMv8
│                   │       │   │   ├───32bit
│                   │       │   │   │   ├───gcc
│                   │       │   │   │   └───platform
│                   │       │   │   │       ├───versal
│                   │       │   │   │       └───ZynqMP
│                   │       │   │   ├───64bit
│                   │       │   │   │   ├───armclang
│                   │       │   │   │   ├───gcc
│                   │       │   │   │   ├───platform
│                   │       │   │   │   │   ├───versal
│                   │       │   │   │   │   │   ├───armclang
│                   │       │   │   │   │   │   └───gcc
│                   │       │   │   │   │   └───ZynqMP
│                   │       │   │   │   │       ├───armclang
│                   │       │   │   │   │       └───gcc
│                   │       │   │   │   └───xpvxenconsole
│                   │       │   │   └───includes_ps
│                   │       │   │       └───platform
│                   │       │   │           ├───Versal
│                   │       │   │           └───ZynqMP
│                   │       │   ├───common
│                   │       │   │   ├───gcc
│                   │       │   │   └───iccarm
│                   │       │   ├───cortexa9
│                   │       │   │   ├───armcc
│                   │       │   │   ├───gcc
│                   │       │   │   └───iccarm
│                   │       │   └───cortexr5
│                   │       │       ├───gcc
│                   │       │       ├───iccarm
│                   │       │       └───platform
│                   │       │           ├───versal
│                   │       │           └───ZynqMP
│                   │       ├───clocking
│                   │       ├───common
│                   │       │   └───clocking
│                   │       ├───microblaze
│                   │       └───profile
│                   └───uartlite_v3_4
│                       └───src
└───resources

So, I tried  a simple copy of the "hw" sub-directory into the folder at the same level as "sw", but now I still see the include directories are unable to be found - where did the Include directory definition get messed up? Also, the "hw" directory that I just copied vanishes, so perhaps that is not the right place to put it. But I had to try!

 

Invalid project path: Include path not found (C:\Users\Eva\ttllc_xilinx_projects\vitis\v_oledrgb1\p_oledrgb1\export\p_oledrgb1\sw\p_oledrgb1\standalone_domain\bspinclude\include).

Any suggestions, from Xilinx  - thanks! 

 

0 Kudos
1 Solution

Accepted Solutions
Highlighted
Observer
Observer
142 Views
Registered: ‎03-17-2020

Hi, I'm not sure if XILINX forum is posting replies correctly: I got an e-mail note with a reply (text) on this topic, but it doesn't show up in the board responses yet. Anyway I was able to complete the development milestone. Some issues that others should be aware of:

There at least four very minor bugs in the PMOD OLEDrgb driver codeset available in the repository for 2020.1 from Digilent. If interested, contact me, but they are quite easy to fix (data type mismatch, missing cast, unused variable) which stops the compilation process due to the use of different compiler flags. Without the code fixes, the driver doesn't compile, hence the BSP (Microblaze, 32KB, UART, GPIO, SPI, AXI Lite, PMOD OLEDrgb) can't be compiled, and the rest cannot proceed which was the resason for the problems outlined above. That is: it's not XILINX issue, but Digilent's developer's issues. But fixable. 

Also, there is a line in the driver Makefile that has to be modified, for the driver libraries to be compiled and the library generated. Once I had taken care of that, I found out that the FPGA development board I used did not have an active 3V3 (or 5V) external pin available for powering the module, so I had to use an external power supply. I also used a non-XILINX, non-Digilent development board, so I had to (during synthesis/impl) assign different pins - and it all worked | though I used an external logic analyzer to see the SPI bus and GPIO bus activity. (I should try out XILINX ILA). 

Then I  experimented to find the required Vertical/Horizontal sizes to fill the OLEDrgb module screen: it's 96Hx64V and not 96Vx64H, 24-bit color, requiring use of a python script to convert .BMP files to the hex code array required for the example code. So GIMP and PAINT came in handy to generate the required small size image source. 

I also just noticed in the original post, I used a different PMOD module (not OLEDrgb) but more or less the same issues should pop up. 

 

View solution in original post

Tags (1)
0 Kudos
2 Replies
Highlighted
Observer
Observer
290 Views
Registered: ‎03-17-2020

Community, I went back to Vivado and think the problem started when I used Digilent PMOD IP, from the Digilent Vivado 2019.x library which was indicated to me in the synthesis process was built for a different board. I thought the synthesis /implementation project was going to take care of "porting" to a new board, but now I opened up the IP and found. If this is indeed the case, then the toolchain should have not allowed me to proceed all the way (Synthesis > Implementation > Bitstream Generation > Export > Vitis > etc. and prevented me from using it on a different board. I guess if this is the case, I will have to use a standard SPI IP from XILINX to talk to a PMOD peripheral. The "board specific outputs" seems to be ominous warning. 

 

* IP definition 'AXI GPIO (2.0)' for IP 'PmodACL2_axi_gpio_0_0' (customized with software release 2017.4) has a different revision in the IP Catalog. * This IP has board specific outputs. Current project board 'seeedstudio.com:spartanedgeacceleratorboard1v0:part0:2.41' and the board 'digilentinc.com:arty:part0:1.1' used to customize the IP 'PmodACL2_axi_gpio_0_0' do not match. * Current project part 'xc7s15ftgb196-1' and the part 'xc7a35ticsg324-1L' used to customize the IP 'PmodACL2_axi_gpio_0_0' do not match. 
0 Kudos
Highlighted
Observer
Observer
143 Views
Registered: ‎03-17-2020

Hi, I'm not sure if XILINX forum is posting replies correctly: I got an e-mail note with a reply (text) on this topic, but it doesn't show up in the board responses yet. Anyway I was able to complete the development milestone. Some issues that others should be aware of:

There at least four very minor bugs in the PMOD OLEDrgb driver codeset available in the repository for 2020.1 from Digilent. If interested, contact me, but they are quite easy to fix (data type mismatch, missing cast, unused variable) which stops the compilation process due to the use of different compiler flags. Without the code fixes, the driver doesn't compile, hence the BSP (Microblaze, 32KB, UART, GPIO, SPI, AXI Lite, PMOD OLEDrgb) can't be compiled, and the rest cannot proceed which was the resason for the problems outlined above. That is: it's not XILINX issue, but Digilent's developer's issues. But fixable. 

Also, there is a line in the driver Makefile that has to be modified, for the driver libraries to be compiled and the library generated. Once I had taken care of that, I found out that the FPGA development board I used did not have an active 3V3 (or 5V) external pin available for powering the module, so I had to use an external power supply. I also used a non-XILINX, non-Digilent development board, so I had to (during synthesis/impl) assign different pins - and it all worked | though I used an external logic analyzer to see the SPI bus and GPIO bus activity. (I should try out XILINX ILA). 

Then I  experimented to find the required Vertical/Horizontal sizes to fill the OLEDrgb module screen: it's 96Hx64V and not 96Vx64H, 24-bit color, requiring use of a python script to convert .BMP files to the hex code array required for the example code. So GIMP and PAINT came in handy to generate the required small size image source. 

I also just noticed in the original post, I used a different PMOD module (not OLEDrgb) but more or less the same issues should pop up. 

 

View solution in original post

Tags (1)
0 Kudos