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
Adventurer
Adventurer
750 Views
Registered: ‎08-21-2017

Kintex7 SPI multiboot stall

Jump to solution

Hi,

 

I have implemented SPI multiboot on Kintex7 7k160t. When erasing the first sector of the normal image, all works well, watchdog triggers, and golden design boots. When I erase some of the other parts of the FPGA design, the boot stalls and golden design never boots. here are my constraints, please let me know if I overlook something;

 

Best regards

 

Srdjan

 

normal design:

set_property BITSTREAM.CONFIG.SPI_BUSWIDTH 4 [current_design]
set_property CONFIG_MODE SPIx4 [current_design]

set_property BITSTREAM.CONFIG.CONFIGRATE 9 [current_design]
set_property CONFIG_VOLTAGE 2.5 [current_design]
set_property CFGBVS VCCO [current_design]
set_property BITSTREAM.CONFIG.SPI_FALL_EDGE YES [current_design]
set_property BITSTREAM.CONFIG.SPI_32BIT_ADDR YES [current_design]

set_property BITSTREAM.CONFIG.CONFIGFALLBACK ENABLE [current_design]
# used for SPIx4 and 9 MHz
set_property BITSTREAM.CONFIG.TIMER_CFG 32'h000C416C [current_design]

 

golden design:

set_property BITSTREAM.CONFIG.SPI_BUSWIDTH 1 [current_design]
set_property CONFIG_MODE SPIx1 [current_design]

set_property BITSTREAM.CONFIG.CONFIGRATE 9 [current_design]
set_property CONFIG_VOLTAGE 2.5 [current_design]
set_property CFGBVS VCCO [current_design]
set_property BITSTREAM.CONFIG.SPI_FALL_EDGE YES [current_design]
set_property BITSTREAM.CONFIG.SPI_32BIT_ADDR YES [current_design]

set_property BITSTREAM.CONFIG.CONFIGFALLBACK ENABLE [current_design]
set_property BITSTREAM.CONFIG.NEXT_CONFIG_ADDR 32'h00800000 [current_design]
# used for SPIx1 and 9 MHz
set_property BITSTREAM.CONFIG.TIMER_CFG 32'h003105AF [current_design]

0 Kudos
1 Solution

Accepted Solutions
Moderator
Moderator
727 Views
Registered: ‎06-05-2013

Re: Kintex7 SPI multiboot stall

Jump to solution

Refer to this AR# https://www.xilinx.com/support/answers/58249.html

I assume you are editing the mcs file via hex editor. Because the FPGA configuration process logic gets stuck after receiving a corrupted packet, no further action (for example fallback) will be taken. The FPGA hangs and can never boot until the configuration image is properly updated again. This seems to be the case here.

 

Any reason for using different SPI buswidth for both the images?

 

Although you can try to corrupt the IDCODE and check if it fails or fallback correctly. Your design works fine when you load the multiboot image. It would be good to try timer barrier method which we have shared within XAPP1247. This would be ideal for this situation and take care of other case. Like sync word for update image or corruption in the later part of the image.

Basically you will be adding 2 timers. One before the update image and other after the update image.

1st timer will take care of sync word of update image and 2nd timer will take care of rest of the image. We have shared the script in the reference designs, please use that to generate the timers as per the design setup.


Can you append the mcs file via HW manager and see if anything changes. 

 

Check these steps:-

 

Program flash with original multiboot file.

Update the flash data with the corrupt mcs file. Using the config file only option. Check the below snapshot:

 

captu.jpg

 

 

 

Thanks

Harshit

-------------------------------------------------------------------------
Don’t forget to reply, kudo, and accept as solution.
-------------------------------------------------------------------------
0 Kudos
3 Replies
Moderator
Moderator
728 Views
Registered: ‎06-05-2013

Re: Kintex7 SPI multiboot stall

Jump to solution

Refer to this AR# https://www.xilinx.com/support/answers/58249.html

I assume you are editing the mcs file via hex editor. Because the FPGA configuration process logic gets stuck after receiving a corrupted packet, no further action (for example fallback) will be taken. The FPGA hangs and can never boot until the configuration image is properly updated again. This seems to be the case here.

 

Any reason for using different SPI buswidth for both the images?

 

Although you can try to corrupt the IDCODE and check if it fails or fallback correctly. Your design works fine when you load the multiboot image. It would be good to try timer barrier method which we have shared within XAPP1247. This would be ideal for this situation and take care of other case. Like sync word for update image or corruption in the later part of the image.

Basically you will be adding 2 timers. One before the update image and other after the update image.

1st timer will take care of sync word of update image and 2nd timer will take care of rest of the image. We have shared the script in the reference designs, please use that to generate the timers as per the design setup.


Can you append the mcs file via HW manager and see if anything changes. 

 

Check these steps:-

 

Program flash with original multiboot file.

Update the flash data with the corrupt mcs file. Using the config file only option. Check the below snapshot:

 

captu.jpg

 

 

 

Thanks

Harshit

-------------------------------------------------------------------------
Don’t forget to reply, kudo, and accept as solution.
-------------------------------------------------------------------------
0 Kudos
Adventurer
Adventurer
687 Views
Registered: ‎08-21-2017

Re: Kintex7 SPI multiboot stall

Jump to solution

Hi @harshit,

 

Thanks for your reply, I see my understanding of the time barrier method wasn't good enough. XAPP1247 suggests Time Barrier as an alternative to calculating precisely Watchdog intervals. But now I see that using only one watchdog actually leaves a possibility of boot stall - so this is definitely not something that I want to use. I'll try implementing Time Barrier method - I just need first to solve the issue of FPGA not booting at all (either over JTAG or SPI), which prevents me from reprogramming SPI FLASH.

 

To answer your question, when previously debugging multiboot, I accidentally discovered that Golden design always boots in SPIx1 mode - so Watchdog interval needs to be adapted. I keep SPIx1 setting here for Golden design as a reminder - I could keep SPIx4, but it would be misleading.

 

Best regards

 

Srdjan

 

 

0 Kudos
Moderator
Moderator
665 Views
Registered: ‎06-05-2013

Re: Kintex7 SPI multiboot stall

Jump to solution
You can post the other query within new post. Our community will definitely help you out. Refer to this XAPP https://www.xilinx.com/support/documentation/application_notes/xapp586-spi-flash.pdf which might give you a clue.
Thanks
-------------------------------------------------------------------------
Don’t forget to reply, kudo, and accept as solution.
-------------------------------------------------------------------------
0 Kudos