LAUNCHXL-CC1352P: Power testing. What is consuming power once per second?

Thanks for the reply. 

Notice there are two small spikes that occur once per second. On the oscilloscope we zoomed in to the first spike, and we believe this is the recharge pulse (it looks similar to the pulse in the document you reference).

However we zoomed in on the second pulse and it looks very different and it's about 5.5 milliseconds wide, so we don't think this is a recharge pulse. We suspect the processor is waking up to do something, but what?

The device we are testing is running the TI zed_sw example with the alterations I mentioned in my original post above. That example has an endless processing loop (see zclSampleSw_process_loop() in zcl_samplesw.c). That loop pends on a semaphore; when the semaphore is posted the loop wakes up and processes the event. There are 5 events that can occur:

1. The radio receives a message
2. A button press occurs
3. A UI refresh event occurs
4. A UI input event occurs (input has arrived at the UART)
5. An end device rejoin event occurs

The UI is disabled so events 3 and 4 are not occurring. I'm positive our device has joined the network, so event 5 is not occurring. We are not pressing the button, so event 2 should not be occurring. That leaves event 1.

So my questions are:

Is the radio waking every second to do something, like check for messages?

How are button presses detected? Does the main processor wake up once per second to poll the button?

Is there something else that I don't know about that occurs once per second?

Any help would be appreciated. We need to get power consumption as low as possible. Remember this is the stock TI example, we are not doing anything weird.

Thanks,

Tim

This could be related to the integrated PA, have you tried disabling CONFIG_PA_TYPE=APIMAC_DEFAULT_PA?  Of course if you are using under 5 dBm output power you should consider using a LAUNCHXL-CC26X2R1 or LAUNCHXL-CC1352R1 instead as the external antenna switch could also be affecting power consumption.

Regards,
Ryan

If you suspect it’s case 1 causing the wakeup, you can set a breakpoint in “the radio receives a message“ related code of zclSampleSw_process_loop to verify it first.

Could these actually be zigbee end device to router/coordinator polls?

The reason I ask is that we're trying to set the end device poll time to 5 minutes.  That's handled in the app through a #define value but I just went to look at what it does with that data, and the system calls to set the poll rate seem to all take a 16 bit (millisecond) value.  I'm wondering if we're seeing is actually a 1 second poll, because the rate we're trying to use is invalid.

Ryan Brown1We just figure that i doesn’t work when we change POLL_RATE from ti_zstack_config.h in SDK 3.30, it’s good to know we have to change it on sysconfig. I would suggest you to mention this somewhere in your document otherwise people might have the same trouble using SDK 3.30. By the way, I think it’s better that TI can make change POLL_RATE from ti_zstack_config.h work in future SDK release. I see no reason why it needs to change POLL_RATE from SYSconfig.

Please reference the warning provided at the bottom of this page: http://dev.ti.com/tirex/content/simplelink_cc13x2_26x2_sdk_3_30_00_03/docs/zigbee/html/sysconfig/zigbee.html 

I apologize if it was not made clear enough.  Future SDK releases will continue to rely on the SysConfig tool to re-generate project files, in order to remove this dependency you must disable SysConfig.

Regards,
Ryan

Ryan Brown1  Shouldn’t it be more reasonable that sysconfig would change related value in ti_zstack_config.h and Z-Stack would use those value in ti_zstack_config.h to build firmware? In this way, it doesn’t matter that developer changes it from sysconfig or ti_zstack_config.h

I will pass along your feedback to the Software Development Team but this discussion has already occurred internally in favor of the process I've described.

Regards,
Ryan

The idea of generating boilerplate code with sysconfig is really helpful for getting started, it just shouldn't be the only way.  My application is very dynamic; a lot of these parameters are configurable at run-time (sometimes at next reboot).  Sysconfig-like approaches can be pretty nice, it's just no good if it's the only way.

If I'm off base here disregard.  I think I'm a little behind on SDK versions at the moment and trying to catch up.

Getting back to my original problem. We have SDK 3.20 so due to the bug, polling was taking place every second. I was unaware of the bug so I thought polling was occurring every 5 minutes since I set it to 5 minutes in zstack_config.h. I fixed by using this code:

zstack_sysConfigWriteReq_t writeReq = { 0 };
writeReq.has_pollRate = true;
writeReq.pollRate = POLL_RATE;
writeReq.pollRateType = POLL_RATE_TYPE_DEFAULT;
Zstackapi_sysConfigWriteReq(appServiceTaskId, &writeReq);

I'll probably upgrade to SDK 3.30, even though I hate upgrading because of the potential of breaking things that are working (e.g. API changes).

Regarding SysConfig, does this come with Code Composer Studio, or is it a separate download?

Tim

Tim,

I recommend using the SysConfig built into CCSTUDIO v9.x, however there is a standalone version available for third party IDE integration & custom development environments.  

Regards,
Ryan

I recommend you to use CCS9.2 which includes sysconfig For SDK 3.30.