S32K3 UTEST program generates hardfault

[Hareesh_S]

Hello,

I am trying to create a test application to restrict JTAG/debug access by setting a 16 byte password (without HSE) for an S32K312. Previously my approach was 2 staged - I had one program to set the password, and another to advance the lifecycle, and this seemingly worked fine.

I am now trying to combine both into a single sequence to integrate into my main application eventually, but I am facing issues where the MCU generates a hardfault when I try to program the password.

I can confirm that before trying to program the password, there is no password set (0xFF throughout) and even though a hardfault was generated, the password has actually been programmed - this must have been why my previous 2 staged approach worked, as even if the first stage hardfaulted, I would not have noticed and simply programmed the second stage.

Below is my code snippet. Do note that I have also set the lifecycle configuration word address in the startup script, to be included in the IVT. There are no other modifications to the startup script or linker.

#define MASTER_ID 						(0U)
#define CUST_DB_PSWD_A_ADDR 			(0x1B000080U)
#define CUST_DB_PSWD_A_SECTOR 			(C40_UTEST_ARRAY_0_S000)
#define CUST_DB_PSWD_A_LENGTH 			(16U)

#define LC_CONFIGURATION_WORD_ADDR 		(0x005A6000)
#define LC_CONFIGURATION_WORD_SECTOR 	(C40_CODE_ARRAY_0_BLOCK_1_S211)
#define LC_CONFIGURATION_WORD_LENGTH 	(8U)

uint8_t cust_db_pswd_a[CUST_DB_PSWD_A_LENGTH] __attribute__((aligned(4)))
= { 0x35, 0x2E, 0x04, 0x92, 0x65, 0x25, 0x09, 0x23, 0x35, 0x2E, 0x04, 0x92,
		0x65, 0x25, 0x09, 0x23 };

uint8_t lc_configuration_word[LC_CONFIGURATION_WORD_LENGTH] __attribute__((aligned(4)))
= { 0xBA, 0xBA, 0xBA, 0xBA, 0x0, 0x0, 0x0, 0x0 }; /* Minimum data length 8 bytes */

int main(void) {

	Clock_Ip_Init(&Clock_Ip_aClockConfig[0]);

	C40_Ip_Init(&C40_Ip_InitCfg);

	/* PROGRAMMING ADKP */
	if (C40_Ip_GetLock(CUST_DB_PSWD_A_SECTOR)
			== C40_IP_STATUS_SECTOR_PROTECTED) {
		C40_Ip_ClearLock(CUST_DB_PSWD_A_SECTOR, MASTER_ID);
	}

	C40_Ip_MainInterfaceWrite(CUST_DB_PSWD_A_ADDR, CUST_DB_PSWD_A_LENGTH,
			cust_db_pswd_a, MASTER_ID); /* Hardfaults here, but UTEST program is actually successful */
	while (C40_Ip_MainInterfaceWriteStatus() == C40_IP_STATUS_BUSY)
		;

	/* ADVANCING LC */
	if (C40_Ip_GetLock(LC_CONFIGURATION_WORD_SECTOR)
			== C40_IP_STATUS_SECTOR_PROTECTED) {
		C40_Ip_ClearLock(LC_CONFIGURATION_WORD_SECTOR, MASTER_ID);
	}

	C40_Ip_MainInterfaceSectorErase(LC_CONFIGURATION_WORD_SECTOR,
	MASTER_ID);
	while (C40_Ip_MainInterfaceSectorEraseStatus() == C40_IP_STATUS_BUSY)
		;

	C40_Ip_MainInterfaceWrite(LC_CONFIGURATION_WORD_ADDR,
	LC_CONFIGURATION_WORD_LENGTH, lc_configuration_word, MASTER_ID);
	while (C40_Ip_MainInterfaceWriteStatus() == C40_IP_STATUS_BUSY)
		;

	while (true)
		;

	return 0U;
}

 
my .mex configuration is as such - 

Any inputs as to what I am doing wrong?

With regards,
Hareesh S

[Robin_Shen · Accepted solution]

Hi

Please check the value of "21.7.1.3 Module Configuration Status (MCRS)" at address 0x402EC004.  If MCRS[RWE] = 1, it means that an RWW error occurred during a previous read.

Then please read the discussion in  "Hard Fault in C40_Ip_MainInterfaceHVJobStatus api when flash is erase in s32k312".

Best Regards,
Robin

[Hareesh_S]

Hello @Robin_Shen,

Thanks for reverting back - It was indeed a RWW error as you had suggested.
I assumed the UTEST section was a different block and hence flash erase/program functions could run from flash but apparently not. Moving the functions to RAM solved my issues.

With regards,
Hareesh S