topic Re: HSE_ReadAdkp returning HSE_SRV_RSP_INVALID_ADDR in S32K

HSE_ReadAdkp returning HSE_SRV_RSP_INVALID_ADDR

Bhushan1312 — Tue, 16 Dec 2025 10:38:32 GMT

Hello Team,

I am trying to set ADKP for S32K314 platform.

Though I am able to confirm HSE Flag Enabled and HSE FW Version using below functions:

HSEFwFlg = checkHseFwFeatureFlagEnabled();

(void)HSE_GetVersion_Example(&gHseFwVersion);

I am getting HSE_SRV_RSP_INVALID_ADDR (0x55A5A26AUL) for check_DebugPasswordProgrammed_Status() function where HSE_ReadAdkp() is called. I guess expected response when ADKP is not programmed is HSE_SRV_RSP_NOT_ALLOWED.

Please guide me in this.

Thanks,

Bhushan

Re: HSE_ReadAdkp returning HSE_SRV_RSP_INVALID_ADDR

lukaszadrapa — Wed, 17 Dec 2025 07:22:51 GMT

Hi @Bhushan1312

Yes, I confirmed that reading of HSE_APP_DEBUG_KEY_ATTR_ID will return error code HSE_SRV_RSP_NOT_ALLOWED when ADKP is not programmed yet.

Try to disable data cache to see if it makes a difference. All data objects used for communication with HSE must be forced to non-cacheable memory and it is quite common root cause.

Also notice that HSE can’t see DTCM memory at 0x2000_0000. This address range is visible only for core. HSE can see only DTCM backdoor addresses at 0x2100_0000. My recommendation is to use only normal RAM for communication with HSE, not DTCM.

There’s an option to enable DTCM support in Autosar Crypto driver. Then the driver checks all used addresses and it adds corresponding offset when necessary. If Crypto driver is not used, this is up to user. The best option is - do not use DTCM for communication with HSE.

Regards,

Lukas

Re: HSE_ReadAdkp returning HSE_SRV_RSP_INVALID_ADDR

Bhushan1312 — Thu, 18 Dec 2025 05:52:39 GMT

Thank You @lukaszadrapa ..

I moved HSE related data variables to Non-Cacheable SRAM and it worked for me.