Strange behavior of S32K148 FTFC Flash sector erase followed by ProgramPhrase commands

[ThomasSch]

Hello,

I am investigating a weird effect I see in a Firmware that is supposed to act as 2nd Stage bootloader update application in RAM.

On an S32K148 there's a Flash based FW running that can, to update itself, load a RAM based application which in turn downloads the new Flash firmware via UART1 and flashes it from program flash address 0x0 on in 1k blocks. I took care to save the Flash configuration field at 0x400-0x40f. Here the problem starts: On an S32K148EVB-Q176 this works well. On a customer board with same uC I see an effect every 5th to 8th download that the whole Flash looks erased (all 0xFF) but the Flash routine which does alot of subsequent ProgramPhrase commands seems not to have written one single byte. The whole Flash remains empty. I took care to poll FTSTAT->CCIF correctly, setting up the FCCOB commands for sector erase (every 0x1000 bytes) and ProgramPhrase command.

Has anyone observed such strange behavior ? Is there something more to obey than erasing the sector that is supposed to be programmed ? I consulted AN12130 and the S32K1xx DataSheet beside the RM but can't get a clue what might go wrong there. Any hint is appreciated!

Thanks,

Thomas 

[ThomasSch]

Hello Lukas,

yes, we checked for the occurance of all 3 bits FPVIOL, ACCERR and RDCOLERR. None occurs during flashing. From the description of these bits it is also unlikely of them to occur because RDCOLERR is set when FTFC Registers are read while they're changed by FTFC operations, as I understand it. The ACCERR comes when Flash commands are set up in wrong order or illegal cmd codes are used. This is not the case in our Flashing application, it's typical baremetal code. FPVIOL doesn't occur because we keep the FCF in the default order as specified in AN12130, so the Flash isn't protected.

The weird thing is, the programming works well ebout 6-8 times but every now and then the whole Flash seems unprogrammed. We checked with GPIOs that our flash routine is reliably entered. Strange thing is that the erase works always, but only the flashing doesn't in this case. I would expect that I see programmed content from 0x0 to the end of the binary, with some unprogrammed chunks within where flash content is stil 0xFF. But, the whole Flash looks unprogrammed in our JTAG debugger.

Then, we tried to build in a repeat routine that checks if there is some non-0xFF content present at the start of program flash (Reset vector table etc.) and to repeat the whole serial download and flashing when this is the case. And strangely, then after 2nd try it works and the flash contains the new firmware.

You can see the source for erasing and flashing attached, I think there is no unusual setups done there but I am open to suggestions.

Thanks in advance,

regards,

Thomas

[lukaszadrapa]

Hi Thomas,
I can see in the code that you are not checking the FSTAT at all. Here is a table describing source of error in case of Program Phrase command:

I would definitely check all of them after each execution of Program Phrase command, especilly MGSTAT0. On top of that, I would also add a code which "manually" checks that a phrase contains correct data after each execution of the command. You can place an endless loop here, so you can attach a debugger and check what's going on when this problem occurs (check FCCOB registers, all addreses...).
It's weird and random issue, so we need to have something to start with. I hope this could move us forward.

And let me also answer other questions I got now:

• Is the ProgramPhrase command generally suitable for writing larger amounts of data one after the other or can something "jam" within this FTFC state machine or similar? Is SectorProgram better?
- There's no problem to execute ProgramPhrase command in a loop. You can use both command as needed.

• We also checked the flash clock, it runs at 12MHz, we also set it to 16MHz, but nothing in principle has changed. I think if the flashclock doesn't fit, reading from the flash wouldn't work at all?
- Both clocks are OK but notice that FLASH_CLK should be an integer divide of the CORE_CLK:

• Could it somehow happen that the flash is already programmed, but for some reason only 0xff is read out to the outside? We always see the flash memory in the JTAG debugger as completely 0xff in such a case.
- The only thing that could cause this is cache memory. The cache should be either disabled or it should be invalidated after flash modification.

Regards,
Lukas

[lukaszadrapa]

Hi Thomas,

that's really weird, I can't see reason for such behavior. Do you check content of FSTAT register after programming of each phrase? Are any error flags set?

Regards,

Lukas