HSE_B Service No-Response Issue after Multi-Core Activation on S32K328

[NewbieNerd]

Dear NXP Technical Support Team,

I am writing to request technical assistance regarding an issue where the HSE_B service hangs (no response) after activating multi-core operations on the S32K328 platform.
1. Environment & Setup

 - MCU: S32K328 (Dual Cortex-M7 + HSE_B)

 - Configuration Tool: EB tresos (for MCAL configuration)

 - Core Roles: M7_0 and M7_1 are running concurrently with an Autosar-OS.

                         M7_0 communicates with HSE_B using shared SRAM for message descriptors.

2. XRDC & Peripheral Configuration (For Testing)

To isolate permission issues, we have applied a highly permissive configuration, but the symptoms remain identical regardless of whether M7_0 and HSE_B are grouped into a single domain or separated into distinct domains:

 - Memory Config: Full Access granted for all SRAM regions, and specific PFLASH/DFLASH regions allocated for HSE.

 - Peripheral Config (PDAC): Full Access assigned to CONFIGURATION_GPR, PFC/PFC_ALT, FMU/FMU_ALT, and MU_0 / MU_1.

3. Boot Sequence

The application follows the boot sequence below:

 3.1 M7_0 Boots → Clock Initialization.

 3.2 Verify HSE STATUS is INIT_OK.

 3.3 Resource Manager Initialization (RM_Init for XRDC setup).

 3.4 Peripheral Initialization.

 3.5 Start M7_1 (Core 1).

 3.6 Start OS.

4. Problem Description & Symptoms

Both M7_0 and M7_1 start up and run normally within the OS environment. However, as soon as an HSE service request is invoked afterwards, the HSE fails to respond, resulting in a hang. The register states during the hang are as follows:

- XRDC Register Status:

    XRDC_DERRLOC[3] changes to 0x00020000.

    However, no error values are captured in the DERR_W3_0/1/2 or DERR_W3_16/17/18 registers.

 - Messaging Unit (MU_0) Status:

    In the MU_0_TSR register, the flags TE1 and TE2 stay in the "Not Empty" state and do not clear.

    In the MU_0_FSR register, the F3 flag remains unchanged.

5. Questions

5.1 Given that XRDC_DERRLOC[3] shifts but DERR_W3_x registers show no specific error details, what could be triggering this behavior? Could it be related to an implicit access violation by the HSE internal DMA or bus matrix configuration?

 5.2 Even though the shared SRAM is explicitly configured as Non-Cacheable via the MPU, are there any known multi-core constraints or hidden caching behaviors under an OS environment that could prevent the HSE from reading the descriptors?

 5.3 Are there any known constraints or prerequisites regarding the execution timing of RM_Init (XRDC initialization) relative to the HSE_STATUS_INIT_OK check or Core 1 bootup?

 5.4 What steps or additional registers should we check to identify why the MU transmit status registers (TE1/TE2) are stuck and the HSE is not processing the descriptors?

We would highly appreciate your insights and guidance on resolving this bottleneck.

Best regards,

[davidtosenovjan]

Could you please specify used HSE FW version, used RTD and S32DS revisions? Thanks

[NewbieNerd]

Thank you for your prompt reply. Here are the specific version details of our development environment as requested:
1. Software & Firmware Versions

   - HSE Firmware: S32K358_0_2_40_0

     Note: We are using this version as the documentation specifies that it supports the S32K328 derivative.

   -  RTD (Real-Time Drivers):  AUTOSAR Release Version: 4.7.0, Software Version: 3.0.0

2. Development Toolchain

    IDE: We are not using S32DS for this project.

    Configuration Tool: EB tresos Studio is being utilized for all MCAL configurations.

                                            EB tresos Version: 27.1.0

3. Additional Context

I am currently leading the development from the HOST side (Cortex-M7). We have already thoroughly aligned and discussed this behavior with our internal HSE FW development team. However, we could not find any root cause or anomalies from the HSE FW perspective, which leads us to highly suspect that this is a HOST-side runtime configuration or synchronization issue triggered during the multi-core/OS initialization.

I sincerely hope we can isolate the exact bottleneck with your guidance. Please let me know if you need any further configuration dumps or register captures from our EB tresos project.

Best regards,

[lukaszadrapa]

Hi @NewbieNerd 

HSE is always supposed to return a response. If no response is received, HSE went to shutdown mode, most likely. This happens in case of fatal error. For example, if HSE can’t read or write some data due to: insufficient access rights, double bit ECC error, invalid address etc.

You can confirm this by reading of GSR register in MU_0. If bit ‘0’ is set, HSE is in shutdown mode.

To see the error details in XRDC, it’s necessary to follow section “19.7.3.2 Handling domain access violation errors” in S32K3 reference manual.

Step 2 is important to see the details in DERR registers:

For quick debugging purposes, you can simply move Cortex-M7_0 / Cortex-M7_0_debug to domain 3 (HSE is always in domain 3 on S32K328) by writing DID=3 in MDA_W0_0_DFMT0:

Then you should see the details in DERR (just an example from my debugger when I triggered some error by HSE). This was not visible when DID = 0:

This should provide some hints what went wrong.

Another point is that XRDC should be enabled after HSE_STATUS_INIT_OK is set. This is explicitly mentioned in HSE FW reference manual:

Regards,

Lukas

[NewbieNerd]

Thank you for your valuable debugging guide and insights.

Regarding your suggestions, I have investigated further and confirmed the following results on our side. I would like to share these findings and request your guidance on how to bypass our tool configuration constraints.
1. RTD Version Clarification

   As mentioned in our previous correspondence, we are currently utilizing:
   -   RTD SW Version: 3.0.0
   -  AUTOSAR Release Version: 4.7.0

2. EB tresos Configuration Constraint (Domain Allocation)

   You mentioned that on the S32K328, the HSE is permanently assigned to Domain 3.
   However, in our EB tresos (v27.1.0) environment with the RTD 3.0.0 plug-in, the configuration structure for the Resource Manager (RM) only allows us to allocate up to Domain 2 (Domain ID 0, 1, and 2).

  Because the configuration tool limits the maximum number of domains to 2, we are unable to naturally configure or assign masters/slaves to Domain 3 via EB tresos.

  Question: Could you please specify which RTD version or patch officially unlocks Domain 3 configuration in EB tresos for the S32K328 derivative? Or do we need to manually override the XRDC registers via runtime code?

3. XRDC Error Register Status (DERRLOC vs DERR_Ww_i)

  Following your reference manual guide, we observed the following behavior during the error state:

   XRDC_DERRLOC[3] is captured as 0x00020000 by dump not peripheral view(DERRLOC[3] not exist).
However, despite following the error-handling steps, all DERR_Ww_i registers remain 0.
As you pointed out, this lack of detail in DERR appears to happen because our host core (Cortex-M7_0) is running on a different domain (e.g., DID=0 or 1), preventing it from reading the error logs generated by Domain 3 (HSE).

4. Execution Timing Verification

 We have double-checked our boot sequence and confirmed that XRDC is enabled explicitly AFTER HSE_STATUS_INIT_OK is set, which complies with the HSE FW Reference Manual requirement.

5. Request for Guidance

Since we cannot easily move the Cortex-M7_0 or its debug master to Domain 3 inside EB tresos due to the tool constraint mentioned above, could you advise us on:

The proper method to runtime-override MDA_W0_0_DFMT0 to force DID=3 for debugging without breaking the MCAL initialization?

If there are any known workarounds in RTD 3.0.0 to inspect Domain 3 error registers from Domain 0/1?

Thank you again for your continuous support.

[lukaszadrapa · Accepted solution]

The missing domain 3 is known issue in RTD 3.0.0. It is fixed in version 4.0.0 and higher. Recommended solution is to upgrade the RTD to newest version. Otherwise it would be necessary to manually implement some kind of workaround – rewrite XRDC registers, rewrite configuration file, generate configuration file in newer RTD and then use it in your project or something like that… But this would be rather temporary hot fix, recommended and clean solution is to use newer RTD.

According to the section “19.7.3.2 Handling domain access violation errors”, the domain should be reconfigured only temporarily for the error handler. At this point, I would just try to modify DID by debugger to be able to read the error details.

And did you confirmed if bit 0 in GSR register in MU_0 is set?

Regards,

Lukas