cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
Highlighted
10,568 Views
Registered: ‎06-20-2013

Spartan-6 'Safe Update' will not fallback

Jump to solution

Hi All,

 

I am trying to get the 'Safe Update' mechanism working. I want to have a small HEADER image in FLASH at address 0x0 that will program the FPGA with the MAIN image at address 0x600000. However, if that MAIN image is corrupt then I want the FPGA to 'fallback' and be programmed with the GOLDEN image at address 0x10000. Both the MAIN image and GOLDEN image allow me to overwrite (via Ethernet) the MAIN image in the field with a new image. The GOLDEN image is in an area of FLASH that is protected so cannot be overwritten in the field.

 

FLASH.png

 

I have manually generated a HEADER image.

 

HEADER.png

 

I have set the address of the MAIN image to 0x600000 and the address of the GOLDEN image to 0x10000. I have written the HEADER, GOLDEN and MAIN images to FLASH. When I powercycle the FPGA the HEADER image loads and programs the FPGA with the MAIN image.

 

However, if I corrupt the MAIN image and powercycle the FPGA the GOLDEN image is not loaded. Thinking that I must have the GOLDEN image at the incorrect address I swapped the addresses of the MAIN and GOLDEN images in the HEADER image and powercycled the FPGA. The HEADER image loads and programs the FPGA with the GOLDEN image. Therefore, the addresses in FLASH of the GOLDEN and MAIN images are correct and the HEADER image appears to be configured correctly, but the 'fallback' mechanism doesn't appear to be working.

 

What have I done wrong?

 

Thanks,

 

Simon

0 Kudos
1 Solution

Accepted Solutions
Highlighted
11,318 Views
Registered: ‎06-20-2013

It was a while back now, but I belive that I resoved this issue by ticking the '-g reset_on_error:' option in ISE > Generate Programming File (right click for properties) > General Options in my main image.

 

Presumable if the SYNC word is found but the CRC fails then this option causes a reset which in turn fallsback to the golden image.

 

Appears to work for me.

 

Simon

View solution in original post

0 Kudos
11 Replies
Highlighted
Moderator
Moderator
10,545 Views
Registered: ‎01-15-2008

Hi,

 

Can you check if the following option is set in your bitgen settings

next_config_register_write:Disable in the main image.

If not set this option and let us know the results. Also share us the status registers during configuration failure to golden image.

 

--Krishna 

0 Kudos
Highlighted
Community Manager
Community Manager
10,543 Views
Registered: ‎07-23-2012
Hi,

How did you corrupt the multiboot image? Did you edit the CRC register?

Please note that either a CRC error or a watchdog time out error (tracks the time taken for the detection of sync word) triggers fallback in Spartan6 devices.

If you are editing the contents of the multiboot image, you have to be 100% sure that the corrupted image throws a CRC error during configuration.
To test whether the image was corrupted properly or not, please configure the FPGA with the multiboot image in JTAG mode. If the configuration fails with a CRC error then we should expect the fallback assuming that the bitgen settings were set to appropriate values.

Regards,
Krishna
-----------------------------------------------------------------------------------------------
Please mark the post as "Accept as solution" if the information provided answers your query/resolves your issue.

Give Kudos to a post which you think is helpful.
0 Kudos
Highlighted
10,537 Views
Registered: ‎06-20-2013

Hi Krishna(s)?,

 

Thanks for your reply.

 

I have "Place MultiBoot Settings into Bitstream" unticked in the Main image and Golden image.

 

During a failure I never get to the Golden image so I cannot read the Status registers.

 

I corrupted the Main image by only writing half the image to FLASH (aborted the data transfer before it is finished, something that may well happen in the field), I presume that this has corrupted the Main image because after a powercycle the FPGA will not program (DONE LED is off). Since I have written half the image the SYNC word 0xaa995566 will be found, as it is at the beginning of the image so presumably this means that the watchdog will not timeout. Writing half the image may or may not result in a CRC error. However, since the FPGA has not been programmed then presumably some sort of error has occurred.

 

I tried to manually edit the Main image bitfile, prior to programming via Impact. However, Impact threw an ERROR stating that the byte I changed was invalid and then crashed (Impact application closed).

 

Regards,

 

Simon

 

0 Kudos
Highlighted
Community Manager
Community Manager
10,531 Views
Registered: ‎07-23-2012

Hi Simon,

 

The easy way would be to edit the CRC register value in the bitstream.

 

How to find the CRC register in .bit file?

 

The CRC register is a type1 packet register. Refer to Table 5-24, page 91 of UG380 for a description of a Type 1 Packet:

 

  Since we are looking for CRC value,the command for type1 write1 to CRC register would be->

 

001 xx xxxxxx xxxxx

 

001 10 000000 00010

 

10 is determined from Table 5-23

000000 is determined from Table 5-30 as the CRC register address is 6'h00

 

Translating this to HEX is 30 02.

 

In your bit file,search for the value 30 02 by opening the bit file in any editor. The value followed by 30 02 is the CRC value.

 

Now, edit this crc value to some random value. This will help in throwing the CRC error.

 

Try this and see if the fallback works correctly.

 

Regards,

Krishna 

-----------------------------------------------------------------------------------------------
Please mark the post as "Accept as solution" if the information provided answers your query/resolves your issue.

Give Kudos to a post which you think is helpful.
0 Kudos
Highlighted
10,527 Views
Registered: ‎06-20-2013

Hi Krishna,

 

There are three instances of 0x30 02 in my bitfile. If I modify the byte following 0x30 02 in each instance individually the bitfile still sucessfully programs the FPGA using Impact in each instance.

 

Regards,

 

Simon

0 Kudos
Highlighted
Community Manager
Community Manager
10,524 Views
Registered: ‎07-23-2012
Hi Simon,

There should be only one 0X3002. Can you please attach the bit file?

Regards,
Krishna
-----------------------------------------------------------------------------------------------
Please mark the post as "Accept as solution" if the information provided answers your query/resolves your issue.

Give Kudos to a post which you think is helpful.
0 Kudos
Highlighted
10,521 Views
Registered: ‎06-20-2013

Hi Krishna,

 

The three instances of 0x3002 are as shown below.

 

0x3002#1.PNG

 

0x3002#2.PNG

 

0x3002#3.PNG

 

Regards,

 

Simon

0 Kudos
Highlighted
10,507 Views
Registered: ‎06-20-2013

Update:

 

Using the 'Read Device Status' option in IMPACT here is the output when the Main image is good .....

 

StatusGood.PNG

 

...and here is the output when the Main image is corrupted (by only writing half the image to FLASH) ...

 

StatusBad.PNG

 

... this shows that the Main image corruption has caused a CRC error, but also that FALLBACK has not occured.

 

Any ideas why?

 

Simon

0 Kudos
Highlighted
10,500 Views
Registered: ‎06-20-2013

Further Update:

 

I removed the SYNC word completly from the MAIN image and after a powercycle the GOLDEN image loaded. When I read the status register it looked like this ....

 

StatusWatchdog.PNG

 

.... so fallback is working, but only when the WATCHDOG times out as a result of not finding the SYNC word.

 

The question is why does fallback not work when there is a CRC error?

 

Thanks,

 

Simon

0 Kudos
Highlighted
Observer
Observer
5,803 Views
Registered: ‎09-13-2012

> .... so fallback is working, but only when the WATCHDOG times out as a result of not finding the SYNC word.
> The question is why does fallback not work when there is a CRC error?

 

Hi Simon,

we expect the same behavior here, we did a bunch of tests with Spartan6 Multiboot and I can confirm:

It works when the SYNC word isn't there but a corrupted image (due to a canceled update for example) won't trigger the fallback. Is there a solution to it in the meanwhile?

 

Greetings,

0 Kudos
Highlighted
11,319 Views
Registered: ‎06-20-2013

It was a while back now, but I belive that I resoved this issue by ticking the '-g reset_on_error:' option in ISE > Generate Programming File (right click for properties) > General Options in my main image.

 

Presumable if the SYNC word is found but the CRC fails then this option causes a reset which in turn fallsback to the golden image.

 

Appears to work for me.

 

Simon

View solution in original post

0 Kudos