cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
reaiken
Explorer
Explorer
1,662 Views
Registered: ‎07-18-2011

SPI bootloader broken in 2018.3?

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]


 

7 Replies
bklopp
Contributor
Contributor
1,567 Views
Registered: ‎05-16-2018

I'm having the same exact issue.

0 Kudos
bklopp
Contributor
Contributor
1,542 Views
Registered: ‎05-16-2018

I created a project that didn't work on 2018.3 and it worked on 2018.2. The vivado dev team should look into this.
0 Kudos
rikraf
Explorer
Explorer
1,420 Views
Registered: ‎01-15-2008

I'll bet you're seeing the same .mmi-generation problem that this other user figured out, see this post:

https://forums.xilinx.com/t5/Embedded-Development-Tools/Vivado-2018-3-Updatemem-strange-behavior-in-endianness/m-p/928937/highlight/false#M48003

 

0 Kudos
reaiken
Explorer
Explorer
1,415 Views
Registered: ‎07-18-2011

@rikraf

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. 

0 Kudos
rikraf
Explorer
Explorer
1,401 Views
Registered: ‎01-15-2008

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

Capture.JPG

0 Kudos
reaiken
Explorer
Explorer
1,395 Views
Registered: ‎07-18-2011

@rikraf

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:

vivado_2018r2r2.jpg

0 Kudos
rikraf
Explorer
Explorer
1,387 Views
Registered: ‎01-15-2008

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....

0 Kudos