LucAce

Members
  • Content Count

    3
  • Joined

  • Last visited

About LucAce

  • Rank
    Newbie

Recent Profile Visitors

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

  1. LucAce

    Complete Cmod A7 35T OOB Project

    @jpeyron, After a lot of digging, I discovered some of my problems. I put together a procedure to build the OOB have it stored in BRAM and executing independently of the debugger. See: Building OOB to BRAM Procedure.txt Issue #1: OOB can't possibly be using external memory and the SREC SPI Bootloader Because the OOB includes an external memory tester and the SREC SPI Bootloader moves data from flash to the external memory for execution, it is obviously not going to work properly if the code being executed is overwritten. So this leaves the program must be executing from BRAM. See Issue #2. Issue #2: Not booting without the debugger. The issue here is that in Vivado when a bitstream image is created, the "mb_bootloop_le.elf" image is associated and inserted into the design by default. Not sure what all this bootloader does but I it appears to cause the Microblaze to wait for the debugger before executing user code. This obviously isn't going to work for standalone uses of the development board. To resolve this, the easiest way is to replace the mb_bootloop_le.elf for the user code you want to run. To do that, develop and test your code in Xilinx SDK and when finished go back into Vivado and replace mb_bootloop_le.elf with the final .elf file and program the configuration memory through Vivado. After unplugging and plugging back in the dev board should start executing if all went correctly. Issue #3: Changing AXI Quad SPI device to use x1 during Configuration. To be honest this doesn't make much sense to me, the mode during FPGA configuration should not matter as it is independent from the SPI component that is being instantiated in the FPGA bitstream. It is possible the SREC SPI Bootloader doesn't support Quad SPI mode for some reason and the RTL would need to reflect that but configuration and operation are independent. In the attached procedure I use compress, SPIx4 and 33Mhz for FPGA configuration with no issues. I'll provide an update if I have issues testing BRAM bootloader and Flash application storage which I'm going to do next. Building OOB to BRAM Procedure.txt
  2. LucAce

    Complete Cmod A7 35T OOB Project

    Is it possible to get the complete Vivado 2018.2 project with SDK files to restore the Cmod A7 devices back to OOB? The provided OOB project does not include the AXI Quad SPI component so it doesn't seem to me that the provided OOB project files are what were originally used to generate the image. Maybe they are and some other method was used to preload the memorytest (knowing that procedure would be useful too). I have used the "How To Store Your SDK Project in SPI Flash" guide to program the flash when using a Microblaze design but it would seem that it wouldn't work for the OOB program because the guide has the program loaded from QSPI to the external memory which in theory would get corrupt once the memory test is started. I could be wrong about that but it seems the most logical outcome of a memory test. So I'm guessing the memorytest was really loaded to BRAMs instead of external memory and getting an example of that would be useful. The reason I ask is that I have been having a lot of issues flashing the QSPI with Microblaze designs. I get a lot of failures while flashing and when it does flash correctly it suffers from not starting until the reset button is pushed. I have seen some suggest that changing the FPGA configuration to SPI x1 fixes the issue I don't see how changing the initial load to SPI x1 mode affects the QSPI reads after the FPGA is already configured and should be executing code from the Microblaze. I have a complete step by step procedure to my build, if that helps. I haven't ruled anything out but something isn't right. Cmod-A7-35T.xdc Steps.txt user_35t_bd.tcl
  3. LucAce

    cmod-A7 SPI-bootloader starts with second connection

    @Weevil, @jpeyron Is there an explanation why this works? The fetching of microblaze code from QSPI occurs long after the FPGA is configured and has released the QSPI interface. So I don't see why this would change the ability of the bootloader to read flash. I have been fighting this board for more hours then I would like to admit to, I have encountered multiple flash program failures or it just not being able to find the flash when the boot load starts trying to execute it. The best I have gotten is to this point where the FPGA will run the microblaze code after the button is pressed/reset issued. These are the properties I'm using when it requires a button press to being fetching from QSPI. set_property BITSTREAM.GENERAL.COMPRESS TRUE [current_design] set_property BITSTREAM.CONFIG.CONFIGRATE 33 [current_design] set_property CONFIG_MODE SPIx4 [current_design] I have only tried using the USB interface. Using Debug builds in SDK, Verbose is defined (enabled) in the bootloader.