CC2745R10-Q1: CC2745 has repeated abnormal freezes

Hello,

Are you resetting the watchdog timer value?

Best,

Nima Behmanesh

Hello, I've implemented a timer to periodically reset the watchdog timer. But when a fault occurs, my entire software appears to lock up—even the timer ceases functioning, resulting in the watchdog not being fed as intended.

Based on the key_node demo, I have added over a dozen custom messages to the BLE task for handling application functions, and also created a separate UART task specifically for production testing (sending and receiving test commands). Will these modifications affect the chip's operation?

Additionally, based on the key_node demo, I have added the OTA (Over-the-Air) functionality and allocated the key_node address to 0x32000. The address range 0x00000000–0x31FFF is used for the persistent app area.

Hello,

liu shi said:

Based on the key_node demo, I have added over a dozen custom messages to the BLE task for handling application functions, and also created a separate UART task specifically for production testing (sending and receiving test commands). Will these modifications affect the chip's operation?

It depends. I'd need to see the code and review it to properly answer that question. That's not say it will, but depending on how those tasks were created (i.e. they must be lower than the BLE application task priority) those separate tasks may have an effect on the BLE stack operation.

Additionally, since you're using UART, this would inhibit the device from going to lowpower mode, which could also be a cause to the high current usage. 

What do you observe if you disable the watchdog entirely?

Best,

Nima Behmanesh

Hello, if the watchdog is completely disabled, the software will get stuck at a certain stage, with the power consumption remaining around 7mA. I have also considered whether my UART task is causing the issue, but the problem still occurs even after I remove the UART task.

Hello,

Thanks for the for the information. When you say that it gets stuck at a certain stage, can you provide a callstack or the function it's getting stuck at?

Without some more debug information, it will be hard to root cause what could be happening to cause the device to hang. Any more information regarding what's happening in the software would be helpful.

Best,

Nima Behmanesh 

Hello,

During today's testing, I observed that when using the SDK's key_node program (with BLE advertising disabled) — after removing the original UART configuration from sysconfig and adding a custom UART — abnormal power consumption occurs during power-on/off stress testing, even when a several-second wait is incorporated into the power-off phase.

Hello,

     You can perform the same configurations and tests on the key_node project in SDK14 to see if you can identify the root cause of the issue.

Hello, 

Are you using the base key node project? Are you using channel sounding, and if so, did you change any of the channel sounding configuration? What exactly is the goal for the key node project? I assume channel sounding, but are you incorporating anything else besides UART, and OAD? 

Please provide the call stack view when the project becomes stuck. This will help in debugging. 

What power policy have you enabled? Wait for interrupt or standby? Let me know. 

Thanks,
Isaac

Hello,

I am using the basic key node demo without modifying any channel sounding configurations, nor have I integrated the OAD function. During testing yesterday, I found that on the basic key node project—without any configuration changes, no integration of UART or OAD functions, and no additional code added—if I only disable the Bluetooth advertising operation and then perform power-on/power-off tests (with a longer power-off time to ensure the chip is completely powered down), a high power consumption issue occurs. This phenomenon only happens during sleep; it does not seem to occur when there are other RF operations such as Bluetooth advertising or connections. I have not modified the power management policy and am using the default standby policy.

I don't think I can reliably capture the exact moment the issue occurs when in debug mode.

I have used the key node demo—without adding any custom code or modifying any configurations—and downloaded the program to the demo board. During stress testing, I found that a high power consumption issue occurs as long as Bluetooth advertising is disabled.

Hello,

I am using the basic key node demo without modifying any channel sounding configurations, nor have I integrated the OAD function. During testing yesterday, I found that on the basic key node project—without any configuration changes, no integration of UART or OAD functions, and no additional code added—if I only disable the Bluetooth advertising operation and then perform power-on/power-off tests (with a longer power-off time to ensure the chip is completely powered down), a high power consumption issue occurs. This phenomenon only happens during sleep; it does not seem to occur when there are other RF operations such as Bluetooth advertising or connections. I have not modified the power management policy and am using the default standby policy.

I don't think I can reliably capture the exact moment the issue occurs when in debug mode.

I have used the key node demo—without adding any custom code or modifying any configurations—and downloaded the program to the demo board. During stress testing, I found that a high power consumption issue occurs as long as Bluetooth advertising is disabled.

Hello,

During the test of low-power mode without BLE advertising in debug mode, no abnormal freezing has occurred so far. However, the device keeps freezing when running in low-power mode without debug mode enabled. The power consumption in debug mode stays around 2 mA, which leads me to conclude that the chip does not enter deep low-power state under this condition. As a result, potential issues either cannot be reproduced or are much less likely to show up.

I have identified another phenomenon: the program freezes when I disable BLE advertising after receiving a UART command, and the freeze occurs at the line of ICall_abort();

Hello,

During the test of low-power mode without BLE advertising in debug mode, no abnormal freezing has occurred so far. However, the device keeps freezing when running in low-power mode without debug mode enabled. The power consumption in debug mode stays around 2 mA, which leads me to conclude that the chip does not enter deep low-power state under this condition. As a result, potential issues either cannot be reproduced or are much less likely to show up.

I have identified another phenomenon: the program freezes when I disable BLE advertising after receiving a UART command, and the freeze occurs at the line of ICall_abort();