AM2431: OSPI malfunction during power-off

futoshi kawarazaki

Prodigy 155 points

Part Number: AM2431

Tool/software:

The OSPI is connected to the FLASH memory and is used with a single I/O bus.

OSPI only reads during boot.

The program is designed to write USB data to the FLASH memory only when a USB is inserted.

Currently, since no USB is inserted, there is no access after boot.

In this state, if the power is turned off, there may be OSPI access.

I checked the commands sent to FLASH memory with an oscilloscope during power-off.

In most cases, the command is a Read command (03h) or a (00h).

Very rarely, a Write Enable command (06h) and PAGE PROGRAM command (02h) are sent.

Since the PAGE PROGRAM happens during power-off, the power is cut off midway, and the data in the FLASH memory gets corrupted.

There seems to be no difference in the power supply voltage when accessing the FLASH memory or not during power-off.

Q1. Is it unavoidable for the CPU to malfunction and access the FLASH memory during power-off?

It is not a problem if the Read command is executed during power-off. However, I want to avoid the execution of the PAGE PROGRAM.

Q2. Is there a way to avoid this?

6 months ago

0 Vaibhav Kumar 6 months ago

TI__Mastermind 44926 points

Hi,

futoshi kawarazaki said:
In this state, if the power is turned off, there may be OSPI access.

Firstly, I want to understand, ff the power is turned off, how is there OSPI access happening? There should be none happening right?

futoshi kawarazaki said:
Since the PAGE PROGRAM happens during power-off, the power is cut off midway, and the data in the FLASH memory gets corrupted.

My understanding: This means that the write operation has not been completed correctly and hence data corruption has happened. Although, semaphore would have taken care of atomic writes but then due to power being cut off midway, the issue arises.

Regards,

Vaibhav

0 futoshi kawarazaki 6 months ago in reply to Vaibhav Kumar

Prodigy 155 points

Hi,

We expect that OSPI access will not occur when the system is powered down.

However, during the process of powering off, OSPI access occurs unexpectedly.

We suspect that there might be a bug in the CPU causing malfunction.

During the process of powering off, the PAGE program is executed unexpectedly, and the write operation is not completed, resulting in data corruption.

Best regards,

Futoshi

0 Mari Tsunoda 6 months ago in reply to Vaibhav Kumar

TI__Expert 5726 points

Hi Vaibhav,

If you need more details or need the schematics around OSPI pins/flash from Kawarazaki-san please let him know.

Best regards,

Mari Tsunoda

0 Vaibhav Kumar 6 months ago

TI__Mastermind 44926 points

Hi,

futoshi kawarazaki said:
single I/O bus.

This essentially means 1s-1s-1s mode of operation right?

I want to understand at my TI EVM setup if this is something expected(which it is not). But it would be a good thing for me to find out on my TI EVM itself.

FYI, there has been a different issue, not related to the current customer, where I would be probing AM64x and checking the data lines.

I will be powering off and checking the behaviour at my end for multiple cycles, if I do not see a similar behaviour then I would need your schematics for the Hardware team to review.

I will be able to do so when I have the TI EVM's OSPI data lines soldiered. Once done I will keep you posted here.

Thanks for your patience.

Regards,

Vaibhav

0 futoshi kawarazaki 6 months ago in reply to Vaibhav Kumar

Prodigy 155 points

Hi,

This essentially means 1s-1s-1s mode of operation.

If you need a circuit diagram, please let me know.

The following is reference information.

I tested with three types of PCBs.

This issue occurs with two types of PCBs.

With one type of PCB, this issue does not occur.

I believe that the difference in the power voltage during the power-off process is what causes the issue in some PCBs but not in others.

Best regards,

Futoshi

0 futoshi kawarazaki 6 months ago in reply to futoshi kawarazaki

Prodigy 155 points

Hi,

When the ENB_SPI_FLD bit in the OSPI_CONFIG_REG is set to 0, OPSI is not accessed during power off.

I am considering implementing the following control to avoid the issue:

･ When using OSPI, set the ENB_SPI_FLD bit to 1.

･ After use, set the ENB_SPI_FLD bit to 0.

Could you please let me know if there is any issue with this control?

I am concerned whether there will be any negative effects from setting the ENB_SPI_FLD bit to 0 when not in use.

Best regards,

Futoshi

0 Mari Tsunoda 6 months ago in reply to Vaibhav Kumar

TI__Expert 5726 points

Hi Vaibhav,

Could you respond to Kawarazaki-san's question?

futoshi kawarazaki said:
I am considering implementing the following control to avoid the issue:

･ When using OSPI, set the ENB_SPI_FLD bit to 1.

･ After use, set the ENB_SPI_FLD bit to 0.

Could you please let me know if there is any issue with this control?

Also were you able to test on your end?

Vaibhav Kumar said:
I will be able to do so when I have the TI EVM's OSPI data lines soldiered. Once done I will keep you posted here.

Best regards,

Mari

0 Vaibhav Kumar 6 months ago in reply to futoshi kawarazaki

TI__Mastermind 44926 points

Hi,

Thank you very much for your patience.

futoshi kawarazaki said:
I am considering implementing the following control to avoid the issue:

･ When using OSPI, set the ENB_SPI_FLD bit to 1.

･ After use, set the ENB_SPI_FLD bit to 0.

Interesting piece of information, let me run this quickly through the TRM and check this bit field at my end after OSPI operation gets over.

Regards,

Vaibhav

0 futoshi kawarazaki 6 months ago in reply to Vaibhav Kumar

Prodigy 155 points

Hi Vaibhav,

How is the progress going?

Please provide a response regarding the workaround by the end of this week.

Best regards,

Futoshi

0 Vaibhav Kumar 6 months ago in reply to futoshi kawarazaki

TI__Mastermind 44926 points

Hi,

At application level the SPI ENB FLD is always set to 1. It is not cleared to 0 as per my observation of running an application of OSPI which just writes and reads from the flash. The reason being the reset value of this bit is 1 itself.

I have also observed that even when drivers are closed, this is not set to 0.

I think you can go ahead and set it to 0, but setting it to 0/1 implies the following:

When ENB_SPI_FLD = 0, the controller stops using Octal-SPI after completing the current transaction.

When ENB_SPI_FLD = 1, the Octal-SPI interface is enabled and actively used for communication.

Regards,

Vaibhav

0 futoshi kawarazaki 6 months ago in reply to Vaibhav Kumar

Prodigy 155 points

Hi Vaibhav,

Q1. Do you think there could be any issues with performing the following control?

･ When using OSPI, set the ENB_SPI_FLD bit to 1.

･ After use, set the ENB_SPI_FLD bit to 0.

Q2. Have you observed the phenomenon where OSPI access is executed during power off?

Q3. Have you figured out the cause?

I would like to receive the response to Q1 by the end of this week.

Best regards,

Futoshi

0 Vaibhav Kumar 6 months ago in reply to futoshi kawarazaki

TI__Mastermind 44926 points

Hi,

I will answer your questions in the order you have asked.

futoshi kawarazaki said:
Q1. Do you think there could be any issues with performing the following control?

･ When using OSPI, set the ENB_SPI_FLD bit to 1.

･ After use, set the ENB_SPI_FLD bit to 0.

There should not be any problem as far no OSPI operation is called by other threads(considering you have a multi threaded environment/setup).

futoshi kawarazaki said:
Have you observed the phenomenon where OSPI access is executed during power off?

I did not observed this phenomenon at all, as once I powered off my TI EVM, then I saw all the lines just returning back to their original state, for example all became low. Here by all lines I mean Clock, CS and Data lines and other lines to be used for OSPI communication.

So at my setup, there was no page program/undefined operation happening post power up.

futoshi kawarazaki said:
Q3. Have you figured out the cause?

There is nothing as such that can be figured out atleast at my setup, as its not reproducible at my setup. I have highlighted this while answering your second question.

futoshi kawarazaki said:
The program is designed to write USB data to the FLASH memory only when a USB is inserted.

But we can figure out something around this point. Please see my follow up response.

Sincerely,

Vaibhav

0 Vaibhav Kumar 6 months ago

TI__Mastermind 44926 points

Splitting my follow up response to make sure this gets highlighted properly.

futoshi kawarazaki said:
OSPI only reads during boot.

The program is designed to write USB data to the FLASH memory only when a USB is inserted.

I am assuming that the read operation which happens is calling OSPI_readDirect() API at low level and for writes, OSPI_writeIndirect() is called.

Can you confirm the same? Also mention the MCU PLUS SDK version which you are using for development.

Sincerely,

Vaibhav

0 futoshi kawarazaki 6 months ago in reply to Vaibhav Kumar

Prodigy 155 points

Hi Vaibhav,

OSPI_readDirect() and OSPI_writeIndirect() are called.

The MCU PLUS SDK version is 08.03.00.18

Best regards,

Futoshi

0 Vaibhav Kumar 6 months ago in reply to futoshi kawarazaki

TI__Mastermind 44926 points

Hi,

Thanks for your patience.

I would encourage you to go ahead with the latest SDK as there has been quite a lot of improvements in the OSPI as well as other drivers.

But if you want to stick to the current SDK, I would get back to the older one and check how read and writes are implemented.

Allow me sometime on this.

Regards,

Vaibhav

0 futoshi kawarazaki 6 months ago in reply to Vaibhav Kumar

Prodigy 155 points

Hi Vaibhav,

I want to stick to the version 08.03.00.18 because it is already being used in products that have already been shipped.

Best regards,

Futoshi

0 Vaibhav Kumar 6 months ago in reply to futoshi kawarazaki

TI__Mastermind 44926 points

Hi,

Thanks for your response.

futoshi kawarazaki said:
I want to stick to the version 08.03.00.18 because it is already being used in products that have already been shipped.

Okay sure, I understand you want to stick to the mentioned version.

I have checked the source code of 8.03 and compared it with latest SDK offering, there is not much difference in the API readDirect and writeIndirect.

Hence, from Software point of view I can say that the sudden page programming should have not happened.

But, you can try to incorporate one change and let me know if it helps upto some extent.

I want you to head over to the API OSPI_readDirect and make the following change:

int32_t OSPI_readDirect(OSPI_Handle handle, OSPI_Transaction *trans)
{
    int32_t status = SystemP_SUCCESS;
    const OSPI_Attrs *attrs = ((OSPI_Config *)handle)->attrs;
    OSPI_Object *obj = ((OSPI_Config *)handle)->object;
    const CSL_ospi_flash_cfgRegs *pReg = (const CSL_ospi_flash_cfgRegs *)(attrs->baseAddr);

    uint8_t *pSrc;
    uint8_t *pDst;
    uint32_t addrOffset;

    addrOffset = trans->addrOffset;
    pDst = (uint8_t *) trans->buf;

    /* Enable Direct Access Mode */
    CSL_REG32_FINS(&pReg->CONFIG_REG,
                   OSPI_FLASH_CFG_CONFIG_REG_ENB_DIR_ACC_CTLR_FLD,
                   1);
    CSL_REG32_WR(&pReg->IND_AHB_ADDR_TRIGGER_REG, 0x04000000);

    pSrc = (uint8_t *)(attrs->dataBaseAddr + addrOffset);

    /* DMA Copy fails when copying to to certain memory regions. So in this case we switch to normal memcpy
       for copying even if dmaEnable is true. Also do DMA copy only if size > 1KB*/
    uint32_t isDmaCopy = (attrs->dmaEnable == TRUE) &&
                         (OSPI_isDmaRestrictedRegion(handle, (uint32_t)pDst) == FALSE) &&
                         (trans->count > OSPI_DMA_COPY_LOWER_LIMIT);

    if(isDmaCopy == TRUE)
    {
        uint8_t *tempSrc = pSrc;
        uint8_t *tempDst = pDst;
        uint32_t remainingBytes = trans->count;

        /* Check for 32B alignment of source address */
        if(((uint32_t)pSrc % OSPI_DMA_COPY_SRC_ALIGNMENT) != 0)
        {
            uint32_t initResidualBytes = OSPI_DMA_COPY_SRC_ALIGNMENT - (((uint32_t)pSrc) % OSPI_DMA_COPY_SRC_ALIGNMENT);

            /* Do CPU copy for the initial residual bytes */
            memcpy(pDst, pSrc, initResidualBytes);

            tempDst = (uint8_t *)((uint32_t)pDst + initResidualBytes);
            tempSrc = (uint8_t *)((uint32_t)pSrc + initResidualBytes);
            remainingBytes -= initResidualBytes;
        }

        /* Do DMA copy for 32B-aligned bytes */
        uint32_t unalignedBytes = (remainingBytes % OSPI_DMA_COPY_SIZE_ALIGNMENT);

        if(attrs->phyEnable == TRUE)
        {
            /* Enable PHY pipeline */
            CSL_REG32_FINS(&pReg->CONFIG_REG,
                   OSPI_FLASH_CFG_CONFIG_REG_PIPELINE_PHY_FLD,
                   TRUE);
        }

        OSPI_dmaCopy(obj->ospiDmaHandle, tempDst, tempSrc, remainingBytes - unalignedBytes);

        if(attrs->phyEnable == TRUE)
        {
            /* Disable PHY pipeline */
            CSL_REG32_FINS(&pReg->CONFIG_REG,
                   OSPI_FLASH_CFG_CONFIG_REG_PIPELINE_PHY_FLD,
                   FALSE);
        }

        /* Do a CPU copy of unaligned bytes if any */
        if(unalignedBytes > 0)
        {
            tempDst += (remainingBytes - unalignedBytes);
            tempSrc += (remainingBytes - unalignedBytes);
            memcpy(tempDst, tempSrc, unalignedBytes);
        }
    }
    else
    {
        memcpy(pDst, pSrc, trans->count);
    }

    // disable dac mode(newly added as of 03/11/2025)
    CSL_REG32_FINS(&pReg->CONFIG_REG,
                    OSPI_FLASH_CFG_CONFIG_REG_ENB_DIR_ACC_CTLR_FLD,
                    0U);
    CSL_REG32_WR(&pReg->IND_AHB_ADDR_TRIGGER_REG, 0);

    return status;
}

Notice, there is a small change at the end of the API, where after read operation has been done, I disable the DAC mode. I have done so, because thats how it should be, and also the latest offering does so.

Please make the changes as mentioned and rebuild the libraries by using the command:

Let me know if this helps resolve the issue.

If not, then this has no connection with the SW code as such and has to be either the following or something else.

futoshi kawarazaki said:
I believe that the difference in the power voltage during the power-off process is what causes the issue in some PCBs but not in others

Looking forward to your response.

Regards,

Vaibhav

0 futoshi kawarazaki 6 months ago in reply to Vaibhav Kumar

Prodigy 155 points

Hi Vaibhav,

As a result of changing OSPI_readDirect, no access to OSPI occurred when the power was off.

Q1. Was the DAC malfunctioning?

Q2. Is there any impact from disabling the DAC mode?

Q3. Is it necessary to modify the higher-level control, keeping in mind that the DAC mode is disabled?

Best regards,

Futoshi

0 futoshi kawarazaki 5 months ago in reply to futoshi kawarazaki

Prodigy 155 points

Hi Vaibhav,

In addition to the above, please let me know the following:

Q4. Would this issue occur if you downgrade the SDK in your evaluation environment to the version 08.03.00.18?

Best regards,

Futoshi

+1 Vaibhav Kumar 5 months ago in reply to futoshi kawarazaki

TI__Mastermind 44926 points

futoshi kawarazaki said:
As a result of changing OSPI_readDirect, no access to OSPI occurred when the power was off.

Q1. Was the DAC malfunctioning?

Q2. Is there any impact from disabling the DAC mode?

Q3. Is it necessary to modify the higher-level control, keeping in mind that the DAC mode is disabled?

I am glad the issue is no more occurring with the fix I proposed.

The reason for introducing DAC disable is because when DAC is enabled, we have seen some accesses to the flash, so it is better to have it disabled once we get out of the OSPI_readDirect.

futoshi kawarazaki said:
Q4. Would this issue occur if you downgrade the SDK in your evaluation environment to the version 08.03.00.18?

Yes this would occur if I downgrade.

But its fixed in the latest release.

Please mark my response above resolved if it helped you out.

Regards,

Vaibhav

Arm-based microcontrollers

Arm-based microcontrollers forum

AM2431: OSPI malfunction during power-off