AM2434: For xSpi custom flash driver for AM2434, step 4 (ospi_flash_io) fails to read manufacturer ID and device ID.

Hi Moonil,

Apologies for such hiccups. This is to let you know that we are undergoing some changes to have better experience for flash driver. But for current version of SDK, I can extend some pointers for you -

1. The ospi_flash_diag is working on 1s-1s-1s mode whereas ospi_flash_io is functional in 8d-8d-8d mode, so it seems like the flash driver is functional for 1s-1s-1s mode but not for 8d-8d-8d mode. You also need to configure the dummy cycles to higher number.

2. When the PHY Mode is enabled, the Clock Divider is bypassed. So your driver is clock enabled for 200MHz, but the part number you shared does not support 200MHz. Can you lower your clock to 133MHz ?

Also, the flash_diag works on very slow clock which overrides the sysconfig in the code.

Accordingly, the dummy cycles will be 12-13.

3. Try disabling the PHY Mode for starters. It might just work with this too, then more tuning should be done in place.

Hope that helps.

Best Regards,
Aakash

Hi Aakash,

Thank you for your prompt support and also your review of the IS25LX256 datasheet.

I tried the configuration which you pointed out but the issue was still the same as before.

• set dummy cycle as 13 in "flash_nor_xspi_device_IS25LX256.c"
• set clock as 133,333,333 Hz and divider as 4 in "example.syscfg"
• disabled PHY in "example.syscfg"

"flash_nor_xspi_device_IS25LX256.c":

/*
 *  Copyright (C) 2021 Texas Instruments Incorporated
 *
 *  Redistribution and use in source and binary forms, with or without
 *  modification, are permitted provided that the following conditions
 *  are met:
 *
 *    Redistributions of source code must retain the above copyright
 *    notice, this list of conditions and the following disclaimer.
 *
 *    Redistributions in binary form must reproduce the above copyright
 *    notice, this list of conditions and the following disclaimer in the
 *    documentation and/or other materials provided with the
 *    distribution.
 *
 *    Neither the name of Texas Instruments Incorporated nor the names of
 *    its contributors may be used to endorse or promote products derived
 *    from this software without specific prior written permission.
 *
 *  THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
 *  "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
 *  LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
 *  A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT
 *  OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
 *  SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
 *  LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES, LOSS OF USE,
 *  DATA, OR PROFITS, OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
 *  THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
 *  (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
 *  OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
 */

#include <board/flash.h>

Flash_NorXspiDevDefines gFlashNorXspiDeviceDefines_IS25LX256 = {

    .NOR_CMD_SRSTE                       = 0x66U,
    .NOR_CMD_SFRST                       = 0x99U,
    .NOR_CMD_WREN                        = 0x06U, // need to confirm
    .NOR_CMD_WRREG                       = 0x00U, // need to confirm
    .NOR_CMD_BULK_ERASE                  = 0xC7U, // need to confirm
    .NOR_CMD_BLOCK_ERASE                 = 0xD8U, // 0xD8U - 3B, 0xDCU - 4B, // need to confirm
    .NOR_CMD_RDSR                        = 0x05U,
    .NOR_CMD_RDID                        = 0x9FU,
    .NOR_CMD_WRITE_VCR                   = 0x85U, // need to confirm
    .NOR_CMD_OCTAL_READ                  = 0x8BU, // OCTAL OUTPUT FAST READ? need to confirm
    .NOR_CMD_READ                        = 0x03U, // READ 1-1-1, 0x00u - fast 1-1-1? need to confirm
    .NOR_CMD_PAGE_PROG                   = 0x02U, // 0x02U - 3B, 0x12 - 4B ? need to confirm
    .NOR_CMD_RDREG                       = 0x00U, // need to confirm
    .NOR_CMD_OCTAL_PROG                  = 0x84U, // need to confirm
    .NOR_CMD_OCTAL_DDR_READ              = 0x9DU, // need to confirm
    .NOR_SR_WIP                          = 0,
    .NOR_RDID_NUM_BYTES                  = 0x5U,
    .NOR_MANF_ID                         = 0x9DU,
    .NOR_DEVICE_ID                       = 0x5A19,
    .NOR_SINGLE_CMD_READ_DUMMY_CYCLE     = 13U, // need to confirm
    .NOR_OCTAL_READ_DUMMY_CYCLE          = 13U, // need to confirm
    .NOR_OCTAL_READ_DUMMY_CYCLE_LC       = 13U, // need to confirm
    .NOR_OCTAL_READ_DUMMY_CYCLE_INDAC    = 13U, // need to confirm
    .NOR_OCTAL_READ_DUMMY_CYCLE_LC_INDAC = 13U, // need to confirm
    .NOR_OCTAL_DDR_CMD_READ_DUMMY_CYCLE  = 13U, // need to confirm
    .NOR_OCTAL_SDR_CMD_READ_DUMMY_CYCLE  = 13U, // need to confirm
    .NOR_WRR_WRITE_TIMEOUT               = (12U * 100U),
    .NOR_BULK_ERASE_TIMEOUT              = (72U * 1000U * 1000U),
    .NOR_PAGE_PROG_TIMEOUT               = 120U, //12U
    .NOR_VREG_ADDR                       = 0x0U, // volatile register address is correct?
    .NOR_CFG2_VREG_ADDR                  = 0x01U, // volatile register for dummy cycle? correct?
    .NOR_CFG3_VREG_ADDR                  = 0x04U, // what address should be for this?
    .NOR_CFG3_NVREG_ADDR                 = 0x00U,
    .NOR_PAGE_SIZE                       = 256U,
};

#define FLASH_SIZE                  (32U * 1024U * 1024U)
#define FLASH_BLOCK_SIZE            (128U * 1024U)
#define FLASH_PAGE_SIZE             (256U)
#define FLASH_NUM_BLOCKS            (FLASH_SIZE / FLASH_BLOCK_SIZE)
#define FLASH_NUM_PAGES_PER_BLOCK   (FLASH_BLOCK_SIZE / FLASH_PAGE_SIZE)

Flash_Attrs gFlashNorXspiAttrs_IS25LX256 =
{
    .deviceId       = 0,  /* filled by Flash_open, after querying the flash */
    .manufacturerId = 0,  /* filled by Flash_open, after querying the flash */
    .driverInstance = 0,  /* filled by SysConfig */
    .flashSize      = FLASH_SIZE,
    .blockCount     = FLASH_NUM_BLOCKS,
    .blockSize      = FLASH_BLOCK_SIZE,
    .pageCount      = FLASH_NUM_PAGES_PER_BLOCK,
    .pageSize       = FLASH_PAGE_SIZE,
    .sectorSize     = 0,  /* NOT USED */
    .sectorCount    = 0,  /* NOT USED */
};

"example.syscfg":

I captured the applied setting when Flash_norXspiOpen() was called, as below. they seemed to be correctly set.

• (1) shows the flash size configuration from "flash_nor_xspi_device_IS25LX256.c".
• (2) shows dtr is enabled, phy is disabled, xferline is 3 (OSPI_XFER_LINES_OCTAL).

Q1) Is there another check-point for this problem? I would like to review with you again about the commands, register address and dummy cycles mapped in "flash_nor_xspi_device_IS25LX256.c", SFDP from TI ospi_flash_diag below, and IS25LX256 datasheet. Could you review these? Please find SFDP below and c file above in this post. For example, XSPI_NOR_CMD_WRREG = 0x00 in SFDP, but I found the datasheet mention 81h for non-volatile register write. I would like to cross-check those with you.

"SFDP" from TI ospi_flash_diag:

[OSPI Flash Diagnostic Test] Starting ...
[OSPI Flash Diagnostic Test] Flash Manufacturer ID : 0x9D
[OSPI Flash Diagnostic Test] Flash Device ID       : 0x5A19
[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                       : 0x6
Number of Parameter Headers in this Table : 2

Types of Additional Parameter Tables in this flash
---------------------------------------------------
4 BYTE ADDRESSING MODE INSTRUCTIONS TABLE

Flash_NorXspiDevDefines gFlashNorXspiDeviceDefines_<part-number> = {

    .XSPI_NOR_CMD_RSTEN = 0x66,
    .XSPI_NOR_CMD_RSTMEM = 0x99,
    .XSPI_NOR_CMD_WREN = 0x06,
    .XSPI_NOR_CMD_WRREG = 0x00,
    .XSPI_NOR_CMD_BULK_ERASE = 0xC7,
    .XSPI_NOR_CMD_SECTOR_ERASE_3B = 0x20,
    .XSPI_NOR_CMD_SECTOR_ERASE_4B = 0x21,
    .XSPI_NOR_CMD_BLOCK_ERASE_3B = 0xD8,
    .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 = 0x00,
    .XSPI_NOR_CMD_RDID = 0x9F,
    .XSPI_NOR_CMD_READ = 0x03,
    .XSPI_NOR_CMD_888_SDR_READ = 0x00,
    .XSPI_NOR_CMD_888_DDR_READ = 0x00,
    .XSPI_NOR_CMD_444_SDR_READ = 0x00,
    .XSPI_NOR_CMD_444_DDR_READ = 0x00,
    .XSPI_NOR_CMD_114_READ = 0x00,
    .XSPI_NOR_SR_WIP = 0,
    .XSPI_NOR_SR_WEL = 0,
    .XSPI_NOR_RDID_NUM_BYTES = 5,
    .XSPI_NOR_MANF_ID = 0x9D,
    .XSPI_NOR_DEVICE_ID = 0x5A19,
    .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 = 0x00,
    .XSPI_NOR_QUAD_CMD_READ_DUMMY_CYCLES = 0x00,
    .XSPI_NOR_OCTAL_READ_DUMMY_CYCLE = 0,
    .XSPI_NOR_OCTAL_READ_DUMMY_CYCLE_LC = 0x00,
    .XSPI_NOR_OCTAL_DDR_RDSR_DUMMY_CYCLE = 0,
    .XSPI_NOR_OCTAL_DDR_RDREG_ADDR_BYTES = 0, 
    .XSPI_NOR_OCTAL_DDR_WRREG_ADDR_BYTES = 0, 
    .XSPI_NOR_OCTAL_DDR_RDVREG_DUMMY_CYCLE = 0, 
    .XSPI_NOR_OCTAL_DDR_RDNVREG_DUMMY_CYCLE = 0, 
    .XSPI_NOR_OCTAL_RDSFDP_DUMMY_CYCLE = 0, 
    .XSPI_NOR_OCTAL_RDSFDP_ADDR_TYPE = 0, 
    .XSPI_NOR_WRR_WRITE_TIMEOUT = 1200,
    .XSPI_NOR_BULK_ERASE_TIMEOUT = 72000000,
    .XSPI_NOR_PAGE_PROG_TIMEOUT = 120,
    .XSPI_NOR_VREG_OFFSET = 0x0,
    .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 = 0x0,
    .XSPI_NOR_DDR_OCTAL_MODE_CFG_BIT_LOCATION = 0x0,
    .XSPI_NOR_DUMMY_CYCLE_CFG_ADDR = 0x0,
    .XSPI_NOR_FLASH_SIZE = 33554432,
    .XSPI_NOR_PAGE_SIZE = 256,
    .XSPI_NOR_BLOCK_SIZE = 131072,
    .XSPI_NOR_SECTOR_SIZE = 4096,
    .addrByteSupport = 1,
    .dtrSupport = 1,
    .qeType = 7,
    .seq444Enable = { 0, 0, 0, 0, 0 },
    .seq444Disable = { 0, 0, 0, 0 },
    .oeType = 0,
    .cmdExtType = 0,
    .byteOrder = 0,
};

All tests have passed!!

Q2) I still want to check with you about the previous question (Q2) in my first post. I found "Flash_norXspiEnableDDR()" has some hard codes for Infineon flash embedded in TI evaluation board. In this function, "regData" is 0x43, and cmd address is 0x00800006 as you can see in the code below. This function is called by Flash_open() if dtr is enabled. Do you think this hard code can be related to the current issue for IS25LX256 flash? if yes, could you guide me on how to change this function? 

Regards,

Moonil

Hi Moonil,

Yes you're right, the current driver function has some hardcoding for the spansion flash. I took a look at the datasheet of the ISSI flash you're using, and seems like for enabling Octal DDR, the bit pattern to be written is 0xE7, to volatile configuration register with address 0x00. Command to write the volatile register is 0x81, and to read would be 0x85. In this function, I think you would have to change

```
regData = 0xE7;
```

AND

```
status = Flash_norXspiCmdWrite(config, 0x81, 0x00, 3, &regData, 1);
```

and rest of the things same. Make sure that after Octal DDR is enabled, everything in controller also should be setup to use this protocol, as in setting the lines, address bytes etc. Let me know if there is any progress after this. You would need to set the right dummy cycles and adjust the RD DATA CAPTURE DELAY also correctly for the reads to work properly. (this should already be part of the driver)


Regards,
Anand M

Moonil,

I want to request for one more piece of data if possible, can you run the ospi_flash_diag again and capture the values of variables gBfpt (of type NorSpi_SfdpBasicFlashParamTable) and g4bait (of type NorSpi_Sfdp4ByteAddressingParamTable) and send here either as a binary dump or text? I am interested in how the octal DDR information is provided in the table.

Regards,
Anand M

Hi Anand,

Thank you for your prompt response with very details.

Anand Mahadevan SS said:

Yes you're right, the current driver function has some hardcoding for the spansion flash. I took a look at the datasheet of the ISSI flash you're using, and seems like for enabling Octal DDR, the bit pattern to be written is 0xE7, to volatile configuration register with address 0x00. Command to write the volatile register is 0x81, and to read would be 0x85. In this function, I think you would have to change

```
regData = 0xE7;
```

AND

```
status = Flash_norXspiCmdWrite(config, 0x81, 0x00, 3, &regData, 1);

When I tried the same test with "regData = 0xE7" and "status = Flash_norXspiCmdWrite(config, 0x81, 0x00, 3, &regData, 1);" as you commented, I was able to see different values like 0x01 and 0xff00 instead of 0x00. But, it still failed to read the correct ID.

Q1) I also updated gFlashNorXspiDeviceDefines_IS25LX256 as below as you pointed out about read/write registers, but some parameters are still questionable to me. Could you please review this table and correct any wrong parameters?

• (1) NOR_CMD_WRREG was changed from 0x00(in SFDP) to 0x81 as you pointed out. 
• (2) NOR_CMD_RDREG was changed from 0x00(in SFDP) to 0x85 as you pointed out, but this conflicted with NOR_CMD_WRITE_VCR. please correct this if this is wrong.
• (2) NOR_SR_WIP is 0 (in SFDP). Is this a correct value? 
• (3) All dummy cycles are 13. Do you think this is enough? what value should be for LC, INDAC, LC_INDAC?
• (4) I would like to cross-check all these addresses with you. could you check whether or not all these are correct?

/cfs-file/__key/communityserver-discussions-components-files/908/flash_5F00_nor_5F00_xspi_5F00_device_5F00_IS25LX256.c

Anand Mahadevan SS said:

You would need to set the right dummy cycles and adjust the RD DATA CAPTURE DELAY also correctly for the reads to work properly. (this should already be part of the driver)

Q2) for "RD DATA CAPTURE DELAY", I found the value is 4U in the existing TI code as below, however, this value becomes a big value after a few minus operation because its data type is unsigned type (uint32). This leads to almost infinite loops of the "while" when failing to read ID. Should we fix this as well? and 4U is correct for "readDataCapDelay" of IS25LX256?

Anand Mahadevan SS said:

I want to request for one more piece of data if possible, can you run the ospi_flash_diag again and capture the values of variables gBfpt (of type NorSpi_SfdpBasicFlashParamTable) and g4bait (of type NorSpi_Sfdp4ByteAddressingParamTable) and send here either as a binary dump or text? I am interested in how the octal DDR information is provided in the table.

Please find the dump files for gBfpt and g4bait below, and also refer to the captured image from ccs.

/cfs-file/__key/communityserver-discussions-components-files/908/gBfpt.dat

/cfs-file/__key/communityserver-discussions-components-files/908/g4bait.dat

Regards,

Moonil

Hi Moonil,

Thanks for the due diligence. I will need one more day to parse the 4 byte addressing table and BFPT data. Meanwhile I can answer Q1 and Q2.

Q1

1) RDREG and WRREG parsing is incorrect in the SDK version you're using. This will be fixed in a newer SDK. 0x81 and 0x85 are the correct values.

2) NOR_SR_WIP should be (1 << 0), again the ospi_flash_diag doesn't print the "1 << " part (bug which is fixed now) so it seems incorrect. You should update the value as (1 << 0) or simply 1.

3) Dummy Cycles matter only in read, and read is done only in DAC mode.  I think the fields which will matter are

NOR_OCTAL_READ_DUMMY_CYCLE
NOR_OCTAL_READ_DUMMY_CYCLE_LC
NOR_OCTAL_DDR_CMD_READ_DUMMY_CYCLE
NOR_SINGLE_CMD_READ_DUMMY_CYCLE

Hi Anand M,

Anand Mahadevan SS said:

I will need one more day to parse the 4 byte addressing table and BFPT data

Thanks for your feedback again and let me wait for your review of BFPT data. 

Anand Mahadevan SS said:

You're right, that is a bug which might put it into infiinte loop if it's not able to read the ID using any of the values from 4 to 1. The bug is fixed in newer SDKs. But if it doesn't find a value within those, then there is some other issue as well. You can try looping from 8 through 0 and change the >= to a >

SDK version 08.00.02.31 is used for our project. yes, I found this fix in 08.00.03.18 but other logic in driver is same. so I think SDK version will not resolve out current issue. please let me know if we need to update SDK with the latest version.

Anand Mahadevan SS said:

2) NOR_SR_WIP should be (1 << 0), again the ospi_flash_diag doesn't print the "1 << " part (bug which is fixed now) so it seems incorrect. You should update the value as (1 << 0) or simply 1.

I tested the same after all change and fix we discussed. but still failed to read ID with them.

so, I also checked some pin signals like spi0_clk, DQ0 and DQ7, using "ospi_flash_daig" and "ospi_flash_io" as below. 

1) ospi_flash_daig (1-1-1 mode): it looks good.

 2) "ospi_flash_io" (8-8-8 mode): it looks a bit weird to me.

Do you think the signal of DQ0 and DQ07 below is problematic? if yes, is this signal related to the parameters set we are discussing? 

FYI, these signals were captured during the code execution (1) below.

I would appreciate it if you share the result of your review BFPT data and your opinion on my question above. 

I think we can also have a call in one or two days to investigate this issue together on my real target. (with sharing my screen using MS Teams). Please let me know when you are available.

Regards,

Moonil

Hi Anand,

Could you let me know if there is any update on this topic at your end?

Regards,

Moonil

Hi Anand,

As we discussed in the debug session, Octal DDR is not working now and so 1s-1s-1s can be a choice for our urgent dev schedule if its speed is not that slow for bootup.

So, I tested 1s-1s-1s mode with "ospi_flash_io" example on the evaluation board (AM2434 EVM). but assert happened as below,

Q1) Could you run opsi_flash_io and reproduce this with 1s-1s-1s mode on evm at your end, and clarify the reason why the assert happen?

I did test the same on the boot modes as below,

1. run “ospi_flash_io” enabling 1s-1s-1s with NO BOOT MODE ("load_dmsc.js" as an initial script in ccs) on our real target --> OK, all tests were passed. (this is the case we tested on our product board in debug session.)
2. run “ospi_flash_io” enabling 1s-1s-1s with NO BOOT MODE on EVM ("load_dmsc.js" as an initial script in ccs) --> NOT OK, (this is the tests we tested on EVM)
3. run “ospi_flash_io” enabling 1s-1s-1s with OSPI BOOT MODE on EVM (“sbl_null” was flashed on evm as it is in SDK) --> NOT OK, Flash open failed.

Q2) I also built/tested SBL_OSPI with enabling 1s-1s-1s mode on evm, SBL is not working as well. Do you think this is caused by the same reason as Q1 or any hw configuration fixed to  Octal DDR mode in EVM?

As we know, we have to rebuild SBL OSPI with 1s-1s-1s mode for our product now. So this issue needs to be clarified urgently.

I am looking for your reply.

Regards

Moonil

Hi Moonil,

All the experts in India are OOO and will be back by Thursday. Apologies for the delay. We will get back to you ASAP.

Thanks and Regards,
Aakash

Hi Aakash,

Thanks for the information again.

Could you please arrange 3rd debug session on Thursday? In this session, we should focus on only 1s-1s-1s mode operation on SBL with EVM and real board.

Please send me the invitation for this meeting. the same time should be okay.

Regards,

Moonil 

Hi Anand and Askash,

I tested 1s-1s-1s mode using applications on our real board as below,

• ospi_flash_io: all tests are passed.
• jtag_uniflash: flash one image and verification success.
• uart_uniflash: NOK, please see below,

So, it is unclear to me yet the reason why uart_uniflash is not working even though it used the same board.lib and syscfg used in ospi_flash_io.

I am wondering if we can trace the code of uart_uniflash app in CCS. Do we need CCS JS for sbl_ospi or uart_uniflash app debugging in CCS? if yes, could you please prepare JS for 3rd debugging session? I would like to check the code of uart_unifalsh in CCS together.

Thanks

Moonil

Hi Moonil,

How are you sure that UART_UNIFLASH is not working..  This seems to me like the Uart UniFlash has not yet started because ROM rejected your sbl_uart_uniflash image. Can you check which OpenSSL version are you using ? Is it OpenSSL 1.1.1k ?

The major difference in SBL Uart UniFlash and SBL Jtag UniFlash is that SBL Jtag Uniflash loads the .out file directly via debug access and does not require ROM to validate that SBL image (which is .tiimage format and a x509 format). Although for your AM243x, it is a GP device and ROM verification should not be mandatory.

Can you also put the device in UART BOOT mode and send a .tiimage via xmodem for SBL NULL ? Do you see any prints in that case ? Can you connect the debugger to R5 core and let us know what is the PC of that core ?

Best Regards,
Aakash

Hi Aakash,

This issue seems to be related to MMCSD in syscfg of uart_uniflash. after I modifed code, syscfg and library as below, it was fixed.

• removed DDR and MMCSD from example.syscfg.
• disabled MMCSD in driver.lib (/* #define DRV_VERSION_MMCSD_V0  */ in soc_config.h)
• modified linker.cmd and file buffer size in main.c accordingly. (replaced DDR address properly. refer to the file linked below)
• /cfs-file/__key/communityserver-discussions-components-files/908/0268.main.c
• /cfs-file/__key/communityserver-discussions-components-files/908/linker.txt

please let me know if my fix will harm any operation.

After this fix, uart_uniflash is working. But I found that it sometimes fails to flash images like the log below. 

Once this failure happened, uart_uniflash was not able to flash images on that area anymore. Only after erasing all by using "jtag_uniflash", it was recovered.

Do you think this can be caused by flash driver configuration in "flash_nor_xspi_device_IS25LX256.c" or our change on "flash_nor_xspi.c" for 1s-1s-1s mode? Do we need to increase a timeout parameter?

Good thing is, today I was able to create sbl with 1s-1s-1s mode and make the system bootup with SPI boot mode on our real board. However, this flash failure seems to happen quite frequently ( 1 failure per 5 tests ) when using uart_uniflash.

Q1) Could you please share any checkpoints on this flash failure?

Q2) Can we add a flash erase command in uart_uniflash to recover this failure like jtag_uniflash? (like modifying cfg file.) because jtag will not be used in our firmware upgrade process.

Regards,

Moonil