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.

AM6442: About erase commands of SPI.

Part Number: AM6442


When I checked the OSPI Flash Diagnostic sample output below, the erase command output by SFDP was "0xDC", but in the sample, the command used in the erase process is "0xD8".

1. It seems that there is no "0xD8" in the output of SFDP. Is it correct to use "0xD8" for erasing?

2. When I changed the erase processing command to "0xDC" ​​and executed it, the erase processing did not work properly.
In the output of SFDP, the erase command is "0xDC". Is there any additional processing required to erase with "0xDC"?

3. The OSPI Flash IO sample works correctly with the erase process regardless of whether the erase command is "0xDC"​or "0xD8".
Why is there a difference in the behavior of erase commands between OSPI Flash Diagnostic and OSPI Flash IO?
Both samples use S28HS512T (DEVICE_ID: 0x5B1A).

OSPI Flash Diagnostic output result:
------------------------------------------------------------------
All tests have passed!!
[OSPI Flash Diagnostic Test] Starting ...
[OSPI Flash Diagnostic Test] Flash Manufacturer ID : 0x34
[OSPI Flash Diagnostic Test] Flash Device ID : 0x5B1A
[OSPI Flash Diagnostic Test] Executing Flash Erase on first block...
[OSPI Flash Diagnostic Test] Done !!!
[OSPI Flash Diagnostic Test] Performing Write-Read Test...
[OSPI Flash Diagnostic Test] Write-Read Test Passed!
[OSPI Flash Diagnostic Test] SFDP Information :
================================================
SFDP
================================================
SFDP Major Revision : 0x1
SFDP Minor Revision : 0x8
Number of Parameter Headers in this Table : 6

Types of Additional Parameter Tables in this flash
---------------------------------------------------
4 BYTE ADDRESSING MODE INSTRUCTIONS TABLE
XSPI PROFILE TABLE
STATUS CONTROL AND CONFIGURATION REGISTER MAP TABLE
OCTAL DDR MODE COMMAND SEQUENCE TABLE
SECTOR MAP TABLE

Parsing of OCTAL DDR MODE COMMAND SEQUENCE TABLE table not yet supported.

Flash_NorXspiDevDefines gFlashNorXspiDeviceDefines_<part-number> = {

.XSPI_NOR_CMD_RSTEN = 0x66,
.XSPI_NOR_CMD_RSTMEM = 0x99,
.XSPI_NOR_CMD_WREN = 0x06,
.XSPI_NOR_CMD_WRREG = 0x71,
.XSPI_NOR_CMD_BULK_ERASE = 0xC7,
.XSPI_NOR_CMD_SECTOR_ERASE_3B = 0x21,
.XSPI_NOR_CMD_SECTOR_ERASE_4B = 0x21,
.XSPI_NOR_CMD_BLOCK_ERASE_3B = 0xDC,
.XSPI_NOR_CMD_BLOCK_ERASE_4B = 0xDC,
.XSPI_NOR_CMD_PAGE_PROG_3B = 0x02,
.XSPI_NOR_CMD_PAGE_PROG_4B = 0x12,
.XSPI_NOR_CMD_RDSR = 0x05,
.XSPI_NOR_CMD_RDREG = 0x65,
.XSPI_NOR_CMD_RDID = 0x9F,
.XSPI_NOR_CMD_READ = 0x03,
.XSPI_NOR_CMD_888_SDR_READ = 0x00,
.XSPI_NOR_CMD_888_DDR_READ = 0xEE,
.XSPI_NOR_CMD_444_SDR_READ = 0x00,
.XSPI_NOR_CMD_444_DDR_READ = 0x00,
.XSPI_NOR_CMD_114_READ = 0x00,
.XSPI_NOR_SR_WIP = 1,
.XSPI_NOR_SR_WEL = 2,
.XSPI_NOR_RDID_NUM_BYTES = 5,
.XSPI_NOR_MANF_ID = 0x34,
.XSPI_NOR_DEVICE_ID = 0x5B1A,
.XSPI_NOR_114_READ_MODE_CLKS = 0,
.XSPI_NOR_114_READ_DUMMY_CYCLES = 0,
.XSPI_NOR_444_READ_MODE_CLKS = 0,
.XSPI_NOR_444_READ_DUMMY_CYCLES = 0,
.XSPI_NOR_444_READ_DUMMY_CYCLES_LC = 0xFF,
.XSPI_NOR_QUAD_CMD_READ_DUMMY_CYCLES = 0x00,
.XSPI_NOR_OCTAL_READ_DUMMY_CYCLE = 24,
.XSPI_NOR_OCTAL_READ_DUMMY_CYCLE_LC = 0x0B,
.XSPI_NOR_OCTAL_DDR_RDSR_DUMMY_CYCLE = 4,
.XSPI_NOR_OCTAL_DDR_RDREG_ADDR_BYTES = 4,
.XSPI_NOR_OCTAL_DDR_WRREG_ADDR_BYTES = 4,
.XSPI_NOR_OCTAL_DDR_RDVREG_DUMMY_CYCLE = 4,
.XSPI_NOR_OCTAL_DDR_RDNVREG_DUMMY_CYCLE = 8,
.XSPI_NOR_OCTAL_RDSFDP_DUMMY_CYCLE = 8,
.XSPI_NOR_OCTAL_RDSFDP_ADDR_TYPE = 0,
.XSPI_NOR_WRR_WRITE_TIMEOUT = 5120,
.XSPI_NOR_BULK_ERASE_TIMEOUT = 256000000,
.XSPI_NOR_PAGE_PROG_TIMEOUT = 512,
.XSPI_NOR_VREG_OFFSET = 0x800000,
.XSPI_NOR_NVREG_OFFSET = 0x0,
.XSPI_NOR_QUAD_MODE_CFG_ADDR = 0x0,
.XSPI_NOR_QUAD_MODE_CFG_BIT_LOCATION = 0x0,
.XSPI_NOR_DDR_OCTAL_MODE_CFG_ADDR = 0x6,
.XSPI_NOR_DDR_OCTAL_MODE_CFG_BIT_LOCATION = 0x1,
.XSPI_NOR_DUMMY_CYCLE_CFG_ADDR = 0x3,
.XSPI_NOR_FLASH_SIZE = 67108864,
.XSPI_NOR_PAGE_SIZE = 256,
.XSPI_NOR_BLOCK_SIZE = 262144,
.XSPI_NOR_SECTOR_SIZE = 4096,
.addrByteSupport = 1,
.dtrSupport = 1,
.qeType = 0,
.seq444Enable = { 0, 0, 0, 0, 0 },
.seq444Disable = { 0, 0, 0, 0 },
.oeType = 0,
.cmdExtType = 0,
.byteOrder = 0,
};

All tests have passed!!
------------------------------------------------------------------

  • Hello,

    Could you please share which software or tool you are using so that I can assign your thread to the proper subject owner?

    Thanks,

    Jianzhong

  • Hello, thank you for your reply.

    I'm using the R5 core of TMDS64GPEVM and running the example below in Code Composer Studio 10.3.1.
    MCU + SDK 08_00_00_21
    examples/drivers/ospi/ospi_flash_diag
    examples/drivers/ospi/ospi_flash_io

    Regards.

  • Hi,

    I'm looking into this and will get back with you shortly.

    Regards,
    Frank

  • Hi,

    I confirmed your findings.

    ospi_flash_diag uses 0xD8, while ospi_flash_io uses 0xDC.

    For ospi_flash_diag, I changed OSPI_NOR_CMD_BLOCK_ERASE from 0xD8 to 0xDC in ospi_nor_flash.c. With this change, I observe the following output:

    ERROR: ospi_flash_diag_test_compare_buffers:165: OSPI read data mismatch !!!
    Some tests have failed!!

    I'm reaching out to an internal expert for help and will get back with you shortly.

    Regards,
    Frank

  • Hi,

    I can provide some clarification here. The ospi_flash_diag and ospi_flash_io are very different examples. The ospi_flash_diag example uses the ospi_nor_flash.c generic layer for communications with the connected flash device, and ospi_flash_io uses the flash driver. Generally in applications you would need to use apis from the flash driver. The ospi_nor_flash.c is used only in the ospi_flash_diag example. The diag example is more of a tool than an example. The diag example is supposed to work with any flash device, in SPI mode (1-1-1) mode. So to make this independent of any user parameters, we have hard coded some commands in the source file directly. The diag example does basic sanity on the connected flash device and also prints SFDP information. 

    Now to answer your questions specifically,

    1. SFDP outputs the erase command supported in 4Byte addressing mode by default. The reason why it prints 0xDC for the 3B mode as well is probably an error in the table. Anyways, crux is that 0xD8 is used when addressing mode is 3B and 0xDC is used when address is 4B. In the flash diag example/tool, we expect it to work for a large number of flashes, even the ones without the 4B addressing mode. When a flash is restarted, initially it will be in 3B addressing mode. That's why we use 0xD8 in the diag example. If you use 0xDC it won't work, because we won't switch to 4B addressing mode.

    2. I am assuming you changed the command in ospi_nor_flash.c file. That is unnecessary. Like I explained before, the 0xDC can't be used if the flash device is in 3B mode. In the case of ospi_flash_io example, flash driver is used. And during the initialization part (Flash_norXspiOpen() function), flash driver configures the flash to use 4B addressing mode. That's why in all examples using flash driver the 0xDC command is being used.

    3. Like I already explained, ospi_flash_io do not use the ospi_nor_flash.c layer. That is used only by the diag example/tool. So if you make changes in the ospi_nor_flash.c it wont affect the ospi_flash_io example. The commands used by the flash layer are in a separate device data file, flash_nor_xspi_device_S28HS512T.c. 

    Bottomline is that both the commands are valid, but are used in different addressing modes. The diag example always starts from a reset flash config, so we have to use a 3B block erase command. I hope that explains your doubt. Let me know if there are any more queries.

    Regards,
    Anand Mahadevan SS 

  • Hello, thank you for your reply.

    I have an additional question.
    In the OSPI Flash IO example, there is a case where 0xC7 is used for the erase command.
    What happens when I use 0xC7?
    Will the entire area be erased?

  • Hi,

    Yes. The commands 0xC7 and 0x60 are Chip Erase (or Bulk Erase) commands, which wipe the entire flash memory. They are very rarely used though. I think you might have seen the command being used in the implementation of the blockErase function where in if the block number passed is -1, we do a bulk erase. This is mostly never required.

    Regards,
    Anand Mahadevan SS