CCS/AM5716: QSPI write speed issue

Zhengxin Rui

Intellectual 290 points

Part Number: AM5716

Tool/software: Code Composer Studio

Hi all，

We test the QSPI flash driver on IDK5718, and found the QSPI flash write speed is too slow, about 4KByte/s,

in u-boot, it works good.

The post mentioned the same issue, but it seems have no good answer.

The SF25FL_bufferWrite write JUST ONE byte on every programme cycle in memory map mode.

We try to change the length up to the FLASH's PAGE SIZE, eg.256,

BUT only the first byte is correct on FLASH.

Is any solution or suggestion for this issue??

Thanks very much.

over 5 years ago

0 Frank Livingston over 5 years ago

TI__Mastermind 29388 points

Hi,

I'll check on this and get back with you shortly.

Regards,
Frank

0 Frank Livingston over 5 years ago in reply to Frank Livingston

TI__Mastermind 29388 points

Hi,

This issue should have been fixed in PRSDK 5.3.0.5. Please see the release notes, PRSDK-5094.

http://software-dl.ti.com/processor-sdk-rtos/esd/docs/05_03_00_07/rtos/index_release_specific.html#fixed-issues

Developer comments concerning root cause: In memory map mode, the application use CPU to check the write status for every byte write which has very low performance.

Please also see this commit in external Git which contains the code for the fix (commit comment is "Add dma support in memory map mode for QSPI IP v1 driver to increase the read/write performance.").

https://git.ti.com/cgit/keystone-rtos/spi-lld/commit/?id=0370daf32ada2d8b72dbdc7fac0e9fe4076d3d44

The fix was verified using the DMA mode QSPI read/write test. Likely the settings in this test (DMA, DAC) need to be applied in the case of the flash writer.

Regards,
Frank

0 Zhengxin Rui over 5 years ago in reply to Frank Livingston

Intellectual 290 points

Hi Frank,

Thanks for you help,

I'll try it after the Spring Festival.

I measured the multi bytes write waveforms in non-DMA mode before holiday,

it shows the CS signal is valided only one byte write,

not the whole write process.

I'm not sure if that's the root cause of this issue or not.

In my mind, DMA mode can reduce the CPU load,

but cannot improve the SPI write speed when CPU is IDLE.

B.R.

Zhengxin RUI

0 Zhengxin Rui over 5 years ago in reply to Frank Livingston

Intellectual 290 points

Hi Frank,

I've tested the new driver, it can write flash multi bytes one time.

BUT there is another issue in the driver.

The DMA can write more bytes than the driver need in some case of datasize.

The screenshot show the bytes index from 9-15 are changed when datasize is 9.

The write buffer is 128 byte aligned, so it cannot be caused by address alignment.

B.R.

Zhengxin

0 Zhengxin Rui over 5 years ago in reply to Frank Livingston

Intellectual 290 points

The screenshot shows the issue in CCS environment.

The project is QSPI_BasicExample_idkAM571x_armDmaTestProject created by PDK.

datasize of flashTranscation is set to 12,

The 12 bytes rxBuf[0-2] are correct,

rxBuf[3] is equal to txBuf[3],

but we just want to write 12 bytes.

The DMA write 16 bytes in the FLASH actually.

BTW,

rxBuf need to invalid cache after DMA read.

0 Frank Livingston over 5 years ago in reply to Zhengxin Rui

TI__Mastermind 29388 points

Hi Zhengxin,

Sorry for the long delay in responding. I'm taking a look at this issue now.

Regards,
Frank

0 Frank Livingston over 5 years ago in reply to Frank Livingston

TI__Mastermind 29388 points

Hi Zhengxin,

I'm unable to reproduce the issue for test project QSPI_BasicExample_idkAM572x_armDmaTestProject, testID=QSPI_TEST_ID_MMAP_DMA.

I manually set the transfer length to 3 32-bit words:

        /* Set the transfer length in number of 32 bit words */
        //transferLength = QSPI_TEST_LENGTH;
        transferLength = 3;

At the end of the test, the UART log always shows the test passes:

QSPI UT 2

QSPI flash memory map mode with DMA enabled test

QSPI flash memory map mode with DMA enabled test have passed

Also rxBuf contains the correct data:

I notice it makes a difference whether use software breakpoints when I execute the code. If I use software breakpoints for debugging, the test can hang or fail. If I use hardware breakpoints or execute in Free Run mode (Control-F8), though, the test always passes.

>> rxBuf need to invalid cache after DMA read

When DMA mode is enabled, the cache is cleaned and invalidated after pattern generation :

#ifdef SPI_DMA_ENABLE
        if (test->dmaMode)
        {
            CacheP_wbInv((void *)rxBuf, (int32_t)sizeof(rxBuf));
            CacheP_wbInv((void *)txBuf, (int32_t)sizeof(txBuf));
        }
#endif

rxBuf[] isn't accessed afterwards until the read is complete and the data is verified:

        /* Read data from flash */
        retVal = SF25FL_bufferRead(flashHandle, &flashTransaction);

        /* Verify Data */
        retVal = VerifyData((unsigned char *)&txBuf[0], (unsigned char *)&rxBuf[0],
            transferLength);

The Rx data will be fetched into the cache during the VerifyData() function. Hence I don't think an explicit cache invalidate is required.

Regards,
Frank

0 Zhengxin Rui over 5 years ago in reply to Frank Livingston

Intellectual 290 points

Dear Frank,

Thanks for your reply.

tranferLength is a gobal paramter in the test,

Flash read also use the tranferLength parameter,

so it can't read the following bytes anymore.

When set transferLength to 3, and just set the write length to 12 bytes, the read 16 bytes,

the rxBuf will contain the following 4 bytes of testPattern.

I need to use the QSPI Flash driver for a custom filesystem,

and find that the flash content will changed unexpected.

0 Frank Livingston over 5 years ago in reply to Zhengxin Rui

TI__Mastermind 29388 points

Hi Zhengxin,

Thanks, I'll try setting different write & read lengths.

Regards,
Frank

0 Frank Livingston over 5 years ago in reply to Frank Livingston

TI__Mastermind 29388 points

Hi Zhengxin,

I performed an experiment with:

transferLength = 4;
write: flashTransaction.dataSize = (transferLength-1) * 4;
read: flashTransaction.dataSize = transferLength * 4;

In this case, I observe rxBuf[3] contains the unexpected 32-bit word 0x0F0E0D0C.

I need to discuss this further with the development team to see if this is expected driver behavior. I'll keep you posted.

Regards,
Frank

0 Frank Livingston over 5 years ago in reply to Frank Livingston

TI__Mastermind 29388 points

Hi Zhengxin,

I filed a PRSDK bug for this issue and the development team will look into it. The fix is targeted for PRSDK 7.0. Please check PRSDK release notes for the issue PRSDK-8170.

Regards,
Frank

0 Zhengxin Rui over 5 years ago in reply to Frank Livingston

Intellectual 290 points

Hi Frank,

Thanks for your help.

I'll pay attention to this issue.

B.R.

Zhengxin

0 Frank Livingston over 5 years ago in reply to Zhengxin Rui

TI__Mastermind 29388 points

Hi Zhengxin,

Do you have a workaround for this issue in advance of a fix? For example, can you use CPU mode instead of DMA mode?

Thanks,
Frank

0 Zhengxin Rui over 5 years ago in reply to Frank Livingston

Intellectual 290 points

Hi Frank,

I have no workaround for the issue.

The CPU mode can only transfer 1 Byte per transaction though dataSize is 256.

I'm very curious about DMA mode can write more bytes one time.

DMA mode can reduce the CPU usage.

Why it can effect QSPI transfer?

B.R.

Zhengxin

Processors

Processors forum

CCS/AM5716: QSPI write speed issue