• State Resolved
  • +1 person also asked this people also asked this
  • Locked Locked
  • Replies 4 replies
  • Subscribers 34 subscribers
  • Views 250 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

AM13E23019: AM13E23019: Flash write verification issues

Viktoriia Palianytsia
Prodigy 10 points

Part Number: AM13E23019

After performing the 64 bit write operation we would like to verify the first programmed byte for containing the correct data, however, when checking said byte, the value that is obtained via read would appear to be 0xFF when the memory shows that the data is there, it's not blank.
This happens with different levels of optimization from O0 to O3. Such sync mechanisms as volatile, data barriers, blocking wait and others did not help with the issue. Could it be that the data cache is here at fault? In the TRM it states that "Following programming of the flash memory, there can be stale data in the processor's cache logic. Before reading programmed locations, TI recommends to first flush the cache in the CPU subsystem. " However, we did try Clear and Invalidate Cache functions and they did not resolve the issue. Could there please be an example provided on how to flush the cache before reading programmed flash?
I have recreated in the flash example code a similar case that fails the check of the first programmed byte. The file is attached as well as the screenshot that shows the memory and the read byte value mismatching each other.
image.png
Here is the file: main.c 
Thank You and Best Regards!
Viktoriia

  • 0
    TI__Prodigy 60 points

    Hi  
    When you are trying to do a readback and verify the written flash contents, you can disable the code and data cache by writing to the FRI->FRD_INTF_CTRL register. 

    static bool Flash_Write_64_Bit(uint32_t address, uint8_t *data_buffer)
{
    bool result = false;
    FRI->FRD_INTF_CTRL = 0;
    if (DL_FlashCTL_acquireFlashSemaphore() == DL_FLASH_SUCCESS)
    {
        DL_FlashCTL_executeClearStatus(NVMNW);
        DL_FlashCTL_unprotectSector(NVMNW, address, DL_FLASHCTL_REGION_SELECT_MAIN);
        DL_FLASHCTL_COMMAND_STATUS command_status = DL_FlashCTL_programMemory64WithECCGenerated(NVMNW, address, ((uint32_t *)(&data_buffer[0])));
        if (command_status == DL_FLASHCTL_COMMAND_STATUS_PASSED) // proceed if the programming operation has passed
        {
            volatile uint8_t check_value_target = ((uint8_t *)(address))[0u];
            volatile uint8_t check_value_source = data_buffer[0];
            if ((check_value_target == check_value_source)) // verify whether correct data was written (first byte)
            {
                result = true;
            }
        }
        if (DL_FlashCTL_releaseFlashSemaphore() != DL_FLASH_SUCCESS) // semaphore should be released successfully
        {
            result = false;
        }
    }

    return result;
}


    regards 
     

  • 0 in reply to Adwait Dhamane
    Prodigy 10 points

    , Thank You for your suggestion! Is there a possibility to actually flush the cache instead of disabling and then enabling it again? Or does the disable clears the cache as well? Because even with the disabled cache could it be that once it is enabled again after programming and verification that some outdated stale values still will be fetched from the cache again if we want to read the data later?

  • 0 in reply to Viktoriia Palianytsia
    TI__Prodigy 60 points

    The Disable clears the cache as well. So after verification if you enable the cache again then anytime you read the flash again, it will not return a stale value.

  • 0 in reply to Adwait Dhamane
    Prodigy 10 points

    Thank You for the clarification!