Skip to main content
MBax.2
MBax.2
Associate III
July 1, 2022
Solved

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

  • July 1, 2022
  • 28 replies
  • 8853 views

@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.

This topic has been closed for replies.
Best answer by Jocelyn RICARD

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

28 replies

Show previous replies
MBax.2
MBax.2Author
Associate III
July 4, 2022

I added the code to the SBSFU example user app an that works, when I add the same code to my own app, it throws the error. I'm lost, no idea how to debug this.

MBax.2
MBax.2Author
Associate III
July 4, 2022

Prior to calling SE_APP_ValidateFw() I added a call to SE_APP_GetActiveFwState() to my own app as well as the user app. These both give the same image state [FWIMG_STATE_SELFTEST], while the successive call to SE_APP_ValidateFw() succeeds in my modified userapp and fails in my own application.

Jocelyn RICARD
Jocelyn RICARD
ST Employee
July 4, 2022

Hi @Community member​,

I understand you call modified userapp, the userapp example with some changes you made.

In your own application, did you change anything in the SBSFU setup ? Did you change the flash mapping for instance?

In any case, you can find the root cause of the issue using debugger.

Just create a debug configuration starting from your userapp.

Change debug configuration to remove application download (it will use what is already flashed).

Also add in "Startup" tab of debug configuration the SECodeBin.elf. Set it up as no build and no download.

This way, you will get your application symbols and the STCorebin symbols.

Set a breakpoint at the call to SE_APP_ValidateFw.

Then use assembly step into until you get back symbols. You should be inside Secure engine.

Set a breakpoint in SE_IMG_SetActiveFwState and see what happens

Best regards

Jocelyn

MBax.2
MBax.2Author
Associate III
July 4, 2022

During debugging, there are some values which I need to check, like e_ret_status which cannot be checked as the debugger mentions the value has been optimized out. When going through the code line by line is also skips parts it seems. Is there a optimization setting that I need to change?

Jocelyn RICARD
Jocelyn RICARD
ST Employee
July 4, 2022

Yes, you can deactivate compiler optimization for the file (right click on the file, properties, optimize for debug) , or for the function itself using pragma.

Other way to check values is to go at assembly level which is sometimes not so straightforward ... depends.

Best regards

Jocelyn

MBax.2
MBax.2Author
Associate III
July 5, 2022

@Jocelyn RICARD​ 

I've been trying to debug, with the compiler optimization for debug for SECoreBin, but eventhough the code is fairly straightforward, debugging it is a nightmare. I can't go through the code line by line, as there is erratic debugging behavior. Multiple lines are skipped, sometimes the debugger jumps backup while advancing one line, or debugging itself introduces a hardfault. After having spent 10 hours on this, I think this approach to find the problem might not be the right one.

Ideally for debugging I would just have a printf() to the uart. So I tried to add that, including the hal uart drivers and managed to build without errors, but the uart does not print. I did not do a uart_init as that is already done in SBSFU, so it should work, but I'm without ideas anymore.

When SE_IMG_SetActiveFwState() fails, what can be the reasons for this? Maybe if you have some pointers I can check that out. The userapp works, my custom app doesn't. They both use the same builds of SBSFU and SECoreBin. They both use the same STM32L4S5VITx_FLASH.ld file

Pulling my hairs here as this is my final bug to solve before a overdue product release.

Jocelyn RICARD
Jocelyn RICARD
ST Employee
July 5, 2022

Hello @Community member​,

The first thing I would look for is the write in flash.

Having exact same configuration of secure boot in both cases, it is quite strange anyway.

In your debugging, did you reach the function SE_IMG_SetActiveFwState ?

Be careful that if you change the compilation option for se_fwimg.c, I advise you clean and rebuild SBSFU. Dependency is not well managed. If you are not sure, best is to rebuild everything and download new SBSFU_UserApp.bin to the target.

I made the test to just change the optimization for se_fwimg.c to optimization for debug, and I can debug though the function flowlessly.

Also, what you could do to would be to replace the return SE_Error by a while(1) loop. This way you just need to stop the debugger and look where you are.

Also, add this loop just before jumping back from this function (return e_ret_status;)

Best regards

Jocelyn

MBax.2
MBax.2Author
Associate III
July 5, 2022

I'm trying allsorts of things to get the debugging working normally, right now its a mess.

In the meantime, can you elaborate on your statement "Having exact same configuration of secure boot in both cases, it is quite strange anyway."? What would you expect to be different then between the SBSFU configuration of the default userapp and my own custom app?

Jocelyn RICARD
Jocelyn RICARD
ST Employee
July 5, 2022

Hi @Community member​,

That's the point, I have no idea.

Now as you made this application, you can check on your side the different possible errors.

First one could be that your application was linked with different version of se_interface resulting in a different service call. But I guess you already checked that.

I didn't catch actually if you we able to break in SE_IMG_SetActiveFwState function.

This is really first step.

Then with the change of the optimization option, you should find rapidly what fails in this function

Best regards

Jocelyn

MBax.2
MBax.2Author
Associate III
July 5, 2022

Right now I'm struggling to get normal debugging operation. I did break into SE_IMG_SetActiveFwState, but then I cannot step through it normally and the breaks jump all over the place. I'm confident I can at least find the source of the bug if I can debug. So I'm going to try some more things to hopefully get debugging sorted. If I can't I will make a detailed description how I setup debugging, perhaps you can then tell me what I'm doing wrong.

Show more replies
Terms & ConditionsAccessibility statement