• State TI Thinks Resolved
  • Locked Locked
  • Replies 6 replies
  • Answers 1 answer
  • Subscribers 31 subscribers
  • Views 461 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

TMDS243EVM: OSPI Flash Diagnostic fails

Lars Stein
Prodigy 50 points
Part Number: TMDS243EVM
Other Parts Discussed in Thread: LP-AM243

Hi experts,

I am trying to run the SDK example "OSPI Flash Diagnostic" on my TMDS243EVM board.

Unfortunatly some tests failed and the output is:

[MAIN_Cortex_R5_0_0] [OSPI Flash Diagnostic Test] Starting ...
[OSPI Flash Diagnostic Test] Flash Manufacturer ID : 0xFF
[OSPI Flash Diagnostic Test] Flash Device ID : 0xFFFF
[OSPI Flash Diagnostic Test] Executing Flash Erase on first block...
[OSPI Flash Diagnostic Test] Erase Failed !!!
[OSPI Flash Diagnostic Test] Performing Write-Read Test...
[OSPI Flash Diagnostic Test] Wtite Failed !!!
ERROR: ospi_flash_diag_test_compare_buffers:181: OSPI read data mismatch !!!
Some tests have failed!!


I did exactly the same on a LP-AM243 which is working as expected:

[MAIN_Cortex_R5_0_0] [OSPI Flash Diagnostic Test] Starting ...
[OSPI Flash Diagnostic Test] Flash Manufacturer ID : 0x34
[OSPI Flash Diagnostic Test] Flash Device ID : 0x2A1A
[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!
[QSPI 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 Par [...]


What did I miss?

Best regards,
Lars

  • 0
    TI__Expert 7610 points

    Hi Lars, 

    Can you please tell me:

    • the revision of your EVM
    • the sdk version you are using
    • and the bootmode that you have in each platform (LP and EVM)

    Best,

    Daniel

  • 0 in reply to Daniel Bermudez
    Prodigy 50 points

    Hi Daniel,

    thanks for your response.

    Here are the requested informations:

    EVM-Revision: PROC101C(005)
    SDK-Version: 9.01.00.41
    Bootmode (EVM): OSPI Boot Mode (NULL Bootloader)
    Bootmode (LP): QSPI Boot Mode (NULL Bootloader)

  • 0 in reply to Lars Stein
    TI__Expert 7610 points

    Hi Lars, 

    Can you confirm if you are following the steps in this page? AM243x MCU+ SDK: EVM Setup (ti.com)

    To set the EVM to OSPI bootmode, are you using the picture in the page above or following the user guide?

    Best,

    Daniel

  • 0 in reply to Daniel Bermudez
    Prodigy 50 points

    Yes I can confirm that I did the EVM setup following the steps from the SDK online documentation.

    I already recognized that the OSPI boot mode mentioned in the SDK documention for the EVM is the xSPI boot mode mentioned in the TRM. Do I have this right?

    In the meantime I tried the example with Dev-Boot mode and initialized the board with the "load_dmsc_hsfs.js" script. In this configuration the example worked as expected.

    Just from the documention of the example I would expect this behaviour also with OSPI boot mode.

  • 0 in reply to Lars Stein
    TI__Expert 7610 points

    Hi Lars,

    Lars Stein said:
    I already recognized that the OSPI boot mode mentioned in the SDK documention for the EVM is the xSPI boot mode mentioned in the TRM. Do I have this right?

    You are correct on this, you should be using xSPI mode but it looks like that is the case you are observing anyways. 

    I ran the same experiment as you and my results were the same, I was not able to get a pass on the ospi_diag example using the NULL bootloader. I also ran the ospi_flash_io example via the NULL bootloader and I got a pass on that one, so I'm thinking it could be a problem with the example itself.

    I pull the software expert to comment on the discrepancy between the DEVBOOT and SBL NULL flow and why this example is failing in the latter.

    Best,

    Daniel

  • 0 in reply to Lars Stein
    TI__Mastermind 26145 points

    Hi Lars,

    Lars Stein said:
    Just from the documention of the example I would expect this behaviour also with OSPI boot mode.

    This expectation is completely wrong. The diagnostics example works in 1s-1s-1s mode with slowest clock possible where as incase of OSPI Boot Mode, ROM configures the flash into 8d-8d-8d mode (low frequency). Also the SBL OSPI configures the flash into 8d-8d-8d mode (high frequency).

    If your application is expecting a flash usage where you are changing the configuration from SBL to Application you should be resetting the flash as well the controller.

    In case of LP, the mode which works is 4s-4d-4d and comparatively 4s-4d-4d is much simpler protocol so this might have worked but is not the correct flow.

    I hope this helps.

    Best Regards,
    Aakash