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