topic Re: S32K358 - freeRTOS SMP in S32K

S32K358 - freeRTOS SMP

sathishkumar_sunmugavel — Mon, 16 Jun 2025 11:23:25 GMT

Hello NXP Support Team,

I am currently working on a project using the S32K358 MCU and would like to clarify the multicore capabilities in relation to FreeRTOS.

My requirement is to use a single FreeRTOS kernel shared across both cores (M7_0 and M7_2), and to be able to create tasks that are pinned to and executed on specific cores, similar to what is typically achieved in an SMP (Symmetric Multiprocessing) setup.

Could you please confirm:

Whether SMP support (a single FreeRTOS instance scheduling tasks across both cores) is currently available or planned for the S32K358.
If not available, whether there are any workarounds or recommendations for inter-core task management and communication in an AMP (Asymmetric Multiprocessing) setup using FreeRTOS.
Whether any official example projects or documentation exist that demonstrate such a setup.

Looking forward to your clarification.

Best regards,
Sathish Kumar

Re: S32K358 - freeRTOS SMP

Julián_AragónM — Mon, 16 Jun 2025 17:40:51 GMT

Hi @sathishkumar_sunmugavel,

1. You can enable and configure the SMP feature inside the FreeRTOS package from Config Tools:

3. In the latest FreeRTOS package (for RTD 5.0.0), there is an existing example for S32K358 and SMP, FreeRTOS_Toggle_Led_Example_S32K358_SMP. Here is the description:

"Support SMP FreeRTOS: Switch 4 tasks with 2 cores: Per core has 2 tasks
1.1 The application software functionality
Multiple core can switch tasks"
 

There are no specific documents for SMP, but you can refer to both pdfs attached to this reply for FreeRTOS documentation.

Best regards,
Julián

Re: S32K358 - freeRTOS SMP

sathishkumar_sunmugavel — Tue, 17 Jun 2025 08:49:00 GMT

Hi @Julián_AragónM

Thank you for your prompt response.

I’m working with the SMP example provided in RTD 5.0.0, which includes 4 tasks across 2 cores (2 tasks per core). To observe parallel execution, I added printf statements inside each task. However, I only see output from the tasks assigned to Core 1 — there’s no output from the tasks intended for Core 2.

Could you help clarify this behavior?

Specifically:

Why am I not seeing output from Core 2’s tasks?
How can I confirm which core is executing a given task?
Is there a recommended way to verify that tasks are truly running in parallel across both cores?

Looking forward to your guidance.

Best regards,
Sathish Kumar

Re: S32K358 - freeRTOS SMP

sathishkumar_sunmugavel — Tue, 17 Jun 2025 11:43:49 GMT

I’ve attached the complete project for your reference.

In this project’s debug configurations, only Core M7_0 is selected. Based on this, I assume that the binary is being flashed only to Core 0 (M7_0).

However, I’m not entirely confident about the flashing process and how it affects core execution.

Could you please help clarify how the binary is flashed and how it is mapped to each core? Specifically,

Is the binary indeed being flashed only to M7_0?
What needs to be done to flash and run code on both cores?

Best Regards,
Sathish kumar

Re: S32K358 - freeRTOS SMP

Julián_AragónM — Tue, 17 Jun 2025 22:14:40 GMT

Hi @sathishkumar_sunmugavel,

Actually, I'm not sure if this example works correctly through the PEMicro (OpenSDA) interface.

I can see in the project's directory, a debug_t32 folder is included for the Lauterbach debugger. The scripts included may be necessary to run the project. Right now, I am not able to test it as I do not have the HW with me, but do you have a Lauterbach debugger to test the project instead?

Since this package is a code drop, and the first time SMP functionality was implemented, there are some issues with configuration. I will ask internally about this issue.

Could you please help clarify how the binary is flashed and how it is mapped to each core? Specifically,

Is the binary indeed being flashed only to M7_0?
Yes, this seems to be the case. Normally, a second project, or object file is requested to debug multicore, however, SMP should run in a Lockstep configured core.
What needs to be done to flash and run code on both cores?
I've asked internally to the responsible team, I will get back ASAP, once I get a response.

Re: S32K358 - freeRTOS SMP

sathishkumar_sunmugavel — Wed, 18 Jun 2025 07:11:33 GMT

Hi @Julián_AragónM

Since this package is a code drop, and the first time SMP functionality was implemented
I wanted to clarify — does this mean the SMP support is still in early stages or not fully stable yet?
Do you have access to a Lauterbach debugger to test the project?
I can arrange a TRACE32 setup — could you please guide me on how to proceed further with it?

Additionally, I have a few observations:

I noticed that the startup code doesn't seem to enable M7_2.

In that case, how is this core supposed to be activated?
Since the FreeRTOS kernel is running on the boot core (M7_0), will it be responsible for starting the secondary core?

Best Regards,
Sathish.

Re: S32K358 - freeRTOS SMP

Julián_AragónM — Fri, 20 Jun 2025 22:32:45 GMT

Hi @sathishkumar_sunmugavel,

I apologize for the late reply; I was waiting for a response from the respective team regarding this FreeRTOS implementation.

1. SMP is still in early stages, e.g., some problems may arise while testing the project.

2. If you already have a TRACE32 installation, you can simply open a TRACE32 Arm instance, load the .elf file with the Lauterbach debugger, and run the "run.cmm" script under the debug_t32 folder inside the project's directory.

This should pop two windows, from which you can control the program flow.

I can see the TaskX_CoreX variables increasing for each loop. I've also initialized some GPIOs inside each task for both cores, indicating each function is being entered correctly.

In that case, how is this core supposed to be activated?
Since the FreeRTOS kernel is running on the boot core (M7_0), will it be responsible for starting the secondary core?

Keep in mind that in this example, the Lauterbach script configures Core 1 at startup. In normal multicore projects, M7_0 (main core) initializes all of the necessary registers for M7_2, however, it can also be done with debugger scripts.

I've sent you a private message regarding the SW version.

Best regards,
Julián

Re: S32K358 - freeRTOS SMP

sathishkumar_sunmugavel — Mon, 23 Jun 2025 04:05:12 GMT

Hi @Julián_AragónM

Thank you for the update.

2. If you already have a TRACE32 installation, you can simply open a TRACE32 Arm instance, load the .elf file with the Lauterbach debugger, and run the "run.cmm" script under the debug_t32 folder inside the project's directory.

I have installed the TRACE32. If I create a project with Lauterbach T32 Debugging Interface like below,

I am able to see the debug configurations for Lauterbach Debugger.

Is it sufficient to just click debug from this debug configuration? Please share me the steps how to load the .elf and run "run.cmm".

Also, If I open "FreeRTOS_Toggle_Led_Example_S32K358_SMP" project, I don't see any debug configurations for the project. Please let me know how to create the debug configuration or load elf and run 'run.cmm' in this case.

Best Regards,
Sathish.

Re: S32K358 - freeRTOS SMP

Julián_AragónM — Mon, 23 Jun 2025 17:23:32 GMT

Hi @sathishkumar_sunmugavel,

Is it sufficient to just click debug from this debug configuration?

This simply loads the .elf file to the MCU, which is the first step. You can use S32DS as a GUI to flash the board, or use the Lauterbach interface, whichever should be fine.

In the TRACE32 instance, you can select "File -> Load File" and select the file from the "debug" folder.

After loading the .elf file, you can run the script by clicking "File -> ChangeDir and Run Script", then move into the debug_t32 folder and click the run.cmm file.

This should run the configuration (load to RAM, path to elf file, which boot core, multicore ON, etc.) and open up the two windows I've previously shared in the thread.

Best regards,
Julián

Re: S32K358 - freeRTOS SMP

sathishkumar_sunmugavel — Tue, 24 Jun 2025 11:31:12 GMT

Hi @Julián_AragónM

Thank you so much for all the inputs. Much appreciated.

Best Regards,
Sathish.