MWCT2016 HSE 2.40.0 Secure Boot Configuration Failure- ImportPlainSymKeyReqMuChannel

ShrikantM

Environment

MCU: MWCT2016S based Wireless Charging Controller
Working Setup (Legacy):
- HSE FW Version: 2.6.0
- (Application + Secure Boot) merge hex.
New Setup (Failing):
- HSE FW Version: 2.40.0
- (Application + Secure Boot) merge hex.

We are migrating from HSE FW v2.6.0 to HSE FW v2.40.0 while maintaining the same Qi key provisioning and Secure Boot flow.

Problem Statement

With HSE FW v2.6.0, the complete provisioning sequence executes successfully:

HSE installation
Erase Keys
S2TP key slot provisioning
Qi key programming
Secure Boot configuration
Application boots successfully

With HSE FW v2.40.0, all provisioning steps complete successfully until Secure Boot configuration is started.

During Secure Boot configuration the following API fails:

ImportPlainSymKeyReqMuChannel() in secure boot code.

return HSE response: 0x55A5A399 which corresponds to:

#define HSE_SRV_RSP_INVALID_PARAM ((hseSrvResponse_t)0x55A5A399UL)

After this failure, Secure Boot configuration cannot be completed, and the ECU remains stuck in the Secure Boot code.

Provisioning Sequence

Working Configuration (HSE 2.6.0)

00_Blank_MWCT2016_CodeFlash_DataFlash.hex

Power Reset

01_HSE_flash.srec version 2.6.0

Power Reset

02_EraseKeysSW.hex

Power Reset

03_S2TP_KeySlotsAligned.srec S2TP SW Version: 1.1.1

Power Reset

Write Qi Keys via UART

Power Reset

Application+SecureBoot.hex

Power Reset

HSE response after merge hex flashing from UART log:

HseStatus : 2848

bit 0 : 0 RFU

bit 1 : 0 HSE_SHE_STATUS_SECURE_BOOT

bit 2 : 0 HSE_SHE_STATUS_SECURE_BOOT_INIT

bit 3 : 0 HSE_SHE_STATUS_SECURE_BOOT_FINISHED

bit 4 : 0 HSE_SHE_STATUS_SECURE_BOOT_OK

bit 5 : 1 HSE_STATUS_RNG_INIT_OK

bit 6 : 0 HSE_STATUS_HOST_DEBUGGER_ACTIVE

bit 7 : 0 HSE_STATUS_HSE_DEBUGGER_ACTIVE

bit 8 : 1 HSE_STATUS_INIT_OK

bit 9 : 1 HSE_STATUS_INSTALL_OK

bit 10 : 0 HSE_STATUS_BOOT_OK

bit 11 : 1 HSE_STATUS_CUST_SUPER_USER

bit 12 : 0 HSE_STATUS_OEM_SUPER_USER

bit 13 : 0 HSE_STATUS_FW_UPDATE_IN_PROGRESS

bit 14 : 0 RFU

bit 15 : 0 RFU

smrCoreStatus_Get :

smrCoreStatus[1] : 0 , smrCoreStatus[0] : 0

smrStatus[1] : 0 , smrStatus[0] : 0

Code debug log HSE response:

ImportPlainSymKeyReqMuChannel-hseResp: 0x55a5aa33

LoadBootMacKey-hseResp: 0x55a5aa33

Generic_ImportKeys-hseResp: 0x55a5aa33

KeyProvisioningForJTAG-status: 1

SecureBootConfiguration-hseResp: 0x55a5aa33

KeyProvisioningToHseNVM-status: 1

NON_SECURE_IVT-BLOCK1-hseResp: 0x55a5aa33

SECURE_IVT-BLOCK0-hseResp: 0x55a5aa33

writeDefaultData

Running Secure Boot CFG program

Hse-FW Version : 0.13.0.2.6.0 , full mem

using interface version : 0.13.0.2.6.0

HseStatus : 2862

bit 0 : 0 RFU

bit 1 : 1 HSE_SHE_STATUS_SECURE_BOOT

bit 2 : 1 HSE_SHE_STATUS_SECURE_BOOT_INIT

bit 3 : 1 HSE_SHE_STATUS_SECURE_BOOT_FINISHED

bit 4 : 0 HSE_SHE_STATUS_SECURE_BOOT_OK

bit 5 : 1 HSE_STATUS_RNG_INIT_OK

bit 6 : 0 HSE_STATUS_HOST_DEBUGGER_ACTIVE

bit 7 : 0 HSE_STATUS_HSE_DEBUGGER_ACTIVE

bit 8 : 1 HSE_STATUS_INIT_OK

bit 9 : 1 HSE_STATUS_INSTALL_OK

bit 10 : 0 HSE_STATUS_BOOT_OK

bit 11 : 1 HSE_STATUS_CUST_SUPER_USER

bit 12 : 0 HSE_STATUS_OEM_SUPER_USER

bit 13 : 0 HSE_STATUS_FW_UPDATE_IN_PROGRESS

bit 14 : 0 RFU

bit 15 : 0 RFU

smrCoreStatus_Get :

smrCoreStatus[1] : 0 , smrCoreStatus[0] : 0

smrStatus[1] : 1 , smrStatus[0] : 1

Failing Configuration-HSE FW 2.40.0 reports:

00_Blank_MWCT2016_CodeFlash_DataFlash.hex

Power Reset

01_S32K344_HSE_FW_UPDATE_v2_40_0.srec

Power Reset

02_M210WLCUMBCD00A_WSB00.31_EraseKeySW_UART_ENABLE.hex

Power Reset

03_S2TP_2_1_0_KeySlotsAligned.srec

Power Reset

Write Qi Keys via UART

Power Reset

Application+SecureBoot.hex

Power Reset

HseStatus : 2912

bit 0 : 0 RFU

bit 1 : 0 HSE_SHE_STATUS_SECURE_BOOT

bit 2 : 0 HSE_SHE_STATUS_SECURE_BOOT_INIT

bit 3 : 0 HSE_SHE_STATUS_SECURE_BOOT_FINISHED

bit 4 : 0 HSE_SHE_STATUS_SECURE_BOOT_OK

bit 5 : 1 HSE_STATUS_RNG_INIT_OK

bit 6 : 1 HSE_STATUS_HOST_DEBUGGER_ACTIVE

bit 7 : 0 HSE_STATUS_HSE_DEBUGGER_ACTIVE

bit 8 : 1 HSE_STATUS_INIT_OK

bit 9 : 1 HSE_STATUS_INSTALL_OK

bit 10 : 0 HSE_STATUS_BOOT_OK

bit 11 : 1 HSE_STATUS_CUST_SUPER_USER

bit 12 : 0 HSE_STATUS_OEM_SUPER_USER

bit 13 : 0 HSE_STATUS_FW_UPDATE_IN_PROGRESS

bit 14 : 0 RFU

bit 15 : 0 RFU

smrCoreStatus_Get :

smrCoreStatus[1] : 0 , smrCoreStatus[0] : 0

smrStatus[1] : 0 , smrStatus[0] : 0

ImportPlainSymKeyReqMuChannel-hseResp: 0x55A5A399

after Power reset:

UML SW Version : WSB00.3B_UART_ENABLE

Running Secure Boot CFG program

Hse-FW Version : 0.13.0.2.40.0 , full mem

using interface version : 0.13.0.2.40.0

HseStatus : 2848

bit 0 : 0 RFU

bit 1 : 0 HSE_SHE_STATUS_SECURE_BOOT

bit 2 : 0 HSE_SHE_STATUS_SECURE_BOOT_INIT

bit 3 : 0 HSE_SHE_STATUS_SECURE_BOOT_FINISHED

bit 4 : 0 HSE_SHE_STATUS_SECURE_BOOT_OK

bit 5 : 1 HSE_STATUS_RNG_INIT_OK

bit 6 : 0 HSE_STATUS_HOST_DEBUGGER_ACTIVE

bit 7 : 0 HSE_STATUS_HSE_DEBUGGER_ACTIVE

bit 8 : 1 HSE_STATUS_INIT_OK

bit 9 : 1 HSE_STATUS_INSTALL_OK

bit 10 : 0 HSE_STATUS_BOOT_OK

bit 11 : 1 HSE_STATUS_CUST_SUPER_USER

bit 12 : 0 HSE_STATUS_OEM_SUPER_USER

bit 13 : 0 HSE_STATUS_FW_UPDATE_IN_PROGRESS

bit 14 : 0 RFU

bit 15 : 0 RFU

smrCoreStatus_Get :

smrCoreStatus[1] : 0 , smrCoreStatus[0] : 0

smrStatus[1] : 0 , smrStatus[0] : 0

ImportPlainSymKeyReqMuChannel-hseResp: 0x55a5a399

ECU getting stuck in secure boot only

VaneB

Hi @ShrikantM

Could you please share your key catalogs as well as the parameters used in the ImportPlainSymKeyReqMuChannel() function call? The reported error indicates that one or more HSE request parameters are invalid.

BR, VaneB

SwapnilGawade

Hi @VaneB ,

We are using below key catalogs:

/* Table containing NVM key catalog entries */

const hseKeyGroupCfgEntry_t aHseNvmKeyCatalog[] =

{

/* NvmKeyGroup_0 */

{(HSE_MU0_MASK), HSE_KEY_OWNER_CUST, HSE_KEY_TYPE_SHE, 1U, 128U, {0U, 0U}},

/* NvmKeyGroup_1 */

{(HSE_MU0_MASK), HSE_KEY_OWNER_CUST, HSE_KEY_TYPE_ECC_PAIR, 1U, 256U, {0U, 0U}},

/* NvmKeyGroup_2 */

{(HSE_MU0_MASK), HSE_KEY_OWNER_CUST, HSE_KEY_TYPE_AES, 1U, 256U, {0U, 0U}},

/* Marker to end the key catalog */

{0U, 0U, 0U, 0U, 0U, {0U, 0U}}

};

/* Table containing RAM key catalog entries */

const hseKeyGroupCfgEntry_t aHseRamKeyCatalog[] =

{

/* RamKeyGroup_0 */

{(HSE_MU0_MASK), HSE_KEY_OWNER_CUST, HSE_KEY_TYPE_SHE, 1U, 128U, {0U, 0U}},

/* Marker to end the key catalog */

{0U, 0U, 0U, 0U, 0U, {0U, 0U}}

};

For below function we receive HSE_SRV_RSP_INVALID_PARAM

hseSrvResponse_t Generic_ImportKeys(void)

{

hseSrvResponse_t srvResponse = HSE_SRV_RSP_GENERAL_ERROR;

/*Import key linked with SMR#0*/

srvResponse = ImportPlainSymKeyReqMuChannel(

MU0,

1U,

NVM_AES128_BOOT_KEY,

HSE_KEY_TYPE_AES,

( HSE_KF_USAGE_VERIFY ),

0U,

aesEcbKeyLength,

aesEcbKey,

TRUE

);

ASSERT(HSE_SRV_RSP_OK == srvResponse );

if(HSE_SRV_RSP_OK != srvResponse)

goto exit;

/* load keys for SHE secure boot */

srvResponse = LoadBootMacKey();

ASSERT(HSE_SRV_RSP_OK == srvResponse );

if(HSE_SRV_RSP_OK != srvResponse)

goto exit;

exit:

return srvResponse;

}

Please check attached global_defs.h for more details about the parameters.

Thanks and Regards,

Swapnil Gawade

VaneB

Hi @SwapnilGawade

Thank you for sharing the information. Based on your configuration, I have the following observations:

The SHE key group is configured with HSE_KEY_OWNER_CUST as the owner. However, the HSE Service API Reference Manual specifies that, for an SHE key catalog configuration, the owner of an SHE key group must be set to HSE_KEY_OWNER_ANY. This is also demonstrated in the NVM SHE Key Catalog Configuration example.
The targetKeyHandle passed to ImportPlainSymKeyReqMuChannel() is defined as:
```
#define NVM_AES128_BOOT_KEY  GET_KEY_HANDLE(HSE_KEY_CATALOG_ID_NVM, 1, 1)
```
However, according to your NVM key catalog configuration, the AES key group is the third group (NvmKeyGroup_2). Based on this configuration, the correct definition for NVM_AES128_BOOT_KEY should be:
```
GET_KEY_HANDLE(HSE_KEY_CATALOG_ID_NVM, 2, 0)
```

SwapnilGawade

Hi @VaneB ,

As per your suggestion I have done the changes, but it also gives similar response as HSE_SRV_RSP_INVALID_PARAM (0x55a5a399).

After debugging we found that it, in ImportPlainSymKeyReqMuChannel(...)->EraseKeyReq(targetKeyHandle, HSE_ERASE_NOT_USED))->HSE_Send(muIf, muChannelIdx, gSyncTxOption, pHseSrvDesc)->Hse_Ip_ServiceRequest(u8MuInstance, u8MuChannel, pHseIp_Request , HSE_DTCM_ADDR(pHseSrvDesc))->Mu_Ip_SetTxRegister(Hse_Ip_apMuBase[u8MuInstance], u8MuChannel, (uint32)pHseSrvDesc) retruns response as HSE_SRV_RSP_INVALID_PARAM (0x55a5a399).

The parameters of pHseSrvDesc are added in attached Mu_Ip_SetTxRegister-pHseSrvDesc.xlsx.

Thanks and Regards,

Swapnil Gawade

VaneB

Hi @SwapnilGawade

According to your description, I noticed that you appear to have combined the DemoApp framework with the Hse_Ip drivers. Is my understanding correct? If so, what modifications have been applied?

Also, have you disabled the data cache in your project? This is a common cause of the HSE_SRV_RSP_INVALID_PARAM error. All data objects used for communication with HSE must be forced to non-cacheable memory.

I also noticed that you are passing HSE_DTCM_ADDR(pHseSrvDesc) as the pHseSrvDesc parameter to the Hse_Ip_ServiceRequest() function. Please refer to the thread HSE_ReadAdkp returning HSE_SRV_RSP_INVALID_ADDR, where my colleague explains some considerations regarding the use of HSE with DTCM memory.

You may also want to take a look at Hse_Ip_ToAHBAddress(), which converts a local address into an HSE host address when TCM support is enabled. It could be useful in this scenario.

SwapnilGawade

Hi @VaneB ,

In working setup with HSE 2.6.0 we are using following libraries:

1. RTD AUTOSAR 4.4

2. Key catalog as below

/* Table containing NVM key catalog entries */

const hseKeyGroupCfgEntry_t aHseNvmKeyCatalog[] =

{

/* NvmKeyGroup_0 */

{(HSE_MU0_MASK), HSE_KEY_OWNER_CUST, HSE_KEY_TYPE_SHE, 1U, 128U, {0U, 0U}},

/* NvmKeyGroup_1 */

{(HSE_MU0_MASK), HSE_KEY_OWNER_CUST, HSE_KEY_TYPE_ECC_PAIR, 1U, 256U, {0U, 0U}},

/* NvmKeyGroup_2 */

{(HSE_MU0_MASK), HSE_KEY_OWNER_CUST, HSE_KEY_TYPE_AES, 1U, 256U, {0U, 0U}},

/* Marker to end the key catalog */

{0U, 0U, 0U, 0U, 0U, {0U, 0U}}

};

/* Table containing RAM key catalog entries */

const hseKeyGroupCfgEntry_t aHseRamKeyCatalog[] =

{

/* RamKeyGroup_0 */

{(HSE_MU0_MASK), HSE_KEY_OWNER_CUST, HSE_KEY_TYPE_SHE, 1U, 128U, {0U, 0U}},

/* Marker to end the key catalog */

{0U, 0U, 0U, 0U, 0U, {0U, 0U}}

};

Same RTD AUTOSAR 4.4 and Key catalog we are using with HSE 2.40.0, but we are facing issue. ImportPlainSymKeyReqMuChannel(...) function returns HSE Response as HSE_SRV_RSP_INVALID_PARAM.

Hse_Ip_ToAHBAddress() function is not available in this RTD AUTOSAR 4.4.

Thanks and Regards,

Swapnil Gawade

VaneB

Hi @SwapnilGawade

As mentioned, the SHE key group is configured with HSE_KEY_OWNER_CUST as the owner. However, the HSE Service API Reference Manual specifies that, for an SHE key catalog configuration, the owner of an SHE key group must be set to HSE_KEY_OWNER_ANY.

Have you disabled the data cache in your project? This is a common cause of the HSE_SRV_RSP_INVALID_PARAM error. All data objects used for communication with HSE must be forced to non-cacheable memory.

Also, would it be possible to share a simple example showing all the steps you are performing to import the key?

Bhushan1312

Hello @VaneB ,

We corrected the Key CatLog as per your suggestion and application requirements.

Secure boot works well if we are using S2TP ver1.1.0 or skipping S2TP flashing. Please see below table to get more idea. We doubting that something has changed with S2TP ver2.1.0 where CatLog is changed for Qi key import which is not matching with below Key CatLog which we have configured.

HSE Version	S2TP Version	Result
2.40	1.1.1	1. Secure Boot works 2. 25 Watt charging fails -> Qi Key import fails Auth: Init Error: 5, Auth: Init Error - Certificate Import/Validate Failed
2.40	2.1.0	1. Secure Boot fails at Import Keys ERROR: 0x55A5A399 2. 25 Watt charging works without Secure Boot SW (Stand alone application) 3. Secure boot works if we skip S2TP flashing. But Charging functionality do not work

Flashing Flow	Erase SW: Erase and Format Key Catlog
	↓
	Power Cycle
	↓
	Flash Qi keys with S2TP
	↓
	Power Cycle
	↓
	Flash SECBoot Code: Keys Import
	↓
	Flash Boot + App code

Key CatLog:

/* Table containing NVM key catalog entries */

const hseKeyGroupCfgEntry_t aHseNvmKeyCatalog[] =

{

/* NvmKeyGroup_0: For implicit SHE Functional operations */

{(HSE_MU0_MASK), HSE_KEY_OWNER_ANY, HSE_KEY_TYPE_SHE, 12U, 128U, {0U, 0U}},

/* NvmKeyGroup_1: Configured as AES to satisfy NVM_AES128_BOOT_KEY (Group 1, Slot 1) */

{(HSE_MU0_MASK), HSE_KEY_OWNER_CUST, HSE_KEY_TYPE_AES, 4U, 128U, {0U, 0U}},

/* NvmKeyGroup_2: Expanded to 3 slots for PROVISION_KEY0 (Slot 0) and APP_MAC_KEY (Slot 2) */

{(HSE_MU0_MASK), HSE_KEY_OWNER_CUST, HSE_KEY_TYPE_AES, 4U, 256U, {0U, 0U}},

/* HMAC key */ \

{ HSE_ALL_MU_MASK, HSE_KEY_OWNER_CUST, HSE_KEY_TYPE_HMAC, 2U, HSE_KEY512_BITS, {0U, 0U} }, \

/* ECC keys */ \

{ HSE_ALL_MU_MASK, HSE_KEY_OWNER_CUST, WRP_KEY_TYPE_ECC_PAIR, 4U, WRP_ECC_KEY_SIZE, {0U, 0U} }, \

{ HSE_ALL_MU_MASK, HSE_KEY_OWNER_CUST, WRP_KEY_TYPE_ECC_PUB, 2U, WRP_ECC_KEY_SIZE, {0U, 0U} }, \

{ HSE_ALL_MU_MASK, HSE_KEY_OWNER_CUST, WRP_KEY_TYPE_ECC_PUB_EXT, 1U, WRP_ECC_KEY_SIZE, {0U, 0U} }, \

/* RSA keys */ \

{ HSE_ALL_MU_MASK, HSE_KEY_OWNER_CUST, HSE_KEY_TYPE_RSA_PAIR, 2U, HSE_KEY4096_BITS, {0U, 0U}}, \

/* NvmKeyGroup_8: Explicit RSA Public Key Group for NVM_RSA2048_PUB_CUSTAUTH_HANDLE0 */

{(HSE_MU0_MASK), HSE_KEY_OWNER_CUST, HSE_KEY_TYPE_RSA_PUB, 1U, 2048U, {0U, 0U}},

/* Marker to end the key catalog */

{0U, 0U, 0U, 0U, 0U, {0U, 0U}}

};

/* Table containing RAM key catalog entries */

const hseKeyGroupCfgEntry_t aHseRamKeyCatalog[] =

{

/* RamKeyGroup_0 */

{(HSE_MU0_MASK), HSE_KEY_OWNER_ANY, HSE_KEY_TYPE_SHE, 1U, 128U, {0U, 0U}},

/* Marker to end the key catalog */

{0U, 0U, 0U, 0U, 0U, {0U, 0U}}

};

Key Import failure in SecBoot code with S2TP ver2.1.0:

#define NVM_AES128_BOOT_KEY GET_KEY_HANDLE(HSE_KEY_CATALOG_ID_NVM, 1, 1)