K64FX512 Flash Programming failing randomly

[danielcaetano]

Hello,

I am using KSDK2.0 and trying to write and read some data to the last sector of the PFlash (0x0007F000).

The relevant code looks something like:

#define BOOTFLASH_ADDRESS 0x7F000

static flash_config_t BOOTFLASH_flashDriver;

memset(&BOOTFLASH_flashDriver, 0, sizeof(flash_config_t));

result = FLASH_Init(&BOOTFLASH_flashDriver);

FLASH_Erase(&BOOTFLASH_flashDriver, BOOTFLASH_ADDRESS,0x1000, kFLASH_apiEraseKey);

FLASH_Program(&BOOTFLASH_flashDriver, BOOTFLASH_ADDRESS,(uint32_t *) BOOTFLASH_RamCopy, 0x140);

What happens is sometimes it writes correctly and I can read the contents just fine, other times it causes a reset in the middle of the "while (lengthInBytes > 0)" block in FLASH_Program.

I tried disabling interrupts during the execution of FLASH_Program and removing the watchdog, but the behaviour persists and is unpredictable. Does anyone have any suggestion on how to tackle this issue?

Thank you,

Daniel

[kerryzhou]

Hi Daniel,

     After you do the flash erase, do you check the result status?

     Just like this code:

        result = FLASH_Erase(&s_flashDriver, destAdrss, pflashSectorSize, kFTFx_ApiEraseKey);
        if (kStatus_FTFx_Success != result)
        {
            error_trap();
        }

        /* Verify sector if it's been erased. */
        result = FLASH_VerifyErase(&s_flashDriver, destAdrss, pflashSectorSize, kFTFx_MarginValueUser);
        if (kStatus_FTFx_Success != result)
        {
            error_trap();
        }

        /* Print message for user. */
        PRINTF("\r\n Successfully Erased Sector 0x%x -> 0x%x\r\n", destAdrss, (destAdrss + pflashSectorSize));

Because if your erase is failed, then you do the program, it must have the problem.

Please add the flash erase result checking code, and test it again.

Besides, please check your NMI hardware, do you add the external 4.7k to 10K pull up resistor?

Any updated test result, please kindly let me know.

Have a great day,
Kerry

-----------------------------------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the Correct Answer button. Thank you!
-----------------------------------------------------------------------------------------------------------------------

[danielcaetano]

Hi Kerry. Thanks for answering.

I only posted a simplyfied version of the code. The actual code does the verification and succeeds, as you can see:

result = FLASH_Erase(&BOOTFLASH_flashDriver, BOOTFLASH_ADDRESS, 0x1000, kFLASH_apiEraseKey);

if (kStatus_FLASH_Success != result)
{
BOOTFLASH_Error(result, __LINE__);
return false;
}

result = FLASH_VerifyErase(&BOOTFLASH_flashDriver, BOOTFLASH_ADDRESS, 0x1000, kFLASH_marginValueUser);

if (kStatus_FLASH_Success != result)
{
BOOTFLASH_Error(result, __LINE__);
return false;
}

I do have a 10k pullup on the NMI pin (pin 38 in the 100-pin packaging).

I know it's not a hardware issue, because I have another application (FNET ethernet bootloader) that can read and write on that portion of the flash memory. 

Do you know of any other possible cause for sporadic flash write failures?

Thanks,

Daniel

[kerryzhou]

Hi Daniel,

   Try to copy the flash launch command function to the RAM, then try it again.

   You said, you have disabled interrupts before your do the flash operation, do you disable the global interrupt?

Have a great day,
Kerry

-----------------------------------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the Correct Answer button. Thank you!
-----------------------------------------------------------------------------------------------------------------------

[danielcaetano]

Hi Kerry.

   Try to copy the flash launch command function to the RAM, then try it again.

I'm using the KSDK2.0 drivers, so the FLASH_Program function calls flash_command_sequence which calls callFlashRunCommand, which I just confirmed runs in the RAM address range (over 0x20000000).

   You said, you have disabled interrupts before your do the flash operation, do you disable the global interrupt?

I use DisableGlobalIRQ() from the same SDK.

The weirdest part to me is that in this application I can write to the FlexNVM (0x10000000–0x13FFFFFF) without any issue, but when it comes to the PFlash it randomly fails. Do you think there can be some interference due to trying to write to both memory sectors (not simultaneously) in the same application?

Thanks,

Daniel

[kerryzhou · Accepted solution]

Hi Daniel,

    Thank you for your updated information, I don't think write to both memory sectors, not simultaneously will have the problem.

   Please download our newest SDK for K64FX, then test the official pflash code on you side directly, do you also have the problem? Please download it from this link:

Welcome | MCUXpresso SDK Builder 

  Choose the chip as K64FX, after you download it, the project will be for FRDM-K64, but don't worry, all the K64FX driver already in that package, you just need to modify it, then test it on your k64fx, just check use the independent pflash code, whether it will reflect your problem.

  Any test result, please kindly let me know.

Have a great day,
Kerry

-----------------------------------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the Correct Answer button. Thank you!
-----------------------------------------------------------------------------------------------------------------------

[danielcaetano]

Hi Kerry,

Coincidentally, I did that just yesterday (I was previously using the driver build for 64FN1M, with some adaptations).

I noticed that if I do an erase->write cycle at the beginning of the main function, it works 100% of the time. However, when I try to do it at the point where I want it the previous behavious persists. I will double-check my code, and start disabing other components of my application to see if anything is interfeering with the flash writing process.

Do you know if there is some kind of list of what could interfere with the process? That would narrow my search a lot.

Thank you,

Daniel

[kerryzhou]

Hi Daniel,

    As I know, two points may caused your problem: interrupt+ copy to RAM.

   But you said you all do it.

   Please also check the optimization, don't do the optimization.

  If you still have problem, you also can comment the other components, besides, I think you also can debug the code, then follow the code, enter the problem area, check the launch command which is copied to the RAM, whether that data is the same as the launch command code in the flash, just make sure it is not caused by the RAM overflow.

Wish it helps you!

Any updated information on your side, please kindly let me know.

Have a great day,
Kerry

-----------------------------------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the Correct Answer button. Thank you!
-----------------------------------------------------------------------------------------------------------------------

[danielcaetano]

Kerry, I finally ot it to work.

The final "combo" was the K64FX drivers, disabling the interrupts before flash operations and, probaly unrelated, type-casting the "src" argument of FLASH_Program to uint8_t* instead of uint32_t*. I'm not sure if this last one had any impact, but now that it's finally working I'm not gonna touch it :smileyhappy:.

Thank you very much for your support.

Daniel.

[kerryzhou]

Hi Daniel,

    Which item in Flash_program is using uint8_t* instead of uint32_t*?

  From the SDK driver:

result = FLASH_Program(&s_flashDriver, destAdrss, (uint8_t *)s_buffer, sizeof(s_buffer));

FLASH_Program definition is:

status_t FLASH_Program(flash_config_t *config, uint32_t start, uint8_t *src, uint32_t lengthInBytes)

If you mentioned s_buffer, the definition is just uint8.

Have a great day,
Kerry

-----------------------------------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the Correct Answer button. Thank you!
-----------------------------------------------------------------------------------------------------------------------

[danielcaetano]

Yes, you are correct. In my code i was casting it to (uint32_t*), which was unnecessary. I still don't think that was the cause, but now it's fixed.

Thank you,

Daniel