Problem with jumping from custom bootloader application with TrustZone to flat application

[cengizhan_bas (Cengizhan_DK)]

Hello,

We have a custom hardware with RA4E1 MCU. MCU has 512KB flash and 128KB RAM. There is a bootloader application that we developed and is already working on the device. However, we converted this bootloader application to a TrustZone-enabled project for both the storage of the keys we use here and for code security. Our bootloader application is currently TrustZone-enabled and our device application is a flat application:

• Bootloader → TrustZone

• Application → Flat

After the project was finished, I tested it with a simple LED blink application. The bootloader worked successfully and I jumped to the LED blink application. However, when I tried it with the actual application, it did not work. To understand the reason, I converted the LED blink application to a freeRTOS-enabled application. Because our normal application has a freeRTOS feature. I experienced the same error here. Apparently, there is a problem with the freeRTOS feature of the flat application we are trying to jump to. If we give a little more detail, our flash and RAM structure is as follows:

• Bootloader secure flash → 64kB

• Bootloader nonsecure flash → 64kB

• Flat Application flash → 384kB

• Secure section of RAM → 24kB

• Non-secure section of RAM → 104kB

I am adding a visual for you to better understand the flash and RAM structure of the MCU. I am also sending the error details I received on the Fault Status screen after jumping. I debugged to understand the part that caused the crash after jumping to the flat application. During the process of starting freeRTOS tasks, the rm_freertos_port_restore_task_stackless() function, depending on the vPortSVCHandler_C() function in the prvPortStartFirstTask() function, causes a problem. In other words, when I check with debug, the rm_freertos_port_restore_task_stackless() function causes a problem at the lowest level. I am also sending this function to you. I am also sending the function at the moment I jumped. Normally, this jump function does not cause any problems if the application I am trying to jump does not have freeRTOS feature. In other words, everything works properly and I see the LEDs blink after the jump. However, when I make the application I am trying to jump a freeRTOS feature application, I get the error I mentioned. Are there any extra things I need to do since my bootloader project has become a TrustZone feature project? Are the PSPLIM and MSPLIM values ​​wrong or do I need to set the _S and _NS ones as well? I am seriously confused. Can you please help me? I have no idea what the problem could be and I cannot go beyond trial and error.

Thank you.

Best regards.

[aggarg (Gaurav Aggarwal)]

Which FreeRTOS port are you using? You can check that by seeing which portable files your project is using.

@cengizhan_bas

rm_freertos_port_restore_task_stackless()

This function does not seem from us. Where did you get the FreeRTOS code from?

@cengizhan_bas

However, when I make the application I am trying to jump a freeRTOS feature application, I get the error I mentioned.

Seems like you are getting a forced hard fault. Would you please enable Usage, Bus and MPU faults as described in this document from ARM - https://www.keil.com/appnotes/files/apnt209.pdf.

[cengizhan_bas (Cengizhan_DK)]

Hi Gaurav,

I couldn’t find exactly which port is used in the link you provided. When I checked the project, it seems that Renesas Middleware used a port named rm_freertos_port. After some research, I realized that TrustZone related features are controlled with some macros in GCC->ARM_CM33 port. The most important of these is configRUN_FREERTOS_SECURE_ONLY macro, I think.

However, when I searched for this macro in the same source file in my own project, I encountered a situation. Renesas side replaced these macros with their own BSP macros while porting freeRTOS. Instead of the macro I specified, they used BSP_TZ_NONSECURE_BUILD macro.

I am using TrustZone feature in hardware in my project. I think in this case, setting configRUN_FREERTOS_SECURE_ONLY macro to 1 would fix the problem. However, this macro seems to be ineffective now. Since the BSP_TZ_NONSECURE_BUILD macro that Renesas uses is also dependent on the entire project, changing it affects all files in the project. The project becomes uncompilable. Frankly, I have no clear idea what to do.

Thanks.
Best regards.

[aggarg (Gaurav Aggarwal)]

@cengizhan_bas

I think in this case, setting configRUN_FREERTOS_SECURE_ONLY macro to 1 would fix the problem

I think so too. To quickly verify, you can modify the portINITIAL_EXC_RETURN to 0xffffffd.

@cengizhan_bas

Since the BSP_TZ_NONSECURE_BUILD macro that Renesas uses is also dependent on the entire project, changing it affects all files in the project. The project becomes uncompilable.

Since this port is not from us, I’d suggest reaching out to Renesas.

[cengizhan_bas (Cengizhan_DK)]

Hi Gaurav,

Sorry for the delay, we are in a busy working period. I think the image I put above is a bit misleading. Normally, in my project, the value of the BSP_TZ_NONSECURE_BUILD macro was 0. So the value of the portINITIAL_EXC_RETURN macro was 0xFFFFFFFD. Changing the portINITIAL_EXC_RETURN macro to 0xFFFFFFBC seems to fix the problem. If anyone encounters a similar problem while working with their freeRTOS port on Renesas, they can overcome the problem temporarily in this way. We are continuing our discussions with the Renesas team for a permanent solution. If they offer a permanent solution, I will forward this solution again.

Thanks.
Best regards.

[aggarg (Gaurav Aggarwal)]

@cengizhan_bas Thank you for sharing your solution!