S32k3 Core1 started in Core 0

[Lisha]

Dear NXP Support Team,

We are currently working on a dual-core implementation for the S32K322 and have encountered a challenge. Our customer requires Core1 to be started from within the master core (Core0), with a single debug launcher and a unified ELF file for execution.

We are unsure how to proceed with this setup, including the necessary debug configurations and the overall dual-core debugging process in a single launcher. Could you please provide guidance on the correct approach? Additionally, if there are any relevant examples, documentation, or videos available, we would greatly appreciate your assistance.

Looking forward to your support.

Best regards,

Lisha

[danielmartynek]

Hello @Lisha,

Please refer to this thread:

https://community.nxp.com/t5/S32K/S32K324-Multi-Core-Example-Project-based-on-Whiteboard/m-p/1547771

and these examples:

https://nxp1.sharepoint.com/:f:/t/25_66/EuY9OgY9mthFlFiCSV2wgfMBvVKPrxvs8aVC7LnRhSj3NA?e=SY8u1K

Example ResourcesAssign_M2xxG1_200 has both cores in a single .ELF

BR, Daniel

[Lisha]

Dear Daniel,

I appreciate your support. I need your guidance on how to release the Reset_Handler for the secondary core in S32 Design Studio (S32DS). The configuration options include "Attach on Target" and "Set PC." I have set the secondary core to the Reset_Handler and now need to release it from the master core. Could you please help me identify the register responsible for releasing the Reset_Handler?

Additionally, I tried accessing the link https://nxp1.sharepoint.com/:f:/t/25_66/EuY9OgY9mthFlFiCSV2wgfMBvVKPrxvs8aVC7LnRhSj3NA?e=SY8u1K, but it appears to be restricted to NXP's SharePoint, and I do not have access.

Looking forward to your support.

Best regards,
Lisha

[danielmartynek]

Hi @Lisha,

I'm not sure what you mean, if you need to launch the secondary core from the primary core, refer to this example:

https://community.nxp.com/t5/S32K-Knowledge-Base/S32K358-Multicore-Start-CM7-2-from-CM7-0/ta-p/19238...

In the thread I shared in the other link, there is this file:

S32K324_Multi-Core_Example.7z

[Lisha]

Hello @danielmartynek,

Thank you for your prompt guidance.

I am already referring to this resource; however, it does not seem to start the core from the master core.

The reference I am using is "S32K358 Multicore Start CM7_2 from CM7_0 - NXP Community." That said, I appreciate your help—I may have overlooked something. I'll review it once again.

Best regards,
Lisha

[edna23roe]

Dear Lisha,

Thank you for reaching out to NXP Support. We understand you're facing challenges with a dual-core implementation on the S32K322, specifically with starting Core1 from Core0 and debugging both cores using a single launcher and ELF file. We're happy to provide guidance.

Here's a breakdown of the approach and essential considerations:

1. Core1 Startup from Core0:

System Integration Unit (SIU) Configuration:
Core1 startup is typically initiated through the SIU registers. You'll need to configure the appropriate registers to release Core1 from its reset state.
This involves setting the relevant bits in the SIU_CPUX_RST registers.
Ensure that Core1's initial stack pointer and program counter are correctly set before releasing it from reset. This is done by writing to the core1's vector table address.
Core1 Entry Point:
The ELF file should contain the code for both Core0 and Core1. You'll need to define the entry point for Core1 within the ELF, usually in a separate memory section.
Core0 needs to write the address of Core1's entry point to the correct startup vector.
Memory Partitioning:
Carefully partition the memory map to avoid conflicts between Core0 and Core1. Ensure that each core has its dedicated memory regions for code, data, and stack.
This is usually done via the linker script.
Inter-Core Communication:
Implement a robust inter-core communication mechanism (e.g., shared memory, message queues, interrupts) to enable data exchange and synchronization between the cores.
Example Code Snippet (Conceptual):
C

// Core0 code
void start_core1(uint32_t core1_entry_point) {
// Configure Core1's stack pointer and program counter
// Write core1_entry_point to core1's vector table.
// ...
// Release Core1 from reset using SIU registers
SIU->CPUX_RST[1] = 0; // Example, check the datasheet for correct register.
}
2. Single Debug Launcher and Unified ELF:

Debugger Configuration:
Modern debuggers (like Lauterbach TRACE32 or some versions of S32 Design Studio with appropriate debug probes) support multi-core debugging. You'll need to configure the debugger to recognize both cores and their respective memory regions.
The debugger should be able to load the unified ELF file and map the code and data to the correct core's memory space.
S32 design studio can use the multicore debug configurations.
Debug Probe:
Ensure that your debug probe supports multi-core debugging. Many JTAG/SWD probes offer this functionality.
Linker Script:
The linker script is crucial for creating the unified ELF. It should define the memory regions for both cores and place the code and data accordingly.
This allows the debugger to correctly map the ELF sections to the respective cores.
Debug Symbols:
The ELF file should contain debug symbols for both cores, enabling you to step through the code and inspect variables.
3. Debugging Process:

Connect Debug Probe:
Connect your debug probe to the S32K322 target board.
Launch Debugger:
Launch your debugger and configure it for multi-core debugging.
Load ELF File:
Load the unified ELF file into the debugger.
Set Breakpoints:
Set breakpoints in both Core0 and Core1 code.
Run and Debug:
Start the debugging session. The debugger should allow you to step through the code in both cores, inspect variables, and monitor memory.
Use the debuggers multicore aware view to see both cores.
4. Resources and Documentation:

S32K3xx Reference Manual:
The S32K3xx Reference Manual contains detailed information about the SIU registers, memory map, and other peripherals.
S32 Design Studio Documentation:
The S32 Design Studio documentation provides information about multi-core debugging configurations and features.
NXP Community Forums:
The NXP Community Forums are a valuable resource for finding answers to common questions and connecting with other developers.
NXP Application Notes:
Search NXP's website for application notes related to multi-core development on S32K3xx devices.
Example projects:
Look within the S32 Design studio example projects, and the NXP website for any multicore examples related to the S32K3 family of devices.
Key Considerations:

Synchronization: Proper synchronization between Core0 and Core1 is crucial to avoid race conditions and data corruption.
Interrupt Handling: Be mindful of interrupt handling in a multi-core environment.
Resource Sharing: Carefully manage shared resources (e.g., peripherals, memory) to prevent conflicts.
Safety and Security: When designing multi-core applications, consider safety and security implications.
We recommend thoroughly reviewing the S32K3xx Reference Manual and experimenting with example projects to gain a better understanding of the dual-core implementation process.

We hope this guidance is helpful. Please do not hesitate to reach out if you have any further questions or require additional assistance.

Best regards,
Edna
EZPassMD

[Lisha]

Thanks for your valuable quick response.

We have taken an example from NXP's Platform_Multicore_SingleElf_S32K324, which includes the following Start_Core() function:

c
Copy
Edit
void Start_Core(void)
{
IP_MC_ME->PRTN0_CORE1_PCONF &= ~(1 << MC_ME_PRTN0_CORE1_PCONF_CCE_SHIFT);
IP_MC_ME->PRTN0_CORE1_PUPD = 1;
IP_MC_ME->CTL_KEY = 0x5AF0;
IP_MC_ME->CTL_KEY = 0xA50F;
while ((IP_MC_ME->PRTN0_CORE1_STAT & MC_ME_PRTN0_CORE1_STAT_CCS_MASK) == 1);

IP_MC_ME->PRTN0_CORE1_ADDR = (uint32)&__CORE1_VTOR;
IP_MC_ME->PRTN0_CORE1_PCONF |= (1 << MC_ME_PRTN0_CORE1_PCONF_CCE_SHIFT);
IP_MC_ME->PRTN0_CORE1_PUPD = 1;
IP_MC_ME->CTL_KEY = 0x5AF0;
IP_MC_ME->CTL_KEY = 0xA50F;
while ((IP_MC_ME->PRTN0_CORE1_STAT & MC_ME_PRTN0_CORE1_STAT_CCS_MASK) == 0);
}
Debugging Questions:
Debugging Approach:

Can we start debugging the master core first and then enable the secondary core afterward?

Is this the correct debugging sequence, or should we follow a different approach?

Issue with Example Code:

The given example does not seem to work as expected.

What steps should we take to ensure that the secondary core is properly initialized and running?

How can we verify that the secondary core is executing code after startup?

Any guidance on debugging this multicore setup would be highly appreciated.
BR,
Lisha