AnsweredAssumed Answered

LPC55S69: Using Flash driver in TrustZone

Question asked by Olaf Heemskerk on Nov 19, 2019
Latest reply on Nov 30, 2019 by Sabina Bruce

Like • Show 0 Likes0
Comment • 4

LS,

I am trying to create 2 projects, 1 secure world, 1 non secure world that both need to be able to store application data in flash. The non secure world would store the data in Non secure part of the Flash, the secure world in the secure part of the flash.

As a starting point, I copied the flash driver code from the flashiap1 SDK example and added this code to the Hello world secure world project. I changed the clock to 100MHz using the function BOARD_BootClockPLL100M, since the flash cannot be erased or programmed at higher speeds.

According to the LPC55S6x User manual (UM11126.pdf), in section 7.5.3.3.2, an example is shown that describes the possibility to expose the Flash driver API to the normal world, although the example is limited to the flash_program function. An additional detail I noticed is that the example uses the boot ROM flash API directly, not the fsl_iap.c driver function FLASH_program.

I assumed the boot ROM flash driver still needs to be initialized. I therefore added a call to the function FLASH_Init in the secure world to initialize the driver. When I now try to debug my code, as soon as the call to flash_init is made, the debugger jumps to the hardfault handler with the IBUSERR(0) Instruction bus error.

Is my assumption actually correct, does the flash_init function need to be called and can it actually be called from the secure world?

If this is the case, what am I doing wrong. Since I am using the flash driver from the secure world, I also reasoned that the FLASH peripheral needed to be in S-Priv mode, but changing this setting this didn't solve the issue.

Any help would be greatly appreciated.

Regards,
Olaf Heemskerk

No one else has this question

Outcomes

Sabina Bruce

Nov 25, 2019 7:38 AM

Hello Olaf,

From what I'm understanding you would like to have the flash divided in two. One is completly secure and the other is completly non-secure. You would like to administer the secure via secure method and the non secure with non secure method(not non secure callable). Is this correct?

If so could you please confirm that the areas of memory which you are trying to access are in fact either secure and non secure(not NSC).

Also the IBUSERR can be caused by:

a) Branch to invalid memory regions for example caused by incorrect function pointers.

b) Invalid return due to corrupted stack pointer or stack content.

c) Incorrect entry in the exception vector table.

Which may be due to trying to access a section of memory without the proper permission.

Best Regards,

Sabina

Actions

Olaf Heemskerk @ Sabina Bruce on Nov 25, 2019 10:58 AM

Hi Sabina,

For my project, I want to have secure Flash storage that is only accessible within TrustZone, as well as non-secure storage accessible from the non-secure world. The only method I found that is mentioned in the User Manual, is to have a non-secure callable Flash_program function. This to me implies that the flash driver provided in the ROM has to be in the secure world. But that is my assumption, which should be confirmed first.

In the mean time I was able to make some progress, I set the ANACTLR, FLASH, GPIO, INPUTMUX and PRINCE slaves to security level S-Priv. This list of slaves might be more that I need, but I want to find a working situation first before optimizing the project. Additionally I switched the entire Boot ROM memory region (0x13000000 - 0x1301FFFF) from NS-User to S-Priv.

By making these changes, I no longer get the IBUSERR, but instead I get a forced hard fault, PRECISERR and BFARVALID.

I used the debugger to execute the code and as far as I can tell, the exception occurs after a successful call to the flash_init boot rom call, just before

the rest of the C function, which would pop the stack and return to the caller.

I'm not sure what exactly happens here.

If needed, I can attach the projects I have been using.

Regards,

Olaf

Actions

Olaf Heemskerk @ Olaf Heemskerk on Nov 26, 2019 12:18 PM

Hi Sabina,

I am now able to execute the flash_init boot rom function. I had still set the clock to the incorrect speed, 150 MHZ instead of the 100 MHZ maximum. Setting the clock to 100 MHZ solves the last forced hard fault.

Regards,

Olaf

Actions

Sabina Bruce

@ Olaf Heemskerk on Nov 30, 2019 6:20 PM

Good to hear! Let me know if you have more questions.

Best Regards,

Sabina

Actions

4 Replies

Sabina Bruce Nov 25, 2019 7:38 AM
Mark Correct
Correct Answer
Hello Olaf,

From what I'm understanding you would like to have the flash divided in two. One is completly secure and the other is completly non-secure. You would like to administer the secure via secure method and the non secure with non secure method(not non secure callable). Is this correct?
If so could you please confirm that the areas of memory which you are trying to access are in fact either secure and non secure(not NSC).

Also the IBUSERR can be caused by:
a) Branch to invalid memory regions for example caused by incorrect function pointers.
b) Invalid return due to corrupted stack pointer or stack content.
c) Incorrect entry in the exception vector table.

Which may be due to trying to access a section of memory without the proper permission.

Best Regards,
Sabina
Like • Show 0 Likes0
Actions
- Olaf Heemskerk @ Sabina Bruce on Nov 25, 2019 10:58 AM
  Mark Correct
  Correct Answer
  Hi Sabina,
  
  For my project, I want to have secure Flash storage that is only accessible within TrustZone, as well as non-secure storage accessible from the non-secure world. The only method I found that is mentioned in the User Manual, is to have a non-secure callable Flash_program function. This to me implies that the flash driver provided in the ROM has to be in the secure world. But that is my assumption, which should be confirmed first.
  
  In the mean time I was able to make some progress, I set the ANACTLR, FLASH, GPIO, INPUTMUX and PRINCE slaves to security level S-Priv. This list of slaves might be more that I need, but I want to find a working situation first before optimizing the project. Additionally I switched the entire Boot ROM memory region (0x13000000 - 0x1301FFFF) from NS-User to S-Priv.
  
  By making these changes, I no longer get the IBUSERR, but instead I get a forced hard fault, PRECISERR and BFARVALID.
  I used the debugger to execute the code and as far as I can tell, the exception occurs after a successful call to the flash_init boot rom call, just before
  the rest of the C function, which would pop the stack and return to the caller.
  I'm not sure what exactly happens here.
  If needed, I can attach the projects I have been using.
  
  Regards,
  Olaf
  Like • Show 0 Likes0
  Actions
  - Olaf Heemskerk @ Olaf Heemskerk on Nov 26, 2019 12:18 PM
    Mark Correct
    Correct Answer
    Hi Sabina,
    
    I am now able to execute the flash_init boot rom function. I had still set the clock to the incorrect speed, 150 MHZ instead of the 100 MHZ maximum. Setting the clock to 100 MHZ solves the last forced hard fault.
    
    Regards,
    Olaf
    Like • Show 0 Likes0
    Actions
    - Sabina Bruce @ Olaf Heemskerk on Nov 30, 2019 6:20 PM
      Mark Correct
      Correct Answer
      Good to hear! Let me know if you have more questions.
      Best Regards,
      Sabina
      Like • Show 0 Likes0
      Actions

LPC55S69: Using Flash driver in TrustZone

Outcomes

Related Content

Recommended Content