LP-EM-CC2340R5: Start up power consumption

Hello!

Thanks for reaching out.

Could you please help me by providing some more information about the energy consumption?

1. Do you have access to XDS110 - ET debugger probe from TI? If yes, could you please follow this guide: EnergyTrace User Guide to collect the current draw of the device from when it boots? You can start running energy trace and then reset the launchpad to see info from boot (press reset button). Please share a screenshot of the current draw (x and y axis are appreciated).
2. Are you measuring the power consumption while running the program in debug mode? This will considerably increase the power consumption.
3. What program are you running on the device? Is it an out of the box example, if yes, which one?

BR,

David.

Hi!

Thank you for answering.

I have used the XDS110 - ET debugger and followed the EnergyTrace guide as you suggested. I attach the image of the relative power when debugging the program (the voltage of the Energy Trace is 3.3V) and as you suggested the image of the current when running the energy trace and reseting the board.

As for your second question, normally I measure the current consumption out of the debug mode by using the oscilloscope.

By the way, I am using the basic_ble example from: SimpleLink Low Power F3 SDK (8.10.01.02)/Examples/Develompent Tools/CC2340R5 LaunchPad/BLE5-Stack/basic_ble. I have changed some parameters, I am using it only as a broadcaster and have changed the primary phy interval to 1000 ms (both minimum and maximum).

As you can see when pressing the reset the current consumption has the same form as in the debug mode. I guess this current consumption is for just starting the micro, correct me if I am wrong. It could be possible to reduce the time this happens or to reduce the consumption? Both would be even better. 

Thank you in advance.

Greetings, 

Eñaut

Hello Eñaut,

Could we please try the following:

1. Disable the UART display (see this guide for power consumption optimization in general): this might be consuming the 20 ms in between the system boot-up and the first advertising (from around 20 msto 40 ms) .
2. The section of the reset event (from around 40 msto 55 ms) is actually the first advertisement.

I would also suggest to compare the reset energy profile while using the empty project (found inside the driver examples from the SDK) to confirm the extra power consumption is coming from the application (BLE related in the basic_ble case).

BR,

David.

Hello David,

I have disabled the UART display and it gets way shorter, I attach you the image. However the consumption is way to large for the application I am using it for. I have also loaded an empty project and it is much shorter, I attach you also the image so you can compare. 

The first one is about 35ms while the empty one is about 6ms. Are there any other option to reduce the current consumption during the boot? Having longer boot times with lower current consumption could fit with my power budget.

Searching for another alternative, we have found another example project called rfPacketTx, which is in SimpleLink Low Power F3 SDK (8.10.01.02)/Examples/Develompent Tools/CC2340R5 LaunchPad/TI Propietary RF/rfPacketTx. It has an option to not use RTOS and it seems to boot more quicly, I attach you the image too. However, I am not sure of what it does and if it is necessary to use RTOS for my application.

Just so you have more info, the application consists on a BLE beacon that can send data, 32 bytes is enough for the application so that is why I am using the BLE in broadcaster mode. The amount of energy that can the chip consume is very limited, that is why having so much energy consumed in very little time is a issue. 

Thank you. 

Greetings,

Eñaut

Hello Eñaut,

Thanks for the information provided, definitively the application that is using Bluetooth LE functionalities requires the CPU to run more tasks to set it up before going into standby. Let me take a look at what can be avoided. Regarding the PropRF one, this one does not implement BLE as the actual protocol, would it still be a potential solution for you?

BR,

David

Hello David,

I have been reading about it and testing it and I think it would be a potential solution. I have made also tests using the one with RTOS and the one without and the consumption of the program without RTOS is slightly lower so it fits better for my application. But I am not sure if it works like a beacon or not, as I have seen that there is a syncword, does it mean that the receiving launcpad has to connect to the transmitting one? It would be possible to make a beacon with the PropRF?

Apart from that, I have used SmartRF studio 8 to make some tests and the data is reaching correctly to the other Launchpad. However, when flashing the rfPacketTx and rfPacketRx programs into the launchpads, I don't know how to visualize the data that is getting to the RX launchpad. Do I have to send it somewhere via UART? I've seen that the UART peripheral is already being initialized, it is not already implemented in the code?

Thank you in advance.

Greetings,

Eñaut

Hello Eñaut,

I will put you in contact with a college who is the expert in PropRF to give you some advise on this. Please bear with me.

BR,

David.

Hi Eñaut,

Eñaut Fernandez said:

I have been reading about it and testing it and I think it would be a potential solution. I have made also tests using the one with RTOS and the one without and the consumption of the program without RTOS is slightly lower so it fits better for my application. But I am not sure if it works like a beacon or not, as I have seen that there is a syncword, does it mean that the receiving launcpad has to connect to the transmitting one? It would be possible to make a beacon with the PropRF?

Please see this post: https://e2e.ti.com/support/wireless-connectivity/bluetooth-group/bluetooth/f/bluetooth-forum/1301556/cc2340r5-building-equivalent-of-tida00759-ble-pir-sensor

If you need more details about the current spike during device boot (seen as ~23mA in the ET shots), I recommend to submit a separate post.

Note that for RTOS, the initial setup time at ~3.8mA is a one time cost after device boot. If you are constantly re-booting, then I agree the noRTOS one makes sense. Otherwise, the RTOS one may provide better application development flow. Of course this all depends on what your application needs.

Eñaut Fernandez said:

Apart from that, I have used SmartRF studio 8 to make some tests and the data is reaching correctly to the other Launchpad. However, when flashing the rfPacketTx and rfPacketRx programs into the launchpads, I don't know how to visualize the data that is getting to the RX launchpad. Do I have to send it somewhere via UART? I've seen that the UART peripheral is already being initialized, it is not already implemented in the code?

The data will be located in the buffer you set in the RX cmd (uint32_t buffer[NUM_DATA_ENTRIES][BUFF_STRUCT_LENGTH/4];).
In the debugger, you can check this buffer where you should see the data sent from the rfPacketTx. There is also some headers within the buffer, but you can calculate the index of the actual data and use that index for the future development.

Thanks,
Toby

Hi Toby,

Thanks for answering. About the post, does it use the bluetooth protocol itself or it only uses the physical part of it? I guess it doesn't as I can't see it in the mobile app (Simple link connect).And if not, there would be any way to send the data in the bluetooth protocol using that program (PropRF)? Because now I know that I can send data using PropRF and it kind of works for me but it would be useful to also make a bluetooth beacon so that does not use as much energy as the basic_ble one. 

About the RTOS the energy when booting the device is critical for me, and also I will be re-booting constantly so it makes sense not using it.

Greetings,

Eñaut

I will look into and provide an update within 3 business days.

Eñaut Fernandez said:

About the post, does it use the bluetooth protocol itself or it only uses the physical part of it?

It does not use BLE stack. It just uses a packet which looks like a BLE packet.

It is only sending advertising packets, no BLE connection.

Eñaut Fernandez said:

it would be useful to also make a bluetooth beacon so that does not use as much energy as the basic_ble on

Please refer to the Bluetooth LE spec on how to format its packets.