S32K324 HSE Setting ADKP Issue

[MohamedAbdelmoteleb]

Hello, I am currently working on enabling Secure Debug for the NXP S32K324. I have configured the target for dynamic authentication with UID diversification by setting the following attributes:

1. HSE_EXTEND_CUST_SECURITY_POLICY_ATTR_ID

2. HSE_APP_DEBUG_KEY_ATTR_ID

3. HSE_DEBUG_AUTH_MODE_ATTR_ID

The issue is that the target enters an unhandled exception immediately after each attribute is set and following a reset. Despite the exceptions, the attributes appear to be set correctly when queried.

 

[lukaszadrapa]

Hi @MohamedAbdelmoteleb 

Table 99 in HSE Firmware reference manual rev. 2.7 shows the types of all attributes.

All those mentioned attributes are OTP-ATTR:

That means the attributes are stored to UTEST memory. But UTEST memory is in the same read partition as flash block 0. And that means it is not possible to access flash block 0 while programming the UTEST. Most likely, your code is running from flash block 0, isn’t it?

The solution is to executed the code (which triggers HSE hseSetAttrSrv_t service) from RAM or from another flash block. This is described in mentioned manual in section “14.6.5  Synchronizing flash read/write access between HSE and application core”, Table 151.

Regards,

Lukas

[MohamedAbdelmoteleb]

Hello @lukaszadrapa ,

Thank you for the clarification.

We are currently using Hse_Ip_ServiceRequest to invoke the hseSetAttrSrv_t request. Based on your feedback and the requirements in Section 14.6.5 (Table 151), I would like to confirm the standard way for the implementation:

Use of Hse_Ip Driver: Is it the standard way to continue using the standard RTD Hse_Ip driver (Hse_Ip_ServiceRequest) for these OTP attribute services? Since the driver is normally linked to Flash by default (CRYPTO_43_HSE_SEC_CODE), is it the standard way to manually relocate this sections CRYPTO_43_HSE_SEC_CODE to SRAM OR to another Flash block?

Relocation Strategy: If RAM relocation is the standard way, is it sufficient to relocate only the Hse_Ip_ServiceRequest call chain and the synchronization loop to SRAM, or must the entire Interrupt Vector Table also be moved to RAM to prevent a fetch from Block 0 during an unexpected interrupt?

Synchronization Method: To comply with the synchronization requirements in Table 151, is polling the HSE GPR Register 3 (0x4039C028) for bits 24 and 25 the standard way to determine when it is safe to resume execution from Flash?

Single-Block Hardware: For S32K3 variants that feature only a single Flash block (where "another flash block" is not an option), is SRAM execution the standard way for setting OTP attributes?

[lukaszadrapa · Accepted solution]

Yes, it is standard way to use Hse_Ip driver for this. But the driver is not prepared to relocate necessary code to RAM or to another flash block, so it must be done manually. And it’s not only HSE_IP_ServiceRequest function. Be aware that this function calls some other functions.

This is the critical part of code inside the function when using synchronous mode:

if (HSE_IP_REQTYPE_SYNC == pRequest->eReqType)

        {

            /* Convert from microseconds to ticks */

            u32TimeoutTicks = OsIf_MicrosToTicks(pRequest->u32Timeout, (OsIf_CounterType)HSE_IP_TIMEOUT_OSIF_COUNTER_TYPE);

            /* Send the service request to HSE */

            Mu_Ip_SetTxRegister(Hse_Ip_apMuBase[u8MuInstance], u8MuChannel, (uint32)pHseSrvDesc);

            /* Read the current value of the counter */

            u32CurrentTicks = OsIf_GetCounter((OsIf_CounterType)HSE_IP_TIMEOUT_OSIF_COUNTER_TYPE);

            /* Wait for the HSE response */

            while ((FALSE == Mu_Ip_IsResponseReady(Hse_Ip_apMuBase[u8MuInstance], u8MuChannel)) && (u32ElapsedTicks < u32TimeoutTicks))

            {

                /* Update the elapsed ticks, current ticks will be updated too by the OsIf function */

                u32ElapsedTicks += OsIf_GetElapsed(&u32CurrentTicks, (OsIf_CounterType)HSE_IP_TIMEOUT_OSIF_COUNTER_TYPE);

            }

The Mu_Ip… functions are inlined, so there’s no problem. But OsIf functions from BaseNXP module are not inlined, so you need to move them to RAM too. I recommend to step the function to see that all the code executed in this area is running from RAM. Or you can check the map file as well.

I will create a feature request to implement some support for code relocation to future versions of the driver because I can see this is causing troubles.

When the UTEST is being programmed, nothing can access flash block 0. So, it’s necessary to keep the interrupts disabled. Otherwise you would have to move all used resources (vector table, handlers, functions and data used by handlers) to RAM or to another flash block. But because OTP attributes are usually programmed in factory in controlled environment, it should be more convenient to disable interrupts.

Synchronization: in configuration phase, it is good idea to launch one command at a time when programming OTP attributes. In this case, it’s sufficient to wait for completion of current service only. In more complex system, yes, it could be necessary to use also HSE GPR3 register.

In case of single flash block device, run the code from RAM.

Regards,

Lukas