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.

LP-AM243: OSPI bootloader SPI PHY enabling failed

Part Number: LP-AM243
Other Parts Discussed in Thread: UNIFLASH, TMDS243EVM

Tool/software:

I am flashing the LP-AM243 (PROC109A(001), PCB date code 4023) with the stock SBL OSPI tiboot3.bin file from MCU+ SDK V9.1.2.5. Upon power-cycle, the CCS terminal reports:

ERROR: Flash_norOspiOpen:1269: Flash_norOspiOpen : PHY enabling failed!!! Continuing without PHY...
ERROR: Board_flashOpen:201: FLASH open failed for instance 0 !!!
ASSERT: 0.134840s: ../main.c:main:116: status == SystemP_SUCCESS failed !!!

I imported the project and disabled the "Enable PHY mode" option. The CCS terminal now reports:

DMSC Firmware Version 9.2.8--v09.02.08 (Kool Koala)
DMSC Firmware revision 0x9
DMSC ABI revision 3.1

Unfortunately, the bootloader appears to hang and never transitions to the application.

I have also tried the tiboot3.bin file from MCU+ SDK V11.1.0.17 and observed the same failure. I have qty 3 of the LP-AM243 boards and they all have the same failure.

I can successfully load and run my application via XDS110 JTAG. I have no problem flashing the other SBL bootloaders (NULL, UART, UART UniFlash) and these bootloaders run without issue. I also have a TMDS243EVM and can flash the SBL OSPI bootloader and run it successfully. The problem is only with the OSPI bootloader for the LP-AM243.

Can someone explain the SPI PHY enable failure? Does anyone have success or failure with the SBL OSPI with the LP-AM243 (specifically with date code 4023)?

  • A developer from a different company confirmed that they were able to successfully flash the exact same tiboot3.bin file (with my application) and run it successfully it on their LP-AM234 (PROC109A(001), PCB date code 2423). Unfortunately, the only obvious difference I can see at the moment is the PCB date code. 

  • Here is the call stack. On line#1241, the attackVectorStatus returned -1. Lines#1249 to 1255 were executed. Line#1255, the attackVectorstatus returned -1 again. The program will eventually execute line#1269 and generate the CCS terminal message: "ERROR: Flash_norOspiOpen:1269: Flash_norOspiOpen : PHY enabling failed!!! Continuing without PHY..."

  • Here is the call stack inside of OSPI_phyReadAttackVector(). After the call to OSPI_enableDacMode(), the Memory Browser shows the data of the QSPI flash chip. I confirmed that the boot and app firmware images match the SPI data in memory locations 0x60000000 and 0x60080000. In the image below, the Memory Browser is showing the data starting at address 0x62000000. It's all FFs so it doesn't match the gOspiFlashAttackVector pattern and fails. Is 0x62000000 the correct address for the attack vector?

  • Hi,

    Looks like the phy tuning data is not present on the flash.

    Hence we need to put it there.

    Firstly, if the AM243-LP TI EVM you have got is having the S25HL512T flash part by default, then we are good to go ahead with.

    All we need to do is introduce this line in the cfg file while flashing the other binaries.

    Please refer this FAQ to understand about what line I am referring to:  [FAQ] SK-AM64B: What is the purpose of --operation=flash-phy-tuning-data ? 

    In case you have a different flash, then let me know. Also let me know how you are flashing? I am assuming using the python uart_uniflash.py command and providing the cfg file along with COM<X> port number.

    Thanks,

    Vaibhav

  • Hello Vaibhav,

    Before I try your suggestion, I saved the entire QSPI flash data using the Memory Browser and found the PHY tuning data at addresses 0x6001E8D3 and 0x60083967.

    The LP-AM243 uses the S25HL512T flash part. I'll add the line and report back asap. I was using the python uart_uniflash.py command but switched to UniFlash (V9.2.0.5300) as it was more convenient. Thanks.

  • Using the default_sbl_ospi.cfg solved the problem. I was originally using the python uart_uniflash.py command to flash the NULL bootloader to allow JTAG debug from CCS. After that, I used the UniFlash tool to flash the boot and app firmware. Apparently, the UniFlash tool does not have an option to perform the PHY data tuning (or at least I couldn't find it) so the default_sbl_ospi.cfg must be run once to perform the PHY data tuning. Thanks for your help.

  • Hi,

    I am glad that the FAQ helped in resolving your issue.

    Thanks for marking the above response as resolved.

    Closing the thread.

    Thanks,

    Vaibhav