MCU-PLUS-SDK-AM243X: SBL_OSPI works only when started after SoC initialization script but it fails when starting from flash

Hi Andrea,

To help me understand your problem better, please let me know the following details:

1. In your custom board, are you using a NOR SPI flash tied to the OSPI IP? Or eMMC? Because SBL OSPI is meant for NOR SPI flashes only. Furthermore, the SBL which ships with the SDK is supposed to work for the OSPI flash in the AM243x EVM (S28HS512T) or AM243x LP (S25HL512T). These are selectable from the sysconfig of SBL OSPI. If you want to support a custom flash, there is a procedure to add that to the SDK - https://software-dl.ti.com/mcu-plus-sdk/esd/AM243X/08_03_00_18/exports/docs/api_guide_am243x/CUSTOM_FLASH_SUPPORT_GUIDE.html . Since your flow works in 8.2 SDK, I assume you have the right flash.

2. The attackVector is supposed to be flashed to the flash device already at the last block's address. The UART based flashing tool has an option to do this, the SBL JTAG doesn't have this option. This is required if you want to have PHY enabled for the OSPI driver. Is there any hurdle regarding using the UART based flashing tool? ( we even have an experimental GUI for this - find the usage link here: https://software-dl.ti.com/mcu-plus-sdk/esd/AM243X/08_03_00_18/exports/docs/api_guide_am243x/TOOLS_FLASH.html#TOOLS_UART_UNIFLASH_GUI
If you don't want to try this, you can disable the PHY in SBL OSPI's sysconfig and see SBL OSPI goes through.

Let me know if writing the attackVector (or disabling PHY if that is not possible) helped you get past the Board_driversOpen().

Also, when you're booting the SBL OSPI directly, keep the Bootloader_socWaitForFWBoot line since it takes 12-13 ms for the SYSFW to initialize and send the boot notification and SBL shouldn't start System_init before that.

Regards,
Anand M

Hi Anand,

   in our custom board we are using  NOR SPI flash of the same type as in your demo board AM243x EVM, so S28HS512T.

At my opinion the problem isn't in the attackVector self, but it is the first reading that the driver is doing at Board_driversOpen().

Here is my test ospi bootloader initiatization part:

int main()
{
    int32_t status;
    volatile int32_t count = 0;
    volatile register int32_t resetForJtag = 0;
    volatile register int32_t startFromCCS = 0;
    volatile register int32_t waitForDebugger = 1;

    Bootloader_profileReset();

    if (!startFromCCS) {
        Bootloader_socWaitForFWBoot();
    }
    Bootloader_profileAddProfilePoint("SYSFW init");

    Bootloader_socOpenFirewalls();

    System_init();
    Bootloader_profileAddProfilePoint("System_init");

    Drivers_open();
    Bootloader_profileAddProfilePoint("Drivers_open");

    #if 1
    DebugP_log("\r\n");
    DebugP_log("Starting OSPI Bootloader\r\n");
    #endif

    while(waitForDebugger);

    status = Board_driversOpen();
    DebugP_assert(status == SystemP_SUCCESS);
    Bootloader_profileAddProfilePoint("Board_driversOpen");

I wanted to test exactely the same code running from flash or from CCS initialization script.

My breakpoint is at line 483 in C:\ti\mcu_plus_sdk_am243x_08_03_00_18\source\board\flash\flash_nor_xspi.c

        /* Enable PHY if attack vector present and PHY mode is enabled */
/*>>>*/ uint32_t phyTuningOffset = Flash_getPhyTuningOffset(config);
        if(OSPI_isPhyEnable(obj->ospiHandle))
        {
            attackVectorStatus = OSPI_phyReadAttackVector(obj->ospiHandle, phyTuningOffset);

            if(attackVectorStatus != SystemP_SUCCESS)
            {
                /* Flash the attack vector to the last block */
                uint32_t blk = 0, page = 0;
                uint32_t phyTuningData = 0,phyTuningDataSize = 0;
                OSPI_phyGetTuningData(&phyTuningData, &phyTuningDataSize);
                Flash_offsetToBlkPage(config, phyTuningOffset, &blk, &page);
                Flash_norXspiErase(config, blk);
                Flash_norXspiWrite(config, phyTuningOffset, (uint8_t *)phyTuningData, phyTuningDataSize);
                attackVectorStatus = OSPI_phyReadAttackVector(obj->ospiHandle, phyTuningOffset);
            }

            if(attackVectorStatus == SystemP_SUCCESS)
            {
                status += OSPI_phyTuneDDR(obj->ospiHandle, phyTuningOffset);
                if(status == SystemP_SUCCESS)
                {
                    obj->phyEnable = TRUE;
                    OSPI_setPhyEnableSuccess(obj->ospiHandle, TRUE);
                }
            }
            else
            {
                DebugP_logError("%s : PHY enabling failed!!! Continuing without PHY...\r\n", __func__);
                obj->phyEnable = FALSE;
                OSPI_setPhyEnableSuccess(obj->ospiHandle, FALSE);
            }
        }

1) CASE RUNNING FROM CCS

Our board is always set in OSPI boot mode but we can disable the flash power with a switch to let the ROM code to fallback in NoBoot mode.

• I set the switch to disable flash power supply
• I turn POWER ON
• I use loadJs from CCS script console to initializate SysFw
• I set the switch to enable flash power supply
• I load my ospi bootloader
• I set variable startFromCCS to 1 in order to skip Bootloader_socWaitForFWBoot()
• I set variable waitForDebugger to 0 in order to don't wait into the while loop
• I set a breakpoint at line 483 in flash_nor_xspi.c
• When the execution flow passes from
            attackVectorStatus = OSPI_phyReadAttackVector(obj->ospiHandle, phyTuningOffset);
  it will read successfully the attackVector and attackVectorStatus will become zero

2) CASE RUNNING FROM FLASH

I used JTAG uniflash tool to flash ospi bootloader debug tiimage at the beginning of the flash (offset 0x0).

Our board doesn't have a UART (in production version) so jtag is the only way to connect to when the flash is empty.

• I set the switch to enable flash power supply
• I turn POWER ON
• I start a debug session in CCS and I connect to the R5 core 0-0
• I load the symbols
• I find the debugger stopped at the while loop, so I set the variable waitForDebugger to 0 in order to exit
• I set a breakpoint at line 483 in flash_nor_xspi.c
• When the execution flow passes from
            attackVectorStatus = OSPI_phyReadAttackVector(obj->ospiHandle, phyTuningOffset);
  it will fail and attackVectorStatus will become -1
• The code execution will continue trying to write into the last block of the flash a new attackVector
• Then in the code there is a new call trying to read the attackVector just written and it fails again !

I hope this can help you to discover which is the reason why the flash seams not readable in case 2.

Previous SDK 08.02.00.31 isn't affected by this issue and ospi bootloader runs from flash like a charm.

Looking forward

    Andrea

Hi Anand,

  any news about this issue ?

Looking forward

   Andrea