• State Resolved
  • Locked Locked
  • Replies 15 replies
  • Subscribers 41 subscribers
  • Views 4597 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/CC3220: In LPDS mode, cannot exit the sleep function.

xinggang zheng
Intellectual 260 points

Part Number: CC3220
Other Parts Discussed in Thread: UNIFLASH,

Tool/software: TI-RTOS

condition:

1. Use the example of power_measurement with the SDK version 2_10_00_04, and the target chip is CC3220R.

2. Select the UseCase_AlwaysConnected mode in LPDS mode, keep the connection with the router, receive data using the blocking mode of serial port, and use Power_disablePolicy() before the receiving process to prevent CC3220 get into LPDS mode.

3. In the process of waiting for the serial port reception, if the waiting time is longer, after the data is collected, it will be blocked, unable to exit from sleep function.

Then, I tried to use the driver function in D:\ti\simplelink_cc32xx_sdk_2_10_00_04\source\ti\devices\cc32xx\driverlib\uart.c  .h, to realize the function of serial port send and receive, and find the problem came up again.

 Why this happens?How can I solve this problem?

I want CC3220 enter the LPDS mode while maintaining the connection router, and then the peripheral device wakes up 3220 via IO port and communicates with the serial port.

 The current waveform when blocking in the sleep state (the current waveform is normal LPDS mode):

code(power_measure.c):

code(uart_term.c):

log information:

project file:

power_measurement-uart-lib.zip

  • 0
    TI__Mastermind 40965 points

    Hi xinggang,

    I have reproduced the issue with my own CC3220 launchpad, where waiting for ~5 minutes before sending UART data causes the sleep(LPDS_IDLE_TIME/5000) call to never return.

    I still have not determined the root cause, but have tried the following in an attempt to see if it fixes the issue:

    • Changed the UART driver from UARTCC32XX to the DMA-enabled UARTCC32XXDMA
    • Call PRCMLPDSWakeupSourceEnable(PRCM_LPDS_TIMER) to ensure that the RTC is used as a wakeup source
    • Changed the UART read function to the non-polling UART_Read()
    • Added a timeout to the UART_Read() function so that it returns after 10 seconds, and then repeating the UART read if no data was sent.

    None of the above debug workarounds fix the issue, unfortunately.

    I'll keep debugging this and seeing what might be causing the issue, and let you know when I find a fix or workaround.

    Regards,

    Michael

  • 0 in reply to Michael Reymond
    Intellectual 260 points

    Hi Michael,

    Is there any progress now?It seems to be a software bug.

  • 0 in reply to xinggang zheng
    TI__Mastermind 40965 points

    Hi xinggang,

    So we have discovered that there is a bug within the RTOS kernel as of SDK ver. 2.10.00.04, where it does not take into account the clock drift between the fast clock-based systick used by the RTOS clock module and the RTC used by the MCU while in LPDS. When you enter LPDS, the systick is stopped since the fast clock is disabled, thus when you exit LPDS you need to restore and resync the systick to the correct count based on the time elapsed while in LPDS.

    Since the kernel's power module that handles the LPDS transitions assumes that there is no clock drift between systick and RTC, when it restores the systick it doesn't restore it to the correct time. From some experiments we have been running, we have observed that the systick drifts slower than the RTC by a few hundred ms per hour. This relates back to the problem you are seeing since the scheduler has events pending on systick counts that will never get triggered since systick has moved past the count at which they were supposed to occur at. Let me illustrate what is happening:

    Event Systick time RTC time
    Clock module initialization 0s 0s
    (Running) ... ...
    Task1 blocks on sleep(), wants to block 5s. 5890.0 5890.55
    Scheduler sets event to unblock Task1 at 5895.0s 5890.0

    5890.55
    Power module enters system into LPDS 5890.0

    5809.55
    (Sleeping) ...

    ...
    MCU is woken from sleep by RTC 5890.0

    5895.55
    Power module resyncs systick to RTC 5895.55

    5895.55
    Scheduler checks to see if there are any Tasks that are ready to run 5895.55

    5895.55
    No tasks are ready, Task1 is blocked until systick loops back to 5895.0s 5895.55

    5895.55
    Power module enters system into LPDS since there are no tasks ready to run 5895.55

    5895.55

    We are currently testing a fix to the power module in the kernel to resync the systick to the correct time that the scheduler/rest of the RTOS expects. This fix should be committed into the next SDK release. I will let you know if anything changes, and when we release the fix.

    Regards,
    Michael

  • 0 in reply to Michael Reymond
    Intellectual 260 points

    Hi Michael:

    When I change the sleep time to 5s,it crashed.

  • 0 in reply to xinggang zheng
    TI__Mastermind 40965 points

    Hi xinggang,

    Just to double-check, are you using TIRTOS? With freeRTOS, there is a similar LPDS wake problem but a different fix is required since the clock restore in the power policy is handled differently.

    If you are using TIRTOS, the fix should work. I've tested it with the power_measurement example on the latest SDK (v. 2.10.00.04). The following is how I replicated and the issue, and then confirm that the fix worked:

    1. Import the power_measurement example
    2. Edit common.h with my AP details.
    3. Replace the default power_measure.c file with the UART read modifications. (See attached file at the end of this post).
    4. Copy the fixed PowerCC32XX_tirtos.c file into the project
    5. Insert the following definition into uart_term.h: 
      int UartRead(char* buf, int len);

      then, the following implementation of that function into uart_term.c:

      int UartRead(char* buf, int len){
    return UART_readPolling(uartHandle, buf, len);
}

    6. Build, and then program onto the CC3220 using Uniflash

    Is there something different with what I'm doing and the setup you have?

    Regards,

    Michael

    /cfs-file/__key/communityserver-discussions-components-files/968/power_5F00_measure.c

  • 0 in reply to Michael Reymond
    Intellectual 260 points

    Hi Michael

    This fix is working,

    I mean it is another problem that resulted in program crashed, and will never wake up again.

  • 0 in reply to xinggang zheng
    TI__Mastermind 40965 points

    Hi Xinggang,

    Ok, I understand now. I was confused when you mentioned that using sleep() would still put you into a bad state.

    From your terminal output, it looks like you are not getting to sleep(5) on the iterations where you crash. It looks as if you are crashing at UartReadPolling(). I assume that during this time the processor is active, so you can use the debugger to check the state of the system. It would be interesting to do so, and see what happens during your crash.

    Have you taken a look at the code I provided and checked to see whether or not there is any difference between what I'm running and the code that causes your device to crash? I cannot replicate this crash behavior with my provided code on a launchpad.

    Are you using your own custom board? If so, it would be great to run your code on a launchpad and see if you get the same issue.

    Regards,
    Michael

  • 0 in reply to Michael Reymond
    Intellectual 260 points

    Hi Michael

    Sorry, it's my fault.

    This problem only appear when keepDebugActiveDuringLPDS is false, if keepDebugActiveDuringLPDS set to true ,it will never happen again.So, I can't debug the code.

    And yes, I'm using my own custom board, I do not have a launchpad right now.

  • 0 in reply to Michael Reymond
    Intellectual 260 points

    Hi Michael

    This problem is not always happen. Sometimes it work normal.

    Here is the normal current wave and error current wave.

    Here is the video of current measurement.(from boot to error happen)

  • 0 in reply to xinggang zheng
    TI__Mastermind 40965 points
    Hi xinggang,

    Thank you for posting your oscilloscope captures and video.
    The dips you are seeing on what I assume is VIN might be too much for the part to tolerate. What do you have your VIN nominally at, and what does the voltage dip down to when you have high current draw?

    Regards,
    Michael
  • 0 in reply to Michael Reymond
    Intellectual 260 points

    Hi Michael

    I'm wired a 1 ohm resistor to VIN to capture current wave.So the voltage dip down is almost 300mV. If I wire VIN to VCC directly, this problem still happen.

    High current draw happens when CC3220 transmitting data.The power supply is 3.28V.

    When I set keepDebugActiveDuringLPDS to true, CC3220 works good, so I don't think that the power supply drop makes the problem happen.

    And this problem happens high probability, not always.

  • 0 in reply to xinggang zheng
    TI__Mastermind 40965 points
    Hi xinggang,

    Your reasoning about the power supply drop not being the problem seems correct. It's interesting though that setting keepDebugActiveDuringLPDS eliminates the problem. I'll have to check a bit and see what is different when keeping the debugger/JTAG active in LPDS.

    I think that you should double-check and see if this behavior also appears with a CC3220 launchpad. While there are no CC3220R launchpads, you can run your code with a CC3220S launchpad. You can use the same code, and flash it as a CC3220R project with Uniflash and it should work exactly the same as running it on an R device. By running it on a launchpad we will be able to confirm that it is definitely not a software problem.

    I have asked the field team to reach out to you and let you use one of their CC3220S launchpads. Please let me know of your test results with the launchpad.

    Regards,
    Michael
  • 0 in reply to Michael Reymond
    Intellectual 260 points

    Hi Michael

    OK, thank you,I will  double-check this problem when I get a launchpad.

  • 0 in reply to Michael Reymond
    Intellectual 750 points

    Hi Michael,

    do you have a similar fix for FreeRTOS ?  (same SDK version)

    regards

    ron