• Content Count

  • Joined

  • Last visited

Everything posted by BYTEMAN

  1. You're welcome! Don't know but may be interesting reading also this thread: How to store SDK project in SPI flash (bootloader with Microblaze) I've spent some time to figure out how keep this working, would be nice know the experiences from others to see if the results are similar or there are others think fo take in consideration. Bye
  2. Hi, I'm same trouble in my design with VIVADO 2017.4, following your last suggest I can see into the terminal only a first row and then nothing about the rest of the messages from the bootloader. But if I run into the Xilinx System Debugger I can see all the booting messages and the system is able to work properly. Do you have some advice? I'll be gratefully for any help on this subject. Thanks., UPDATE To be sure about the steps I've did again all the steps with VIVADO 2016.1 design and all is working properly, the bootstrap process run fine hence seems somethings related to the VIVADO 2017.4. Also may be due to the importing from the 2016.1 but this seems strange to me because into VIVADO 2017.4 the simulation (GDB and Xilinx System Debugger) run fine without any trouble and also If I try the System Debugger I'll able to see the boostrap process with whole messages... UPDATE Hi again, under the suspect that there are some things related the import task from VIVADO 2016.1 to the VIVADO 2017.4 I've completely delete the content of the .sdk folder that is into the main design folder. Then, from VIVADO I've exported the hardware with bistream included and then I've launched the SDK. The SDK is empty, so I've rebuild all things following the tutorial starting from the creation of the SPI Bootloader Application and so on, at the end of the process all things was able to work then if anyone got same problem my suggestion is to delete all the contents inside the .sdk folder and performs again starting from scratch all the tutorial steps. Debugging with the DBG and the System Debugger are corrects but I'm unable to booot from the SPi Flash, when the USB cable was unplugged and then inserted again into the terminal I can see only the first line of the bootloder "SREC SPI Bootloader", and then no activity on the serial as the process is blocked. UPDATE I've rebuilded from scratch the whole design inside VIVADO 2017.4.1 but at the end of the story the result is the same, the SPI storing is not working anymore... UPDATE - WORKING BOOTLOADER!! STEP 1 I've rebuilded again from zero the whole design into VIVADO 2017.4.1 but now I've followed carefully all the steps listed inside the tuturial: "Cmod A7 - Getting Started with Microblaze" (LINK) on the web site there is a indication that is obsolete but for me have solved every issue. In my flow I've only two differences regarding what is shown into the tutorial: one is about the Microblaze configuration (see below, I've followed the values listed in this thread from @jpeyron and changed the default ones) and the QSPI Flash that is added as last pheriperal just after the USB UART (see below). As written above the second difference is that after putting the USB UART, as explained into the step 5.1 of the cited tutorial, you have also to insert into the Block Design the QSPI Flash from the board tab and then perform the Run Automation All task as specified into the tutorial at the step 5.2. Despite this little difference follow the rest of the tutorial until you reach the step 8.1, make the hardware exporting with the bitstream included and stop a moment. It seems to me, from all the tests that I've did, that is more important execute the Run Automation task exactly at the point specified into the tutorial (step 5.2), into my previous design, also started from zero, I've performed this task after putting some IP block, then too soon regarding the flow shown into the tutorial, and this may be have corrupted or changed my final design into a way that the bootloader was not able to work properly but able to work only under debugging. At this point I strongly suggest to perform the archive project action in order to have a fresh copy of the design for future reference before starting the SDK work. After the backup finish make the step 8.2 and then run the SDK, the first part is finished. STEP 2 Now you are into the SDK, wait a little that the workspace is builded from the hardware description that is automatically imported from VIVADO. Now you have basically to follow every steps listed into the following tutorial: "How To Store Your SDK Project in SPI Flash" (LINK) As a side note I've not followed the first step "0. Compress Bitstreams (Optional)" I therefore jumped directly to the next step "1. Create a SPI Bootloader Application". Into the "2. Create User Application" section I've only changed the printf statement with the xil_printf into the helloworld.c source. For the Cmod A7-35T board you have also to skip the step 2.3 (thank @jpeyron). From this point until the end of the tutorial follow all the listed steps, just take care of the right flash type option when you have to perform the Program Flash task, for the Cmod A7-35T select the n25q32-3.3v-spi-x1_x2_x4 memory model. There are exactly the full procedure that I've followed to get all working, the pdf of my design is also attached to this post in order to use it as reference and check if your Block Design schematic looks like mine. I hope this informations will be useful for other people that get trouble to have the bootloader properly working with the Cmod A7-35T. Let me know if somethings is not clear and I'll try to explain it better. Best regards system.pdf
  3. UPDATE FOR THE XILINX SYSTEM DEBUGGER ERROR (VIVADO 2016.1) From XILINX this error appear as a software bugs, I've asked for a patch. Best regards UPDATE - 19/04/2018 The patch tried was not working with the 2016.1 (I'm able to debug only with the GDB) then I've make a test by importing all design into the VIVADO 2017.4 and now I'm able to debug with GDB and also with the Xilinx System Debugger. Best regards
  4. No prob @jpeyron I'll do some test by myself and let you know the results. Thank
  5. Thank you @JColvin, I've did many test with the System Debugger but results is still the same and I'm unable to perform the debugging. With the GDB debugger all is fine and no error arise and I'm able to debug the system. I don't know why isn't possible doing the System Debugger and over the net I've not found any useful info on this specific error "Failed to call get_cpu_nr". Best regards
  6. thank you @JColvin, I've did some test but already get following error: Error while launching program: Failed to call get_cpu_nr Reason: ERROR: [Common 17-55] 'get_property' expects at least one object. Resolution: If [get_<value>] was used to populate the object, check to make sure this command returns at least one valid object. Failed to call get_cpu_nr Reason: ERROR: [Common 17-55] 'get_property' expects at least one object. Resolution: If [get_<value>] was used to populate the object, check to make sure this command returns at least one valid object. Here the sequence of step I've used: Do you have some advice how to solve this issue? Thank Best regards
  7. Hi @jpeyron thank for the feedback do you have also did some test by "heavy" change the C code of the Microblaze in order to see if it is woking also with a compiled bitstream of very different size? Best regards
  8. FIRST WORKING TEST WITH TX INTERRUPT ON UARTLITE (VIVADO 2016.1 - Cmod A7-35T) Waiting for some help on the precedent question, I've made a test starting from the xuartlite_intr_example.c code (not the xuartlite_intr_tapp_example.c code, see my previous post about this point).Here below my full implemented code: I've do some simple change to adapt the code to my case, the change reside in how to manage the interrupt transmission, I've used the TxIsDone flag to know when the transmission was finished and then get another one, in this way I'm sure to start a new transmission just after the old one is completed (see the SendHandler function). Actually the system is working properly into the SDK Debug Mode (GDB), into the RealTerm monitor I can see the transmitted chars: Total transmissione time check Now I can see a CPS equal approximatively to 2000, if this value reflect the Chars Per Seconds sounds to me higher than the correct value should be. For a 9600,8,N,1 setting we have a 10 bit (1 start + 8 data + 1 stop) for every char to be transmitted then a final time equal to 10/9600=1.042 ms. This give theorically 960 character every seconds if we suppose zero delay time between the frame so is a upper theoretical limit. This is a know bug of the Realterm that effectively show twice regarding the correct value so the UART Lite behaviour should be correct also from this point ( QUESTION #1 - SDK Debug behavior in GDB mode A question is related to the SDK debugger, when I run the Debug (GDB mode) I'm able to step the code, but if I choose the Resume option (then to run freely the code) the debug can't be paused and the only choice is to terminate the debug (the pause button on the toolbar is greyed and no way to stop the debugging with it). Someone have seen this behaviour and found a way to overcome this problem? Thank! Best regards
  9. Hi All, I'm start working with the AXI UART Lite in my Block Design with a Microblaze soft core. Actually I've the whole design working, using the xil_printf I'm able to send data out the board to the PC through the Virtual COM Port exposed by the board itself. The better approach involve the use of interrupts in order to manage the RX and TX operations. My first try was to found some documents about this point, found it into the yourdesign_bsp > BSP Documentation > uartlite_v3_2 folder: right click and select Open Documentation give the API list on the browser, the documentation reside locally on the following path (I'm using VIVADO 2016.1): C:/Xilinx/SDK/2016.1/data/embeddedsw/XilinxProcessorIPLib/drivers/uartlite_v3_2/doc/html/api/index.html Opening the: C:/Xilinx/SDK/2016.1/data/embeddedsw/XilinxProcessorIPLib/drivers/uartlite_v3_2 inside the examples there are several examples how to use interrupt with this peripheral, I took the xuartlite_intr_tapp_example.c file. Concerning this example I've some question to asking. Looking through the source code I see: #ifdef XPAR_INTC_0_DEVICE_ID #include "xintc.h" #include <stdio.h> #else #include "xscugic.h" #include "xil_printf.h" #endif First question is about this conditional statement. Starting from the SDK I've opened the xparameters.h file: scroll down until you reach the xparameters.h file. Double click on to open the file and make a search for the XPAR_INTC_0_DEVICE_ID label: This label should be the reference to the AXI Interrupt Controller present into the Block Design (system.pdf).with name microblaze_0_axi_intc. Now I need to know the exact difference between this two type of controller, the AXI is into the Fabric and I think is automatically managed from the Microblaze side by means of a dedicated software layer also the Generic Interrupt Controller I think is also managed by Microblaze but may be I've to configure it in order to instruct what peripheral have to use I'm correct? In this example I'm using the AXI Interrupt Controller so I can avoid to insert the whole code related the Generic Interrupt Controller, correct? Another question is if I'm using the AXI Interrupt Controller there are some reason to use also the Generic Interrupt Controller or I can't use it due to some constraints or other reasons? Someone can give me some explanation about this point? Thank!
  10. Hi @jpeyron, my supposition was correct, I've changed the main code as following one: /****************************************************************************** * * Copyright (C) 2009 - 2014 Xilinx, Inc. All rights reserved. * * Permission is hereby granted, free of charge, to any person obtaining a copy * of this software and associated documentation files (the "Software"), to deal * in the Software without restriction, including without limitation the rights * to use, copy, modify, merge, publish, distribute, sublicense, and/or sell * copies of the Software, and to permit persons to whom the Software is * furnished to do so, subject to the following conditions: * * The above copyright notice and this permission notice shall be included in * all copies or substantial portions of the Software. * * Use of the Software is limited solely to applications: * (a) running on a Xilinx device, or * (b) that interact with a Xilinx device through a bus or interconnect. * * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL * XILINX BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF * OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE * SOFTWARE. * * Except as contained in this notice, the name of the Xilinx shall not be used * in advertising or otherwise to promote the sale, use or other dealings in * this Software without prior written authorization from Xilinx. * ******************************************************************************/ /* * helloworld.c: simple test application * * This application configures UART 16550 to baud rate 9600. * PS7 UART (Zynq) is not initialized by this application, since * bootrom/bsp configures it to baud rate 115200 * * ------------------------------------------------ * | UART TYPE BAUD RATE | * ------------------------------------------------ * uartns550 9600 * uartlite Configurable only in HW design * ps7_uart 115200 (configured by bootrom/bsp) */ #include <stdio.h> #include "platform.h" #include "xil_printf.h" #include "microblaze_sleep.h" int main() { init_platform(); print("Hello World\n\r"); while(1) { xil_printf("\r\nHello from Microblaze!\r\n"); MB_Sleep(100); } cleanup_platform(); return 0; } so I've used a simply delay by means of the MB_Sleep() functions (declared into the Microblaze system library Microblaze_sleep.h) between two consecutive serial transmission in order to check if the incorrect data was originated from a sort of framing error (overwriting the tx buffer before this one was really empty) and now this seems working right (of course a more clean way is to use the interrupt approach, this will be my next task, if you have some starting material fell free to let me know :-)). Hence may be that into the debugging, due to the delay of the systems, the whole design was working just because this delay was intrinsic into the debugging process, working in a wild, without the delay that caming from the debugger processing, the transmitted characters was messed up, thus because the simple added delay get all things working properly I suppose that this proof the concept so also the storing design into the SPI procedure was correct and the task can be considered solved. Here a link to a very short recording video (TEST.avi) of the serial terminal monitor during the execution of the main code (I've not recorded the very start because there was only the bootloader messaging so this also proof that the whole procedure used to store the design into the quad SPI external monitor is correctly completed). Also, to facilitate other users in this steps, I've rewritten the starting tutorial from Digilent in a pdf format and the settings used was specifically targeted for the Cmod A7-35T board, I'll gratefully if someone at Digilent can take a look and if needed make correction or integration notes if these ones can be useful to better understand the whole process that at the very end is the one used to pack the design for a real in wild application. TUTORIAL_HOW_TO_STORE_YOUR_SDK_PROJECT_IN_SPI_FLASH QUESTION - PROGRAMMING STEP 4.1 and 4.2 Now the last thing to investigate is if is really necessary perform the step 4.1 and 4.2 every time is changing only the Microblaze code or if is possible only perform the step 4.1 and then skip the 4.2 (this is related the ability of the system to erase only a section of the Flash, but this should be true otherwise into the 4.2 step the SDK code will be also erased instead this not occourring at all and the design work properly after the step 4.2, but about this point I kindly ask some confirmation/precisation from the Digilent team. Many thank for all your help!
  11. Thank you @jpeyron but actually I will have to work around the full design Flash SPI implementation because now I cannot recognize correctly the serial characters that are coming from the virtual com port when the system are booting from SPI, but these characters are correctly readed into the debug stage, I've to investigate more on this subject... may be the serial routine inside the while is causing some frame error due the overwritting into the tx serial buffer before the serial transmissione is finished? It sound strange to me that in simulation the behaviour is correct and into the field (when the system is booting from the SPI flash memory) the behaviour is different. Thanks for the ext_spi_clk matter I'll wait from your team. Best regards
  12. Another question on programming. .Aafter programming the SPI FLASH with the application code (step 4.1 of the tutorial) and programming the bitstream as per step 4.2 of the same tutorial, If I change only the source code of my application (the .c code) and recompile it I've to program again also the download.bit image file or I can perform the step 4.1 and avoid to do the step 4.2? Thank!
  13. Hi @jpeyron I've followed the " "How To Store Your SDK Project in SPI Flash " and inside the SDK by means of debugging I can see the messages from the Microblaze, then I've programmed the SPI basing on the tutorial steps. Now, in order to see if all is able to work correctly from SPI, I've detached the Cmod A7-35T USB from my PC, set a Hyperterminal connection to the COM6 (the virtual COM port that is set from the board on my system) and then reconnct the USB connector from the board. A yellow led located near rge USB connector on the Cmod board start blinking but no messages arise into the Hyperterminal Window then I don't know what can be wrong, but if I go to the SDK through the debug mode (GDB) I'm able to see the messages after connecting the STDIO to the COM6. Here below a link to download the design (40 MB). LINK My suite is VIVADO 2016.1 Same results by means the demo project you did, the yellow led goes on but I can't see any char into the Hyperterminal window (9600,8,N,1). Using the RealTerm terminal software (is free) I can see uncorrect data on the display like as the baud rate is not set correctly...., same behaviour with your and my design... But If I run the application in debug mode (GDB) from the SDK and using the RealTerm (with STDIO not connected to the COM port related the demo board) the behaviour looks correct so I think that the Microblaze code and the HW parts are working correctly. So apparently, at now, the trouble seems to be related the SPI storing procedure... Thank for your time!
  14. Thank you @jpeyron, from the cited Xilinx application notes (xapp586) on page 7 figure 5 I can retrieve same SPI connections like into the Cmod A7-35T board schematic on the page 2/7, so I can desume that the SPI interface is configured to work as x4, also from the same board schematic page I can see that: M0 was tied to 3.3 V so logical "1" M1 and M2 was tied to GND so logical "0" then the M[2:0]=M2-M1-M0 is equal to 001 and from the xapp586 paragraph "Configuring the FPGA from SPI Flash" this imply that the starting CCLK frequency is fixed to 3 MHz as you pointed and confirmed by the FPGA datasheet ds181 Artyx-7 datasheet parameter FMCCK_START: From what I can understand this clock frequency will be automatically adjusted by the FPGA itself basing on the communication mode settings x1/x2 or x4, but this CCLK frequency seems to me unrelated to the clock supplied internally to the AXI Quad SPI module. In other words it seems to me that the SPI interface used from the FPGA for the initialization stage is not related to the AXI QSPI IP that I've put into my design or to be more precise, at the very first startup the FPGA, the FPGA internal startup circuitry will drive the SPI pins to retrieve the biststream (that for our design will be the bootloader with the glue logic inside the fabric) and after that the Microblaze is able to run the bootloader and drive the SPI pins by means of my AXI Quad SPI IP on the design then at this level I've to check how to configure the IP module correctly in order to define the ext_spi_clock and the a_axi_aclk properly. Make sense? Thank!
  15. Again about the QSPI IP I've another question concerning the physical connection to the FPGA pin, into the board.xml definition file provided by Digilent I can see definition for: qspi_db0 qspi_db1 qspi_db2 qspi_db3 qspi_csn from the file system_axi_quad_spi_0_0_board.xdc inside the project folder from the source navigator I have: #--------------------Physical Constraints----------------- set_property BOARD_PIN {qspi_db0} [get_ports io0_t] set_property BOARD_PIN {qspi_db1} [get_ports io1_t] set_property BOARD_PIN {qspi_db2} [get_ports io2_t] set_property BOARD_PIN {qspi_db3} [get_ports io3_t] set_property BOARD_PIN {qspi_csn} [get_ports ss_t] Instead into the general XDC constraints file provided also by Digilent (myconstr.xdc) I have the following directives: ## QSPI #set_property -dict { PACKAGE_PIN K19 IOSTANDARD LVCMOS33 } [get_ports { qspi_cs }]; #IO_L6P_T0_FCS_B_14 Sch=qspi_cs #set_property -dict { PACKAGE_PIN D18 IOSTANDARD LVCMOS33 } [get_ports { qspi_dq[0] }]; #IO_L1P_T0_D00_MOSI_14 Sch=qspi_dq[0] #set_property -dict { PACKAGE_PIN D19 IOSTANDARD LVCMOS33 } [get_ports { qspi_dq[1] }]; #IO_L1N_T0_D01_DIN_14 Sch=qspi_dq[1] #set_property -dict { PACKAGE_PIN G18 IOSTANDARD LVCMOS33 } [get_ports { qspi_dq[2] }]; #IO_L2P_T0_D02_14 Sch=qspi_dq[2] #set_property -dict { PACKAGE_PIN F18 IOSTANDARD LVCMOS33 } [get_ports { qspi_dq[3] }]; #IO_L2N_T0_D03_14 Sch=qspi_dq[3] now I'm confused about the physical definition of these pins where this reside? Inside the board definition VIVADO folder: C:\Xilinx\Vivado\2016.1\data\boards\board_files\cmod_a7-35t\B.0 I can see a file with name part0_pins.xml and inside this one the followings directives: <pin index="36" name ="qspi_csn" iostandard="LVCMOS33" loc="K19"/> <pin index="37" name ="qspi_db0" iostandard="LVCMOS33" loc="D18"/> <pin index="38" name ="qspi_db1" iostandard="LVCMOS33" loc="D19"/> <pin index="39" name ="qspi_db2" iostandard="LVCMOS33" loc="G18"/> <pin index="40" name ="qspi_db3" iostandard="LVCMOS33" loc="F18"/> CONCLUSION So these constraints are the corrects that I've to use then I've to leave commented the rows inside my custom constraints file myconstr.xdc to avoid any problem with the pins mapping and I've to use the myconstr.xdc files only to allocate pins that is not predefinited for the particular board used (in this case the Cmod A7-35T). Correct? Thanks
  16. Hi @jpeyron, about your hint concerning the Quad SPI flash clock you wrote about the need to use a 50 MHz clock for the SPI, this make some bell ringing in my head.... (thank you for that!) In my Block Design from the Run Automation feature, I got connections for the AXI Quad SPI ext_spi_clk together with the s_axi_aclk and then to the output of my clocking wizard , but my clk_out1 was configured at 100 MHz. Basing on your hint reading the AXI Quad SPI v3.2 guide ( PG153 April 4, 2018) I've found this table: hence if the Artix-7 chip soldered on the Cmod A7-35T have the speed grade -1 (I suppose that should be this one because the label sticked onto the chip package report ARTYX-7 35T cpg236-1 and the last -1 may be the speed grade, I'm correct?), so if this is correct I've to limit the ext_spi_clk to a maximum if 60 MHz hence, as you wrote, 50 MHz is a good compromise. Now in my design I've the ext_spi_clk tied to the 100 MHz clock then I suppose to have to change the clocking wizard in order to setup another output and configure it equal to 50 MHz then detach the ext_spi_clk from the 100 MHz and attach to the 50 MHz source clock. Also I've searched throught the constraints file for the Quad SPI IP and I've found some interesting at this folder: C:\Users\STE\VIVADO\hello_world\hello_world.srcs\sources_1\bd\system\ip\system_axi_quad_spi_0_0 in bold I've written the relative path to my design. Into this folder I've this file: system_axi_quad_spi_0_0_ooc.xdc, opening it give me this single clock contraints: create_clock -name all_clock -period 20 [get_ports {s_axi_aclk ext_spi_clk}] from this the s_axi_aclk is constrained to the 50 MHz then I kindly ask the following question: if I've a Microblaze based design working at 100 MHz I've to downscale the clock to 50 MHz due to the s_axi_aclk or this two clock can be unrelated then I can use for the s_axi_aclk a clock equal to 100 MHz and for the ext_spi_clk a clock of 50 MHz? In my thinking the s_axi_aclk clock is the one used to communicate with the Microblaze core through the AXI bus and this one should be equal to 100 MHz (the Microblaze drive the bus with this clock I suppose), the other ext_spi_clk clock should be used from the Quad SPI IP in order to drive the external Quad SPI Flash physical memory hence, in my mind, could be different that the one used for the AXI interface. From table 1,1 of same document I have: and these Note with particular reference to the point 1 and 2: Because I've to use a 50 MHz external clock with a AXI clock of 100 MHz the note 2 sound good then may be I've to select the Enhanced Performace option into the IP then: from this settings I see that the frequency rate is fixed to 2 hence should produce on the ext_spi_clk a 50 MHz clock with a a_axi_aclk equal to 100 MHz so, if I'm correct, both clock line can be connected together at the 100 MHz clocking wizard output. I'm correct or there is some fault into this reasoning? I kindly ask some light up on this point. In this perspective I think also to have to split the clock constraints into the system_axi_quad_spi_0_0_ooc.xdc file as following: create_clock -name all_clock -period 10 [get_ports {s_axi_aclk}] create_clock -name all_clock -period 20 [get_ports {ext_spi_clk}] make sense or I'm missing somethings? Thank for your help. Best regards
  17. Thank you @jpeyron, I don't know why but every time I restart the SDK the design_1_wrapper_hw_platform_1 is created again, also into the SDK I can see two folders: design_1_wrapper_hw_platform_0 (existent) design_1_wrapper_hw_platform_1.(every time is re-created) May be you have to pack the design as archived design? Usually an archived project have a extension, your example seems a pure .zip of the whole project folder, may be some files was not correctly closed when you did the zip ? I don't know these are just simple hypothesis... Best regards
  18. Hi @jpeyron, after launching the SDK (from VIVADO File->Launch SDK...) I've got other error that say to check the log file without any other indication. from the I've found the Log log.txt and I can see a Java exception. !ENTRY org.eclipse.ui.workbench 4 2 2018-04-06 19:31:27.912 !MESSAGE Problems occurred when invoking code from plug-in: "org.eclipse.ui.workbench". !STACK 0 java.lang.IndexOutOfBoundsException: Index: 0, Size: 0 ..... I've searched some info about this stuff, but I've not foud anything useful, from your side do you have encountered such type of error with the SDK opening? Thank as usual! Best regards
  19. Thank again. Now the errors arise with my VIVADO release: Vivado v2017.4 (64-bit) SW Build: 2086221 on Fri Dec 15 20:55:39 MST 2017 IP Build: 2085800 on Fri Dec 15 22:25:07 MST 2017 Now I'm dowloading the 2017.4 update 1 may be this one can fix somethings (?) When I've installed it and make a test I'll let you know. Best regards
  20. Hi @jpeyron, I've installed VIVADO 2017.4 but when I try to load the example I got 2 errors. Don't know what can be, I have not seen these ones with the old release 2016.1 Do you have any idea? Thank
  21. Hi @jpeyron I'm gratefully to you and all your team for the great help in better understanding and using your products and also for the help about general question! I'm downloading the design, I've read that mutiple release of VIVADO can be on the same machine, I'll try to install the 2017.4. Best regards
  22. Hi @jpeyron, thank for your answer. QUESTION #1 I've read the "How To Store Your SDK Project in SPI Flash" but I kindly ask you about this sentence: "Before you start; this guide assumes that you already have a Microblaze system built complete with Quad SPI, External Memory, and Uart cores, and that you have the appropriate QSpi mode jumper setting. This tutorial takes place in SDK." from this I understand that I've to place into my design also an AXI Quad SPI IP but I can't understand the red sentence, may be this one is related to a target board different than the Cmod A7-35T? This question arise because the SPI memory, from the schematic (IC3 labeled), is directly connected to the FPGA and there is no jumper or at least I didn't noticed it... QUESTION #2 If I've got the point, the startup flow should be the following one: 1. at the power up the FPGA will try to load a valid bitstream from the flash SPI memory, if the FPGA controller detect that the code is valid then will go to load it into the BRAM of the FPGA. This first step is related to the Microblaze bootloader code because this one is the first code that has to be executed in order to retrieve the real user application code as shown into the next step. 2. The SPI interface is released from the FPGA internal booting circuitry. Due to the presence of the added AXI Quad SPI interface IP, the Microblaze is able to use it directly by means of the bootloader code when this one is executed. The bootloader execution basically work in order to retrieve the bitstream application code that is stored into another region of the external flash SPI memory (IC3) and then upoload it into an external RAM memory, this one will be the place where the user application code will be physically executed (then the C or C++ compiled code). 3. When all the user application code is uploaded to the external RAM memory the Microblaze will be able to run the user application program. If the previously described points are corrects I just need a last little clarification about the external memory RAM because into the cited tutorial I read about DDR external memory but into the Cmod A7-35T I've only a static memory model IS61WV5128BLL-10BLI (labeled IC9 into the board schematic) and constrained as Cellular RAM into the XDC file. For that the correct memory controller that I've to use could be the Cellular RAM controller and this one is exactly the one inferred by the Block Design as AXI EMC IP instead the one that is shown into the tutorial. Tutorial talk about DDR memory because, I think, is based on the Arty7 development board that is equipped with a DDR memory, but for the Cmod A7-35T board I see a different memory type and then I think that the board configuration file, automatically, instruct VIVADO to choose the right memory controller, so the AXI EMC IP. Hence if I'm correct, something will be different into the Generate Linker Script form shown into the tutorial at point 2.3 (I've to do these steps in practice, but before doing that I need to understand how the system work). I kindly ask some confirmations/corrections about my reasoning... Thank you!
  23. Thank you @jpeyron for your help and time! Best regards
  24. Hi all, I'm confused about storing bitstream into the SPI memory that is on board and how to use a SPI bus to interface external peripheral. To be more specific if I need to use the on board SPI memory (IC3 on the schematic board) to store my bitstream I've to add the AXI Quad SPI attached to my Microblaze or this memory is adreessed automatically from the FPGA at startup? If instead only use the on board SPI memory to store my bitstream and then autoconfig the FPGA on startup I need to drive external SPI peripheral (e.g. and DAC) I've to add the AXI Quad SPI and then drive it from Microblaxe through the AXI mapping? I'm a little confused about this point... [EDITED] I'm reading again the Cmod A7 manual (MANUAL) and I've found some information into the paragraph 2.2 and Chapter 4. if I've correctly understand I can use the SPI memory to store my FPGA program without need to instantiate the AXI Quad SPI bus because this task will be do automatically on the FPGA startup (this sound also logic if I've a design that not need of a microblaze core, lika a simple logic as the button example, provided from Digilent), but if I need to store some data into the SPI memory, e.g. configuration data for my application I can read the SPI through the Microblaze into the adreess not used for the bitstream, my think is correct? Also if I need to use an external peripheral different than the on board memory (like a serial DAC) I'll use another AXI Quad SPI bus and then set the physical FPGA outputs for it through the XDC filles, e.g. using some pio pins. Is correct? Make sense? Thank!