topic Re: MCXA153 flash writing problem in Processor Expert Software

MCXA153 flash writing problem

_Ferrari_ — Thu, 23 Oct 2025 07:38:52 GMT

Dear all,
I am developing an application based on the MCXA153 processor. The project uses an external 16MHz crystal, and I have modified the clock configuration, according to your suggestion, to obtain 96MHz as the Main clock.

Also following your instructions, I used the information from the 'romapi_flashiap' project to be able to write to the flash.
Everything works fine, but after the first flash write operation, the Main clock completely changed.

In this post you can find the class and method that I used.

Have you ever had a similar problem?
How was it solved?
Thank you very much for your cooperation and your help.
Regards

class flash { public: flash(); virtual ~flash(); void init(); int32_t flashWrite(uint8_t *source, int32_t size); int32_t flashRead(uint8_t *pDest, int32_t size) ; private: status_t status; uint32_t destAdrss; /* Address of the target location */ uint32_t i, failedAddress, failedData; uint32_t pflashBlockBase ; uint32_t pflashTotalSize ; uint32_t pflashSectorSize ; uint32_t PflashPageSize ; flash_config_t s_flashDriver; union _uBuffer buffer; void speculation_buffer_clear(); void lpcac_clear(); };

void flash::init() { pflashBlockBase = 0U; pflashTotalSize = 0U; pflashSectorSize = 0U; PflashPageSize = 0U; FLASH_API->flash_init(&s_flashDriver); /* Get flash properties kFLASH_ApiEraseKey */ FLASH_API->flash_get_property(&s_flashDriver, kFLASH_PropertyPflashBlockBaseAddr, &pflashBlockBase); FLASH_API->flash_get_property(&s_flashDriver, kFLASH_PropertyPflashSectorSize, &pflashSectorSize); FLASH_API->flash_get_property(&s_flashDriver, kFLASH_PropertyPflashTotalSize, &pflashTotalSize); FLASH_API->flash_get_property(&s_flashDriver, kFLASH_PropertyPflashPageSize, &PflashPageSize); destAdrss = pflashBlockBase + (pflashTotalSize - (SECTOR_INDEX_FROM_END * pflashSectorSize)); } int32_t flash::flashWrite(uint8_t *source, int32_t size) { status = FLASH_API->flash_erase_sector(&s_flashDriver, destAdrss, pflashSectorSize, kFLASH_ApiEraseKey); if (status == kStatus_Success) { speculation_buffer_clear(); lpcac_clear(); status = FLASH_API->flash_verify_erase_sector(&s_flashDriver, destAdrss, pflashSectorSize); if (status == kStatus_Success) { status = FLASH_API->flash_program_page(&s_flashDriver, destAdrss, (uint8_t*) source, size); } speculation_buffer_clear(); lpcac_clear(); } return status; }

Re: MCXA153 flash writing problem

Alice_Yang — Fri, 24 Oct 2025 03:47:46 GMT

Hello @_Ferrari_

"but after the first flash write operation, the Main clock completely changed."

->> Do you mean that after running for a while, you noticed the main clock changed and is no longer 96 MHz?
And the main clock is 96 MHz when running romapi_flashiap?
How did you observe this?
Could you please share a screenshot or log to show the behavior?

Alice

Re: MCXA153 flash writing problem

_Ferrari_ — Mon, 27 Oct 2025 09:28:19 GMT

I analyzed the problem in detail and would like to present the result of my measurements.

I developed two programs. The first uses the CTIMER0 timer interrupt to toggle a CPU pin with a period of 20 microseconds (10 microseconds OFF and 10 microseconds ON).
The clock source for CTIMER0 is the Main CLOCK at 96MHz. As seen in the image, the period does not change both before and after the write operation. (see the A1-A2 and B1-B2 cursors)
This means that the 96MHz clock doesn't change, but, as can be noted, interrupts are disabled for approximately 500 microseconds during the flash write phase. (see the C1-C2 cursors)

// PROGRAM 1 uint8_t buffer[128]; volatile int32_t OnOff = 1; int main(void) { /* Init board hardware. */ BOARD_InitBootPins(); BOARD_InitBootClocks(); BOARD_InitBootPeripherals(); #ifndef BOARD_INIT_DEBUG_CONSOLE_PERIPHERAL /* Init FSL debug console. */ // BOARD_InitDebugConsole(); #endif memoryFlash.init(); for(int i=0;i<128;i++) { buffer[i]=(uint8_t)i; } SDK_DelayAtLeastUs(100, SDK_DEVICE_MAXIMUM_CPU_CLOCK_FREQUENCY); memoryFlash.flashWrite(buffer,128); SDK_DelayAtLeastUs(100, SDK_DEVICE_MAXIMUM_CPU_CLOCK_FREQUENCY); while(1); return 0; } // INTERRUPT ROUTINE void TestBit(uint32_t flg) { GPIO_PinWrite(BOARD_INITPINS_RS485_TX_GPIO, BOARD_INITPINS_RS485_TX_GPIO_PIN, OnOff); OnOff = !OnOff; }

Image 1

The second program toggles the CPU pin 10 times using a dedicated routine (togglePin).
As seen in the image, before the write operation, the period is approximately 640 nanoseconds (320 OFF and 320 ON).

(see the A1-A2 cursor on the image 2)

After the flash write operation, the half-period lengthens by about three times (from 320 nanoseconds to 1.52 microseconds) (wait states are probably being added). (see the B1-B2 cursor on the image 3)
This obviously slows down the program execution.

// PROGRAM 2 flash memoryFlash; uint8_t buffer[128]; volatile int32_t OnOff = 1; static void togglePin() { for(int i=0;i<10;i++) { GPIO_PinWrite(BOARD_INITPINS_RS485_TX_GPIO, BOARD_INITPINS_RS485_TX_GPIO_PIN, OnOff); OnOff = !OnOff; } } int main(void) { /* Init board hardware. */ BOARD_InitBootPins(); BOARD_InitBootClocks(); BOARD_InitBootPeripherals(); #ifndef BOARD_INIT_DEBUG_CONSOLE_PERIPHERAL /* Init FSL debug console. */ // BOARD_InitDebugConsole(); #endif memoryFlash.init(); for(int i=0;i<128;i++) { buffer[i]=(uint8_t)i; } togglePin(); memoryFlash.flashWrite(buffer,128); togglePin(); while(1); return 0; }

Image 2

Image 3

Therefore:

1) How can I prevent interrupts from being disabled during the flash write operation?
2) How can I prevent the program from slowing down after the flash write operation?

Thank you very much for your help and cooperation

regards

Re: MCXA153 flash writing problem

Alice_Yang — Tue, 28 Oct 2025 10:51:59 GMT

Hello @_Ferrari_

1) How can I prevent interrupts from being disabled during the flash write operation?

->>It is not recommended to keep interrupts enabled during flash write operations. Disabling interrupts helps prevent data corruption.

2) How can I prevent the program from slowing down after the flash write operation?

->>After the flash write is completed, the program should not run slowly—this is not related. Regarding the clock, you can measure it using the clock output pin.

Alice

Re: MCXA153 flash writing problem

_Ferrari_ — Thu, 30 Oct 2025 11:54:08 GMT

Thank you for your answer

You wrote:

->>It is not recommended to keep interrupts enabled during flash write operations. Disabling interrupts helps prevent data corruption.

However, I seem to recall that this is only true if, during the execution of an interrupt service routine, I try to read data or execute code that resides in the flash block I am currently erasing or writing.

->>After the flash write is completed, the program should not run slowly—this is not related. Regarding the clock, you can measure it using the clock output pin.

As you suggested, I followed the 'romapi_flashiap' example.
In the flash writing routine, you disable the microprocessor's cache memory but do not re-enable it at the end of the writing.
Therefore, after a flash write, the software's execution speed is lower.

(flashiap.c routine in romapi_flashiap example)

PRINTF("\r\n Erase a sector of flash"); status = FLASH_API->flash_erase_sector(&s_flashDriver, destAdrss, pflashSectorSize, kFLASH_ApiEraseKey); if (status != kStatus_Success) { error_trap(); } /* Clear speculation buffer and lpcac. */ speculation_buffer_clear(); lpcac_clear(); // ------------------------ // CACHE MEMORY IS DISABLED // ------------------------ /* Verify if the given flash range is successfully erased. */ PRINTF("\r\n Calling flash_verify_erase_sector() API."); status = FLASH_API->flash_verify_erase_sector(&s_flashDriver, destAdrss, pflashSectorSize); if (status == kStatus_Success) { PRINTF("\r\n Successfully erased sector: 0x%x -> 0x%x\r\n", destAdrss, (destAdrss + pflashSectorSize)); } else { error_trap(); } /* Prepare user buffer. */ for (i = 0; i < BUFFER_LEN; i++) { s_buffer[i] = i; } /* Start programming specified flash region */ PRINTF("\r\n Calling FLASH_Program() API."); status = FLASH_API->flash_program_page(&s_flashDriver, destAdrss, (uint8_t *)s_buffer, sizeof(s_buffer)); if (status != kStatus_Success) { error_trap(); } /* Clear speculation buffer and lpcac. */ speculation_buffer_clear(); lpcac_clear(); // ------------------------ // CACHE MEMORY IS DISABLED // ------------------------

As you suggested I

Re: MCXA153 flash writing problem

Alice_Yang — Fri, 31 Oct 2025 07:15:30 GMT

Hello @_Ferrari_

Thanks for your reply.

Yes, you are right. You can enable the cache after flash operation finished.

Alice