2018-06-25 08:44 AM
We are testing SBSFU on a 32L476_nucleo board, using the 2-image example project with IAR EWARM.
We can reliably build and update the application in the way suggested.
We would like the roll-back feature to work properly - we have been introducing deliberate bugs which cause application watch-dogs, and after 3 of these, SBSFU marks the downloaded application as BAD. So far, so good.
However, SBSFU refuses to roll back to the application in the other image slot because the reported version is the same as the new (buggy) application (in this case, 1).
From the readme file in the application section of the project:
3. Pressing 3 allows to call user defined services running in Secure Engine.
As an example, SE_APP_GetActiveFwInfo service is called in order to display the firmware informationlocated in the protected area such as version and size.What is the correct way to define the application firmware version so that the secure engine can read it and decide if a roll-back is possible?
#sbsfuSolved! Go to Solution.
2018-07-12 08:25 AM
My colleague figured it out: The application version number is defined as the last argument in the post-build command line for the User Application. It's a 16-bit int, and needs to increment with every release or else the roll-back mechanism won't work. The number below is the starting point, so the next application firmware would be 2.. etc.
2018-07-12 08:25 AM
My colleague figured it out: The application version number is defined as the last argument in the post-build command line for the User Application. It's a 16-bit int, and needs to increment with every release or else the roll-back mechanism won't work. The number below is the starting point, so the next application firmware would be 2.. etc.