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.

TMS570LC4357: Can SRAM contents be corrupted by resets?

Part Number: TMS570LC4357

Can SRAM contents be corrupted by resets other than power-on reset?

We want to guarantee that the contents of the SRAM will not be changed after a reset, because we want to use the information from before the reset.

In particular, I'm worried that if a reset occurs while writing to SRAM, the contents will be corrupted.

  • Hello,

    We don't explicitly state/guarantee the content of the SRAM can be preserved after a reset cycle. You should treat the SRAM content as suspect for corruption after a reset cycle and take steps to validate the contents. You can not assume the device will ensure the contents are preserved even if it seems to act like it on the bench.

    A warm reset can be due to various reset events such as OSC fail, watchdog reset, software reset and external reset. Software reset can be controlled by the CPU but others are not.

    When a reset happens in the middle of a write operation to the SRAM, it can result in corruption of the SRAM contents as the timing protocol to the SRAM may not be met.

  • Dear Mr. Wang,

    Thank you for the advice. I understood. I will think other ways.

  • If you are wanting to save a state, so you can pick it up later...

    Consider a small FRAM from Cypress.  They are 8 pin packages and you use SPI to read and write.  Writing 16 bytes is a simple matter of 17 bytes out on spi and then setting /CS again.  Likewise reading.  No waits for things to be stable or anything - very fast.  You can write a state to the device using SPI hundreds of seconds for a century without any problem --Ferroelectric ram doesn't wear out.

    CY15B004 for instance.  (Wish TI had external FRAM parts.)

  • You can also use the on-chip dedicated 128KB data-storage Flash bank for persistent storage.

  • Thank you. However, our hardware has already been fixed.
    We consider to use on-chip peripherals.

  • Thank you.
    It is a strong candidate.