• TI Thinks Resolved

Compiler/AM6548: QSPI flash latency

Prodigy 250 points

Replies: 9

Views: 99

Part Number: AM6548

Tool/software: TI C/C++ Compiler

i am running below rtos code on AM65xx a53 core

uint32_t ioMode;
ioMode = BOARD_FLASH_QSPI_IO_MODE_QUAD;

uint32_t blockNum, pageNum; /* Block, page number */

Board_flashOffsetToBlkPage(flashHandle, SPI_EEPROM_DEVICEIP_OFFSET,
&blockNum, &pageNum);

Board_flashEraseBlk(flashHandle, blockNum);

Task_sleep(1000); //we see that the value is not getting written to flash if sleep not here

Board_flashWrite(flashHandle, SPI_EEPROM_DEVICEIP_OFFSET, (uint8_t *)&ipAddr, 4,
(void *)(&ioMode));

Task_sleep(1000);

Board_flashRead(flashHandle, SPI_EEPROM_DEVICEIP_OFFSET, (uint8_t *)&test_ip_after,
4, (void *)(&ioMode));

UART_printf("current ip = %d, current ip from spi read = %d", ipAddr,test_ip_after );

basically, i am trying to write IP address to flash memory.

The problem i see is in the last line when i print the data that i intended to write to flash and the data i read from flash after writing.(ipAddr and test_ip_after )

I notice that these two values are not same unless i insert bunch of task sleep in between,

Is it a known issue, what is the best way to deal with it?

  • Hi,

    I'll need to check into this and get back with you.

    Regards,
    Frank

  • In reply to Frank Livingston:

    Hi,

    I followed up a bit on this internally and have a few questions for you.

    • What mode are you using, DAC (Direct) or IND (Indirect)?
    • Is DMA mode disabled or enabled?
    • Are you using a custom hardware platform, or attempting to run this on TI EVM? I assume the former since AM654x EVM/IDK has OSPI flash.
    • Have you tried running the AM65x OPSI test in <PDK>\packages\ti\drv\spi\test\ospi_flash?

    Note that in DAC mode, the flash driver always checks the status of the flash to confirm write completion.

    Regards,
    Frank

  • In reply to Frank Livingston:

    Frank,

    Thanks for your reply.

    >>

    • What mode are you using, DAC (Direct) or IND (Indirect)?
    • Is DMA mode disabled or enabled?

    my init function is below, i borrowed it from some exisitng example, i hope you would find answers to these init specific details below.

    void local_SPI_init()
    {
    OSPI_v0_HwAttrs ospi_cfg;

    /* Get the default OSPI init configurations */
    OSPI_socGetInitCfg(BOARD_OSPI_NOR_INSTANCE, &ospi_cfg);

    /* Indirect access controller mode always uses polling, interrupt is not supported */
    ospi_cfg.intrEnable = false;

    /* Set the default OSPI init configurations */
    OSPI_socSetInitCfg(BOARD_OSPI_NOR_INSTANCE, &ospi_cfg);


    /* Open the Board QSPI NOR device with QSPI port 0
    and use default QSPI configurations */
    boardFlashHandle = Board_flashOpen(BOARD_FLASH_ID_MT35XU512ABA1G12,
    BOARD_OSPI_NOR_INSTANCE, NULL);

    if(!boardFlashHandle)
    {
    UART_printf("\n Board_flashOpen failed. \n");
    return;
    }
    }

    >>

    • Are you using a custom hardware platform, or attempting to run this on TI EVM? I assume the former since AM654x EVM/IDK has OSPI flash.

    sorry for the confusion, i am using TI EVM AM65xx, and OSPI flash(not QSPI).

    • Have you tried running the AM65x OPSI test in <PDK>\packages\ti\drv\spi\test\ospi_flash?

    I haven't tried yet, should i run this to verify my setup?

  • In reply to Shubham Shandilya22:

    Hi,

    >> I haven't tried yet, should i run this to verify my setup?

    Yes, I think this is a worthwhile exercise.

    Build the test using: 

    > gmake spi_apps LIMIT_SOCS="am65xx" LIMIT_BOARDS="am65xx_evm" LIMIT_CORES="mpu1_0 mpu1_1 mpu2_0 mpu2_1"

     

    Regards,
    Frank

  • In reply to Frank Livingston:

    Frank,

    i ran the test and below are the logs.

    it seems that tests are passing.

    OSPI RCLK running at 133333333 Hz.

    OSPI UT 0


    OSPI flash test slave in DAC mode at 133MHz RCLK

    OSPI NOR device ID: 0x5b1a, manufacturer ID: 0x2c

    Board_flashWrite 1048576 bytes at transfer rate 746 Kbps

    Board_flashWrite CPU load 100%

    Board_flashRead 1048576 bytes at transfer rate 52 Mbps

    Board_flashRead CPU load 100%


    OSPI flash test slave in DAC mode at 133MHz RCLK have passed

    OSPI UT 1


    OSPI flash test slave in INDAC mode at 133MHz RCLK

    OSPI NOR device ID: 0x5b1a, manufacturer ID: 0x2c

    Board_flashWrite 1048576 bytes at transfer rate 11762 Kbps

    Board_flashWrite CPU load 6%

    Board_flashRead 1048576 bytes at transfer rate 66 Mbps

    Board_flashRead CPU load 100%


    OSPI flash test slave in INDAC mode at 133MHz RCLK have passed

    OSPI RCLK running at 166666666 Hz.

    OSPI UT 3


    OSPI flash test slave in DAC mode at 166MHz RCLK

    OSPI NOR device ID: 0x5b1a, manufacturer ID: 0x2c

    Board_flashWrite 1048576 bytes at transfer rate 746 Kbps

    Board_flashWrite CPU load 100%

    Board_flashRead 1048576 bytes at transfer rate 55 Mbps

    Board_flashRead CPU load 100%


    OSPI flash test slave in DAC mode at 166MHz RCLK have passed

    OSPI UT 4


    OSPI flash test slave in INDAC mode at 166MHz RCLK

    OSPI NOR device ID: 0x5b1a, manufacturer ID: 0x2c

    Board_flashWrite 1048576 bytes at transfer rate 12404 Kbps

    Board_flashWrite CPU load 6%

    Board_flashRead 1048576 bytes at transfer rate 83 Mbps

    Board_flashRead CPU load 100%


    OSPI flash test slave in INDAC mode at 166MHz RCLK have passed

    All tests have passed.
    Done

  • In reply to Shubham Shandilya22:

    Hi Shubham,

    That's encouraging. I notice the test code (<PDK>\packages\ti\drv\spi\test\ospi_flash\src\main_ospi_flash_test.c) doesn't include Task_sleep() between Board_flashEraseBlk(), Board_flashWrite() & Board_flashRead(). However, these API functions are called in separate loops, so perhaps the code between the function calls (and the calls for specific areas of the flash) is providing sufficient delay to mask the problem you're observing.

    I suggest as a next step that you compare your example code with the test code to see if you can identify any discrepancies between the driver mode settings (especially for DAC mode and DMA-mode enabled). If you're unable to find any differences, then try paring off pieces of the test code until it matches with the functionality of your example code. If the problem still persists, then it's possible you've discovered an issue with the code. Please keep me informed about the outcome of the further investigation.

    Regards,
    Frank

  • In reply to Frank Livingston:

    Frank,

    Thanks for reply.

    I would definitely try the suggested steps.

    Also would it be possible to run my code at your end to reproduce the issue.

    All i am trying to do is to initialize OSPI and, do erase, write and read.

  • In reply to Shubham Shandilya22:

    Hi Shubham,

    Yes, I can give it a quick try. Can you please share your code here on the forum?

    Regards,
    Frank

  • In reply to Frank Livingston:

    Hi Shubham,

    I haven't heard from you in a while, so I'm assuming this issue has been resolved. Hence I'll close the thread.

    Regards,
    Frank