Compiler/AM6548: QSPI flash latency

Shubham Shandilya22

Prodigy 705 points

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?

over 4 years ago

0 Frank Livingston over 4 years ago

TI__Mastermind 28788 points

Hi,

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

Regards,
Frank

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

TI__Mastermind 28788 points

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

0 Shubham Shandilya22 over 4 years ago in reply to Frank Livingston

TI__Prodigy 705 points

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?

0 Frank Livingston over 4 years ago in reply to Shubham Shandilya22

TI__Mastermind 28788 points

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

0 Shubham Shandilya22 over 4 years ago in reply to Frank Livingston

TI__Prodigy 705 points

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

0 Frank Livingston over 4 years ago in reply to Shubham Shandilya22

TI__Mastermind 28788 points

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

0 Shubham Shandilya22 over 4 years ago in reply to Frank Livingston

TI__Prodigy 705 points

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.

0 Frank Livingston over 4 years ago in reply to Shubham Shandilya22

TI__Mastermind 28788 points

Hi Shubham,

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

Regards,
Frank

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

TI__Mastermind 28788 points

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

0 Shubham Shandilya22 over 4 years ago in reply to Frank Livingston

TI__Prodigy 705 points

Frank,

Sorry for the late response.

I finally got it working correctly after adding below change in my Init function.

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;

ospi_cfg.phyEnable = 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;
}
}

I go it from the PDK example you pointed to.

Thanks for all the help.

It will be good though if you could tell, what this change does.

Processors

Processors forum

Compiler/AM6548: QSPI flash latency