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. 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
  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.
  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 aft
  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 brow
  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 pers
  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 f
  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 ar
  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
  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