This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

CC2540: anyway to use UART with power saving mode?

Other Parts Discussed in Thread: CC2540

hi, when I use cc2540 and it's uart port, it works fine.

But when i changed to PWRMGR_BATTERY by define POWER_SAVING, it will cause a receive data lose. 

I'm not using the hci, neight HCI_EXT_HaltDuringRfCmd  nor  HCI_EXT_ClkDivOnHaltCmd is called.

So, if I want to use UART while power saving, is there anyway to do this?

someone said that one line for interrupt is needed for weak up the cc2540, if it is true, how to do this? 

I saw the code in _hal-uart_dma.c:

#if (HAL_UART_DMA == 1)
HAL_ISR_FUNCTION(port0Isr, P0INT_VECTOR)
#else
HAL_ISR_FUNCTION(port1Isr, P1INT_VECTOR)
#endif
{
HAL_ENTER_ISR();

PxIFG = 0;
PxIF = 0;

dmaRdyIsr = 1;

#ifdef POWER_SAVING
CLEAR_SLEEP_MODE();
(void)osal_pwrmgr_task_state(Hal_TaskID, PWRMGR_HOLD);

#if HAL_UART_TX_BY_ISR
if ( dmaCfg.txHead == dmaCfg.txTail )
{
HAL_UART_DMA_CLR_RDY_OUT();
}
#endif
#endif
HAL_EXIT_ISR();
}
#endif

is it used for this purpose?

By the way, i'm using BLE stack V1.4 and uart DMA mode could not solve the problem.

 

  • http://e2e.ti.com/support/low_power_rf/f/538/t/147510.aspx

    someone use RTS & CTS line for this propuse.   is it could work?

  • BLE stack V1.3 have the follow words:

    Version 1.3
    Dec 12, 2012

    - The physical HCI interface used by the network processor (HostTestRelease)
      has been enhanced to work while power management is enabled on the CC254x 
      device. The UART interface, when using RTS and CTS lines, can be used by an
      external application processor to wake-up the CC254x network processor. When
      the network processor has completed all processing, it will go into deep
      sleep. In addition to UART, an SPI interface has been added as an option for
      the physical HCI interface. It also supports power management by means of 
      the MRDY and SRDY lines.

     

    does somebody know how to do this for non-HCI interface?

     

  • Hi there.


    I seem to have a similar problem.  I confess I need to add some debugging, but thought I'd see what I can find online quickly.

    Basically, with POWER_SAVING enabled, I am able to communicate with the CC2540 when I keep my RTS line pulled low on my MCU, but struggle to do successful comms if I toggle it.

    I try to pull it low 700us before starting comms and wait for my TX buffer to be empty before releasing it again.  I'll try and play with the timing and add some more debug stuff.

    If you have any insight in the meantime I would really appreciate it.  The BLE 1.4 doc refers to using the RTS as well as the CTS lines however...?

  • An update on my scenario - waiting about 10ms from RTS low to start TX and about 10ms from TX buffer empty to RTS high resulted in perfect comms!  I'll try and speed it up later, but for now, I have the following problem...  As soon as I try to make an connection from a central, the device clearly wakes up (I'm monitoring the current), but the device seems to hang.  Connection isn't established and even UART comms to the device thereafter fail.

  • I disabled CTS requirements on the CC2540 and got comms working.  My current issue is that CC2540 seems to stop 'handshaking' (Packets sent between two BLE devices containing the, ao, SequenceNumber and NextExpectedSequenceNumber) after a few seconds, sometimes single digits, sometimes going towards a minute. 

    It's rather difficult for me to debug properly as the disconnect and going to sleep happens ms apart and although I have some debug tools, they're not synced.

    Hoping maybe some of you have sorted their sleep modes and can give some guidance.

  • So my problem was using the internal 32.768kHz RC oscillator.  I had to make a mod to use a crystal we use elsewhere on the board for a RTC on our main mircro and it resolved my problems.

    Cheers

    JD

  • Old thread I know. I was having similar problems and found this interesting comment.
    /* Any ISR that is used to wake up the chip shall call this macro. This prevents the race condition
    * when the PCON IDLE bit is set after such a critical ISR fires during the prep for sleep.
    */
    #define CLEAR_SLEEP_MODE() st( halSleepPconValue = 0; )

    Now the UART ISRs do not use this call but the dma one does. My problem appears to have gone away by adding this to the isr in _hal_uart_isr.c

    i.e.
    #if (HAL_UART_ISR == 1)
    HAL_ISR_FUNCTION( halUart0TxIsr, UTX0_VECTOR )
    #else
    HAL_ISR_FUNCTION( halUart1TxIsr, UTX1_VECTOR )
    #endif
    {
    HAL_ENTER_ISR();
    CLEAR_SLEEP_MODE();
  • Awesome, always good to have more insight on a subject and have it in a central knowledge base for the next person looking for answers. :)