Complete Cmod A7 35T OOB Project

[LucAce]

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

[jpeyron]

Hi @LucAce,

Here is a forum thread that discusses changing the AXI QSPI IP to standard and selecting SPIx1. 

thank you,

Jon

 

[LucAce]

@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