Tool/software:
Hello
I run the demo "uart2echo_LP_EM_CC2674P10_nortos_ticlang",
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.
Tool/software:
I run the demo "uart2echo_LP_EM_CC2674P10_nortos_ticlang",
Hi !
The reason why you enter this function can be determined by debugging your firmware. This can be done is CCS by moving step-by-step in your software, and seeing when are you getting blocked.
In CCS 20, you can click on "Run > Debug Project" to flash and debug your project on your board. You will be allowed to step into functions and more, and you will see why are you jumping inside this function.
Kind regards,
Maxence
Hi,
The demo program may call this function through the drivers of the chip. This is something that may be difficult to find when only following function calls.
For example, NoRTOS_start might initialize the power management driver, which may call the PRCMDeepSleep function.
This is why debugging and stepping into your program, or setting a breakpoint in PRCMDeepSleep and watching the call stack is a good idea.
Kind regards,
Maxence
Hi !
The example is not comprised of only one file but multiple source files that are added to your CCS project and other source files which are included when building. The reason why you enter the PRCMDeepSleep function is probably because your UART is blocking, which causes the system to go to sleep when you are waiting for UART data to read or send.
If you run the debugger and stop at a breakpoint in the PRCMDeepSleep function, your call stack will likely be UART2_read -> UART2_readTimeout -> SemaphoreP_pend, and since no tasks are active then the idle function calls PowerCC26XX_standbyPolicy -> PRCMDeepSleep which is really just CPUwfi since UART2 read disables standby low power mode entry.
Kind regards,
Maxence