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.

TMDSCNCD263P: Why Does the OSPI Flasher Read The EEPROM?

Part Number: TMDSCNCD263P
Other Parts Discussed in Thread: UNIFLASH

Tool/software:

Hello,

Re: project: C:\ti\mcu_plus_sdk_am263px_09_02_00_56\tools\flasher\jtag_uniflash\am263px-cc\r5fss0-0_nortos

In file board.c, function i2c_flash_reset() the code first attempts to read the on board EEPROM. If the EEPROM read is successful (regardless of a legitimate board version or garbage value), the code then does the OSPI flash reset.

QUESTION: Why is the OSPI flash reset dependent on being able to read the EEPROM? I can't see the relevance especially since it doesn't seem to matter what value is read from the EEPROM.

Thank you very much.

  • Hi Kier,

    Depending on the board version, we decide which io-expander is present on the board. Due to availability of the different parts we have different expanders on boards . Then the relevant apis are called.

    For example the recent am263px cc will have OSPI lines directly connected to Flash reset lines, so we will be adding support for that in next sdk release. 

  • I can't see the relevance especially since it doesn't seem to matter what value is read from the EEPROM.

    Why do you think so? We look for the board revision from the eeprom and the respective io-expander is selected.

  • Thank you. I see my mistake now, I did not see that is a different API call for E2 / E1 (Other). I was code blind!

    The background to my question was regarding what I need to consider for a custom flasher for our PCB. If your EEPROM check is to decide which I/O Expander to use then I can just skip this step since we don't have an I/O expander on our PCB.

  • Yes in case your PCB does not have an IO-expander, then the check is not needed.