• State Resolved
  • Locked Locked
  • Replies 10 replies
  • Subscribers 53 subscribers
  • Views 754 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.

LAUNCHXL-CC1310: Calling SysCtrlSystemReset sometimes causes code execution to stuck

Slev1n
Genius 5680 points
Part Number: LAUNCHXL-CC1310
Other Parts Discussed in Thread: CC1310

Hey guys,

we use sensor/collector example (SDK 3.1 CC1310 and 3.2 CC1352R1, respectively). We use Flash programmer 2 for device flashing since we are aware of the fact that using CCS can cause the code execution to stuck the first time after calling SysCtrlSystemReset(). This is definitely not the problem here.

In my code I have few scenarios, where a reset is desired and for whatever reason in some cases it works in some not. Luckily it is reproducible. I ran 5 Tests calling SysCtrlSystemReset() at 4 different occassions meaning in two cases, SysCtrlSystemReset() was called from the same function, once it works once does not.

1. As a first test, I put the following code snipped at the very beginning of the function: sensor_process() --> works

/* Clear NVItems */

Ssf_clearAllNVItems();

/* Sleep for 1s=100000ticks */

Task_sleep(100000); /

* Restart */

SysCtrlSystemReset();

2. When frequency hopping is activated and no PA frame has been received after 5 PAS transmissions on the sensor side, the sensor device performs a restart within the callback function: processPASTrickleTimeoutCallback() --> works

3. When the PA message has been received and I remove the collector, the sensor will perform a restart after 5 unsuccessful PCS transmissions within processPCSTrickleTimeoutCallback()  --> board stucks

4. When association Fails twice, the sensor performs a restart --> works

5. When the sensor disassociates from the network, it deletes all network info and searches for a new network sending PAS frames. This time, when the sensor tried 5 times and wants to restarts it gets stuck calling SysCtrlSystemReset() from processPASTrickleTimeoutCallback(). --> board stucks

 

Everytime, the board is stuck a manual reset is necessary pressing the reset button on the board. However, also after that Manual Restart, if Scenario 3 or 5 occur again, the code will stuck. So I am quite at a loss, why the board sometimes stops and sometimes restarts just fine.

Any ideas are welcome.

Best wishes

Slev1n

  • 0 in reply to TER
    Genius 5680 points

    Hey TER;

    untfortunately I did not find the answer within the posted thread or the other threads it was linking to. I am not an expert in the underlying mechanics of the chips including the different register states and whatsoever. Besides, since I am not using a watchdog, I assume my case is different. But here is some stuff I've tried.

    1. Use HWREGBITW( AON_SYSCTL_BASE + AON_SYSCTL_O_RESETCTL, AON_SYSCTL_RESETCTL_SYSRESET_BITN ) = 1;
    2. Use HAL_SYSTEM_RESET();
    3. Put the SysCtrlSystemReset() into a sensor event to remove it from the callback context.

    Nothing helped.

    Besides, scenario 2 and 5 from above call SysCtrlSystemReset() at the exact same position in the code. The only difference is that in scenario 5, the sensor first associates successfully, than disconnects from the network (erasing all network info) and looks for a new one. Hence, in both scenarios the sensor looks for a new network and calls SysCtrlSystemReset() within processPASTrickleTimeoutCallback(). How is that possible?

    Hope you could elaborate what you wanted to show me with the link, but currently I dont have any idea what to do to make the reset work.

    best wishes

    Slev1n

  • 0 in reply to Slev1n
    TI__Guru**** 317180 points

    It looks like you are calling in from a callback for 3) and 5)? If that is the case, please re-read the post I linked to and focus on callbacks

  • 0 in reply to TER
    Genius 5680 points

    I went through your linked post again. Ryan suggests the following "You could try clearing the watchdog timer inside the callback and set an event which performs the SysCtrlSystemReset."

    In my last post I highlighted, that I tried putting the SysCtrlSystemReset() into a sensor event being executed in sensor_process().Thus, in processPASTrickleTimeoutCallback() it set the sensor event, which is executed in sensor_process(). But still scenario 2) works and scenario 5) not, though in both scenarios SysCtrlSystemReset() is called within the sensor event.

    Any further ideas?

    EDIT:

    TER said:
    It looks like you are calling in from a callback for 3) and 5)?
    • Scenario 2) was also called from a callback function, the same cb-function as in scenario 5). Besides scneario 4 is called in assocIndCb(), which is also a callback function.
    • Scenario 3) does not work either when setting the reset event within the callback function and then execute the actual reset in a sensor event.
  • 0 in reply to Slev1n
    TI__Guru**** 317180 points

    I find slightly contradicting information on this. The post I linked to indicate that calling the reset within a watchdog reset causes issues but some has gotten it to work.

    I still suspect callbacks but could be dependent on type of callback or (power) constraints. Are you able to recreate what you are seeing in a basic example with just one callback that calls the reset?

  • 0 in reply to TER
    TI__Guru**** 317180 points

    I read your first post as you don't have a debugger connected when this happens? If you have, you can get a "halt in boot"

  • 0 in reply to TER
    Genius 5680 points
    TER said:
    I still suspect callbacks but could be dependent on type of callback or (power) constraints.

    Well, I dont argue, that callbacks can cause the system to halt, but since it also happens within the sensor event in sensor_process() it has to be something else. Besides, at the beginning, it works in the same callback and later not anymore (refert to scenario 2) and 5)) I will try to find a simple example within the sdk (maybe UART) where I can place a callback and tell you about the outcome.

    TER said:
    I read your first post as you don't have a debugger connected when this happens? If you have, you can get a "halt in boot"

    In my setup, the sensor is a CC1310 Launchpad which is connected to the PC via USB. When I run my tests, I use Flash Programmer 2 to flash the firmware onto the device to avoid debugger attachment errors with CCS.

    But I dont know where to set the option "halt in boot" and what it does?

    If you guide me how to properly debug the reset situation I will do my best. But if the programm was flashed onto the launchpad via CCS it will always stuck during reset, right?

    Best wishes

    Slev1n

  • +1 in reply to Slev1n
    TI__Guru**** 317180 points

    To put it differently: Do you have the Jtag interface connected to the XDS110 when you do the testing? If yes, could you test without the JTag connected and if possible tie TCK high? 

    For "halt in boot", please search the TRM. 

  • 0 in reply to TER
    Genius 5680 points
    TER said:
    Do you have the Jtag interface connected to the XDS110 when you do the testing? If yes, could you test without the JTag connected and if possible tie TCK high? 

    I wasnt completely sure what you wanted me to do, but TCK rang a bell. I removed the jumpers (TMS, TCK, TDI, TDO, SWO) on the launchpad. I did not tie TCK high, I just keep the pin open. So I guess, yes, the JTAG interface was connected to the XDS110 though the JTAG header is open (=unused).

    Whatsoever, it does now work. I always get my reset, including scenario 3) and 5). Since we actually use TIDA boards as sensor devices, where the JTAG connection is removed after flashing the device via XDS110 I dont think there will be similiar reset issues now, but I will test and if anything comes up, I will report back. Thank you for your help!

    Finally, can you elaborate what you think caused the probleme?

    best wishes

    Slev1n