BYTEMAN

Members
  • Content count

    66
  • Joined

  • Last visited

About BYTEMAN

  • Rank
    Frequent Visitor

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. BYTEMAN

    Cmod A7-35T Microblaze design and output pins

    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 (https://sourceforge.net/p/realterm/bugs/37/). 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