Continuous reset loop with SBSFU on STM32L4R9. Reset always happens right at the moment the secure engine is called.

NAhme.2 · ‎2021-05-20

When the Secure Engine Call (inside SE_Init() function) is called in this line:

e_ret_status = (*SE_CallGatePtr)(SE_INIT_ID, peSE_Status, primask_bit, uSystemCoreClock);

(which is between a SE_EnterSecureMode and SE_ExitSecureMode).

The MCU resets at this point, the reset happens continuously (reset loop) always at this line. The code executed until after SE_EnterSecureMode(&primask_bit); is called. I have added TRACE calls to check this.

Here is the problem area:

/* Enter Secure Mode */
  TRACE("\r\n= [SE_Init] SE_EnterSecureMode...");
  SE_EnterSecureMode(&primask_bit);
 
  /* Secure Engine Call */
  TRACE("\r\n= [SE_Init] (*SE_CallGatePtr)..."); //RESET HAPPENS BELOW:
  e_ret_status = (*SE_CallGatePtr)(SE_INIT_ID, peSE_Status, primask_bit, uSystemCoreClock);
  TRACE("\r\n= [SE_Init] (*SE_CallGatePtr) done");
 
  /* Exit Secure Mode */
  TRACE("\r\n= [SE_Init] SE_ExitSecureMode...");
  SE_ExitSecureMode(primask_bit);

I have setup all other paramters correctly for STM32L4R9 following AN5056 section 3 (Porting X-CUBE-SBSFU to another board) and have made appropriate memory mapping changes for Secure Engine, SBSFU, Download Area, Active Image defined flash sections. Also the SE RAM1 sections. As per errata, I have defined SE firewall protected RAM1 to be under maximum 128KB (instead of 192KB) - actually just 4KB.

I have also seen this issue and applied the recommendation, to no success:

https://community.st.com/s/question/0D50X0000ADEGfr/firewall-reset-when-accessing-unprotected-sram1-memory-stm32l4r9

I have no idea what is happening. I'm not even sure it's the firewall spurious reset. I disabled SFU_FWALL_PROTECT_ENABLE define and the same issue persists. Also if it was an actual firewall (or other reset) I would get the TRACE printout telling me that. This is just a inexplicable reset.

Any help is appreciated. It's a complete showstopper with SBSFU.

NAhme.2 · ‎2021-05-31

Hello Jocelyn,

You are exactly right, over the weekend that exactly what I did. I loaded the .elf symbols from SECoreBin for debugging in the SBSFU project.

And I placed breakpoint for SECallGate function calls and figured out the issue was happening in the SECoreBin project file se_low_level.c in the function:

SE_ErrorStatus SE_LL_Buffer_in_ram(void *pBuff, uint32_t Length)

At the if statement check:

  /* Check if length is positive with no overflow */
  if ((Length != 0U) && (!((0xFFFFFFFFUL - addr_start) < Length))
      && (((addr_start >= SRAM1_BASE) && (addr_end <= 0x20017FFFU)) ||
          ((addr_start >= SRAM2_BASE)  && (addr_end <= 0x10007FFFU))))

So this of course is using hard-coded values for SRAM1 and SRAM2 end address checking. Also I was using SRAM3 which the STM32L4R9 has, but not the STM32L476. So I modified this check and this issue is now resolved!.

I wish ST didn't hard-code these values and used #define constant names based on which microcontroller is defined for the project. As a developer I am using ST's software libraries to develop an end product, and really spent way too much time debugging this issue. I see most everywhere else there are no such hard-coded values, so this one was a bit of a surprise.

Nabeel

Jocelyn RICARD · ‎2021-05-31

Hello Nabeel,

OK thank you for your feedback.

I had a look to other projects and this value is not always hardcoded.

I guess the reason here is that we need to provide the whole RAM and there is no symbol that can be used for this purpose.

Also, even if a symbol could be used, in your case you would still had to modify the code to add this SRAM3.

Anyway, I agree this is frustrating !

Best regards

Jocelyn

NAhme.2 · ‎2021-05-31

It's actually even more nuanced. Due to notes in the errata "Spurious Firewall reset" for STM32L4Rxxx, there is issue with sharing the lower 18-bits with SRAM1 SE Firewall region.

So this issue neatly described the safe regions that can be used:

https://community.st.com/s/question/0D50X0000ADEGfr/firewall-reset-when-accessing-unprotected-sram1-memory-stm32l4r9

Maybe someone can add a bit more obvious note somewhere in SBSFU documentation about these issues, if using STM32L4R9 etc.

NAhme.2 · ‎2021-06-02

Hi Jocelyn,

So moving on from this issue, is there possibly other hard-coded areas of the firmware?

Now with the first issue resolved, I get the following (All the protections in app_sfu.h are disabled for now during debugging/tesitng):

= [SBOOT] SECURE ENGINE INITIALIZATION SUCCESSFUL
= [SBOOT] STATE: CHECK STATUS ON RESET
          INFO: A Reboot has been triggered by a Software reset!
          INFO: Last execution detected error was: No error. Success.
= [SBOOT] STATE: CHECK NEW FIRMWARE TO DOWNLOAD
= [SBOOT] STATE: CHECK USER FW STATUS
          New Fw to be installed from slot SLOT_DWL_1
= [SBOOT] STATE: INSTALL NEW USER FIRMWARE
          Abnormal error 2 at line 1161 in D:/Robbox/new_project/level/STM32_SBSFU/Project/STM32L4R9_Level/Applications/2_Images/2_Images_SBSFU/SBSFU/App/sfu_fwimg_swap.c - CONTINUE
= [SBOOT] STATE: HANDLE CRITICAL FAILURE
= [EXCPT] DECRYPT FAILURE!
= [SBOOT] STATE: REBOOT STATE MACHINE
========= End of Execution ==========

Abnormal error 2 seems to points to "SFU_IMG_FLASH_WRITE_FAILED" as the return status for the function call "SFU_LL_FLASH_Write(...) in sfu_fwimg_swap.c

Any ideas why this is happening now?

Jocelyn RICARD · ‎2021-06-03

Hello,

STM32L4R9 can be single or dualbank.

You need to check if the conversion between address and page is adapted to your configuration

Best regards

Jocelyn

NAhme.2 · ‎2021-06-03

Hi,

can you explain that a little more.

so far I’ve disabled dual-bank operation in the option bytes, and also defined NO_SWAP.

Where do I check/configure what you’re saying?

Jocelyn RICARD · ‎2021-06-03

Hello,

Depending on the example you used as source to make your porting you may need to adapt what the code located in SBSFU/Target

especially sfu_low_level_flash_int.c

Easiest way to understand what happens is to put a breakpoint on the call to flash write just before the line 1161, and go into to understand where it fails

Best regards

Jocelyn

NAhme.2 · ‎2021-06-03

Hi Jocelyn,

Thank you for your quick responses!

So when I disable all the protections in app_sfu.h, the above issue on line 1161 disappears (I was wrong in that post when I said protections were disabled, they were all enabled actually).

So now (with app_sfu.h protections disabled) I'm able to send a full image (UserApp.sfb) over YMODEM using TeraTerm. After the full image transfer, it Reboots and beings to install the new image, but doesn't proceed beyond that. So it's stuck installing the update somehow:

= [SBOOT] SECURE ENGINE INITIALIZATION SUCCESSFUL
= [SBOOT] STATE: CHECK STATUS ON RESET
          INFO: A Reboot has been triggered by a Software reset!
          INFO: Last execution detected error was: No error. Success.
= [SBOOT] STATE: CHECK NEW FIRMWARE TO DOWNLOAD
= [SBOOT] STATE: CHECK USER FW STATUS
          New Fw to be installed from slot SLOT_DWL_1
= [SBOOT] STATE: INSTALL NEW USER FIRMWARE
          Image preparation done.
          Installation started ...

So it never proceeds after the "Installation started ..."

I am trying to get this working with all protections disabled, then will solve the issues related to that once I have at least a setup working with protections disabled.

Any clues to the above?

PS: I have adapted SBSFUs STM32l476G-DISCO example for use with my STM32L4R9VGT project.

Nabeel

NAhme.2 · ‎2021-06-03

The SBSFU is now fully working on STM32L4R9VG. As for the last issue in recent conversation, I had to re-enable dual-bank operation in the Option Bytes (using STM32CubeProgrammer) - which are enabling DB1M, and DBANK. Due to the fact that the SBSFU code I'm using was based on STm32L476G which had code in sfu_low_level_flash_int.c for dual-bank mode erase etc., I also re-enabled dual-bank on STM32L4R9. Or else in single-bank mode only mass erase it used, not bank erase - so this would've required rewriting code in that file, any other possible unforeseen consequences. The issue on pausing at "Installation Started..." had to to with the system hanging in the erase operation awaiting last operation to finish. Also for STM32L4R9 there isn't MPU protection (as far as I've seen) so those protections are disabled in app_sfu.h.

It is now fully working with all other protections enabled.

Jocelyn RICARD · ‎2021-06-04

Hello,

OK thank you for your feedback.

Just for your information, single bank is normally easier to manage as there is no risk related to firewall vs bank swap. This releases a constraint on the mapping of the slots. If you want to make single bank working, normally only flash service implementation in target directory is needed to be changed.

Best regards

Jocelyn