CC2650MODA: UART blocking Sleepmode and increasing current consumption

Hans Raupig

Part Number: CC2650MODA
Other Parts Discussed in Thread: CC2650, SYSBIOS

Tool/software:

Hello,

I am using a CC2650MODA with Bluetooth Stack Version 2.2.8.12 and Simplelink SDK version 6.30.01.03. My application is based on the SimplePeripheral example.

The CC2650MODA is connected to another device via UART which sends a message once a second. It asynchronously receives messages sent by a connected BLE central (PC) and sends answers. The CC2650MODA is configured with two characteristics (one for read, one for write) with a length of 80 characters each.

The CC2650MODA copies the received UART messages into the send characteristic to be read by the BLE central (PC) via Bluetooth. After receiving a message by a connected PC, the CC2650MODA will write this message to the connected device using UART. It will answer to the message by sending specific answer message using the same UART port that is used for the regular 1 second messages. In this example I have not included the reading and answering process, to make the example as simple as possible.

The SBP_PERIODIC_EVT_PERIOD is set to 1000, so the SimpleBLEPeripheral_performPeriodicTask() will be executed once every second.

The SimpleBLEPeripheral_performPeriodicTask() looks like this:

SimpleBLEPeripheral_performPeriodicTask()
{

      UARTCC26XX_read(my_Handle, &my_Buffer, 80);

      SimpleProfile_SetParameter(SIMPLEPROFILE_CHAR4, SIMPLEPROFILE_CHAR4_LEN, my_Buffer);

}

Very simple. The problem is:

My current consumption while connected via bluetooth starts with 1.40 mA and goes down to 0,7 mA over course of 2 hours. After that, it goes up to 1,7 mA at once and slowly decreases to 0,7 mA over time.

What I think that happens is: While the UARTCC26XX_read function is called and waiting for data to come, the UART peripheral is active and blocking the sleep mode. The slow downshift in current consumption can be explained with a timing difference between the connected device and the clock in the CC2650MODA. So the periods the sleepmode is being blocked becomes shorter and suddenly goes to a maximum of 1,7mA.

I have already tried to read the UART bytewise with the callback function, but that will leave the UART peripheral always activated, which means the sleepmode is permanently deactivated, so the current consumption is 1,7mA at all times.

I try to optimize the application for current consumption, so this issue is vital for my project.

Is there a way to stop the active UART peripheral from blocking the sleep mode? Or to optimize the timing to maximize the time in sleep mode?

Thank for your time and help.

8 months ago

0 Ryan Brown1 8 months ago

TI__Guru**** 217367 points

Hello Hans,

Hans Raupig said:
What I think that happens is: While the UARTCC26XX_read function is called and waiting for data to come, the UART peripheral is active and blocking the sleep mode

This is correct, standby mode is blocked during UART_read. I have two ideas for mitigation

The PC starts by sending a dummy byte, and the CC2650 has configured its UART RX pin to instead be a GPIO interrupt so that it can detect the level change from the dummy byte and thus change modes to start UART_read before valid data arrives. This will require a timing agreement from both sides so that UART_read does not accidentally start in the middle of this dummy byte and cause an incoming data bit shift.
Start a timer immediately before the first UART_read and stop it after existing, thus getting the time spent waiting for the UART transaction. This should give you an offset which you can apply to the next periodic task so that you can synchronize with the connected PC. This operation may need to be performed occasionally to prevent drift.

Either of these ideas may not be valid given system configurations which I'm not aware of, however hopefully this gives you a few ideas to try out.

Regards,
Ryan

0 Hans Raupig 7 months ago in reply to Ryan Brown1

Prodigy 11 points

Hello Ryan,

thanks for your quick response. Today I tried implementing your first suggestion. My first question about this approach is: Is it possible to have your UART RX-Pin configurated for UART and hardware interrupt at the same time? When I tried this the UART stopped working.

I also found it very difficult to find useful information about how to configure a GPIO port to trigger a hardware interrupt in this API. I looked through the 'SimpleLink WirelessMCU Technical Reference Manual' but couldnt find anything useful. The 'Technical Reference Manual' gave me more information about this issue, but not about the implementation. Finally I found the Sensortag example in the SDK folder. This example uses GPIO in interrupt mode for user input with a relay.

  hGpioPin = PIN_open(&pinGpioState, SensortagAppPinTable);
  PIN_registerIntCb(hGpioPin, SensorTag_callback);

I identified these two lines as relevant for configuring the GPIO pin for interrupt. Also how it is initialized in the PinTable.

Either the callback function is not being called, I dont see the device advertising or the UART is not working. But I couldnt get this approach to work.

I find it very difficult to get definite information about the usage of this API. Is there further documentation about the syntax? Can you tell me where I can look this up?

Thank you for your help. It is greatly appreciated.

0 Ryan Brown1 7 months ago in reply to Hans Raupig

TI__Guru**** 217367 points

Hans Raupig said:
Is it possible to have your UART RX-Pin configurated for UART and hardware interrupt at the same time?

No, you would need to reconfigure the pin in between functions

Hans Raupig said:
I identified these two lines as relevant for configuring the GPIO pin for interrupt. Also how it is initialized in the PinTable.

There should be supporting Board.h and LaunchPad .c/.h files which initialize the pin table

Hans Raupig said:
I find it very difficult to get definite information about the usage of this API. Is there further documentation about the syntax? Can you tell me where I can look this up?

There should be a docs folder in the SDK which explains these APIs.

I apologize for the lack of support in the CC2650MODA device and SDK as it is and older part which has been supersedes by the newer Simplelink F2 SDK devices. www.ti.com/.../SIMPLELINK-LOWPOWER-SDK

Regards,

Ryan

0 Hans Raupig 7 months ago in reply to Ryan Brown1

Prodigy 11 points

Hello again,

I managed to make the receiving by Interrupt work, by shortcutting the UART RX PIN to another GPIO pin. What happens now is, that the UART Message is received by two PINS. One for Interrupt and one for UART stuff. What bothers me is, that the example in the documentation about the implementation of HWI did not work at all. I coincidently found an implementation of a Hardware Interrupt in the PIN_INIT function in PINCC26XX.c:

    Hwi_Params_init(&hwiParams);
    hwiParams.priority = PINCC26XX_hwAttrs.intPriority;
    Hwi_construct(&PinHwi, INT_AON_GPIO_EDGE, PIN_hwi,&hwiParams, NULL);

This code works and the PIN_hwi(UArg arg) gets called, when the PIN I configured for Interrupt is triggered.

What I found in the documentation is:

Hwi_Params_init(&hwiParams);
hwiParams.arg = 10;
hwiParams.enableInt = FALSE;
myHwi = Hwi_create(5, myIsr, &hwiParms, &eb);

I could not find any Information about the Hwi_construct function in any of the documents available.

It is not possible to disable the Interrupts with hwi_disable, but I need to do so, because receiving a whole message will trigger the Interrupt Service Routine several time and distorts the received message.

Do you have any hints how I can properly implement the Hardware Interrupt?

Thank for your Help!

0 Ryan Brown1 7 months ago in reply to Hans Raupig

TI__Guru**** 217367 points

Hello Hans,

May I ask why you are using the SYS/BIOS HWI hal instead of the PIN TI Driver? Have you tried using Hwi_destruct instead?

PIN TI Driver: tirtos_cc13xx_cc26xx_2_21_01_08/products/tidrivers_cc13xx_cc26xx_2_21_01_01/docs/doxygen/html/_p_i_n_8h.html
SYS/BIOS: tirtos_cc13xx_cc26xx_2_21_01_08/products/bios_6_46_01_38/docs/cdoc/index.html, module ti.sysbios.hal.Hwi

Regards,
Ryan

Bluetooth®︎

Bluetooth forum

CC2650MODA: UART blocking Sleepmode and increasing current consumption