• State TI Thinks Resolved
  • Locked Locked
  • Replies 8 replies
  • Answers 1 answer
  • Subscribers 31 subscribers
  • Views 784 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.

AM2432: OSPI STIG functionality

Leonid Rosenboim
Prodigy 25 points
Part Number: AM2432

For context, this is related to our effort to program our home-made JTAG controller to perform programming of the external SPI NOR-Flash memory used for booting. 

For the sake of simplicity, we are tending to prefer to use STIG mode exclusively for this purpose.

Reading through the documentation, there seem to be room to improve the clarify and technical accuracy of the TRM verbiage.

More specifically, the following paragraph is unclear:

12.3.2.4.11 OSPI Software-Triggered Instruction Generator (STIG) 

The OSPI_FLASH_CMD_CTRL_REG[31-24] CMD_OPCODE_FLD bits should be set different than OSPI_DEV_INSTR_RD_CONFIG_REG[7-0] RD_OPCODE_NON_XIP_FLD and OSPI_DEV_INSTR_WR_CONFIG_REG[7-0] WR_OPCODE_FLD. 

  1. What is the reason the CMD_OPCODE_FLD should be different than WR_OPCODE_FLD, RD_OPCODE_NON_XIP_FLD ?
  2. How strict is this requirement/recommendation?
  3. What will be the impact in case this requirement/recommendation is not adhered to?
  • 0
    Prodigy 25 points

    The notice regarding command op-code in the STIG CMD_OPCODE_FLD to not be equal to the DA/INDAC opcodes is again reiterated here, but without any details on hwhat behavior to expect if this requirement is not followed, or now to work around this if one choses to use STIG for all operations including reading the Flash array and programming it.

    12.3.2.5.2 Configuring the OSPI Controller for Optimal Use Note

    When using the OSPI Controller, the opcodes in OSPI_DEV_INSTR_RD_CONFIG_REG[7-0] RD_OPCODE_NON_XIP_FLD, OSPI_DEV_INSTR_WR_CONFIG_REG[7-0] WR_OPCODE_FLD and OSPI_WRITE_COMPLETION_CTRL_REG[7-0] OPCODE_FLD bit fields shall not match the opcode in the OSPI_FLASH_CMD_CTRL_REG[31-24] CMD_OPCODE_FLD bit field.

    Another question that is forming now is how does OSPI control the Chip Select (CS#) signals.
    Assuming we only have a single device connected to the CS0# signal.

    The configuration register OSPI_CONFIG_REG[PERIPH_CS_LINES_FLD] field is programmed with '0xE' to drive CS0# low, but it is unclear from the functional description if this fields needs to be manipulated by the JTAG controller before and after every Flash operation, or does the OSPI activate and deactivate these signals automatically at the start and end of each Flash operation?

    Definition of register  OSPI_DEV_DELAY_REG does suggest that CS# is turned on and off automatically, but does not elaborate if this works in STIG mode as well as in DAC/INDAC modes, hence the question.

  • 0 in reply to Leonid Rosenboim
    TI__Mastermind 26025 points

    Hi ,

    Our Subject Matter Expert is OOO and is expected to be back after the holidays. So please expect some delay in response.

    Best Regards,
    Aakash

  • 0 in reply to Aakash Kedia
    TI__Expert 5770 points

    Hi Leonid,

    The chip select signal is handled by the OSPI controller during the operation and it should still be during STIG mode as well all other modes.

    Leonid Rosenboim said:

    12.3.2.4.11 OSPI Software-Triggered Instruction Generator (STIG) 

    The OSPI_FLASH_CMD_CTRL_REG[31-24] CMD_OPCODE_FLD bits should be set different than OSPI_DEV_INSTR_RD_CONFIG_REG[7-0] RD_OPCODE_NON_XIP_FLD and OSPI_DEV_INSTR_WR_CONFIG_REG[7-0] WR_OPCODE_FLD. 

    1. What is the reason the CMD_OPCODE_FLD should be different than WR_OPCODE_FLD, RD_OPCODE_NON_XIP_FLD ?
    2. How strict is this requirement/recommendation?
    3. What will be the impact in case this requirement/recommendation is not adhered to?

    It's true that this is not specific in our collateral, I have reached out to the design owner and I should have an answer to your question by tomorrow. Thank you for your patience on this.

    Best,

    Daniel 

  • 0 in reply to Daniel Bermudez
    TI__Expert 5770 points

    Hi Leonid,

    Unfortunately, we were not able to find the answer to your question just yet. Please allow a few more days to allow us to discuss the OSPI spec with design owners as they are currently unavailable. If there is no reply by Friday then please feel free to leave a reply on this post. I will raise urgency on this from my side moving forward

    Best,

    Daniel

  • 0 in reply to Daniel Bermudez
    TI__Expert 5770 points

    Hi Leonid,

    here are the updates on your questions:

    "Why does this requirement exist? what is the reason for why the values in these registers must be different?"

    Basically Flash Command Control Register [31:24], Device Read Instruction Register [7:0] and Device Write Instruction Register [7:0] are used during command phase of OSPI Transaction.

    As the purpose of command code to memory might be different, so they are expected to be different. Flash Command Control Register [31:24] (command code) is used for Register read or Register write or erase portion of memory etc. which are not supported Device Read or Write Instruction Registers.

    "How strict is this requirement? what would happen if this is not met?"

    From Controller point of view, this is not a strict requirement. However, we need to see this from the OSPI Memory Standpoint.

    In general, OSPI Memory is agnostic to mode Controller configured like STIG or DIRECT etc. Therefore, memory is going to see OSPI transaction as presented on OSPI Interface. And quite frankly, we do not expect memory using same command code for different operations. For example, command code programmed into Device Write Instruction Register [7:0] will be used for Flash Memory Program Operation and we do not expect same command code can be used for Flash Memory Register Write. Therefore, we expect command codes programmed in Flash Command Control Register [31:24], Device Write Instruction [7:0] Register and Device Read Instruction [7:0] Register to be different. Nevertheless, if you have got such memory which has same command code for Register Write and Program, we recommend verifying operation in functional verification.

    Best,

    Daniel

     

  • 0 in reply to Daniel Bermudez
    Prodigy 25 points

    Daniel, thank you for taking the time to compose this very diplomatic but technically unhelpful response.

    Our objective is to use STIG for all the commands needed to program an external Flash memory via the JTAG interface, which we view as a simpler alternative than using a combination of STIG (for erase) and Direct-Command mode for programming.

    Your suggestion to perform "functional verification" seems to translate to "just give it a try and see what happens" is exactly what we are trying to avoid - often things that seem to work at one particular time, while not officially supported by the vendor, may stop working at a later point.

    What is more worrisome is that your description seems to suggest that using STIG for Program commands might not work even if we change the values of INSTR_RD_CONFIG, INSTR_WR_CONFIG registers (as suggested by the documentation) to avoid conflict with the op-codes used during STIG.

    We would really appreciate feedback from a person who really understands the design of the OSPI Flash controller and can shed light on the design considerations involved in this topic.

  • 0 in reply to Leonid Rosenboim
    TI__Expert 5770 points

    Hi Leonid,

    I'll make sure to pull more experts into this issue. We also need the following clarification:

    Leonid Rosenboim said:
    Our objective is to use STIG for all the commands needed to program an external Flash memory via the JTAG interface, which we view as a simpler alternative than using a combination of STIG (for erase) and Direct-Command mode for programming.

    When talking about "Direct-Command" mode for programming are you talking about the DAC mode of operation in the IP?

    I will verify again with experts, but I don't believe it is possible avoid using DAC/INDAC altogether since you would need to use these modes of operation to send data to flash.

    In apologize if I'm deviating from the main question at hand. I'm just trying to understand better your goal here so see how we can help you further with this issue.

    Best,

    Daniel

  • 0 in reply to Daniel Bermudez
    TI__Expert 5770 points

    Hi Leonid,

    I got some updates from my side.

    It looks like from the Controller design perspective, command codes from Device Read/Write Instruction Register (DAC/INDAC) and the FLASH Command Control Register do not conflict with each other. There are some internal data path decision and control path decision based on command codes, but there are no contradicting decisions taken by hardware for opcode values in these registers.

    This means that even if software sets up same command opcode in Device Read Instruction Register and Flash Command Control Register with same value, hardware processing of commands will be same seen at OSPI Interface, so the requirement for not having same command code in the Device Write/Read Instruction Register and the Flash Command Control Register is from the standpoint of the OSPI memory rather than a requirement from the Controller.

    Unfortunately we don't have data on what kind of behavior would present in the flash memory if this requirement is not met, but taking Controller failures out of the equation leads me to believe that the flash would either would execute the incorrect commands when the controller issues the corresponding command control/read/write with the incorrect opcodes in their expected fields, assuming the values in all these registers are the same at any point during the communication between flash and processor.

    Please let me know if this helps and if you need any further information on this matter.

    Best,

    Daniel