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

RTOS/CC1352P: Restart of collector in SUB 1 GHZ communication

Haricharan sarpatwar
Expert 1750 points
Part Number: CC1352P

Tool/software: TI-RTOS

Hi, 

I am using CC1352P IC as collector and connected 3 sensors. I am using the following SDK simplelink_cc13x2_sdk_2_20_00_71. The sensors are sending data with 5 minutes interval to collector and collector is receiving the data sent from sensors and that data i am transmitting to PC using UART. After 24 hours Collector is being restarted with restart reason as 0x7 . I used the following code to get restart reason 

/* Get the reason for reset */
rSrc = SysCtrlResetSourceGet();

what are the possible reasons for getting this restart?

Actually restart reason should be any one of the reason but i am receiving three reasons

// WARMRESET Software reset via PRCM warm reset request
// SYSRESET Software reset via SYSRESET or hardware power
// management timeout detection.
//
// Note: The hardware power
// management timeout circuit is always enabled.
// CLK_LOSS SCLK_LF, SCLK_MF or SCLK_HF clock loss detect
// VDDR_LOSS Brown out detect on VDDR
// VDDS_LOSS Brown out detect on VDDS
// PIN_RESET Reset pin
// PWR_ON Power on reset
#define AON_PMCTL_RESETCTL_RESET_SRC_W 3
#define AON_PMCTL_RESETCTL_RESET_SRC_M 0x0000000E
#define AON_PMCTL_RESETCTL_RESET_SRC_S 1
#define AON_PMCTL_RESETCTL_RESET_SRC_WARMRESET 0x0000000E
#define AON_PMCTL_RESETCTL_RESET_SRC_SYSRESET 0x0000000C
#define AON_PMCTL_RESETCTL_RESET_SRC_CLK_LOSS 0x0000000A
#define AON_PMCTL_RESETCTL_RESET_SRC_VDDR_LOSS 0x00000008
#define AON_PMCTL_RESETCTL_RESET_SRC_VDDS_LOSS 0x00000004
#define AON_PMCTL_RESETCTL_RESET_SRC_PIN_RESET 0x00000002
#define AON_PMCTL_RESETCTL_RESET_SRC_PWR_ON 0x00000000

 By the above statements, the restart reason should be any one of these. Actually restart reason should be any one of the above reasons but i am receiving three reasons 0x7 why? 

Some times i am receiving TI-RTOS HANDLER also.

  • 0
    TI__Guru 58425 points
    Hi,

    Reason 7 as received from that API should be (taken from dev.ti.com/.../AON_PMCTL.html

    0x7 WARMRESET Software reset via PRCM warm reset request

    The values there you listed is with register offset included. As the reset source is given is found in bit 1-3, you have to shift those defines by one step to compare them to the SysCtrlResetSourceGet() return value.
  • 0 in reply to IUsedToBeARealPerson (M-W)
    Expert 1750 points
    Hi,
    Thanks for the quick response, The reset source is "Software reset via PRCM warm reset req". Is this something the RTOS does? i used SysCtrlSystemReset(); to enable Warm Reset Converted to System Reset. And in my application i require Time to be updated if this happens i could not update time. Some times my code is entering in to TI-RTOS HANDLER, so i enable RESET_ASSERT which again call SysCtrlSystemReset();. My question is why my collector code enters in to TI-RTOS HANDLER..

    Thanks & Regards
    haricharan
  • 0 in reply to Haricharan sarpatwar
    TI__Guru 58425 points
    Hi,

    SysCtrlSystemReset() will perform a reset, not enable the "Warm Reset Conv. to System Reset", this is enabled per default. TI-RTOS do not do this by itself, but some more advanced software examples could have this as part of watchdog/assert handlers.

    Now to why you enter "TI-RTOS HANDLER" I do not know. I'm not sure to what you are referring so it would help if you could elaborate on it.
    For example, when you say "I enable RESET_ASSERT", what exactly do you do? When you enter "TI-RTOS HANDLER", what is this handler and where are you in your code?

    Also, have you tried using ROV at this point to look at the state of your system. Check stacks, Hwi exceptions etc etc.
  • 0 in reply to IUsedToBeARealPerson (M-W)
    Expert 1750 points

    Hi,

     Sorry For late reply, i am out of office so i could not reply your mail.

    1. 
    SysCtrlSystemReset() will perform a reset, not enable the "Warm Reset Conv. to System Reset", this is enabled per default. TI-RTOS do not do this by itself, but some more advanced software examples could have this as part of watchdog/assert handlers.

    when you say "I enable RESET_ASSERT", what exactly do you do?

    #define RESET_ASSERT// This line i added in main.c

    void Main_assertHandler(uint8_t assertReason)
    {
    Main_assertReason = assertReason;

    #if defined(RESET_ASSERT)// By default it is not enabled. And this one, i have done with Tech.Ref. Manual recommendation
    Csf_assertInd(assertReason);

    /* Pull the plug and start over */
    SysCtrlSystemReset();
    #else
    Hwi_disable();
    while(1)
    {
    /* Put you code here to do something if in assert */
    }
    #endif
    }

    2.

    Now to why you enter "TI-RTOS HANDLER" I do not know. I'm not sure to what you are referring so it would help if you could elaborate on it.
    For example, When you enter "TI-RTOS HANDLER", what is this handler and where are you in your code?

    My collector code entering in to TI RTOS_HANDLER while performing normal operation of processSensorData function that too after 24 hours or later.

    I kept some debug messages using uart when following

    Sending tracking msg in generate Tracking msgs, Tracking response in Process tracking response

    Sending Config msg in generate config req, config response in Process config response

    Data received from sensors in ProcessSensorData

    Up to 24 hours i am receiving data from sensors (Tracking and DATA) and when restart of sensors/ collector config msgs. I had logs for that. 

    3. 

    Also, have you tried using ROV at this point to look at the state of your system. Check stacks, Hwi exceptions etc etc.

    No i have not tried ROV.
  • 0 in reply to Haricharan sarpatwar
    TI__Guru 58425 points

    Hi,

    Could you try to use the ROV and inspect the state of the system? It might also be an idea to use while(1) loops instead of resets to allow you to debug the root cause. 

  • 0 in reply to IUsedToBeARealPerson (M-W)
    Expert 1750 points
    HI
    I have downloaded same application in launchpads, Now i did not see any restarts for 10 days, might be any hardware might cause the restart so i will check with my hardware team to find the issue. Thanks for the valuable support

    Best Regards
    Haricharan