• State Resolved
  • Locked Locked
  • Replies 16 replies
  • Answers 1 answer
  • Subscribers 55 subscribers
  • Views 3282 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.

CC2640R2F: Last reset cause when WARM reset converted to system reset ?

Mahesh Pothugunta
Prodigy 170 points
Part Number: CC2640R2F

Hi

I am using BLE Stack 3.1.0 with CC2640R2 SDK 1.50.00.58 in my project

By referring the manual under section 6.7.2  http://www.ti.com/lit/ug/swcu117h/swcu117h.pdf

In the above screen shot, for CC2640R2F board, what is the last reset cause after the device restart due to warm reset ? is it warm or PIN or System reset ?

Regards,

Mahesh

  • 0
    TI__Guru** 105180 points
    Hello Mahesh,

    The reported reset source types are enumerated in the RESETCTL Register, RESET_SRC field. See table Table 6-44 in the above TRM.

    Best wishes
  • 0 in reply to JXS
    Prodigy 170 points

    Hi JXS,

    Does that mean, the last resource will remain the warm reset ? with table 6-44 i do not see the WARM reset ?

    But where as during my test on the board resulting watchdog, the source captured as WARM reset, where as i am expecting that to be either PIN or System reset

    Please do let me know, what should be last reset cause source for the watchdog, as SDK converting warm reset to PIN reset ?

    As per my understanding it should be PIN reset, but not warm reset..

    Please let me know the details at the earliest..


    Regards,
    Mahesh

  • 0 in reply to Mahesh Pothugunta
    Prodigy 195 points

    Hi JXS,

    I even have a query on the same topic,

    From the document mentioned above

    Because warm reset does not reset the analog parts of the device, such as the radio, doing

    a warm reset will put the device in a partly unknown state. It is therefore strongly

    recommended to enable Warm Reset Converted to System Reset feature as described in

    the section above.

    Triggering a warm reset run-time can lead to problems such as unexpected behaviour or

    program freeze. The only situation where it is ok to not enable Warm Reset Converted to

    System Reset is during development and debugging if a SW problem is triggering a warm

    reset. In that situation, not enabling the warm to cold reset feature is typically required to

    identify the reset source.

    Does it mean that the Cortex-M0 will not be reset on warm reset on Cortex-M3 (may be due to watchdog) ?

    If yes is answer for above question,then it indirectly means that warm reset is not a complete reset ,needs a system reset for complete reset of the system.

    Does it has to be done as  a part of application?(may be by detecting last reset source)

    Or can we alter the watchdog code in stack as below?

    From:

    __STATIC_INLINE void
    WatchdogResetEnable(void)
    {
        // Enable the watchdog reset.
        HWREGBITW(WDT_BASE + WDT_O_CTL, WDT_CTL_RESEN_BITN) = 1;
    }

    To

    __STATIC_INLINE void
    WatchdogResetEnable(void)
    {
        // Enable the watchdog reset.

       (HWREG( AON_SYSCTL_BASE + AON_SYSCTL_O_RESETCTL ) |= AON_SYSCTL_RESETCTL_SYSRESET_M);
    }

    Or am i complete wrong???

  • 0 in reply to Mahesh Pothugunta
    Prodigy 170 points

    Hi JXS,

    Could you please update on this ?

    Regards,

    Mahesh

  • 0 in reply to Mahesh Pothugunta
    Guru 86755 points
    Hi Mahesh,

    From my testing the watchdog causes WARM Reset. There is code to convert WARM Reset to System Reset. When I was finalizing my watchdog implementation I was lacking time to implement converting WARM Reset to System Reset. So, I just call HAL_SYSTEM_RESET() at Watchdog Callback.

    -kel
  • 0 in reply to Mahesh Pothugunta
    TI__Guru** 105180 points
    Hello Mahesh,

    Our guidance is to use the default configuration to have warm reset converted to system reset for the reasons listed in the TRM w.r.t analog vs. digital circuitry. As Merkel suggests, invoking a system reset in your WDT callback is preferred as well.

    I don't see your attachment in your OP, can you re-attach?

    Best wishes
  • 0 in reply to JXS
    Prodigy 170 points

    Hi JXS and Kel,

    Thanks for the suggestion to go for the System restart on watchdog, But my concern here is as SDK converting the  all the WARM restart to PIN restart, why should we need to that specifically ? on top of the SDK i set the warm set converted to "HWREG(PRCM_BASE + PRCM_O_WARMRESET) |= PRCM_WARMRESET_WR_TO_PINRESET ;" still i see the WARM restart ?

    I would like get the details on this aspect for my understanding and to solve the issues that are ongoing with watchdog in our project...

    This below point mentioned in the reference manual, under section 6.72 (warm restart) in the note

    "The only situation where it is ok to not enable Warm Reset Converted to

    System Reset is during development and debugging if a SW problem is triggering a warm

    reset. In that situation, not enabling the warm to cold reset feature is typically required to

    identify the reset source."

    With the above statement as SDK is converting warm restart to PIN or system restart, I am expecting the rest source also be PIN restart expected under the above scenario, Please let me know the reason being the last resource cause as warm reset ?

    if reset source will be  WARM reset, that means the documentation has to be corrected right ?

    Please do clarify at the earliest...

    Regards,

    Mahesh

     

  • 0 in reply to Mahesh Pothugunta
    TI__Guru** 105180 points
    Hello Mahesh,

    I'm checking with our TRM team and will get back to you when I have an update.

    Best wishes
  • 0 in reply to Mahesh Pothugunta
    TI__Guru** 106705 points
    Hi Mahesh,

    This is the description of PRCM:WR_TO_PINRESET:

    0: No action
    1: A warm system reset event triggered by the below listed sources will result in an emulated pin reset.
    Warm reset sources included:
    ICEPick sysreset
    System CPU reset request, CPU_SCS:AIRCR.SYSRESETREQ System CPU Lockup
    WDT timeout
    An active ICEPick block system reset will gate all sources except ICEPick sysreset
    SW can read AON_SYSCTL:RESETCTL.RESET_SRC to find the source of the last reset resulting in a full power up sequence. WARMRESET in this register is set in the scenario that WR_TO_PINRESET=1 and one of the above listed sources is triggered.

    Note the last lines explaining that in the case of WR_TO_PINRESET being set to ´1´ (which it is by default, and always should be) and the WD triggering a reset, the reset source will still be reported as a warm reset.

    I belive this is inline with your observations, right?

    Cheers,
    Fredrik
  • 0 in reply to Fredrik K
    Prodigy 170 points

    Hi Fredrik,

    Thanks for the response,

    That means warm reset will be converted to Pin or system or cold restart, but the last reset source will be warm restart

    if that is the case, the manual needs to be updated, this will always the be case, there is no need of specific condition like Debugging or so which is misleading...

    This below point mentioned in the reference manual, under section 6.72 (warm restart) in the note

    "The only situation where it is ok to not enable Warm Reset Converted to

    System Reset is during development and debugging if a SW problem is triggering a warm

    reset. In that situation, not enabling the warm to cold reset feature is typically required to

    identify the reset source."

     

    Please let me know if my understanding is correct here ?

    if that is  the case as per your reply, "if system behaves as it intended to behave"  it matches to my observations...

     

    Regards,

    Mahesh

     

  • 0 in reply to Mahesh Pothugunta
    TI__Guru** 106705 points
    Hi Mahesh,

    The TRM is correct. Warm reset must always be converted to system reset by setting the PRCM:WR_TO_PINRESET bit.

    Cheers,
    Fredrik
  • 0 in reply to Fredrik K
    Prodigy 170 points
    Hi Fredrik,

    I am not denying the fact " Warm reset must always be converted to system reset by setting the PRCM:WR_TO_PINRESET bit" only concern is here on the last reset source, in this condition observing as "WARM reset" but as per manual it will be system restart because we are not running in debugging environment...

    Please refer the section 6.72 (warm reset) again, if TRM is correct

    "The only situation where it is ok to not enable Warm Reset Converted to
    System Reset is during development and debugging if a SW problem is triggering a warm
    reset. In that situation, not enabling the warm to cold reset feature is typically required to
    identify the reset source"

    if TRM is correct that means, during watch dog restart the last reset cause should be system restart , But observing the warm restart a reason

    Could you please let me know, why is this happening ?

    Regards,
    Mahesh
  • 0 in reply to Mahesh Pothugunta
    TI__Guru** 106705 points
    Mahesh,

    This is what I tried to explain in my last post, and is also documented in the PRCM:WR_TO_PINRESET register description.

    When a warm reset is converted to a system reset, the reset source reported is still warm reset. For example: WDT triggers a reset. The reset is converted to a system reset as recommended. The RESET_SRC register still reports warm reset.

    Cheers,
    Fredrik
  • 0 in reply to Fredrik K
    Prodigy 170 points
    Hi Fredrik,

    Thanks for the response, Yes it is documented in the PRCM:WR_TO_PINRESET register description.

    But in TRM, it should not conflicting one place it is clearly mentioned as source will be maintained and one place (6.7.2), where it will be mentioned source will be converted system restart..

    So i feel it should be updated to correct this type of conflicts...

    BTW, I think now you can resolve the issue.

    Regards,
    Mahesh
  • 0 in reply to Mahesh Pothugunta
    TI__Guru** 106705 points
    Hi Mahesh,

    I now see which sentence you are looking at, I guess it is this: "In that situation, not enabling the warm to cold reset feature is typically required to identify the reset source", right? It did not really catch my eye since you quoted full paragraphs.

    The sentence is not correct, I will update it down the road.

    Cheers,
    Fredrik
  • 0 in reply to Fredrik K
    Prodigy 170 points
    Yes, You got my point now

    Thanks, Please correct the document.

    Regards,
    Mahesh