cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
afantina
Contributor
Contributor
488 Views
Registered: ‎04-04-2019

Fallback after CRC error does not work

Jump to solution

Hi all,

I have a problem with Fallback feature on Artix7 FPGA  connected to SPIx4 Flash device. 

I generated Golden image with this setup:


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.CONFIGFALLBACK ENABLE [current_design]
set_property BITSTREAM.CONFIG.NEXT_CONFIG_ADDR 0x0400000 [current_design]

 

Update image is on location 0x0400000:


set_property BITSTREAM.CONFIG.SPI_FALL_EDGE YES [current_design];

set_property BITSTREAM.CONFIG.CONFIGFALLBACK ENABLE [current_design]

Setup for generate .mcs file is like this:

mcs.png

When I was testing my fallback feature, I corrupted few bytes in my hex edditor to force CRC error (In the middle of the  Update.bit file). But when I program my flash device, here is what I see:

CRC_error_not_issue_fallback.PNG

 

 

 

 

 

 

 

BIT5_0_CRC_ERROR is high, but fallback bit is zero... When I check WBSTAR value, it is correct - 0x00400000.

Can you help me with this issue? Why fallback not occured? 

Br,

afantina

Tags (2)
0 Kudos
1 Solution

Accepted Solutions
hj
Moderator
Moderator
458 Views
Registered: ‎06-05-2013

@afantina 

Please update your generated MCS file. You have added the update.bit as a data file. Follow the below snapshot and regenerate the MCS file. Please do some basic tests first like the bad IDCODE test. 

Capture_232.JPG

-------------------------------------------------------------------------------------
For more information please refer to configuration resources https://forums.xilinx.com/t5/FPGA-Configuration/Configuration-Resources/m-p/753763/highlight/true#M5891
-------------------------------------------------------------------------
Don’t forget to reply, kudo, and accept as solution.
-------------------------------------------------------------------------

View solution in original post

4 Replies
miker
Xilinx Employee
Xilinx Employee
479 Views
Registered: ‎11-30-2007

@afantina 

Is your FALLBACK bitstream configured to a SPIx1?

forums_7series_goldenFallback.png

Please Reply, Kudos, and Accept as Solution.
0 Kudos
hj
Moderator
Moderator
459 Views
Registered: ‎06-05-2013

@afantina 

Please update your generated MCS file. You have added the update.bit as a data file. Follow the below snapshot and regenerate the MCS file. Please do some basic tests first like the bad IDCODE test. 

Capture_232.JPG

-------------------------------------------------------------------------------------
For more information please refer to configuration resources https://forums.xilinx.com/t5/FPGA-Configuration/Configuration-Resources/m-p/753763/highlight/true#M5891
-------------------------------------------------------------------------
Don’t forget to reply, kudo, and accept as solution.
-------------------------------------------------------------------------

View solution in original post

404 Views
Registered: ‎01-22-2015

@afantina 

-advice from moderator hj should get fallback after a CRC error working for you.

Then, you'll probably want to add fallback after a WATCHDOG_TIMEOUT.  To get this fallback, use a constraint similar to the following for generation of both the golden and update image:

# sets timeout ~30s : bit31=0, bit30=1, bits[29:0]=tics of 250KHz clock
set_property BITSTREAM.CONFIG.TIMER_CFG 0x40735B40 [current_design]


The above constraint configures the WATCHDOG_TIMER for a timeout of about 30 secs.  That is, if the update image does not load within 30 sec, then there is a fallback to the golden image.

It is the responsibility of the update image to setup the WATCHDOG_TIMER.  However, some types of corruption in the update image (eg. update image is blank) can fail to setup the WATCHDOG_TIMER and thus a fallback after WATCHDOG_TIMEOUT will not occur.  The solution for this problem is to place barrier images before and after the update image in flash memory and change the NEXT_CONFIG_ADDR to point to the start of the first barrier image.  See appendix-A of XAPP1247 for more information on barrier images.

Finally, you are probably developing multiboot capability so that you can eventually do a remote update of the FPGA configuration.  So, the next step is to develop a means of sending the image.bin file to the FPGA (eg. via LAN/ethernet).  Then, develop HDL that receives image.bin and writes it to the appropriate address-range in flash memory.  If this remote update of image.bin fails then you should get fallback to the golden image.  The golden image is never updated remotely.

Cheers,
Mark

miker
Xilinx Employee
Xilinx Employee
327 Views
Registered: ‎11-30-2007

@afantina 

Did @hj , markg@prosensing.com , and/or my reply to the post resolve your issue? If so, please select Accept as Solution to the post that resolved your issue so that others may benefit from your experience. If you found any of the replies helpful, please also provide a Kudos.

Please Reply, Kudos, and Accept as Solution.
0 Kudos