Flash write issues when using Bootloader from AN12218

[lucianomoretti]

We're seeing two flash related issues when attempting to use the bootloader in AN12218 on a S32K144.

1. Sometimes the JumpToApplication() fails on 

if(userSP == 0xFFFFFFFF){
return;
}

When I view it in the Memory Browser, 0x1000 shows up as 0xFFFFFFFF. If I power cycle without downloading again, the Memory Browser then reports 0x20007000 as expected and the system can boot.

2. When booting into a loaded application sometimes the system Hard-Faults. Our small test application sometimes works, but our larger real application never does. I added in a Verification of the flash writes in mem_man.c and it often fails. When we get the failures the application usually hard-faults.

		/* Program phrase */
		FlashProgram(&flashSSDConfig, flash_prog_address, data_size,  BP->F.PhraseData, FlashCommandSequence);

		uint32_t failAddress = 0x0;
		flash_drv_status_t result = FlashProgramCheck(&flashSSDConfig, flash_prog_address, data_size,  BP->F.PhraseData, &failAddress, 0x1U, FlashCommandSequence);
		if(result != FTFx_OK)
		{
			// light the error LED.
			led_turn_on(ERR_LED);
		}

Thank you for your assistance.

[lucianomoretti · Accepted solution]

Hi: I think we figured out our issue:

The application uses the FlexNVM in the E Flash configuration and we were fighting with the Flash Controller. Since we have plenty of program flash on the device we moved the bootloader into the first 8k of the program flash and have had no issues since.

[lukaszadrapa]

Hi,

1. It sounds like cache issue. Could you confirm if the cache is disabled (ENCACHE in PCCCR register)?

2. We were told a couple of days ago that s-record parser can fail in case of unaligned phrases:

https://community.nxp.com/t5/S32-Design-Studio/Why-does-the-AN12218SW-bootloader-fails-to-parse-the-...

Could it be the reason? As mentioned in the thread, you can try to convert/align the s-record file.

Regards,

Lukas

[lucianomoretti]

Thank you for your response:
I've verified that the LMEM PCCCR register is currently set to "0x00000000".

I found the post regarding alignment and verified my SREC is currently 16 byte aligned. I'm planning to add a check to the Python program I've written to do the SREC verification and loading.

I found this post related to the UART Baud registers: 

https://community.nxp.com/t5/S32-Design-Studio/Changing-BAUD-rate-in-AN12218SW-bootloader-non-zero-r...

I made the recommended change and it seems to have cleared up my second flash issue where the verification fails. I'm not sure why this would happen.

I still see the wrong value sometimes when trying to load the application, but now the flash verification does not fail.

In the debugger in seems that it doesn't take a full hard reset to clear the issue of reading 0xFFFFFFFF from 0x1000: using the "Restart a process without terminating and relaunching" button in the debugger clears it as well.

I'm thinking of doing a reset after flashing to work around this issue as the client needs this working ASAP.

[lukaszadrapa]

Hi,

could you try to disable speculation buffer? It can be done in OCMDR0 register, OCM1 bit field:

Both bits are '0' (feature is enabled), try to set the bits to '1'.

Does it help?

Regards,

Lukas