S32K328 – FIRC Clock Divider (DIV16) Not Applied When Multicore Is Enabled

[dpsdprtmvl]

Hello NXP Technical Support Team,

I have a question regarding the FIRC clock configuration on the S32K328.

I configured the FIRC clock source for the STM2 module to 3MHz (DIV 16) in a single-core setup. In the single-core configuration, I confirmed that the FIRC clock source is correctly output at 3MHz.

However, once I enable multicore, the FIRC clock source is output at 48MHz instead of 3MHz, even though the divider is still set to 16.

In my current architecture, MCU Init and Set Mode can only be executed on Core 0. My question is whether the MCU clock can also be accessed (or reconfigured) from Core 1, and whether this could be the cause of the issue.

Additional context on my setup:

• I am working in an AUTOSAR environment and have added the RM (Resource Manager) module for multicore support.
• Domain0 master: Core 0, Domain1 master: Core 1. All memory and peripheral access permissions have been granted for each domain.

Tool environment:

• MCAL RTD 3.0.0
• EB Tresos 27.1.0

Findings from my own analysis:
When reading the FIRC_DIV_SEL field in the CONFIG_REG_GPR register at runtime, the value is 3, which corresponds to 48MHz according to the driver code (DividerValue mapping: 48MHz→3, 24MHz→1, 3MHz→2). I also noticed that the divider write path in the clock driver includes an APP_CORE_ACC permission check and a wait for the Secure BAF (CORE2) to enter WFI (by polling PRTN0_CORE2_STAT). I suspect the divider write may be skipped in the multicore configuration.

Could you please advise on the following:

1. Why the FIRC divider setting (DIV 16) is not applied when multicore is enabled, resulting in 48MHz output instead of 3MHz?
2. Whether accessing or reconfiguring the MCU clock from Core 1 is supported or required in this scenario.
3. Whether the divider write could be skipped due to the APP_CORE_ACC permission check or the Secure BAF WFI timeout in the multicore configuration, and how to ensure the divider is correctly applied.

Thank you for your support. I look forward to your response.

Best regards,

AWS-LIBRARIES-S32K3 

[VaneB]

Hi @dpsdprtmvl 

First, the software version being used is several releases behind the current version, so I would recommend migrating to the latest software release.

Regarding FIRC_DIV_SEL, I performed a simple test using the IPCF_Example_S32K358 from S32K3 IPCF v4.3.0 on an S32K3X8EVB-Q289 board. For this test, I modified the IRCOSC configuration structure (Clock_Ip_IrcoscConfigurations_0), changing the IRCOSC range from CLOCK_IP_SUPPORTS_48MHZ_FREQUENCY to CLOCK_IP_SUPPORTS_3MHZ_FREQUENCY.

After running the application and allowing the ping-pong communication between the cores to complete, I verified that CONFIG_REG_GPR[FIRC_DIV_SEL] was correctly configured to the expected value (10b), as shown in the image below.

VaneB_0-1783015826914.png

Could you provide more details on your implementation? How are you configuring FIRC_DIV_SEL? How are you initializing the second core? Are you calling the clock initialization on the other core as well?

BR, VaneB

[dpsdprtmvl]

Hello,

Thank you for testing this on your side and for the detailed response.

To answer your questions about my implementation:

1. How I configure FIRC_DIV_SEL:
In my Clock_Ip_IrcoscConfigurations_0 structure, the FIRC clock is configured with the IRCOSC range set to CLOCK_IP_SUPPORTS_3MHZ_FREQUENCY. So the intended configuration is 3MHz, the same as in your test.

2. How I initialize the second core / whether I call clock initialization on the other core:
Mcu_InitClock and Mcu_SetMode are both called only on Core 0. On Core 1, I do not call any MCU clock-related API.

That said, I will double-check this behavior through further debugging on my side to confirm that no clock reconfiguration is unintentionally happening on Core 1.

Additional observations:

• In single-core, FIRC_DIV_SEL reads as 2 (3MHz) and works correctly.
• In multicore, FIRC_DIV_SEL reads as 3 (48MHz), which results in an STM tick that is 16x faster than expected.

I will also evaluate migrating to the latest RTD release as you recommended.

I will get back to you with the debugging results. In the meantime, if you have any suggestions on what could cause FIRC_DIV_SEL to end up as 3 (48MHz) even though clock initialization is performed only on Core 0 with the 3MHz configuration, I would appreciate your input.

Best regards,

[dpsdprtmvl]

Hello,

I have found the root cause on my side. Please see the relevant driver function below (Clock_Ip_SetFircDivSelHSEb in \Mcu_TS_T40D34M30I0R0\src\Clock_Ip_IntOsc.c 

c

/* Application can write this divider */
if ( ((IP_CONFIGURATION_GPR->CONFIG_REG_GPR & CONFIGURATION_GPR_CONFIG_REG_GPR_APP_CORE_ACC_MASK)
      >> CONFIGURATION_GPR_CONFIG_REG_GPR_APP_CORE_ACC_SHIFT) == CLOCK_IP_APP_CAN_WRITE)
{
    ...
    /* FIRC_DIV_SEL write happens here */
}
else
{
    /* HSE firmware doesn't allow to write FIRC post divider. */
    Clock_Ip_ReportClockErrors(CLOCK_IP_REPORT_WRITE_PROTECTION_ERROR, Config->Name);
}

The problem is that in my multicore configuration, the code never enters this if (APP_CORE_ACC == CLOCK_IP_APP_CAN_WRITE) block when running at full speed. I verified this by placing a while(1) inside the block — it is never reached. As a result, the FIRC_DIV_SEL write is skipped and the register stays at its reset value 3 (48MHz) instead of the configured 2 (3MHz). This makes my STM tick run 16x faster than intended.

However, when I run in debug mode (stepping / with breakpoints), the same block executes correctly and FIRC_DIV_SEL is properly set to 2 (3MHz). This difference between full-speed and debug execution is the key symptom.

So the APP_CORE_ACC bit in CONFIG_REG_GPR is not set to CLOCK_IP_APP_CAN_WRITE at the moment Mcu_InitClock reads it during a full-speed multicore boot, but it does become writable when I slow execution down with the debugger.

Additional context on my setup:

• Mcu_InitClock and Mcu_SetMode are called only on Core 0. Core 1 (CM7_1) does not call any MCU clock API.
• Core 1 is brought up from Core 0 via MC_ME (PRTN0_CORE1_*).
• I am not loading any HSE application firmware.
• The same configuration works correctly in single-core (FIRC_DIV_SEL = 2 / 3MHz).
• Tool environment: MCAL RTD 3.0.0, EB Tresos 27.1.0.

Could you help me understand the following:

1. What controls the APP_CORE_ACC bit in CONFIG_REG_GPR? Under what conditions does the SBAF grant application-core write access to FIRC_DIV_SEL?
2. Why would this bit be set correctly in single-core but NOT be set (at full speed) in a multicore configuration? Does bringing up CM7_1 or adding the multicore boot flow change when/whether the SBAF grants this access?
3. Since the block executes correctly under the debugger but not at full speed, this strongly suggests a timing/ordering issue between the SBAF granting write access and Core 0 calling Mcu_InitClock. What is the recommended way to ensure the SBAF has granted APP_CORE_ACC = APP_CAN_WRITE before Core 0 performs the clock initialization?
4. Is there a specific boot configuration (IVT, lifecycle, or SBAF-related setting) that determines whether the application core is granted this access in a multicore setup?

Thank you for your support. I look forward to your guidance.

Best regards,