• State Resolved
  • Locked Locked
  • Replies 5 replies
  • Subscribers 33 subscribers
  • Views 367 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.

AM263P4: How should OSPI flash reset line connect to AM263P4?

Andy MacGregor
Intellectual 257 points
Part Number: AM263P4

Tool/software:

My team is building a custom board based on the AM263P4. We plan on using the IS25LX256-JHLE OSPI external flash chip.
On our board, we will only use flash for loading program data at boot time (we do not use XIP) and for writing new program images with in-app update.
We are planning to connect the RESET# pin on the OSPI flash chip to the AM263P4 WARMRSTn output. We are pretty confident that this will work for our application. However I see that there are several AM263P4 reference schematics available which connect the OSPI flash reset signal differently which gives me pause.
Can you advise us if directly connecting the OSPI flash RESET# to the AM2634P WARMRSTn output is sufficient?
We're basing this decision on the following: AM263P Technical Reference manual Figure 6-15 shows that the AM2634P internally comes out of reset 128us (WARM_RSTTIME2) after WARMRST assertion. The IS25LX256-JHLE shows that the flash chip will recover from reset in 40ns while idle in standby mode, which is typically the state of the flash chip in our application. 
However the *worst case* reset recovery for the flash chip is 1s (if reset occurs while executing a sector erase command). I think if this were to happen, the ROM bootloader would fail to read OSPI flash then attempt to load the SBL, which is fine. However if the ROM bootloader continuously asserts WARMRSTn I think there could be problems as the flash chip may not be able to recover without a power cycle.
  • +1
    TI__Expert 3140 points

    Hi Andy,

    Thank you for the query.

    Andy MacGregor said:
    for writing new program images with in-app update.

    From my understanding, In -app update needs a Read-While Write flash part(RWW). IS25LX256-JHLE is standard part. You will need to use  IS25LX256-LHLE - RWW part as per ISSI datasheet.

    Andy MacGregor said:
    Can you advise us if directly connecting the OSPI flash RESET# to the AM2634P WARMRSTn output is sufficient?

    Yes , This is sufficient for majority of the cases as explained by you.


    I will need to confirm the *worst_case* scenario from the HW engineer. I will get back on this.


    Thanks & Regards,
    Rijohn

  • +1 in reply to Rijohn Pius
    TI__Intellectual 1890 points

    Hi Andy,

    Adding on to what Rijohn mentioned above, I would suggest connecting the RESET# pin of flash in a similar manner to what is done on our EVMs by passing both the WARMRSTn and OSPI0_RESET_OUT0 (from AM263Px) through an OR logic(since these resets are active low, use AND gate) to generate a reset for RESET# pin. This is needed since if there is any case where the OSPI flash needs to be reset but the AM263Px controller is not to be reset, then this OR logic would be needed. So, we would recommend using both WARMRSTn and OSPI0_RESET_OUT0 for the RESET# logic.

    Andy MacGregor said:
    I think if this were to happen, the ROM bootloader would fail to read OSPI flash then attempt to load the SBL, which is fine

    Can you please elaborate on the above?

    Because if ROM bootloader were to fail to Read OSPI in the sector being erased, it would try to boot from the Redundant boot locations as seen in below Table 5-10 from AM263P Technical reference manual.

    Thanks,
    Tejas Kulakarni

  • 0
    Intellectual 257 points

    Rijohn, Tejas,

    Thank you for the detailed responses. I see the use case for connecting OSPI0_RESET_OUT0 by logic OR gate, and will note it going forwards.


    >> I think if this were to happen, the ROM bootloader would fail to read OSPI flash then attempt to load the SBL, which is fine

    > Can you please elaborate on the above?

    Sure I can be clearer.

    We set Boot mode pins to OSPI Read with UART fallback. I think the worst case scenario would be if the AM263 issues a command to erase a flash sector, then AM263 resets. That would trigger the flash to reset by WARMRSTn output, and the flash chip should take 1s to recover from reset. During that 1s period, I believe the flash chip will not respond to *any* commands. So In that case I expect the RBL attempt to read the SBL from all 4 fallback addresses and fail every time because the flash chip is not responding. Then I expect RBL to switch to UART fallback boot mode; from there we can recover the system.

  • 0 in reply to Rijohn Pius
    Intellectual 257 points

    About the LHLE part. Our app does not use XIP flash. I think we would only need the LHLE for RWW flash operations if we needed to support in-app update and XIP. Is there another use case where we would need the RWW operation?

  • +1 in reply to Andy MacGregor
    TI__Expert 3140 points
    Andy MacGregor said:
    Is there another use case where we would need the RWW operation?

    No Andy, RWW is used primary for OTA application