S32K324 HSE Setting ADKP Issue 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. Re: S32K324 HSE Setting ADKP Issue 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 Re: S32K324 HSE Setting ADKP Issue 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?
記事全体を表示