topic Re: [Virtual ECU] HSE Request for MAC generate/verify is returning address param invalid response in S32K

[Virtual ECU] HSE Request for MAC generate/verify is returning address param invalid response

suponn — Tue, 10 Mar 2026 16:13:51 GMT

Hi Team,

I am observing a behavior on the S32K388 where the request for MAC generate/verify (0xA50201) to HSE is responding back with address parameters are invalid (0x55A5A26A).

The HSE Annexure doc indicates" HSE_SRV_RSP_INVALID_ADDR
The address parameter and length are defined in the SW Location Info1 of the HSE Signed Header is not equal to SW Location Info2"

Could you please let me know what would be these SW Location Info1, SW Location Info2 I have to check for, for address parameter and length?

Thanks,

Sunil

@DanutMosor

Re: [Virtual ECU] HSE Request for MAC generate/verify is returning address param invalid response

lukaszadrapa — Thu, 12 Mar 2026 08:33:29 GMT

Hi @suponn

I can see nothing wrong in the HSE descriptor. Could you check if all parameters are forced to non-cacheable RAM?

Regards,

Lukas

Re: [Virtual ECU] HSE Request for MAC generate/verify is returning address param invalid response

suponn — Mon, 04 May 2026 14:48:54 GMT

This issue is only observed on VECU.

I am observing the Secure peripheral is able to access only 64Kb of DTCM memory, when it was supposed to access 128Kb (0x21000000-0x2101FFFF) when S32K388 Core 0 and Core 1 are configured in lock step.

(The Software seems to be writing the RID payload length between 0x2101000-0x2101FFFF and HSE returns with status 0x55A5A26A)

This is causing the key provisioning to fail with undefined status (0xFE)

Could you please let me know how can I configure HSE_B_SS to access entire 128Kb of DTCM memory?

Thanks

Re: [Virtual ECU] HSE Request for MAC generate/verify is returning address param invalid response

lukaszadrapa — Tue, 05 May 2026 10:10:38 GMT

Yes, S32K388 core 0 has 128KB of DTCM in case of lock step mode and HSE is able to access whole 128KB. I confirmed this on my board.

I can see following reasons why it doesn’t work:

The upper half of DTCM is not initialized. However, double bit ECC error would cause HSE shutdown, not invalid address error.
If DTCM is used for communication with HSE, make sure that backdoor addresses are used. HSE can’t see normal DTCM addresses. If Crypto driver is used, DTCM support must be enabled.
If XRDC is enabled, HSE must have granted the access to DTCM memory area.
And the last one which was already mentioned – make sure that only non-cacheable RAM is used.

Regards,

Lukas

Re: [Virtual ECU] HSE Request for MAC generate/verify is returning address param invalid response

suponn — Tue, 05 May 2026 13:32:25 GMT

Thank you Lukas for analyzing this.

The upper half of DTCM is not initialized. However, double bit ECC error would cause HSE shutdown, not invalid address error. >>[SP] Yeah HSE is not considering upper half of DTCM as configured (HSE treating Core 0 is not in lock step config)
If DTCM is used for communication with HSE, make sure that backdoor addresses are used. HSE can’t see normal DTCM addresses. If Crypto driver is used, DTCM support must be enabled. >>[SP] Correct I am using DTCM backdoor access. And I dont see HSE error HSE_SRV_RSP_INVALID_ADDR (0x55A5A26A) when the DTCM back door range access is with in 64Kb (0x21000000 to 0x2100FFFF)
If XRDC is enabled, HSE must have granted the access to DTCM memory area. >>[SP]XRDC is enabled and no issues with HSE accessing lower DTCM 64Kb
And the last one which was already mentioned – make sure that only non-cacheable RAM is used. >>[SP] same no issues with HSE accessing lower DTCM 64Kb so this configuration might be correct