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

[MBax.2]

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

[MBax.2]

@Jocelyn RICARD​ 

Thank you for your quick reply.

I added the following to my main() to validate the firmware after boot:

  SE_StatusTypeDef eSE_Status = SE_OK;

  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");

  }

I can see the "Firmware validation error" appear in my log however. Am I overlooking something?

[MBax.2]

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]

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]

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]

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]

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]

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

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]

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]

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