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.

AM625: Regarding Flash Write Issue During Nominal Download of Huge Data

Part Number: AM625

Hello Team,

MCAL Package: MCAL_SitaraMPU_10.01.00.03

In continuation with our issue in previous ticket (RE: SK-AM62-LP: Regarding Tool to combine multiple RPRC file from same core into a single binary - Processors forum - Processors - TI E2E support forums ) as discussed in our Call,we have created this ticket.

The issue is there is mismatch between data given as input and data read from flash.

Can you please let us know if there is an example at TI side which is verified for Fls_Write operation over 1 Mb of data.

Thanking You.

Regards,

Pradeep R

  • Hello,

    Allow me sometime to comment on this.

    Thanks,

    Vaibhav

  • Hi Pradeep,

    Currently the observed behaviour is Read Back Data does not match with the known data and a bunch of FFh is seen randomly.

    Can you please perform the following steps to verify if this is purely a write or read issue, as it is not an erase issue for sure:

    1. Write x number of bytes, in your case, write the usual 1 MB of byte.
    2. Now before reading back the data into a RX Buffer, pause and enable the dac bit, that is 7th bit of the register FC40000.
    3. Here, I want you to go the offset where the flashing was done, so basically go to 0x60000000 + WRITEOFFSET and then check if the flash contents shows the random FFh in the middle or not?

    If when DAC is enabled, and you see those random FFh, then write has not been performed correctly, and reading works fine. If you do not see the FFh randomly then this can be categorized as a read failure.

    Hope this gives clarification on what needs to be performed.

    Looking forward to the results.

    Kind Regards,

    Vaibhav

  • Hi Vaibhav,

    We enabled dac bit in the Fls configuration for debugging, please find attached files bin.zip application.bin(input application) and dump_from_flash.bin(output application dump from flash).

    1882.bin.zip

    Please let us know if you need further information.

    BR,

    Shubham

  • Hi,

    Looking at the flash dump, there are random places where the flash has not written correctly and on addition to this, I see blocks of 32 KB not written.

    Please perform the following:

    loop 1024 times:
            write 1024 bytes at a time
    This ensure 1 MB written
    Now check the flash area and see if the written value matches the application binary. It should ideally match as appotronics tested for 1 KB writes for sure.

    Regards,

    Vaibhav

  • Hi Vaibhav,

    As shared bin.zip for application.bin(input application) and dump_from_flash.bin(output application dump from flash), this we have already configured with 1024 Buffer size with1024 times.

    Please let us know if we can check anything.

    BR,

    Shubham

  • Hi Shubham,

    As shared bin.zip for application.bin(input application) and dump_from_flash.bin(output application dump from flash), this we have already configured with 1024 Buffer size with1024 times.

    Please let us know if we can check anything.

    Thanks, this should be fine, lets wait for Appotronic's comments on the way they tested MCAL INDAC example. As it seems like they did not test independently without SBL NULL/SBL OSPI.

    Please check the email for latest update from their side.

    Thanks,

    Vaibhav

  • Sharing updated Fls_delay and OSPI_flashExecCmd

     static Std_ReturnType OSPI_flashExecCmd(const CSL_ospi_flash_cfgRegs *pRegs)
     {
        uint32 retry = OSPI_DAC_WRITE_TIMEOUT;
        Std_ReturnType  retVal = E_OK;
    
        volatile uint32 tempCount = FLS_TIMEOUT_DURATION;
    
        if (FLS_TIMEOUT_DURATION > 9U)
        {
            /* Each unit of SW_delay equals to 9 clockcycles, so dividing by 9U */
            tempCount = (FLS_TIMEOUT_DURATION / 9U);
        }
        /* Wait for FSM to to come out of reset */
        do
        {
            if (tempCount == 0U)        
            {
                /* Timeout */
                break;
            }
            MCAL_SW_DELAY(tempCount);
        }while (CSL_ospiIsIdle(pRegs) == FALSE);
    
        /* Start to execute flash read/write command */
        CSL_ospiFlashExecCmd(pRegs);
        
        while (retry != 0U)
        {
            /* Check the command execution status */
            if (CSL_ospiFlashExecCmdComplete(pRegs) == TRUE)
            {
                break;
            }
            OSPI_delay(OSPI_CHECK_IDLE_DELAY);
            retry--;
        }
    
        if (retry == 0U)
        {
            retVal = E_NOT_OK;
        }
    
        if (FLS_TIMEOUT_DURATION > 9U)
        {
            /* Each unit of SW_delay equals to 9 clockcycles, so dividing by 9U */
            tempCount = (FLS_TIMEOUT_DURATION / 9U);
        }
        do
        {
            if (tempCount == 0U)        
            {
                /* Timeout */
                break;
            }
            MCAL_SW_DELAY(tempCount);
        }while (CSL_ospiIsIdle(pRegs) == FALSE);
    
        return (retVal);
     }
     
     static void Fls_delay(uint32 msecs)
     {
         volatile uint32 tempCount = 1000000U * msecs;
    
         /* Each unit of MCAL_SW_DELAY() equals ~9 clock cycles,
            so we scale tempCount accordingly */
         if (msecs > 9U) 
         {
             tempCount = msecs / 9U;
         }
     
         /* Wait for the delay to complete */
         do 
         {
             if (tempCount == 0U) 
             {
                 /* Timeout reached */
                 break;
             }
             MCAL_SW_DELAY(tempCount);
         } while (tempCount > 0U);
     }

    Kind Regards,

    Vaibhav

  • Hello EB team,

    Thank you Pradeep for running the tests over the call.

    Summary(Call: 11/25/2025):

    1. MCAL FLS writes works for 0.5 MB of data. Data being pre-populated.
    2. MCAL FLS writes works for 1 MB of data. Data being pre-populated with value 0, 1, 2, 3...255, 0, 1, 2..... until 1 MB.
    3. MCAL FLS writes does not works for Incremental Programming. BMW has some known data, which gets compressed, and received in chunks of 1024 bytes, and then these bytes(1 KB) is written on the fly. The comparison does not match at random offsets.
      1. FOLLOW UP 1: Pradeep to check if the data is copied in a similar fashion to DDR, is it matching the original compressed data.
      2. FOLLOW UP 2: If the compressed data is already available in the form of a TX BUFFER of size 1 MB, is it being written correctly or not?

    Kind Regards,

    Vaibhav

  • Hello  ,

    Thanks for the support and all the feedback.

    With multiple times of testing, we figured out that there is sporadic mismatch in decompressed data which was passed to Flash driver.

    The Flash driver has written the data correctly, but decompressed data was not matching at selected locations.

    we will check the decompression part and come back again if we have any queries with respect to flash driver.

    Regards,

    Pradeep R

  • Hello Pradeep,

    Thanks for the update.

    Kind Regards,

    Vaibhav