• State TI Thinks Resolved
  • Locked Locked
  • Replies 5 replies
  • Answers 2 answers
  • Subscribers 16 subscribers
  • Views 857 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.

CCS/CC1352R: Reset behavior

Antoine VENET
Prodigy 250 points
Part Number: CC1352R

Tool/software: Code Composer Studio

Hello,

It seems that the SRAM is not retained when a warn reset occurs (due to watchdog timeout). Could you confirm please ? I don't find this information in the datasheet.

Is there a mean to perform a software reset which retains the SRAM ?

Thank you for your help

Environment

LAUNCHXL-CC1352R1

sdk 2.10.00.48

2.4Ghz IEEE 802.15.4

  • 0
    TI__Mastermind 23730 points
    Hi Antoine,

    SRAM does reset when a warm reset occurs as a result of a Watchdog timeout.

    If you are looking into having retention of data between resets then you could either use AUX RAM (if you're not using the Sensor Controller) or use internal or external NVS storage with the NVS driver.

    How much data do you want in in retention between resets?
  • 0 in reply to Severin Suveren
    Prodigy 250 points

    hello Edvard,

    thank you for your quick answer.

    I need to have retention for all the SRAM (before I use MSP430 where all the SRAM data is kept when a watchdog timeout occurs). I don't want to use neither AUX RAM nor NVS.

    Is there a type of reset where all the SRAM data is kept ? Perhaps I could use a function which forces a reset by setting the PC & SP (Is there a TI function for this ?)

    Other question : If I toggle the reset pin of the CC1352R, the SRAM is also reset ?

    Thank you for your help

     

  • 0 in reply to Antoine VENET
    TI__Mastermind 23730 points
    Why do you want all of SRAM in retention in-between resets? Asking out of curiosity.

    As far as I know it is not possible to keep SRAM from resetting when a reset occurs, including warm reset, as a warm reset is converted to a system reset. Warm reset is considered harmful because it doesn't reset analog parts of the device, such as radio, and doing a warm reset will put the device in a partly unknown state. That is why it is converted to a system reset.

    I guess you're thinking about jumping to the C run-time startup code by setting the PC & SP or something along those lines. There is no TI function for this (driverlib or such), and if there were, you would again face the same problem of putting the device in a partly unknown state.

    Yes, the SRAM is reset with a pin reset as it is a system reset.
  • 0 in reply to Severin Suveren
    Prodigy 250 points
    In my setup, the reset is mainly used to avoid a blocking state of the device (infinite loop, real time isssue,...). For most reset cases I want to keep data from my algorithms /counters/radio neighbor tables stored in SRAM.

    I want to clear my SRAM only if for example I detect a SRAM corruption or if an HW issue occurs.

    I am not sure to understand why the device will be in a partly unknown state if I jump to the C run-time startup code after being blocked in infinite loop (for example).

    To summarize :

    I'd like to have a "software" reset which "just" restart the code (when a software default occurs)
    If a hardware issue occurs (RF core hw issue, hardware initialization issue, ...) it is ok for a system reset.
  • 0 in reply to Antoine VENET
    TI__Mastermind 23730 points

    I have to be frank and say that keeping volatile data between resets sounds like a bad design choice. Again, it sounds like you want NVS. Note that it is possible to have a database-like approach to NVS, where you store data in NVS when appropriate, and fetch data from NVS to SRAM at boot up.

    Problem with jumping straight to C run-time startup code is that a lot of code (drivers, device trim, etc.) assumes HW is reset, in addition to the analog parts not being reset at all. This can cause undefined behavior when doing this kind of "reset".

    I suggest to either use AUX RAM as a volatile "non-volatile" storage, use the NVS driver as mentioned above, or re-design your code where system resets are OK.