Using EB Tresos-generated RTD drivers with FreeRTOS + MPU Hello, we use the RTD 6.0.0 and BMS 0.9.1. SDK in EB Tresos to generate our driver code. It runs fine under FreeRTOS with Cortex M7 port that does not use the MPU. Now, we want to switch to a FreeRTOS port that does use the MPU. I want to do this in two steps: 1) Making all tasks privileged but using the MPU, i.e. the MPU is reprogrammed in each context switch 2) Making all tasks unprivileged. That means I have to enable "Enable user mode support" in the drivers that are used by unprivileged tasks Right now, I struggle at 1). Driver functions do not work reliably. For example, SPI only works intermittently. It seems as MPU regions are not working correctly. Even if this is resolved, how could 2) be implemented? The supervisor call handler is given by FreeRTOS and the RTD. Am I supposed to merge them? Re: Using EB Tresos-generated RTD drivers with FreeRTOS + MPU Hello @Julián_AragónM, I downloaded FreeRTOS from their website and used a port that supports both Cortex M7 and the MPU. If I understand you correctly, I need to use the NXP-provided FreeRTOS. I only found FreeRTOS by NXP that can be configured in S32DS, not EB Tresos. My questions are as follows: - Can I use the generic FreeRTOS, provided with correct M7+MPU Port? - If not, is there an NXP-provided FreeRTOS that can be configured in EB Tresos? We need to use an ASIL-D certified OS at some point. If the NXP-provided FreeRTOS is not ASIL-D certified, we need to switch to something else. Re: Using EB Tresos-generated RTD drivers with FreeRTOS + MPU Hello @PhilippH,
Firstly, MPU initial support was added in FreeRTOS 7.0.0 CD1, can you confirm this is the package you are using? (or 0.8.0 CD1, which is the latest release).
1) Can you share which MPU regions are not working correctly? If possible, please share configuration and routine.
Also, please follow the recommendations included inside the S32K3 FreeRTOS User Manual:
Enable Use mpu and Use mpu wrappers v1 options.
Set first configurable region to 9 instead of 0 to avoid conflict with MPU region from RTD.
Note: Integrating FreeRTOS with MPU support requires modifications in the RTD linker file to define the required memory sections used by FreeRTOS. Use the example files as reference when applying changes to your application.
2) I believe merging is not required, as FreeRTOSConfig.h declares the following macros:
/* Definitions that map the FreeRTOS port interrupt handlers to their CMSIS
standard names. */
#define vPortSVCHandler SVC_Handler
#define xPortPendSVHandler PendSV_Handler
#define xPortSysTickHandler SysTick_Handler
This redirects FreeRTOS's SVC calls to the RTD-provided SVC_Handler in exceptions.c.
Best regards, Julián
Re: Using EB Tresos-generated RTD drivers with FreeRTOS + MPU Hello @PhilippH,
- Can I use the generic FreeRTOS, provided with correct M7+MPU Port?
You can use the generic FreeRTOS port; however, you will need to implement your own solution for S32K3-specific configuration, which is mostly provided in the NXP FreeRTOS package already. Please try to start with this port to see if it solves the problem.
- If not, is there an NXP-provided FreeRTOS that can be configured in EB Tresos?
No, the provided NXP package is compatible only with S32DS for now. Could you share why do you need FreeRTOS with EB Tresos?
Usually, EB Tresos is used for AUTOSAR compliant applications, however, the FreeRTOS package we provided is just for customer evaluation, not recommended to be used in production since it does not meet automotive certifications (ISO26262). You can see it is released as Code Drop (CD) Quality, this is because FreeRTOS is an open-source software and NXP provides it as a reference software without any safety certification.
If your application requires a safety-certified OS, you can explore other options, even from our partners:
SafeRTOS (Based on the FreeRTOS functional model, with simple migration): https://www.highintegritysystems.com/safertos/
AUTOSAR OS
µ-velOSity
embOS-Safe
NXP RTOS
It is up to the customer to select the appropriate third-party RTOS, stacks, IDEs, compilers, etc. for their project.
Best regards, Julián Re: Using EB Tresos-generated RTD drivers with FreeRTOS + MPU Thanks a lot for the answer. I got it working with the NXP-provided SafeRTOS and Port as the NXP-provided port already solved the problems I had with the generic Cortex M7 + MPU port provided by SafeRTOS. Regarding our need for EB Tresos: We started with S32DS, but due to the ICs we use, we needed a recent version of the BMS SDK, which was not available in S32DS (at least at the time). We want to do Autosar as little as possible. What worked for now was to generate the driver functions and calling them from FreeRTOS. We do not use and do not plan to use the Autosar RTE. Regarding the 3rd party OS's: Does "With simple migration" mean that an equally user-friendly port exist for SafeRTOS? We used SafeRTOS before, but not with Autosar drivers, but purely handwritten drivers. Re: Using EB Tresos-generated RTD drivers with FreeRTOS + MPU Hello @PhilippH,
Good to hear it is working as expected!
Migrating to SafeRTOS is generally the simplest path when using FreeRTOs, as they both work on the same functional model, and provide some dedicated migration tools. NXP does not provide a SafeRTOS port for S32K3, unfortunately.
From WHIS' page, I can see S32Kxx devices are supported through our RTD's, which provide full IP and feature coverage for both AUTOSAR and non-AUTOSAR applications, meaning you can choose to not use Autosar.
Best regards, Julián Re: Using EB Tresos-generated RTD drivers with FreeRTOS + MPU FYI, I had to edit system.c supplied by S32K3 RTD 6.0.0: LOCAL_INLINE void Direct_GoToUser(void)
{
ASM_KEYWORD("push {r0}");
//ASM_KEYWORD("ldr r0, =0x1"); <---- Before: CONTROL.SPSEL changes stack when invoked from FreeRTOS Task.
ASM_KEYWORD("ldr r0, =0x3"); // My edit: CONTROL.SPSEL does not change in my case (always invoked from FreeRTOS Task)
ASM_KEYWORD("msr CONTROL, r0");
ASM_KEYWORD("pop {r0}");
} This edit is needed because the used stack must not be changed between push and pop of r0. The RTD assumes that MSP is always used, but FreeRTOS tasks use the PSP. The SVC Handler of the NXP-provided FreeRTOS port correctly clears CONTROL.nPRIV without changing CONTROL.SPSEL when raising privilege. You should change Direct_GoToUser() to set CONTROL.nPRIV, preserving the other bits, instead of setting CONTROL to a constant value. In my case, CONTROL=0x3 suffices because I always call Direct_GoToUser() from a FreeRTOS task, but in the general case it could also be invoked from unprivileged main(). Additionally, I wonder if an ISB instruction should be added after changing CONTROL, as ARM recommends.
View full article
