XAPP1247 is an example application for Multiboot and Fallback when using Barrier Images.
This blog entry covers a method to test the barrier timer flow and an issue that can arise when doing so.
There are many different ways to test the barrier timer flow, including the two below:
With option 1 (deleting the end of the image), it is possible to observe a fallback due to the time-out error.
However, with option 2 (corrupting the sync word) there can be issues.
Say for example that you edited the sync word from AA995566 to ABCDABCD to cause the corruption.
If the sync word is edited in a hex editor, then it loads the update image instead of falling back.
Why does it load the Update image, even if the sync word of the update image is corrupted?
The sync word has already been detected in Timer Image 1/Barrier Image1.
Because there is no DESYNC Word in Timer Image 1/Barrier Image1, it will not look for the sync word in the update image.
How to resolve the issue:
In this scenario, simply corrupting the sync word does not cause fallback to happen.
However if you add the DESYNC word after the timer image, the fallback to golden will happen.
How to add a DESYNC at the end of Timer Image 1/ Barrier Image1:
Open the MCS File in an editor. This contains the Golden image, Barrier Image1, the Multiboot image, and Barrier Image2.
At the end of Barrier Image1, add 30008001(Write CMD register) followed by 0000000D (DESYNC Word).The screen capture below shows how to add 30008001 (Write CMD register) followed by 0000000D (DESYNC Word)
Now save the MCS File.
You can now use this MCS File to boot from Flash and test correct fallback occurs.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.