I have a function that I have declared as BSP_CMSE_NONSECURE_ENTRY uint32_t Secure_VeeSerialNumberGet(void);It exists in my secure application and I am calling in from my non-secure application. Whenever I call it, I end up in the Default_Handler().
// Secure side
BSP_CMSE_NONSECURE_ENTRY uint32_t Secure_VeeSerialNumberGet(void) {
return VeeSerialNumberGet();
}
The address looks correct before the call.
static uint32_t serial_number = 0;
serial_number = Secure_VeeSerialNumberGet();
I tried to make this as simple as possible and build on it if I need to.
I am not sure what I am doing wrong. I have tested all the functions within my secure app. I just need to get it to call from my non-secure app.Thanks!
EK_RA6M5_Virtual_EEProm_Trustzone.zip
I just wanted to mention that when I call Secure_VeeSerialNumberGet() I get an exception that ends up in the Default_Handler().
Hello JD Henhouse ,
Thanks for reaching out Renesas Engineering Community.
We have received the exact same question in our internal ticketing system Ticket #405447.
Please let me inform you that we will support you on the internal ticket you posted.
Best Regards,
IK
Hello sir,
Let me also post my reply on the forum thread for you:
First of all please let me inform you that it is impossible in Trustzone technology to access secure data and secure code from non-secure application.
From non-secure application the only way to access secure SW is through the NSC (non-secure callable) functions.
In your case by declaring in this in the secure side by using this macro BSP_CMSE_NONSECURE_ENTRY , you are creating your own custom non-secure callable functions.
Let's check some things first:
1. When creating the Secure project as project template have you selected this one?
2. Looks like your case is exactly this one:
Described in section 3.3 of this app note: https://www.mouser.com/pdfDocs/SecurityDesignwithArmTrustZone-IPProtectionAppNote.pdf
3. The other thing I am suspecting is that you have not allocated enough stack in your secure project for the non-secure callable functions.
Have you tried to increase the stack size on this stack properties for the non-secure callable?
Did you try to also increase the stack in both secure and non-secure projects projects under BSP tab?
Also try to increase the stack on the thread from which you are calling the non-secure callable function in your non- secure project.
Check these and let me know.
Also please open the Fault status window to show me what kind of exception and analyze the hard fault you get.
Thanks and Regards,
Renesas Support.
Thank you for responding in such a timely manner. I have been working at this problem for a while and I think it comes down to my veneer functions are in the secure library but the non-secure app is still calling the un-wrappered addresses:Secure Map File:
.gnu.sgstubs.__stub
0x00003800 0x40 linker stubs
0x00003800 template_nonsecure_callable
0x00003808 Secure_VeeSerialNumberGet
0x00003810 TZ_InitContextSystem_S
0x00003818 TZ_LoadContext_S
0x00003820 TZ_FreeModuleContext_S
0x00003828 TZ_AllocModuleContext_S
0x00003830 TZ_StoreContext_S
0x00003838 Secure_VeeSerialNumberSet
0x00008000 __tz_FLASH_N = DEFINED (FLASH_NS_START)?ABSOLUTE (FLASH_NS_START):__RESERVE_NS_RAM?ABSOLUTE ((FLASH_START + FLASH_LENGTH)):(FLASH_LENGTH < 0x8000)?FLASH_LENGTH:ALIGN (0x8000)
0x00008000 FLASH_NS_IMAGE_START = DEFINED (FLASH_NS_IMAGE_START)?FLASH_NS_IMAGE_START:__tz_FLASH_N
0x60000000 __tz_QSPI_FLASH_S = ORIGIN (QSPI_FLASH)
Address of Secure_VeeSerialNumberGet() when called:
Secure_VeeSerialNumberGet uint32_t (void) {uint32_t (void)} 0xad4 <Secure_VeeSerialNumberGet> 0xad4
It is as though the secure.o file is not being included as a library object and the secure stubs are not being used: Attached is the project with the changes you suggested. The issue still persists.
The output of my fault but I am not exactly sure how to interpret it in this security context:
PC = 0x0 means the processor tried to execute code at address 0.
This will always cause an undefined instruction UsageFault (or sometimes a HardFault, depending on config).
LR = 0x0 means the code tried to return to address 0.
This almost always means a corrupted stack, invalid function pointer, or a misconfigured interrupt/vector table.
This bit is the “FORCED” bit, meaning the fault was escalated from a configurable fault (UsageFault, MemManage, BusFault) because it wasn't handled.
That matches your earlier CFSR=0x100000: Undefined Instruction.
Well I took a quick look in your project and run it on EK-RA6M5 and this happens due to the fact that something has not been set up properly in your project and inside the non-secure app the secure address of you function is called instead the address of the veneer function for the Non-Secure callable.
Here in the .map file of secure project is the address of the non-secure callable version let's say of your function it should be called:
But instead the secure is trying to be directly accessed and that's why you get the hard fault in your case.
I would recommend to you to go through this lab material here:
I-002B Introduction to TrustZone for RA FSP500 EKRA6M4 Materials
Which shows how to set up a secure and non- secure project. And inside the non secure project it calls the guard functions which are basically the non-secure callable version of the APIs for the peripheral in the non-secure application.
I think going through this will help.
Another thing I would recommend to you to test is to try to call your function in main function before the the function that is starting the ThreadX kernel and see if the hard fault still occurs?
By this way we will understand in case the hard fault does not occur when the function is called outside the and before the ThreadX thread starts that this happens due to something related with thread settings.