ARTY Bootloader in flash: ERROR in SREC line

[breinhold]

I've followed these instructions to load my HW and SW into the ARTY quad SPI flash: https://reference.digilentinc.com/learn/programmable-logic/tutorials/htsspisf/start

Both flash operations are successful, but when I start the ARTY board I get this in the terminal output:

SREC SPI Bootloader
Loading SREC image from flash @ address: 00c00000
ERROR in SREC line: 00000001SREC line is corrupted

Thinking the download.bit flash programming operation might have somehow overwritten the SREC data, I reloaded the program into flash, making sure to set the 0x00c00000 offset and checking the "convert ELF to SREC" check box, and then programmed the FPGA directly with the bitstream and the bootloader elf file. 

Same result.

I'm new to Vivado.  In the past of done this with ISE using iMPACT and it was pretty straightforward, combining the download.bit and the srec data into a single MCS file and loading that into flash in one step, but that doesn't seem to be available with Vivado.  

Can anyone give me a clue where I might have gone wrong?

I'm using Vivado SDK 2017.1 and Windows 7.

[jpeyron]

Hi @breinhold,

I tried doing this tutorial in VIvado 2017.1 and I got an error as well. Instead of n25q128-3.3v-spi-x1_x2_x4 use mt25ql128-spi-x1_x2_x4. let me know if this fixes your issue. Here is a forum thread that talks about this issue. I have also updated the tutorial to comment on this issue.

cheers,

Jon

[breinhold]

I was just about to post an update to mention that n25q128-3.3v-spi-x1_x2_x4 was not available and I was using mt25ql128-spi-x1_x2_x4 (as you suggested) instead.  I checked Micron's datasheets and it seemed to be the closest match.  (So no this does not fix the issue for me)

I put some code to write out what is being read by the bootloader.  The first SREC line should be:

S014000063705F636F6D6D735F6170702E737265631F\r\n

But what is read is below.  The first byte should of course be 'S' but it's '6.'  That's what's causing the error.  Over several flash writes, the first byte is different almost every time and occasionally another byte is written incorrectly but generally most of the record is correct except for the first byte.  

The bootloader data reads are 100% consistent over several runs so I think it's fair to conclude that the SDK is not writing the flash correctly.  

 

 

0:  6 (0x36)
1:  0 (0x30)
2:  1 (0x31)
3:  4 (0x34)
4:  0 (0x30)
5:  0 (0x30)
6:  0 (0x30)
7:  0 (0x30)
8:  6 (0x36)
9:  3 (0x33)
10:  7 (0x37)
11:  0 (0x30)
12:  5 (0x35)
13:  F (0x46)
14:  6 (0x36)
15:  3 (0x33)
16:  6 (0x36)
17:  F (0x46)
18:  6 (0x36)
19:  D (0x44)
20:  6 (0x36)
21:  D (0x44)
22:  7 (0x37)
23:  3 (0x33)
24:  5 (0x35)
25:  F (0x46)
26:  6 (0x36)
27:  1 (0x31)
28:  7 (0x37)
29:  0 (0x30)
30:  7 (0x37)
31:  0 (0x30)
32:  2 (0x32)
33:  E (0x45)
34:  7 (0x37)
35:  3 (0x33)
36:  7 (0x37)
37:  2 (0x32)
38:  6 (0x36)
39:  7 (0x37)
40:  6 (0x36)
41:  3 (0x33)
42:  1 (0x31)
43:  F (0x46)
44:  
 (0xD)
44:  
 (0xA)

 

[jpeyron]

Hi @breinhold,

Here is a xilinx wiki page that states that there is a known issue for 2017.1 Fix array index of writebuffer in fastreaddata that might be affecting this issue. Have you tried using Vivado/SDK 2016.4?

cheers,

Jon

[breinhold]

7 minutes ago, jpeyron said:

Have you tried using Vivado/SDK 2016.4?

I have not but I'll give it a shot tomorrow.

One more update for today:  using the Vivado hardware manager, I added the flash part to the detected configuration and created an MCS file to combine the download.bit and srec files (Tools -> Generate Memory Configuration File).  I then used the hardware manager to write the combined MCS file to flash and got exactly the same result again -- bootloader loads and runs just fine and the first SREC byte is wrong and the rest seems OK.

It sure seems odd that everything, including the bootloader, seems to be loading just fine into flash except for the first byte of the srec...

Thanks Jon.

- Bill

[breinhold]

After a little more thought, I don't have to have this working right now so I'm going to stay with 2017.1 for now and see if there's a solution in this or an upcoming version of Vivado.  Since it seems like more of a Xilinx issue I've moved it to the Xilinx forums here:  https://forums.xilinx.com/t5/Embedded-Development-Tools/Vivado-2017-1-error-writing-srec-to-flash/td-p/772389

[breinhold]

I tried 2017.2, same results.  I also tried 2016.4, same results.

I then tried loading the srec file at 0x00c00001 rather than 0x00c00000.  With the bootloader still pointed at the original location, the second byte read is now 'S,' as it should be.  

Pointing the bootloader at 0x00c00001, the first byte is once again read as '0.'  

So the problem is not with Vivado writing the data, it's with the bootloader reading the first byte.

I'm really stumped.  How could the bootloader be misreading just the first byte?  Is there a modification to the bootloader code I missed?   

 

Can someone confirm they've followed the tutorial and it's worked for them? (https://reference.digilentinc.com/learn/programmable-logic/tutorials/htsspisf/start)

[jpeyron]

Hi @breinhold,

I have been able to get the hello world to work with out issue. I attached my project done in Vivado 2016.4 below. Could you post your compressed project or at least the sdk code you are using along with a screen shot of the vivado block design?

Arty_quad_spi.zip

[breinhold]

I figured out the problem:

In Vivado 2016.4 when you add the Quad SPI device to the block diagram, the connection automation does not connect the ext_spi_clock pin.  I haven't found a block diagram in the tutorials that clearly shows where that pin is supposed to be connected, but the design you posted has it connected to the same pin as the s_axi_aclk pin.

Here's where I went wrong:  When you add the Quad SPI in both 2017.1 and 2017.2 it automatically connects the ext_spi_clock pin to the 166.667MHz system clock.  I re-connected it to the same clock as the s_axi_aclk pin and everything now works fine in both of those versions.  

 

The bootloader tutorial starts out with "Before you start; this guide assumes that you already have a Microblaze system built complete with Quad SPI...."  It would have been very helpful to me to have either a reference to a tutorial where a compatible system is built or just a block diagram here showing the the proper connections in the hardware design for these required components.  

 

[jpeyron]

HI @breinhold,

I am glad to hear you were able to get this going. I can see how you could make a mistake with this and i have passed on the request for a better guide. 

thank you,

Jon

[breinhold]

Thanks again for the help Jon, much appreciated!

Bill