Issues with Microblaze in Arty A7 and Using SPI Flash

[smokingenius]

Greetings Forums,

I just recently got the Arty A7 100T dev board. I have been working through the tutorials. I have been developing on FPGAs for a while but this is my first attempt at using the IP Integrator and the Microblaze architecture from Xilinx. I have been working through the guides posted on the Digilent Resources page for the Arty A7. The one I am currently stuck on is this: https://reference.digilentinc.com/learn/programmable-logic/tutorials/htsspisf/start.

When I get to the end to put the "Hello World" and "Bootloader" .bin file into the SPI it gets programmed but it doesn't appear to operate. I have validated the "Hello World" program is working in DDR3 by running it baremetal as "debug" from SDK with the FPGA programmed. I believe the issue is that when I right to the SPI Flash, SDK is wiping the whole SPI and not just the section of memory I am using. So I am wiping it, putting hello world on, wiping again, and then flashing the bootloader with FPGA bit file, which wipes out the hello world, leaving nothing to boot. I have looked all over SDK for settings to not wipe the entire SPI but can't seem to find any. I have verified the bootloader program is small enough as a .elf to fit into the Microblaze local memory, and it is assigned in the script to use the local memory. The entire download.bit flashing at 0x0 is only a 1 Mb, which is small enough to not clash with the user code space at Flash location 0x003D0900, which is where I am placing the hello world program.

Thanks for the assistance in troubleshooting this issue. I eventually want to move on to using embedded Linux from the SD Card pmod, but want to make sure all this is working and I have confidence in it before I move onto pmod devices and using external storage.

Regards.

[JColvin]

Hi @smokingenius,

I am looking into this as well; I went through the same tutorial as well as an alternate more detailed one from Avnet for the Arty A7 here: https://www.avnet.com/opasdata/d120001/medias/docus/178/UG-AES-A7MB-7A35T-G-Arty-SREC-Bootloader-VIV2015-2-V1.pdf, but have yet to see the application project "start" upon boot-up. Just programing the bitstream and then launching the application project works as always though. I tried programing the flash in a few different orders like you did, but with no useful result as of yet.

I'll let you know if I get this successfully working.

Thanks,
JColvin

[smokingenius]

Good Morning @JColvin,

I found this guide on the Xilinx forum using the MCS programmer in Vivado after building the files in SDK: https://forums.xilinx.com/t5/Xcell-Daily-Blog-Archived/Adam-Taylor-s-MicroZed-Chronicles-Part-221-How-to-boot-a/ba-p/802317?_ga=2.62901743.252807929.1585228887-1952416681.1580396999. It seems to write the entire SPI in one go, however I am still having the boot issue on reset. For testing I did store "hello world" at the proper address in SPI Flash and then ran the bootloader in debug mode on the device. I got all the outputs I was supposed to see from the bootloader with "Verbose" turned on, and then I got Hello World to print after it read all the SREC files. This was after a board reset, so the FPGA is programming the device from the bit file on the SPI Flash, but doesn't appear to be loading the bootloader.elf with it.

I also turned off all the compiler optimizations, and with Verbose on, the bootloader comes out to be about 124 kb. I increased the size to 128 kb, and it seemed to work with no issues the same way I described above, but still wouldn't load upon reset with the bit file. 

I will keep experimenting and see what I get and let you know. There has to be a way of getting this to work, as I am sure others use this all the time, and I have used it for other projects and work with ARM, PowerPC, and ARM-M devices. There has to be something simple that is just getting overlooked in the design files with IP Integrator that has to be turned on or something, or maybe some sort of delay added in on the SPI in/out to slow down the load? Maybe the bootloader is being installed before the bit file is fully loaded to the FPGA and its already tried to execute before it was finished? There isn't a "delay" block in the integrator for I/O or SPI. I know you can add in/out delay via the .v files, but we don't have those for the integrator components. 

Regards.

[JColvin]

Hi @smokingenius,

I found a couple of other threads here (https://forum.digilentinc.com/topic/18001-arty-a7-100t-quad-spi-flash/?do=findComment&comment=51469) and here (https://forum.digilentinc.com/topic/17498-missing-step-in-microblaze-spi-flash-guide/?do=findComment&comment=44063) that have some additional details that I will be trying out. I also noticed that in the AXI Quad SPI IP within the block design that it had Micron as the selected flash family rather than Spansion; a Micron flash part was used in the Rev C version of the Arty but now a Spansion part is used in Rev E. I'm not certain how much affect this will have since in the xilisf settings within the BSP, both Micron and Spansion use the same settings, but I figure it won't hurt to try. Why getting a bootloader application to work correctly on a Microblaze system rather than Zynq/ARM based system is much more difficult I'm not certain of since I agree that it doesn't seem be loading the bootloader.elf correctly.

I'll let you know what I find out.

Thanks,
JColvin

 

[smokingenius]

Afternoon @JColvin,

I was able to get it to work using the MCS method via Vivado. It initially didn't work but finally it did. No change to the design of the SPI or anything. I am testing again with another program via the same method with MCS. I have listed a few points below.

1) I did make sure that I only ran through "Implementation" first and then opened it; once opened, I was able to set the settings for the bit file to include a .bin, needed for SDK, and to allow for modifying the advanced settings; this allows you to set compression, which I did, and to specify a secondary programming configuration for the device, of which you select SPI x4; once you apply the settings, you will be required to save them as a constraint, and then re-generate the bit file

2) Once the initial bit file is exported to a bin, compressed, and send to SDK, I generate the spi_srec bootloader that is availble; once configured, I changed the compilation settings to -g and -Os to compress the size on the compiler, I turned on the -s flag in the linker, and left VERBOSE on in the .c file so I could see output on the UART; all other settings, like changing the xilisf, I left the same as the guide

3) I evaluated the compiled code for Hello_World, bootloader, and the FPGA via SDK prior to going back to Vivado to make the MCS; I loaded an srec version of Hello_World into the flash first, reset board power, flashed the FPGA, and then ran the bootloader on bare metal as a debug; this validated I saw everything I needed to in the bootloader running and would correctly run the srec version of Hello_World; I then generated my own srec (since SDK just makes its in Cache and then deletes it) using the SDK version of bash under the Xilinx tools; the command to run this is "mb-objcopy -O srec <name_of_program>.elf <name_of_program>.srec"

4) Back in Vivado I attached the .elf for the bootloader not only to the design in IP Generator for synthesis but I also tagged it for simulation too

5) Once the bit file generates, I opened the hardware manager and programmed the FPGA; with the programmed FPGA opened I added the necessary memory device, and under "Tools" in Vivado used the option to generate and MCS file; make sure you use the device flag, select the correct Spansion model, and then fill out the fields accordingly; I also checked the "overwrite" and "checksum" fields to make sure I made a clean new MCS file (whatever you named it) and that there was a checksum to use later in programming the flash for verification

6) From the hardware manager I right click on the memory device, and then select the option to program it; I select the .mcs file, and the checksum file for the next two fields; I checked all the boxes, let the device program, and then reset the device; it worked immediately

NOTE: In resetting the device I still had issues with it not running the bootloader unless I held the button down for a count of 2; once I did that it worked every time; I am not sure if there is some latent power that is keeping a portion of the device initialized when you do a quick button press that is causing the issue, or if it is just my board.

I did notice that same option in the SPI and changed it to Spansion from Micron, not sure if that helped in any way, since I was specifying the correct Spansion model in SDK. I do believe SDK is nuking the whole memory, so any user program is getting overwritten. Least that is what my troubleshooting supports. I can't find any setting in SDK to change that.

Overall I used a design and process that combined the Avent guide you provided; the Digilent one I originally posted, and the MCS guide from the Xilinx forum.

I am currently working on getting Vitis 2019.2 installed to see how that changes things up, especially since it seems like moving forward Xilinx is going to bundle all their tools together into that package. I will see if I can post a link to my google drive later with my package files so you can look at my project and how I set things up.

Regards.