01-11-2019 01:05 PM
I cannot get a SPI bootloader to function in Vivado 2018.3 with an Artix-7 XC7A100T-2FGG484I. It works fine in 2018.2.2 and previous versions. I've tried it on three different boards with different DDR3 and SPI configurations, with the same results.
To test the issue, I made a simple project in 2018.2.2 consisting of a MIG, a MicroBlaze, a AXI Uartlite, and an AXI Quad SPI with STARTUP enabled. I generated a bitstream for this project, exported the HW, opened SDK and generated a "Hello World" project and a SPI bootloader project. It works fine and boots itself on powerup as expected.
I then copied the project and updated it and opened it in 2018.3, and it won't boot from SPI on powerup. I tried a few other projects I have created in 2018.3 and they won't boot from SPI flash either. It appears the HW is loaded and running, I added a blinking LED that starts when the MIG init calibration is complete, but I get no bootloader startup messages from the UART. If I manually run the bootloader after a powerup, the program runs and I get the correct UART messages, so I know it got programmed into the SPI flash at the correct offset.
I tried both the Xilinx srec spi bootloader and another known-working elf bootloader, and both fail in 2018.3 and work in 2018.2.2.
Has something changed in the quad SPI IP or configuration interface in version 2018.3? I am using quad SPI mode with a Spansion S25FL256SAGNFI001 flash device, with the following bitstream constraints:
## Configuration constraints
set_property BITSTREAM.CONFIG.CONFIGRATE 22 [current_design]
set_property BITSTREAM.CONFIG.SPI_FALL_EDGE YES [current_design]
set_property BITSTREAM.CONFIG.SPI_BUSWIDTH 4 [current_design]
set_property BITSTREAM.CONFIG.SPI_32BIT_ADDR Yes [current_design]
set_property BITSTREAM.CONFIG.EXTMASTERCCLK_EN DISABLE [current_design]
set_property BITSTREAM.GENERAL.COMPRESS True [current_design]
01-14-2019 12:16 PM
01-28-2019 01:54 PM
I'll bet you're seeing the same .mmi-generation problem that this other user figured out, see this post:
01-28-2019 02:13 PM - edited 01-28-2019 02:14 PM
Yes, I saw that post. I suspect it is the same issue, but I'm not going to be messing around with manually editing files, there's too much room for error.
I switched back to 2018.2.2, at least until Xilinx offers a patch to fix the issue.
01-28-2019 04:54 PM
I thought that was a good idea, so I tried the same (go back to Viv2018.2), but I get the same behavior: my bytes are bit-swapped when I make a download.bit with both system.bit and app.elf, but not when I make a download.bit with bootloop.elf.
You said 2018.2.2, but I only see 2018.2. Here's my Vivado version
01-28-2019 05:31 PM - edited 01-28-2019 05:32 PM
2018.2 was fine, but there is a 2018.2.2 version (see below). It is only 2018.3 that is broken.
Since you can't open a 2018.3 design in 2018.2 (at least not that I know of, there may be a way...), you have to start over from scratch and redo your block design and compile it in 2018.2 and it will work.
Here's my 2018.2.2:
01-28-2019 05:58 PM
Odd, I did that (went back and built the project in 2018.2, then exported hw to SDK2018.2, etc) but still had the problem.
I also wrote a bit of python to swap those bit lane assignments in the .mmi, and it seemed to have no effect. The code viewed in xsct is still bit-swapped within each byte...
I'm missing something here....