UTEST program error and HSE RM issue

[Yiming2]

Dear NXP

We are try to program 512 bytes data into the UTEST(because the Utest

 is a OTP are). But it always failed at the second 128 bytes program (since the max size is 128 one hardware program operation.). but when we run the cody in debug mode (step by step) all data can be successfully programmed. we don't know why. SO we want to get the help from NXP.

And we also checked the "S32K3 常见问题检查列表 Check List 版本 V1.3. and we found that we need to check the HSE_CONFIG_GPR3 (0x4039C028) when application try to operate the utest area. But when we refer to the HSR RM(Rev2.7) for HSE_CONFIG_GPR3 (0x4039C028)(table 143), we found that description is wired.

the Bit#16 and 24 

0 : Block 4 is available for program/read/execute and erase for application .

1: Application program and erase is blocked for UTEST block as HSE FW is reading or executing on this block.

so if we want to program Utest which bit# should we check?  the table is shown 1 means utest 0 means Block4. is that the typo?

the MCU we are using is S32K312.

[lukaszadrapa]

Hi @Yiming2 

"but when we run the cody in debug mode (step by step) all data can be successfully programmed"

- this says that it's read-while-write issue, most likely. Be aware that UTEST and flash block 0 share the same read partition. When UTEST is being programmed, it is not  possible to read or executed from flash block 0. The code must be executed from RAM memory or from different flash block. Interrupts should be either disabled or all interrupt resources should be forced to different flash block as well. 

Regarding the HSE CONFIG register - yes, this is weird, it is obviously some kind of copy-paste issue. Thanks for pointing this out, I will report it. 

Both bits 16 and 24 should be '0' to be able to read and program UTEST. 

Regards,

Lukas

[Yiming2]

hello @lukaszadrapa 

thanks for you information.

We have checked the following items, but all things seem to be OK.
The functions we are using are not created by us. We are directly using HSE lib 1.0 (host_flash.c).
We have successfully programmed UTEST 1B00_0000 to enable the HSE usage flag using this function. However, when we attempt to use this function to program 512 bytes into the specified area, it fails. We need to call HostFlash_Program four times (with a maximum of 128 bytes per call) to program all 512 bytes into the DCF bottom area of the UTEST, but only the first 128 bytes can be programmed successfully.
The second call fails in run mode, but when we run the code in debug mode (step by step), the remaining bytes can be programmed successfully.
I think the first write operation and the UTEST 1B00_0000 program should also fail if the following items are not configured correctly.

[lukaszadrapa]

Not necessarily. There's instruction cache, there's prefetch buffer on the flash. Under some circumstances, you can be lucky enough that no code is fetched from flash during the programming operation. 

I already met a case when a customer advanced life cycle while running from flash block 0. This operation also triggers UTEST programming. And the result was that it worked on most of the devices but there were a few where this operation failed. 

So, this still sounds like read-while-write issue. It's mandatory to run the code from RAM or from different flash block (not block 0). 

Regards,

Lukas