S32K311 HSE — Random Generate Service (RNG) not working

[Sapana_MQ]

Hello NXP Team,

S32K3   

Hardware & Software:

• MCU: NXP S32K311, Cortex-M7 + HSE-B subsystem
• HSE FW: 0.12.0 / 2.55.0 FULL_MEM STANDARD
• MCAL: NXP RTD 6.0.0 (Crypto_43_HSE_TS_T40D34M60I0R0)
• AUTOSAR Stack: Vector MicroSAR R34, DaVinci 5.31.55 SP5
• Compiler: GHS (Green Hills)
• Debugger: Lauterbach TRACE32

Problem Statement:

We are trying to get HSE random number generation working on S32K311. HSE firmware initializes successfully (hseStatus = 0x960 → INIT_OK | RNG_INIT_OK | HOST_DEBUGGER | CUST_SUPER_USER). However, the RNG service fails in both approaches:

Approach 1 — Via AUTOSAR Csm stack (Csm_RandomGenerate

• The driver returns timeout
• In the Lauterbach debugger, the MU0_MUB Receive Register (RR) shows error code 0x55A5A26A = HSE_SRV_RSP_INVALID_ADDR ("The address parameters are invalid")

Approach 2 — Bypassing AUTOSAR stack, calling Hse_Ip_ServiceRequest directly:

• The call returns HSE_IP_SRV_RSP_NO_RESPONSE (timeout, no response in RR at all)
• TSR bit clears (HSE consumed the request), but RSR never gets set

In both cases, the expected random data is never generated.

We also attempted HSE_SRV_ID_FORMAT_KEY_CATALOGS (since INSTALL_OK bit 9 / 0x200 is NOT set in hseStatus) and observed the same timeout behavior.

Do we really need Key formatting for RNG?

MU base address: MU0_MUB = 0x4038C000.

Observation	Via Csm (AUTOSAR)	Via direct Hse_Ip call
TSR (after TR write)	Bit clears ✓	Bit clears ✓
RSR (during polling)	Eventually set	Never set (stays 0)
RR value	0x55A5A26A (INVALID_ADDR)	No response
Driver return	Timeout- No response	Timeout - HSE_IP_SRV_RSP_NO_RESPONSE
hseStatus (FSR)	0x960	0x960

Troubleshooting Steps Performed:

1. Verified hseStatus = 0x960 — Confirmed HSE FW booted successfully, RNG engine initialized, lifecycle is CUST_SUPER_USER. Noted that INSTALL_OK (bit 9) is not set.
2. Ruled out buffer alignment — Ensured random number output buffer is 4-byte aligned and placed in SRAM (0x20400000 region), not in DTCM (0x20000000) which HSE cannot access.
3. Ruled out D-CACHE coherency — Added Cache_Ip_Clean() before Hse_Ip_ServiceRequest() and Cache_Ip_Invalidate() after. Verified in Lauterbach that Data (D:) and Supervisor Data (SD:) memory views show identical content — cache is not causing stale data.
4. Verified channel allocation — Ensured channel 0 is used for admin services and channel 1+ via Hse_Ip_GetFreeChannel() for general services.
5. Cleared descriptor memory — Added memset() to zero the entire hseSrvDescriptor_t before populating fields to eliminate any stale metadata.
6. Attempted FormatKeyCatalogs — Since INSTALL_OK was not set, attempted HSE_SRV_ID_FORMAT_KEY_CATALOGS as the first service after Crypto_43_HSE_Init(). Same timeout behavior observed.
7. Also, we placed.mcal_bss_no_cacheable and .mcal_data_no_cacheable in a non-cacheable memory region (with MPU configured as non-cacheable) for HSE service descriptors to work correctly? Is INVALID_ADDR expected when descriptors are in cacheable memory?

As per the HSE User Manual, we have followed all the required steps for executing the RNG job. However, we are not receiving any response from the HSE.

To assist with troubleshooting, we have attached relevant debugging snapshots for your reference.

We request you to kindly review the issue and provide your feedback or guidance on resolving this problem.

CC; @Shubham_MQ 

[Sapana_MQ]

Yes, HSE core is not responding. 

I have attached the screenshot of the complete MU register for your reference.

I am also sharing again the screenshot of the GSR register, which was captured during debugging.

Please review the attached register details and let us know your observations or recommended next steps.

[davidtosenovjan]

If I understand you well, HSE core does not respond at all. Could you investigate GSR register?