UPGRADE YOUR BROWSER

We have detected your current browser version is not the latest one. Xilinx.com uses the latest web technologies to bring you the best online experience possible. Please upgrade to a Xilinx.com supported browser:Chrome, Firefox, Internet Explorer 11, Safari. Thank you!

cancel
Showing results for 
Search instead for 
Did you mean: 
Highlighted
Visitor shalfbeast
Visitor
837 Views
Registered: ‎03-14-2017

Spartan6 fallback failure even with Barrier images

Jump to solution

I have a design in a XC6SLX45 (Spartan6) I have implemented a multiboot system. If I corrupt one byte at the beginning of the Application image bitstream and remove a second byte completely the design does not fallback to the Golden image.

It does fallback if I corrupt some bits, but don't remove or add any, indicating a CRC error but when I remove a byte and correupt another it locks up and is unresponsive. I have used Impact to determine that the Bootsts is all zeroes. I also have used the usercode register which I put values in to determine whether I'm in a Golden or Application image or not - it reads all F's when it has locked up, which is not the value I have programmed in.

I have seen on the forums that if the beginning of the bitstream is corrupted then fallback can fail and Xilinx recommends that the user implements barrier images (XAPP1247) which I have done. (The XAPP1247 is particular to the 7-series, I have a Spartan 6, I don't know if this applies to the Spartan6?)

 

I have generated some timer1/2.bin files using the TCL script in XAPP1247, however they are particular to 7-Series so I modified them for use with the Spartan6 and put them in my Flash MCS file along with the Golden and Application FPGA images and the multiboot header.

 

I programmed my Flash with the MCS with the Barrier images and the FPGA boots to the application image. I then uploaded a new corrupt Application image (one missing byte and a second corrupt byte) and the FPGA then fails to fallback.

 

I then read out the entire Flash contents and the flash appears to have all the barrier images intact, I can see the corrupt application image and I can see the setting of the watchdog register yet the FPGA does NOT fallback!

 

Please help. These units or going into manufacturing soon and I can't guarantee that the FPGA will fallback!

 

I have attached the MCS file that I loaded into the Flash - 361000564.mcs, the readback version from Flash - readback_361000564.mcs and the two barrier images that I put into the MCS file; timer1.bin and timer2.bin

 

 

 

0 Kudos
1 Solution

Accepted Solutions
Moderator
Moderator
1,130 Views
Registered: ‎01-15-2008

Re: Spartan6 fallback failure even with Barrier images

Jump to solution

if the crc check command is corrupted it doesn not fallback. 

following AR talks about it and suggests to program the sync word last.

https://www.xilinx.com/support/answers/58249.html

barrier images mentioned in the XAPP1247 doesn't include the CRC check command

0 Kudos
2 Replies
Moderator
Moderator
1,131 Views
Registered: ‎01-15-2008

Re: Spartan6 fallback failure even with Barrier images

Jump to solution

if the crc check command is corrupted it doesn not fallback. 

following AR talks about it and suggests to program the sync word last.

https://www.xilinx.com/support/answers/58249.html

barrier images mentioned in the XAPP1247 doesn't include the CRC check command

0 Kudos
Visitor shalfbeast
Visitor
785 Views
Registered: ‎03-14-2017

Re: Spartan6 fallback failure even with Barrier images

Jump to solution

Thanks for your response.

 

I've stumbled across AR#58249 too. I am contemplating using method 2, as method 1 will also alter our software teams drivers as the design can't store all of the bitstream at once so they would have to send the bitstream to the FPGA in reverse order. So method 2 from the above answer record is the method that I'm going to try for Spartan 6.

 

0 Kudos