AWRL6432: about enable lowPowerCfg on awr6432

Hi,

  We look forward to your reply！

Regards,

guilin.shi

Hello,

Thanks for reaching over E2E on low power mode! Its not exactly clear to me what you would like to achieve, but I can explain more of the software flow for the power state management. As you pointed out, upon exiting low power deep sleep, the device can continue to execute the code. In this case, the device will return to the last address in PC register before deep sleep which will still be in the power driver layer, particular the Power_sleep function. This will then execute the user-definable power_LPDSresumehook which for most of our demos, reinitializes and reconfigures drivers, peripherals, and other system components. Afterwards, the program will return through the power driver layer back to the application layer, i.e., the powerManagementTask, the previously deleted DPC and TLV tasks will be created, and the next frame will be started.

Please let me know if this helped at all. If not, please clarify on what your question is or what your end goal is.

Regards,

Kristien

Hello Kristien，

  Due to the power consumption requirements of the project for the product, I need to enable low-power mode.
  When the low-power mode is currently enabled, due to the program being initialized again when powered on, the power on time is too long. I hope to reduce the time for low-power recovery to execute RF

  What I want to express is that when I was debugging the demo, the program did not execute as you described. I observed the execution order of the program through UART debug, and it re executed the main function

Regards,

guilin.shi

Hello,

Thanks for clarifying on your objective here. See some of my comments below.

shi guilin said:

I observed the execution order of the program through UART debug, and it re executed the main function

You should not be able to debug the program - at least initially - upon entering LPDS, so I would expect that the debugger would disconnect after the first frame. Regardless, the stranger behavior here is that the program is re-executing the main function. This should not be the case unless a soft reset is occurring.

I understand that you've resolved this issue, but if you do go back and test the issue with the program re-executing, you can identify the reset cause through the APP_CTRL:APPSS_BOOT_INFO_REG0[3:0] as noted by the TRM.

shi guilin said:

Which of these configurations cause the program to execute as a reboot instead of continuing to execute after entering low power last time

None of these changes should resolve the issue with the program re-executing upon entering low power. These are all settings to enable or configure the SYNCIN_IO as a wakeup source from LPDS upon a rising edge. 

selectGpioSyncioLPDS allows SYNCIN_IO as wakeup source
wakeupSYNCIOEdgeLPDS sets a rising edge on SYNCIN_IO to trigger wakeup
SYNC_IN.$suggestSolution = "SYNC_IN0" sets the instance name for the SYNCIN_IO to SYNC_IN0

Regards,

Kristien

Hello Kristien，

  Got it, I will try to find out the reason, and if there are any results, I will synchronize them with you. Maybe time will be a bit slower.

  "I understand that you've resolved this issue, but if you do go back and test the issue with the program re-executing, you can identify the reset cause through the APP_CTRL:APPSS_BOOT_INFO_REG0[3:0] as noted by the TRM.

Regards,

guilin.shi

Hello,

Sure, let me know if there is anything you can share here. I would like to understand this issue further but take your time.

Regards,

Kristien

Hello Kristien，

  I read the value of the register（APP_CTRL:APPSS_BOOT_INFO_REG0[3:0]） and found that the reason for the restart is STC_PORZ，and I carefully debugged the program, and the reason for the program exception is related to the thresholdForLPDS value.

  ThresholdForLPDS uses the default configuration of 10000 in the demo(motion_and_presence_detection), but after modification, it is 30000000.

  What is the unit of ThresholdForLPDS configuration and are there any restrictions on its configuration.

Regards,

guilin.shi

Hello,

Thank you for looking into this further and letting us know what you discovered. The ThresholdForLPDS is measured in microseconds and indicates the amount of time specified for sleep time that most be surpassed for low power deep sleep to be considered. In this case, the ThresholdForLPDS being set to 30000000 indicates only a sleep time above 30 seconds will trigger low power deep sleep.

This also means you are likely not entering low power mode for motion and presence detection but rather idle mode since the frame period for the default configurations is at most 250 ms and sleep time cannot exceed frame period - at least for our demos. This is also backed up by the fact that STC_PORZ is the last reset cause which would indicate the device was power cycled and did not enter LPDS.

The lower limit on the threshold value is dependent upon the LPDS latency which by default is 2 ms, and the upper limit is 64 seconds as this is the limit of the sleep timer itself.

Regards,

Kristien

Hello Kristien，

  Upon hearing your explanation of ThresholdForLPDS, I realized that I had misunderstood before.
  I used to think that ThresholdForLPDS was the upper limit of low-power mode, and ThresholdForLPDS was the time when it could only be in low-power mode at most.
  Based on this, I re debugged the demo (power_mades) and found that I thought I was in low-power mode before, but in reality I was in POWER-IDLE mode.

  I am using the ti EVM board for debugging. Can you try it out and provide me with your results?

Regards,

guilin.shi

Hello Kristien，

  Is there any update on the low-power demo

Regards,

guilin.shi

Hello,

Sorry for the delay. There was a holiday here in the United States. I have tested the low power demo and found that I was entering LPDS upon using Power Management Option 1. Did you change the ThresholdForLPDS in your tests or the SLEEP_TIME_TICKS macro? 

Regards,

Kristien

Hello Kristien，

  I did not change the ThresholdForLPDS or the SLEEP_TIME_TICKS macro.

  You can see it in the serial port log I gave you，ThresholdForLPDS  is 30000，SLEEP_TIME_TICKS is 50000.

  Is there anything else to pay attention to.

Regards,

guilin.shi

Hello Kristien，

  Does low power consumption require special hardware configuration?
  Can you share your program and project with me via email? I will run debugging and check.

  My email is guilin.shi@mindcruise.ai.

Regards,

guilin.shi

Hello,

You could debug this further by loading the program via the CCS debugger after flashing the empty appimage from the SDK and set a breakpoint at vPortSuppressTicksAndSleep which should be triggered after the xSemaphoreTake. Since this isn't a part of the main project files, I would recommend setting a breakpoint by searching for the vPortSuppressTicksAndSleep function in the Disassembly view of CCS and adding the breakpoint at the start of the assembly instructions for the function.

Upon selecting Power Management Option 1, 50000 ticks should be passed into vPortSuppressTicksAndSleep which should get converted into 50000000 microseconds before being passed to Power_idleFunc. This will be passed to the Power_sleepPolicy function which contains the conditional logic for determining whether the passed in time exceeds the LPDS threshold, sleep threshold (if the former is false), or idle threshold (if the former is false). In this case, it should exceed the LPDS threshold and would normally take LPDS, even if we account for the latency.

If you could share what the sleep time/ticks is at the various stages of this process, we should be able to identify why idle state is being taken when LPDS should be taken.

Regards,

Kristien

Hello Kristien，

   When I was debugging the program, I set a breakpoint at vPortSuppressTicksAndSleep, but it triggered before I had selected the low-power option1.

Is this not as expected?

Regards,

guilin.shi

Hey Shi,

Yes, I apologize for any confusion here. vPortSuppressTicksAndSleep is likely being triggered after the DebugP_scanf function while the application waits for character input. You can set a breakpoint on line 125 when Power_enablePolicy is called, run to it, and then set a breakpoint in vPortSuppressTicksAndSleep. If you want to skip a bit of the power sequence, you can also search for Power_sleepPolicy in the Disassembly view and add a breakpoint there instead. This should only be triggered when Power Management Option 1 is selected.

Regards,

Kristien

Hello Kristien，

   I debugged the program and found that in the function vPortSuppressTicksAndSleep, when we set SLEEP_TIME_TICKS=50000, the calculation exceeded the uin32_t data range, resulting in a final effective time that was not as expected.
   But when I set SLEEP_IME_TICKS to 5000, ThresholdForLPDS = 3000， The program also cannot print the low power consumption log (Exited LPDS) as expected.It also did not print the log pushed out from idle mode.

   I hope you can provide a program that can print logs for entering and exiting low-power mode according to the document, so that I can proceed with further development and debugging.

Regards,

guilin.shi

Hello Kristien，

   I tried the solution you mentioned, and through debugging the program, I was able to see that it eventually entered low-power mode. （Power_sleep(POWER_LPDS);）
But the program still did not print the output to exit low-power mode as expected. （Exited LPDS!! and Reason for Reset is Deep Sleep）

Regards,

guilin.shi

Hey Shi,

I have a few questions to understand where you're at currently:

1. Are you waiting for the device to wakeup through the sleep counter after 50 seconds or manually by hitting the USER_SWITCH on the board? 
2. Are you flashing the empty appimage from the SDK and loading the power example through the CCS debugger or flashing the power example appimage directly?
3. If you are utilizing the debugger, did you also add in the ClockP_sleep calls after Power_disablePolicy - should be after line 126 and 154?

Regards,

Kristien

Hello Kristien，

   1.I am waiting for the device to wakeup through the sleep counter after 50seconds.

    2.I am flashing the empty appiamge from the SDK and loading the example through the CCS debugger to Confirm program operation，and flashing the modified power example appimage onfirm program serial port.onfirm program serial port.

    3.Here are some screenshots of my modified code.

ClockP_sleep 

Regards,

guilin.shi

Hey Shi,

Could you set a breakpoint at Power_sleepPolicy and verify that the remain value passed to PRCMLPDSIntervalSet is around 50000000? More precisely, it should be 49998000 since the function accounts the LPDS latency of 2000. You can also check the following memory address, 0x5A040030, after PRCMLPDSIntervalSet and verify that the register matches the remain value.

Regards,

Kristien