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.

TMDS243GPEVM: OSPI BOOT issue

Part Number: TMDS243GPEVM

Our customer sees OSPI boot fail on TMDS243GPEVM.

In the following procedure, after successful flashing by UART boot, nothing is output on the UART terminal by OSPI boot.

software-dl.ti.com/.../EVM_SETUP_PAGE.html

When using other boards (TMDS243GPEVM or TMDS64GPEVM), our customer can see the output on the UART terminal by the same procedure.

On any board, the BOOTMODE value in both the CTRLMMR_MAIN_DEVSTAT register (4300 0030h) and the CTRLMMR_MAIN_BOOTCFG register (4300 0034h) shows "0000 0273h".

Incidentally, SOC Initialization using CCS Scripting can be successfully performed in the following procedure.

software-dl.ti.com/.../EVM_SETUP_PAGE.html

If the EVM is broken, our customer wants to replace it with a new one.

Best regards,

Daisuke

  • Hi  san,

    Can you please check and run OSPI_DIAG example on the EVM where the boot is failing. This is to check if the flash part is corrupted or not.

    After this we may check Boot Mode Settings and debug even more.

    Best Regards,
    Aakash

  • Hi Aakash-san,

    Thank you for you reply.

    I ran and checked the OSPI_DIAG example and some tests failed by read data mismatch.

    [OSPI Flash Diagnostic Test] Starting ...
    [OSPI Flash Diagnostic Test] Flash Manufacturer ID : 0xA0
    [OSPI Flash Diagnostic Test] Flash Device ID : 0xF039
    [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:181: OSPI read data mismatch !!!
    Some tests have failed!!

    Best regards,

    Daisuke

  • Hi ,

    The diagnostic example works at 1s1s1s mode which is very basic mode and does not require complex software. If this is not working as expected, seems like there can be issues with the hardware as well.

    Best Regards,
    Aakash

  • Hi Aakash-san,

    Thank you for you reply.

    Should I investigate further to clarify the issue?

    As indicated in my question in another thread, the TMDS243GPEVM used by our customer seems to be the new revision "PROC101B (002)".

    e2e.ti.com/.../tmds243gpevm-implementation-for-dqs-and-lbclk-in-ospi

    Has any hardware changed for the new revision "PROC101B (002)"?

    Best regards,

    Daisuke

  • Hi -san,

    The query mentioned above is already assigned to experts, they will be coming back to you shortly on that.

    Should I investigate further to clarify the issue?

    The diagnostic example uses 1s1s1s mode. There is a single data line being used. If that is not working, this seems to be more on hardware end. You can raise a new query to ask specific queries regarding the hardware.

    Best Regards,
    Aakash

  • Hi Aakash-san,

    Thank you for you reply.

    I also ran and checked the "OSPI Flash IO" example and all tests pass.

    software-dl.ti.com/.../EXAMPLES_DRIVERS_OSPI_FLASH_IO.html

    On the other hand, when I ran and checked each of the two examples on the TMDS64GPEVM which succeeds OSPI boot, the results were the same as with the TMDS243GPEVM which fails OSPI boot.

    I am confused by these results and am concerned that these examples have not been tested on older or newer revision boards.

    Were the examples tested on all revision boards?

    If not, on which revision boards were the examples in the latest MCU+ SDK (08.04.00.17) tested?

    Can the OSPI_DIAG example pass all tests on TMDS243GPEVM or TMDS64GPEVM board you own?

    Best regards,

    Daisuke

  • Hi Daisuke-san,

    Can you share the revision number of the board for TMDS64GPEVM ? I understand you have a "PROC101B (002)" for TMDS243GPEVM.

    All the tests are run on nightly basis (each night) on all the revisions of the boards.

    Can you share the following details -

    1. What (OSPI related) examples are passing on TMDS243GPEVM ?
    2. What (OSPI related) examples are failing on TMDS243GPEVM ?
    3. What is the flashing mechanism used by the customer ? Is it JTAG based Uniflash or UART based Uniflash or is it a 3rd Party tool ?
    4. Is the Boot Mode checked to be OSPI boot ? Are the TII delivered *.tiimage also not working on the board ?

    Best Regards,
    Aakash

  • Hi Aakash-san,

    Thank you for you reply.

    Can you share the revision number of the board for TMDS64GPEVM ?

    Our TMDS64GPEVM revision is a little older, "PROC101A (001)".

    1. What (OSPI related) examples are passing on TMDS243GPEVM ?

    OSPI Flash IO example passes on TMDS243GPEVM.

    2. What (OSPI related) examples are failing on TMDS243GPEVM ?

    OSPI_DIAG example fails on TMDS243GPEVM.

    3. What is the flashing mechanism used by the customer ? Is it JTAG based Uniflash or UART based Uniflash or is it a 3rd Party tool ?

    We follow the steps in the link below to flash the SOC initialization binary to the EVM via UART.

    software-dl.ti.com/.../EVM_SETUP_PAGE.html

    4. Is the Boot Mode checked to be OSPI boot ? Are the TII delivered *.tiimage also not working on the board ?

    We have configured SW2 and SW3 as shown in the above link for OSPI boot, but the SOC initialization binary is not working.

    Best regards,

    Daisuke

  • Hi Daisuke-san,

    Correct me if I am wrong.

    While running the examples of OSPI Flash IO and OSPI_DIAG the boot mode is set as "NO BOOT MODE" and the loading process is as mentioned in the link via CCS.

    If not, can you please try the same.

    On another context of SBL not working - did you try with the same *.tiimage that was delivered OOB by MCU_PLUS_SDK or was the SBL-OSPI example rebuilt on customer's end. If the SBL was rebuilt, then I suggest to check the OpenSSL version on their host machine. The expected OpenSSL version is 1.1.1k

    Best Regards,
    Aakash

  • Hi Aakash-san,

    Thank you for you reply.

    While running the examples of OSPI Flash IO and OSPI_DIAG the boot mode is set as "NO BOOT MODE" and the loading process is as mentioned in the link via CCS.

    When running an example in CCS, we follow the steps in the link below to run the SOC Initialization Script in NO BOOT MODE before loading it.

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

    On another context of SBL not working - did you try with the same *.tiimage that was delivered OOB by MCU_PLUS_SDK or was the SBL-OSPI example rebuilt on customer's end. If the SBL was rebuilt, then I suggest to check the OpenSSL version on their host machine. The expected OpenSSL version is 1.1.1k

    We use the pre-built SOC initialization binary (sbl_null.release.tiimage) with the default configuration file (default_sbl_null.cfg) found below.

    C:\ti\mcu_plus_sdk_am243x_08_04_00_17\tools\boot\sbl_prebuilt\am243x-evm

    As I mentioned in my first post, the SOC initialization binary is working when using other boards (TMDS64GPEVM or other TMDS243GPEVM).

    Best regards,

    Daisuke

  • Hi Aakash-san,

    I changed the boot mode for booting from OSPI flash with the pre-built SOC initialization binary and the booting succeeded.

    The boot mode for booting from OSPI flash in the steps in the link below is xSPI boot and SFDP is enabled (BOOTMODE9 pin = 1) by default.

    software-dl.ti.com/.../EVM_SETUP_PAGE.html

    The booting succeeded after SFDP was set to disabled (BOOTMODE9 pin = 0).

    SFDP in the OSPI flash may be corrupted or may have failed to be read.

    Incidentally, the booting failed after SFDP was set to disabled (BOOTMODE9 pin = 0) and transfer mode was set to 8D-8D-8D (BOOTMODE7 = 1). This also failed on the TMDS64GPEVM.

    Best regards,

    Daisuke

  • Hi Daisuke-san,

    Apologies for the delay. Do you mean for AM243x-EVM the boot only works with SFDP disabled and for AM64x-EVM the boot only works for SFDP enabled ?

    This is very unexpected scenario, I need to discuss this with the ROM team. Let me come back to you on this by Wednesday.

    Best Regards,
    Aakash

  • Hi Aakash-san,

    Thank you for you reply.

    OSPI boot (xSPI boot) results for each board are as follows:

    TMDS243GPEVM ROC101B (002):
    SFDP enabled -> Failed
    SFDP disabled and 1S-1S-1S mode -> Succeeded
    SFDP disabled and 8D-8D-8D mode -> Failed

    TMDS64GPEVM PROC101A (001):
    SFDP enabled -> Succeeded
    SFDP disabled and 1S-1S-1S mode -> Succeeded
    SFDP disabled and 8D-8D-8D mode -> Failed

    Best regards,

    Daisuke

  • Hi Daisuke-san,

    Can you also confirm if the 1s-1s-1s and 8d-8d-8d modes that you have mentioned are the modes set by SBL and not via BOOT MODE ?

    Best Regards,
    Aakash

  • Hi Daisuke-san,

    To rule out the issue in the hardware, can you boot via SFDP disabled and try booting SBL via OSPI mode which is 1s-1s-8s mode. If this works, we will be confident, that the hardware is not the issue here. If it does not, then there is some issue with the EVM here.

    Best Regards,
    Aakash

  • Hi Aakash-san,

    Thank you for you reply.

    OSPI boot (1S-1S-8S mode) results for each board are as follows, all failed:

    TMDS243GPEVM ROC101B (002):
    with Iclock source external -> Failed


    with Iclock source internal (pad loopback) -> Failed


    TMDS64GPEVM PROC101A (001):
    with Iclock source external -> Failed
    with Iclock source internal (pad loopback) -> Failed

    Does EVM really support the OSPI boot (1S-1S-8S mode)?

    Best regards,

    Daisuke

  • Hi Daisuke-san,

    I rechecked the datasheet for the flash and it seems like the flash does not support 1s-1s-8d. Another option would be to probe the AM243x-EVM as I suspect some problem in the datelines.

    I have requested the subject matter expert to comment on this. As he is OOO, please expect some delay in response.

    Best Regards,
    Aakash

  • Hi Aakash-san,

    Thank you for your support.

    I have requested the subject matter expert to comment on this. As he is OOO, please expect some delay in response.

    Have you received any comments from the subject matter expert?

    Best regards,

    Daisuke

  • Hi Daisuke-san

    I apologize for the delay on this, I am looking into your query and will update what I see on the data lines in the next few days. I should have an answer for you between the Monday-Tuesday timeframe.

    We are also working in the meantime on getting you a new board since this one seems faulty. We will reach you with details on this.

    Best,

    Daniel