• State TI Thinks Resolved
  • Locked Locked
  • Replies 6 replies
  • Answers 2 answers
  • Subscribers 102 subscribers
  • Views 447 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.

AM6442: PSRAM availability on AM64x

Dominic Rath
Mastermind 6605 points
Part Number: AM6442
Other Parts Discussed in Thread: MSP430FR2100

Dear TI team,

on the AM65x we're using the MCU_PSRAM to preserve data across resets. The AM65x specifically says that the PSRAM is isolated from all types of reset.

The AM64x TRM doesn't mention this specifically, but it has a PSRAMECC0_RAM at 0x0 and a PSRAMECC0_ECC_AGGR, so I'm not sure if it really doesn't have something similar.

  • Does the AM64x have any memory similar to the AM65x's MCU_PSRAM that could be used to preserve some data across resets?

Regards,

Dominic

  • 0
    TI__Expert 8885 points

    Hi Dominic,

    AM64x SoC does not have PSRAM like AM65x.

    Possible options for you to consider:

    1.  a small MCU like the MSP430FR2100

    2. write to OSPI (?)

    Thanks.

  • 0 in reply to Aravind Batni
    Mastermind 6605 points

    Hello Aravind,

    thanks for your reply.

    That's unfortunate, because the PSRAM provided an easily accessible way of preserving data, e.g. in case of a previous exception, that didn't rely on any driver - writing to an EEPROM or OSPI would invoke lots of software, so the PSRAM was a lot more elegant.

    Out of curiosity:

    What is the PSRAMECC0_RAM located at address 0x0 in the AM64x?

    Regards,

    Dominic

  • 0 in reply to Dominic Rath
    TI__Expert 8885 points

    Hi Dominic,

    It is for boot vectors.  It is not for low power / retention of data.  ECC protected memory also gets initialized by reset.

    Thanks.

  • 0 in reply to Aravind Batni
    Mastermind 6605 points

    Hello Aravind,

    that's very unfortunate.

    Our application requires having a fallback copy of the application, and since the application and the SYSFW version need to match, we also have a fallback bootloader. Because the AM65x (like the AM64x) can only have a backup boot address in xSPI at +4MB, which is very inconvenient for our 16 MB NOR flash, we have a pre-bootloader that runs without loading a SYSFW and whose job it is to verify and load the actual bootloader. If the actual bootloader or the application want to boot to "the other" copy, it updates PSRAM content and triggers a reboot. The pre-bootloader reads from PSRAM, and boots the desired bootloader, which subsequently boots the desired application.

    The issue with using some memory outside of the AM64x is that the pre-bootloader needs to run without a SYSFW. Without a SYSFW we can't configure clocking for any external interfaces. We could use some location in the xSPI boot flash, but writing that as part of a "normal" bootflow is a risk that we'd like to avoid.

    • Would it be possible to use reset-isolation and the MCU domain to maintain some state across a reset that is good enough to reset the R5f's, most/all of the peripherals, and especially the DMSC?

    Regards,

    Dominic

  • 0 in reply to Dominic Rath
    TI__Expert 8885 points

    Hello Dominic,

    Let me route your question to our boot expert. Please expect response from one of our team members on this.

    Thanks

  • 0 in reply to Aravind Batni
    TI__Guru** 115480 points

    Dominic,

    We are discussing this internally to provide you with some options. Please note that the I2C EEPROM option that Aravind proposed is a valid alternative. You don`t need to setup clocks using SYSFW for I2C as you can set the I2C clock of PLL in bypass if required to read and write from the EEPROM. 

    However, we do understand that having PSRAM is a convenient option to achieve the same so let me discuss this internally and summarize alternatives.

    Regards,

    Rahul