CC2564B: Wake Up Support by CTS?

Hi,

Please see http://processors.wiki.ti.com/index.php/CC256x_eHCILL_Low_Power_Protocol

If you are using the latest release of Bluetopia version 1.2 R2, It already includes sleep mode.

Bluetopia uses VS_Enable_Sleep_Mode() API to enable sleep. and using the macro HCI_DRIVER_SET_COMM_INFORMATION you are registering your app to use the specified HCI Protocol 

Hi Sundeep,

   Thanks for the confirmation. Even my understanding is that, Bluetopia will be taking care of the same.

We have following code and we have the call back function.

----------------------------------------------------------------------------------------------------------------------------

         HCILLConfig.SleepCallbackFunction        = HCI_Sleep_Callback;
         HCILLConfig.SleepCallbackParameter       = 0;
         DriverReconfigureData.ReconfigureCommand = HCI_COMM_DRIVER_RECONFIGURE_DATA_COMMAND_CHANGE_HCILL_PARAMETERS;
         DriverReconfigureData.ReconfigureData    = (void *)&HCILLConfig;

         /* Register the sleep mode callback.  Note that if this        */
         /* function returns greater than 0 then sleep is currently     */
         /* enabled.                                                    */
         Result = HCI_Reconfigure_Driver((unsigned int)Result, FALSE, &DriverReconfigureData);

----------------------------------------------------------------------------------------------------------------------------

  My understanding is that, when HCI_Sleep_Callback is called, Bluetopia would have performed these eHCILL Sleep commands and Tiva can enter to sleep mode.

  Our use case scenario requires BTLE packet transmission for every 500ms.

   Please let us know whether we need to explicitly call the VS_Enable_Sleep_Mode.

Thanks in advance,

Best regards,

Gupta

Hi,

In the latest release of Bluetopia version 1.2 R2, by default the sleep is enable and if you have inactivity over UART for 100ms,the CC256x will go to sleep. and when there is data it will wake up.

Hi Gupta,

Some additional information.

Hardware flow control on the Tiva platform is enabled by default.

Since none of the sample codes enter into any sleep mode it was not necessary to do anything manual with RTS/CTS because the CPU (host processor) is never put in a low power state and thus can always receive UART data.

If you are actually putting the processor into a lower power state you will need to change HCITRANS to manage RTS/CTS when entering a low power mode.  They will probably need to configure RTS/CTS as GPIOs temporarily, rather than being controlled by the UART, during this period.

you might see that the HCI_Sleep_Callback() is been called, That just means that the controller is asleep (which it has informed us of this via HCILL) and thus the we could put the processor to sleep here.  It does not mean that the processor is actually asleep.

Hi Sundeep,

   Thanks for the recommendations. I did try to change the RTS Line to GPIO line and set the output to Logic 1 in HCI_Sleep_Callback() . But, unfortunately, I am not seeing any change in the behavior of the RTS line coming from BT Chip. I am using UART4 on Port K line. So, i change the GPIO functionality and in this function call back.

    // Change RTS line status to One
    GPIOPinWrite(GPIO_PORTK_BASE, GPIO_PIN_2, GPIO_PIN_2);
    GPIOPinTypeGPIOOutput(GPIO_PORTK_BASE, GPIO_PIN_2);

   I think, before sending ack to HCILL_SLEEP_IND we need to change the state of RTS line i believe. But with current modifications in the call back, not sure whether this timing is achieved. Can you please confirm me whether this is the right place or need to have alternate method for supporting this.

Thanks in advance,
Best regards,
Gupta

Hi,

Please see below the response I have received internally:

There should be no problem regarding the timing of sending the sleep acknowledgment to the chip and the raising of RTS by the host processor. Usually the way we handle this is the following sequence:

1. Controller sends HCILL Sleep Indication to Host
2. HCITR_COMProcess passes the HCILL Sleep Ind to the stack, HCILL driver processes it by sending the HCILL Sleep Confirmation to HCITR_COMWrite, then immediately calling the Sleep Callback with SleepAllowed=TRUE.
3. In the Sleep Callback when SleepAllowed = TRUE, if they want to put the host processor to sleep at that exact moment, they should flush the UART buffers to ensure the Sleep Confirmation is sent out, as well as setting CTS up as an interrupt and raising RTS, and noting that they have suspended the UART in their HCITRANS driver.
4. When the host needs to wake up either because of the application wanting to send Bluetooth data or because the CTS interrupt is triggered by the controller wiggling its RTS line, they need to follow a wakeup procedure where they turn off the CTS interrupt, reinitialize their UART (if needed) and then lower RTS. If it is a locally initiated wakeup then HCILL will automatically send the Wakeup Indication byte to the controller, otherwise the radio will send us a Wakeup Indication after the host lowers RTS. Either way it should be handled automatically.
5. At some point during the wakeup process they will get another Sleep Callback with SleepAllowed=FALSE, but at that point the host should already be aware it needs to wake up.

Hi,

I did the same way as told in step 3. But I don't see any interrupt on CTS line.

Hi,

The following are the steps carried out by me.

1. When Sleep_callback function is called, I'm checking the UART FLAG register (to see if the FIFO buffer is empty i.e bit UART_FR_TXFE).

2. After the bit UART_FR_TXFE is set(i.e UART buffer is empty), RTS line is set as GPIO input line and set 1.

3.Instead of using CTS line directly to receive CTS wakeup indication, We have another GPIO line connected to CTS line. So I'm enabling that GPIO line as interrupt line to receive wakeup indication. We have registerd callback function for that GPIO interrupt line. Now I dont see that callback function being called.

Thanks, 

Nishal

Hi,

               First of All, I would like to confirm that the latest “CC256XM4BTBLESW v1.2R2” release has HCILL enabled and the CC2564 is going to sleep as expected. There are different ways to verify it on your side by either monitoring the CC2564 current consumption or tracking the HCILL protocol in the UART. It is important to note that this Tiva release does not enable the CC2564_RTS pulse functionality to indicate it is waking up, given that the Tiva MCU can wake up directly from a UART RX transaction. To enable the CC2564_RTS pulse, the HCILL_CTS_PULSE_WIDTH variable (@BTPSVEND.c) should be changed to a different value than 0. e.g 0x64 (100us).

Initialization Complete.
OpenStack().
HCI_VS_InitializeAfterHCIReset
VS_Update_UART_Baud_Rate success.
HCI_VS_InitializeAfterHCIReset Success
Bluetooth Stack ID: 1
Device Chipset: 4.0
BD_ADDR: 0x84dd20f0d2c5

******************************************************************
* Command Options: Server, Client, Help                          *
******************************************************************

Choose Mode>Server

******************************************************************
* Command Options: Inquiry, DisplayInquiryList, Pair,            *
*                  EndPairing, PINCodeResponse, PassKeyResponse, *
*                  UserConfirmationResponse,                     *
*                  SetDiscoverabilityMode, SetConnectabilityMode,*
*                  SetPairabilityMode,                           *
*                  ChangeSimplePairingParameters,                *
*                  GetLocalAddress, GetLocalName, SetLocalName,  *
*                  GetClassOfDevice, SetClassOfDevice,           *
*                  GetRemoteName, SniffMode, ExitSniffMode,      *
*                  Open, Close, Read, Write,                     *
*                  GetConfigParams, SetConfigParams,             *
*                  GetQueueParams, SetQueueParams,               *
*                  Loopback, DisplayRawModeData,                 *
*                  AutomaticReadMode, SetBaudRate, Send          *
*                  Help, Quit                                    *
******************************************************************

Server>Inquiry

Server>
Server>

0486.SPPDemo_App_Trace_Details.docx

5141.SPPDemo_App_UART_SleepCB_Traces.logicdata

               The traces attached show the UART lines as well as the Tiva_PD5 pin (toggled in HCI_SleepCallback) for the sequence shown in the “SPPDemo_App_Terminal_Logs.txt“ file. The SPPDemo app w/TI_RTOS for the DK-TM4C129X is used with the modifications below (Project: C:\TI\Connectivity\CC256X BT\CC256x M4 Bluetopia SDK\v1.2 R2\Cortex_M4\Sample\SPPDemo\TI_RTOS\CCSv5).

######################## @ BTPSVEND.c ########################################

   /* The following represents the default CTS Pulse Width (in          */

   /* microseconds).  The Bluetooth Controller will pulse the CTS with a*/

   /* pulse of this width when attempting to wakeup the Host processor  */

   /* (to allow a mechanism of waking the Host from a low power mode).  */

#ifndef HCILL_CTS_PULSE_WIDTH

   //#define HCILL_CTS_PULSE_WIDTH                               0x00

   #define HCILL_CTS_PULSE_WIDTH                               0x64 // Miguel = 100us

#endif

#############################################################################

######################## @ Main.c ############################################

   /* The following is the HCI Sleep Callback.  This is registered with */

   /* the stack to note when the Host processor may enter into a sleep  */

   /* mode.                                                             */

static void BTPSAPI HCI_Sleep_Callback(Boolean_t SleepAllowed, unsigned long CallbackParameter)

{

//xxx Monitor low power state

       //Display(("\r\nEntered Sleep Mode.\r\n")); // Miguel

       GPIOPinWrite(GPIO_PORTD_BASE, GPIO_PIN_5, GPIOPinRead(GPIO_PORTD_BASE, GPIO_PIN_5)?0:GPIO_PIN_5);

}

#############################################################################

Regards,

Miguel