LP-AM243: Unable to open OSPI Flash on LP after working with Beckhoff EtherCat Slave Stack (LP Bricked)

Oh, the Hello World with OSPI flash reports:

ERROR: Board_flashOpen:98: FLASH open failed for instance 0 !!!

Hi

Steve Squires said:

I have been working on the Beckhoff EtherCat slave stack. Specifically, I have been changing the contents of the slave EEPROM (which is emulated and stored in the OSPI Flash) using an EtherCAT master.

Are you talking about "examples\industrial_comms\ethercat_slave_beckhoff_ssc_demo" here? This example does not use flash for saving EEPROM contents. Flash is used for FoE  (Filetransfer over EtherCAT) feature.

If you are talking about "examples\industrial_comms\ethercat_slave_demo", it uses flash for saving EEPROM contents as you mentioned. But the flash offset used by EtherCAT example is different from what the bootloader uses.

Steve Squires said:

However, after doing this for a couple of times, the OSPI Flash no longer opens and the LP is 'bricked'. Even if I take the Hello World example and add Flash via Syscfg, the board initialisation fails

Can you share the .syscfg file which you have updated? Which "Flash Device" are you selecting in SysConfig?

Steve Squires said:

I am also unable to re-initialise the LP using the EVM setup process - it hangs on the second step (see image below).

Can you confirm if you are following all the steps mentioned here? Have you made any changes to "tools\boot\sbl_prebuilt\am243x-lp\default_sbl_null.cfg" file?

https://software-dl.ti.com/mcu-plus-sdk/esd/AM243X/08_02_00_31/exports/docs/api_guide_am243x/EVM_SETUP_PAGE.html#EVM_FLASH_SOC_INIT

Regards
Dhaval Khandla

Hi Dhaval,

I'm using the demo from:

C:\ti\mcu_plus_sdk_am243x_08_02_00_31\examples\industrial_comms\ethercat_slave_beckhoff_ssc_demo

I have been attempting to modify the contents of the EtherCAT slave EEPROM to make it match the ESI file (I'm using the Beckhoff EtherCAT Conformance Test tool). I can change the contents but it seems that this operation subsequently renders the OSPI flash on the LP inoperable. It's happened twice in short succession (I have two dead boards now).

Regarding changes to hello world - see screenshot and zip of syscfg below.

Regarding the steps to reinitialise the LP EVM, they are exactly as you describe.

Thanks, Steve

1738.example.zip

Steve
Thanks for the quick response.

Steve Squires said:

I have been attempting to modify the contents of the EtherCAT slave EEPROM to make it match the ESI file (I'm using the Beckhoff EtherCAT Conformance Test tool). I can change the contents but it seems that this operation subsequently renders the OSPI flash on the LP inoperable. It's happened twice in short succession (I have two dead boards now).

We need to look into this issue. According to me, EtherCAT EEPROM operations are not related to the Flash issue, because this example does not use Flash for EEPROM data. It uses I2C EEPROM.

Can you run the "examples\drivers\ospi\ospi_flash_diag\am243x-lp" example on the board, and share the logs from UART console with us?

Regards
Dhaval Khandla

Hi Dhaval, as below:

[OSPI Flash Diagnostic Test] Starting ...
[OSPI Flash Diagnostic Test] Flash Manufacturer ID : 0x9A
[OSPI Flash Diagnostic Test] Flash Device ID : 0x150D
[OSPI Flash Diagnostic Test] Executing Flash Erase on first block...
[OSPI Flash Diagnostic Test] Done !!!
[OSPI Flash Diagnostic Test] Performing Write-Read Test...
ERROR: ospi_flash_diag_test_compare_buffers:165: OSPI read data mismatch !!!
Some tests have failed!!

Thanks,

Steve

I get the same errors on the other board.

Hi Dhaval, have ordered some replacement flash ICs (and 4 more LPs).

I put a scope on the flash Reset, CS and CLK - all seems in order from a low-level electrical level.

Is there a chance that flash has been accidentally put into write protect mode? Is there a command sequence to 'revive' them? Or do you think that they have failed?

I'm on development line-stop until replacement LPs arrive so any thoughts appreciated.

Thanks, Steve

A bit more info for you Dhaval,

In the Flash Diag example code (ospi_flash_diag.c), after resetting initialising the qspi flash:

/* Initialize the flash device in 1s1s1s mode */
OSPI_norFlashInit1s1s1s(ospiHandle);

The flash Status Register 1 OSPI_NOR_CMD_RDSR returns 0x80 - not busy.

However, after attempting to enable writes (in my debug code):

OSPI_norFlashCmdWrite(ospiHandle, 0x6, 0xFFFFFFFF, NULL, 0);

The flash Status Register 1 OSPI_NOR_CMD_RDSR returns 0x81 (busy) indefinitely meaning wait for ready calls fail with a timeout:

status = OSPI_norFlashWaitReady(ospiHandle, (600U * 1000U));

The same thing happens in the Flash Diag example, code in the call to OSPI_norFlashErase:

DebugP_log("[OSPI Flash Diagnostic Test] Executing Flash Erase on first block...\r\n");
OSPI_norFlashErase(ospiHandle, offset);

Where the return status of OSPI_norFlashErase is NOT checked but is in a non-zero error condition. 

So, in summary, I think the flash's own non-volatile configuration has become corrupted somehow, rendering it inoperable to the normal drivers provided.

Do you have a code snippet to correctly re-configure the flash on the LP?

Thanks, Steve

Hi Dhaval, I am about to have the flash chip replaced as I am unable to proceed.

However, before doing this, I instrumented the flash lines (image below).

The sequence is:

/* Initialize the flash device in 1s1s1s mode */
status = OSPI_norFlashInit1s1s1s(ospiHandle);
status = OSPI_norFlashCmdRead(ospiHandle, 0x05, &readStatus, 1);
status = OSPI_norFlashWaitReady(ospiHandle, (600U * 1000U));

// write enable
status = OSPI_norFlashCmdWrite(ospiHandle, 0x06, 0xFFFFFFFF, NULL, 0);
status = OSPI_norFlashCmdRead(ospiHandle, 0x05, &readStatus, 1);
status = OSPI_norFlashWaitReady(ospiHandle, (600U * 1000U));

The trace starts at // write enable (cmd 0x06) then with reading back the status (cmd 0x05). The status shows bit 0 and 7 set. Bit 7 is the STCFWR means that it should obey the WP# pin. The WP# pin is high throughout so I'm not sure why bit 0 RDYBSY is stuck (the wait function times-out).

I shall now replace the flash (but I do have a second board exhibiting the identical fault).

Thanks, Steve

I have replaced the flash chip - the board appears to work now.

I have had another instance of this error:

ERROR: Board_flashOpen:198: FLASH open failed for instance 0 !!!

This is the third Launchpad that this has happened to.

The only common action is me switching between two example programs: ethercat_slave_beckhoff_ssc_demo_am243x-lp_r5fss0-0_freertos_ti-arm-clang and ethercat_slave_simple_demo_am243x-lp_r5fss0-0_freertos_ti-arm-clang.

However, this time, ospi_flash_diag_am243x-lp_r5fss0-0_nortos_ti-arm-clang works:

[OSPI Flash Diagnostic Test] Starting ...
[OSPI Flash Diagnostic Test] Flash Manufacturer ID : 0x9A
[OSPI Flash Diagnostic Test] Flash Device ID       : 0x150D
[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 : 4

Types of Additional Parameter Tables in this flash
---------------------------------------------------
4 BYTE ADDRESSING MODE INSTRUCTIONS TABLE
SECTOR MAP TABLE
STATUS CONTROL AND CONFIGURATION REGISTER MAP 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 = 0x71,
    .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 = 0x65,
    .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 = 0xEB,
    .XSPI_NOR_CMD_444_DDR_READ = 0x00,
    .XSPI_NOR_CMD_114_READ = 0x6B,
    .XSPI_NOR_SR_WIP = 1,
    .XSPI_NOR_SR_WEL = 2,
    .XSPI_NOR_RDID_NUM_BYTES = 5,
    .XSPI_NOR_MANF_ID = 0x9A,
    .XSPI_NOR_DEVICE_ID = 0x150D,
    .XSPI_NOR_114_READ_MODE_CLKS = 0,
    .XSPI_NOR_114_READ_DUMMY_CYCLES = 8,
    .XSPI_NOR_444_READ_MODE_CLKS = 2,
    .XSPI_NOR_444_READ_DUMMY_CYCLES = 8,
    .XSPI_NOR_444_READ_DUMMY_CYCLES_LC = 0x08,
    .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 = 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 = 0x3,
    .XSPI_NOR_QUAD_MODE_CFG_BIT_LOCATION = 0x6,
    .XSPI_NOR_DDR_OCTAL_MODE_CFG_ADDR = 0x0,
    .XSPI_NOR_DDR_OCTAL_MODE_CFG_BIT_LOCATION = 0x0,
    .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 = 5,
    .seq444Enable = { 0, 0, 0, 1, 0 },
    .seq444Disable = { 0, 0, 1, 1 },
    .oeType = 0,
    .cmdExtType = 0,
    .byteOrder = 0,
};

All tests have passed!!

BUT, for example, ospi_flash_io_am243x-lp_r5fss0-0_nortos_ti-arm-clang fails:

[MAIN_Cortex_R5_0_0] ERROR: Board_flashOpen:98: FLASH open failed for instance 0 !!!
ASSERT: 3.616962s: ../ospi_flash_io.c:ospi_flash_io_main:58: status==SystemP_SUCCESS failed !!!

What's 'bricking' my Launchpads??

Thanks for your urgent response.

Steve

To be clear, I am running the Beckhoff EtherCAT Conformance Test Tool on the slaves (I'm trying to make the TI examples fully-compliant - which they are not!).

Steve

Nudge. Any ideas?

Our EtherCAT development has halted until we have a solution - we only have a finite supply of Launchpads.

Thanks, Steve

Hi

Steve Squires said:

(I'm trying to make the TI examples fully-compliant - which they are not!).

Can you provide more details on this?

Regards

Dhaval Khandla

Hi Dhaval - I am expecting some more LPs this week and will send you the non-compliance report.

Thanks, Steve