Hi,
I have the following situation:
- I have a legacy C application that runs on the good old nRF5 SDK on NRF52840 with FreeRTOS. (No BLE on the application, but the bootloader is BLE DFU capable).
- I need to port this application to run on NRF54L15.
- I don't want to port the application to Zephyr, I want to keep FreeRTOS.
- I still don't need BLE for the application (but I do use the radio).
- I want to keep BLE DFU capability.
To achieve this, I wanted to use the new NCS bare metal software solution, which is advertised as: "RTOS-independent software solution for Bluetooth LE development, designed to ease developers’ migration from the legacy nRF5 SDK and nRF52 Series to the next-generation nRF54L Series."
At closer inspection, I realized it's actually not that bare metal. Originally I wanted to add FreeRTOS to one of the NCS bare metal sample application and then port the HAL to use the nRFX library without the nRF5 SDK stuff. It seems that's not that easy because I already got stuck with the SVC handler implementation:
Zephyr forces the use of it's own vector table that implements the z_arm_svc handler which conflicts with the SVC_Handler that FreeRTOS needs. (Similar conflicts with PendSV and Systick handlers too.)
Is there a practical way to disable Zephyr-specific components - such as the vector table for example - that conflict with porting another RTOS into the application?
If not, alternatively:
Is it feasible to run an independently built FreeRTOS application on top of the NCS bare-metal MCUboot + SoftDevice + firmware loader combination?
I’m considering building the application outside of NCS (using GCC + CMake) and then integrating the resulting HEX file into sysbuild for signing alongside other NCS images. Is this a practical or supported approach, and are there any references or examples?
Thanks in advance,
Best regards,
Bence
