cancel
Showing results for 
Search instead for 
Did you mean: 

SBSFU: "Installation not validated" error if version number is increased

MBax.2
Senior

@Jocelyn RICARD​ 

I've built, installed and used SBSFU to successfully update the firmware through the serial terminal with a YModem transfer. This update was from version "0" to version "1".

Now I have built a new version "2" which only differs from version "1" in that it prints a different version number at startup. The build process and scrips used are exactly the same. Now when I try to install version "2", it downloads correctly, but after that SBSFU throws an error: "Installation not validated: rollback procedure initiated (SLOT_ACTIVE_1 / SLOT_DWL_1)"

I've tried it multiple times, each update from "0" to "1" works without problems, but going from "1" to "2" throws the same error. I'm completely mystified.... Log is attached.

1 ACCEPTED SOLUTION

Accepted Solutions
Jocelyn RICARD
ST Employee

Hello @Community member​ ,

First, thank you for sharing your project and build details. Build went smoothly.

Regarding debug configuration. You added SBSFU in the picture.

To make things work with also SBSFU, the SECoreBin.elf should be in first place.

One possible reason for the issue you are facing (step debugging is going in random places) could be related to your USB cable or intermediate USB Hub.

You can give it a try.

Regarding the issue, the first thing I can see is that you are calling SE_APP_ValidateFw unconditionally.

As you can see in the SE code, if you want to validate a firmware that is already validated, you get an error.

But the issue is still here.

For some reason, when calling HAL_Init() in your code, the flash of the flash PGERR is rising. I couldn't find the reason as this seems related to some interrupts triggering at early stages.

Now, if you clear this flash before calling the service the validation works.

So, here is the code I used to make it work:

	  if (fw_state_mb == 3)
	  {
		  if (__HAL_FLASH_GET_FLAG(FLASH_FLAG_PGSERR))
		  {
			  LogPrint("Clearing FLASH_FLAG_PGSERR flag \r\n");
			  __HAL_FLASH_CLEAR_FLAG(FLASH_FLAG_PGSERR);
		  }
		  if(SE_SUCCESS == SE_APP_ValidateFw(&eSE_Status, SLOT_ACTIVE_1)){
			  LogPrint("\n\rFirmware validated..\n\r");
		  }
		  else{
			  LogPrint("\n\rFirmware validation error..\n\r");
		  }
	  }

Then here is the trace I get:

Current firmware state = [FWIMG_STATE_SELFTEST]..

Clearing FLASH_FLAG_PGSERR flag

Firmware validated..

So, something needs to be checked at ealy initialization in HAL_Init but you have at least a validated image 🙂

Best regards

Jocelyn

View solution in original post

28 REPLIES 28
MBax.2
Senior

Additional test results. I decided to skip the YModem installation of version "2" and installed it with an ST-Link. I then used Ymodem to install from "2" to "3". That worked without any problems. Then I made a version "4" and got the same error. "Installation not validated: rollback procedure initiated (SLOT_ACTIVE_1 / SLOT_DWL_1)"

So it seems that the version number is not relevant (what your would expect), but the second update via Ymodem always fails.

Jocelyn RICARD
ST Employee

Hello @Community member​ ,

this behaviour is strange indeed.

Could you please provide which project and which IDE you are using, I will try to reproduce.

I guess you are using latest version 2.6.0 of SBSFU.

Best regards

Jocelyn

MBax.2
Senior

Thank you for your help. I am using:

STM32CubeIDE

Version: 1.8.0

Build: 11526_20211125_0815 (UTC)

From SBSFU 2.6.0, I've included the following projects:

B-L4S5I-IOT01_2_Images_KMS_Blob

B-L4S5I-IOT01_2_Images_SBSFU

B-L4S5I-IOT01_2_Images_SECoreBin

MBax.2
Senior

I tried it again a few times. It 100% reproduces. My steps:

-Install a userapp version X with ST-Link

-Boot

-Reboot, keeping the user button depressed to initiate YModem transfer

-Build a version X+1, download it via Ymodem. --> Results in successfull installation

-Build a version X+2

-Reboot, keeping the user button depressed to initiate YModem transfer

-Upload version X+2 via YModem transfer --> Results in "Installation not validated: rollback procedure initiated (SLOT_ACTIVE_1 / SLOT_DWL_1)"

MBax.2
Senior

Some more testing. Instead of compiling my own app, I tried it with the original SBSFU user app. I first installed "A" with Ymodem, all ok. Then I tried to install "B", same error as before. See log attached.

MBax.2
Senior

And some more testing. This time I did not user the user button, but instead used the UI of the userapp to initiate the transfer. I installed version "B" with ST-Link. Then upgraded to "C" with Ymodem, then tried to upgrade again to "D" using YModem and ran into the same error. See log attached.

MBax.2
Senior

As a final check to make sure the error is not on my side, I made a new empty CubeIDE workspace and downloaded a new fresh copy of SBSFU 2.6.0. I then added the 4 projects:

B-L4S5I-IOT01_2_Images_KMS_Blob

B-L4S5I-IOT01_2_Images_SBSFU

B-L4S5I-IOT01_2_Images_SECoreBin

B-L4S5I-IOT01_2_Images_UserApp

I then compiled everything (in the order SECoreBin, SBSFU, KMS_Blob, UserApp). Flashed SBSFU_UserApp.bin with ST-Link. Booted and used the UserApp UI to trigger a YModem firmware upgrade.

In the UserApp project, I changed the version name from "A" to "B" and the version number from "1" to "2" in the post build steps command and rebuilt. I then uploaded the generated UserApp.sfb with TeraTerm YModem and the firmware installed successfully.

I then changed the version name from "B" to "C" and the version number from "2" to "3" in the post build steps command and rebuilt. I then uploaded the generated UserApp.sfb with TeraTerm YModem and this time the error returned "Installation not validated: rollback procedure initiated (SLOT_ACTIVE_1 / SLOT_DWL_1)".

Attached is the complete log of the process.

The only conclusion I can come up with is that the problem lies in SBSFU 2.6.0, please advise what to do, this is blocking my product launch.

MBax.2
Senior

@Jocelyn RICARD​ 

Just made an observation that might point more directly to the core of the problem. The first version must always be installed with ST-Link. The second version/install thereafter installs correctly with YModem and boots and runs. However a simple power cycle than gives the problem and reverts "B" back to "A" due to this. See attached log.

New edit: another observation; Just performed the update from "A" to "B" via OTA instead of YModem. This gave the same problem. After the update, the images are swapped and "B" starts normally. Then, after a powercycle the error is given and "B" is reverted back to "A"

Please let me know if there's anything else I can do to help debug this. This is a very urgent problem for my product release.

Jocelyn RICARD
ST Employee

Hello @Community member​,

OK, thank you for the details.

The issue you get is related to the activation of the image validation option.

If you launch the original user application you will get a menu displayed on the terminal.

=================== Main Menu ============================
  Download a new Fw Image ------------------------------- 1
  Test Protections -------------------------------------- 2
  Test SE User Code ------------------------------------- 3
  Multiple download ------------------------------------- 4
  Validate a FW Image------------------------------------ 5
  Test tKMS --------------------------------------------- a
  Selection :

You can see this Validate a FW Image.

If the image is not validated after installation, SBSFU automatically triggers a rollback.

Image validation feature is a way to ensure that new installed application is correctly running.

You can add a specific test in your application like a connection test. If it passes the test you just call the SE_APP_ValidateFw service. If this service is not called, on next reset or new image installation, it will detect that image is not validated and trigger a rollback to previous working image.

So, you have 2 solution.

1) You keep this configuration and you add the call to SE_APP_ValidateFw in your application

2) You disable this validation feature. This feature is activated as a compilation flag : ENABLE_IMAGE_STATE_HANDLING

Best regards

Jocelyn