• State Resolved
  • Locked Locked
  • Replies 9 replies
  • Subscribers 30 subscribers
  • Views 463 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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.

Original question:

MCU-PLUS-SDK-AM243X: How can I use S25FL512S flash instead of S28HS512T?

MCU-PLUS-SDK-AM243X: custom OSPI flash with AM2434_ALV

Dominik Fischer
Intellectual 480 points
Part Number: MCU-PLUS-SDK-AM243X
Other Parts Discussed in Thread: AM2434, SYSCONFIG

Hello,

We have chosen AM2434_ALV chip and now have a custom eval-board, which uses a OSPI-Flash from Micron. The used Flash is a MT35XU512ABA2G12-0AAT.

I am a ware that we might need to make changes in Flash driver. That's why I tried to execute OSPI Flash Diagnostic tool/project software-dl.ti.com/.../EXAMPLES_DRIVERS_OSPI_FLASH_DIAG.html

However I cannot establish communication with flash, the program is not able to read manufacturer id or device id correctly, read and write tests also fail:

[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:182: OSPI read data mismatch !!!
Some tests have failed!!

From the part number one sees, that this the I/O Pin Configuration Option 2 is selected.
1 = Boot in SDR x1
2 = Boot in DDR x8
could it be a problem, that the flash boots in DDR x8? Any hints on this topics?

Thank you very much!!

Tested with
CCS 12.4
MCU+ SDK 09.00.00.35

I could only get a brief data sheet, here: www.mouser.com/.../mict_s_a0004925991_1-2291093.pdf. However, I got one of a similar chip, hopefully flash commands are also similar: datasheet.octopart.com/MT35XU02GCBA1G12-0AAT-Micron-datasheet-138896808.pdf

  • 0
    TI__Expert 5390 points

    Hi Dominik,

    It is possible that the reason you are seeing this fail is because the diag example actually expects the flash to be in 1s1s1s mode to establish initial communication with it and then print out the SFDP of the flash device. If the flash is already configured in octal ddr mode then the SoC would fail due to the mismatch in communication protocols. 

    If it is not possible to get the SFDP table initially from the flash then I'd like to suggest a few options:

    1) we have a set of instructions in the sdk documentation regarding flash support: AM243x MCU+ SDK: Adding Support For a Custom Flash Device (ti.com). Try going over the steps, but treating this scenario as a "Case 2: Flash Doesn't Support SFDP." This case essentially explains that you need to fill out the flash information in SysConfig manually. After you have this information then you can try running a different flash example, like the io example present in the SDK.

    2) this is more of a question, but have you read through the Flash Selection Guide for the AM243 to see if this flash is compatible with the SoC? I'd check here too to verify that there wouldn't be any other underlying potential conflicts that can occur even after solving the given problem. Link: AM243x OSPI, QSPI Flash Selection Guide

    Please let me know if any of these help or if you need more assistance

    Best,

    Daniel  

  • 0 in reply to Daniel Bermudez
    Intellectual 480 points

    Hi Daniel,

    thanks for your hints. We followed the steps from here "Case 2: Flash Doesn't Support SFDP" and tried to fill out the sysconfig manually. However, we are still stuck, see the following call stack from Board_driversOpen()

    Fullscreen
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    20
    21
    /**
    * These arguments were used when this file was generated. They will be automatically applied on subsequent loads
    * via the GUI or CLI. Run CLI with '--help' for additional information on how to override these arguments.
    * @cliArgs --device "AM243x_ALV_beta" --package "ALV" --part "ALV" --context "r5fss0-0" --product "MCU_PLUS_SDK_AM243x@09.00.00"
    * @versions {"tool":"1.17.0+3128"}
    */
    /**
    * Import the modules used in this configuration.
    */
    const flash = scripting.addModule("/board/flash/flash", {}, false);
    const flash1 = flash.addInstance();
    const clock = scripting.addModule("/kernel/dpl/clock");
    const debug_log = scripting.addModule("/kernel/dpl/debug_log");
    const mpu_armv7 = scripting.addModule("/kernel/dpl/mpu_armv7", {}, false);
    const mpu_armv71 = mpu_armv7.addInstance();
    const mpu_armv72 = mpu_armv7.addInstance();
    const mpu_armv73 = mpu_armv7.addInstance();
    const mpu_armv74 = mpu_armv7.addInstance();
    const mpu_armv75 = mpu_armv7.addInstance();
    XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

    Yes we were aware of the  AM243x OSPI, QSPI Flash Selection Guide, actually we used a Flash mentioned here "MT35XU512ABA"

  • 0 in reply to Dominik Fischer
    TI__Expert 5390 points

    Hi Dominik,

    Do you get the same problem when running a different OSPI example other than the diagnostic? the diag example should not be used in any other mode than 1s1s1s so i believe it would just fail constantly for this flash device

    Can you also try to run the ospi_flash_io example using the SBL NULL? is it possible to change bootmodes in your custom board?

    Best,

    Daniel

  • 0 in reply to Daniel Bermudez
    Intellectual 480 points

    Hi Daniel,

    yes that was already the ospi_flash_io example with the adjusted sysconfig. We did not execute ospi_diag example with changed settings (ospi_diag, would not use Flash_...() funcitons of driver I guess). We can switch boot modes, we have similar dip switches as on a EVM board. Currently we are in Dev Boot mode/No Boot mode and do the initialization manually via ccs scripting.

    I thought for flashing and using the SBL null bootloader we need a working OSPI flash, that's why we currently are doing SOC initialization via CCS scripting

  • +1 in reply to Dominik Fischer
    TI__Expert 5390 points

    Hi Dominik,

    I discussed this issue with the ROM experts and it looks like this kind of device is not supported in our SoC. To be more specific, flash memories that boot by default in 8D mode won't be recognized by our SoC. 

    It is true that this family of devices is mentioned in the Flash Selection Guide, but we were not aware of the possibility of there being a variant that booted in 8d mode out of the box. is it possible for you to switch to a part that starts up in 1S mode and then do the switch to 8D?

    Best,

    Daniel 

  • 0 in reply to Daniel Bermudez
    Intellectual 480 points

    Hi Daniel,

    thank you for the information, that's good to know. We will checkout our possibilities.

    Kind regards

    Dominik

  • 0 in reply to Dominik Fischer
    TI__Expert 5390 points

    Hi Dominik,

    Thank you, I will place a ticket to modify the flash selection guide based on this information. I will be closing this thread now. If you have any other question feel free to open a new thread.

    Best,

    Daniel 

  • 0 in reply to Daniel Bermudez
    Intellectual 480 points

    Just to sum it up: We now switched to MT35XU512ABA1G12-0AAT this chip seems to work, we can execute ospi_diag flash example successfully and get parameters/json printed

  • 0 in reply to Dominik Fischer
    TI__Expert 5390 points

    Hi Dominik,

    Glad to hear that switching the device worked for you, please let us know if you have any further questions

    Best,

    Daniel