Using MCX N ROM API for Internal Flash Erase/Programming

[Vagni]

My application needs to store some configuration data on the MCXN547 internal Flash memory, so I started looking at the SDK mcxn5xxevk_mcxromapi_flashiap_cm33_core0 example. I have some questions about it:

1. Is the SysTick timer really needed? It is initialized to generate 1ms interrupt, but it seems not used.
2. PRINTF("\r\n Config flash memory access time. \r\n"): actually, nothing is done, right?
3. The example is configured to run at 150MHz mcu clock frequency, right? Internal Flash memory can be erased/programmed by firmware at 150MHz with 3 additional wait-state (like Clocks Config Tool does), right?
4. MCXN547 device embeds up to 2 MB of flash, implemented as 2 x 1MB flash block instances. The example runs from the flash block #0 and erases/programs one sector  on the flash block #1. I verified the example also successfully erases/programs one sector on the same flash block #0, is it true?
   
5. If I try to erase the same sector written before, the FLASH_VerifyErase() returns 154 error code: what is it? The 154 error code is not listed in the MCXN Reference Manual among the possible return codes of the FLASH APIs.
6. Even if FLASH_VerifyErase() returns 154 error code, the data program and verify are then  successfull: is it normal?
7. The example has both SysTick timer and UART interrupts enabled while performing internal flash accesses: is it right? Or should all the interrupts be disabled while erasing/programming the same flash block where the ISR vector table is defined?

[Alice_Yang]

Hello @Vagni 

Thanks for your patience. I have confirmed with our internal team.

This issue is caused by not invalidate cache after erasing/programing flash, you can add below macro:

#define LPCAC_INVALIDATE 1

Then copy fsl_cache_lpcac.c/h files to drivers folder and re-build the project, you will see the flash erase verify error code will disappear.

We have created a ticket to SDK team to update SDK example.

Sorry for the inconvenience for you.

BR

Alice

[Alice_Yang]

Hello @Vagni 

Thanks for your patience. 

After I confirmed with our internal team,

"The error code 153 and 154 will be added in the latest MCX N RM, the new RM is still under review and will be published on NXP website at the end of Feb or early of March. You can see the description for error code 154 in below figure.

For the sector erase, I think we can erase the sector after writing, but please note that the code execution should not be on the same sector at this moment.

"

Sorry for the inconvenience for you.

BR

Alice

[Vagni]

OK Alice, error code 154 indicates the flash sector is not erased.

Also my added direct reading back from flash fails in verifying erased sector from the first beginning address (at destAdrss = 0x000FC000 read 0x00000000 instead of 0xFFFFFFFF).

But the debug memory reading reports the flash sector is actually erased:

I added a delay of 1 sec after the FLASH_Erase() call (which never fails), but I get no behavior change.

Anyway, the subsequent flash write is always (and unexpectedly) successful.

[Alice_Yang]

Hello @Vagni 

How about changing to another flash address? I will also test it on my side.

BR

Alice

[Alice_Yang]

Hello @Vagni 

Which version of the SDK do you use? Do you perhaps mean the demo named 'flashiap'?

BR

Alice

[Vagni]

Hello Alice,

I am using SDK_2.x_MCXN547 v24.12.00 with MCUXpresso IDE v24.12 and I refer to the \driver_examples\mcxromapi_flashiap_cm33_core0 example.

[Alice_Yang]

Hello @Vagni 

I'll answer your questions one by one. 

• Is the SysTick timer really needed? It is initialized to generate 1ms interrupt, but it seems not used.

->> No, it is not needed. 

• PRINTF("\r\n Config flash memory access time. \r\n"): actually, nothing is done, right?

->> Yes.

• The example is configured to run at 150MHz mcu clock frequency, right? Internal Flash memory can be erased/programmed by firmware at 150MHz with 3 additional wait-state (like Clocks Config Tool does), right?

->>Yes.

• MCXN547 device embeds up to 2 MB of flash, implemented as 2 x 1MB flash block instances. The example runs from the flash block #0 and erases/programs one sector  on the flash block #1. I verified the example also successfully erases/programs one sector on the same flash block #0, is it true?
  

->>Yes, It can work well as long as you don't erase or program the address that your code uses. Also, the start address must be sector - size aligned (that is, a multiple of 8 KB).

1. If I try to erase the same sector written before, the FLASH_VerifyErase() returns 154 error code: what is it? The 154 error code is not listed in the MCXN Reference Manual among the possible return codes of the FLASH APIs.
2. Even if FLASH_VerifyErase() returns 154 error code, the data program and verify are then  successfull: is it normal?

->> About the two questions, please send your project that can reproduce the issue. Thanks.

• The example has both SysTick timer and UART interrupts enabled while performing internal flash accesses: is it right? Or should all the interrupts be disabled while erasing/programming the same flash block where the ISR vector table is defined?

->> This is just a demo, in real project, we recommend disable all the interrupt when erasing/programming flash.

Hope it helps.

BR

Alice

[Vagni]

Hello Alice,

Attached you find my project I used to check the ROM API functionalities for the internal flash erasing/programming.

[Alice_Yang]

Hello @Vagni 

Thanks for your project. 

I have reproduce the issue on my side. 

I will confirm with internal about the meaning of 154 return code. Thanks for your patience. 

BR

Alice