• State TI Thinks Resolved
  • Locked Locked
  • Replies 18 replies
  • Answers 1 answer
  • Subscribers 54 subscribers
  • Views 1119 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

LAUNCHXL-CC1352R1: Low power, UART and flow control signals...

Peter Blomqvist
Prodigy 80 points
Part Number: LAUNCHXL-CC1352R1
Other Parts Discussed in Thread: TL16C550C, SYSCONFIG

(The HW used is actually 1352 LPSTK - but i found no such part number. But i hope it will be close enough)

We are confused about the UART HW FC signals together with low power on 1352:
Using the "XX" driver in "callback mode" we learned that we need to remove the RX callback for TI driver to allow sleep.
With the callback in place CPU runs and draws about 1mA+, without the consumption is reasonable.

So - removing the RX callback reduces CPU draw as mentioned above, the RXEN bit in the UART peripheral
is set to false, so the UART peripheral knows it is in a state where RX is disabled. But, the RTS flow control signal stays low in this mode (i.e stays asserted):
With HW FC the RTS should be de-asserted when UART RX is disabled - since other end of UART will send due to asserted RTS and data loss results.
Below i have attached a plot where "ARC GP1" (second plot from the bottom) is toggling from asserted to de-asserted (as expected) when we "flood" the UART FIFO.
However at min about 6:45 there is a 10s window where UART RXEN is set to false, but RTS is still asserted and this results in data loss. 

Is there any workaround that we can use to make sure that RTS is de-asserted when the UART RXEN is set to false?

Best
Peter

  • 0
    TI__Intellectual 2115 points

    Hi Peter,

    Could you also specify which simplelink SDK version are you using in your application?

    Regards,

    Fausto

  • 0 in reply to Fausto C
    Prodigy 80 points

    Thanks Fausto,

    We certainly have an ancient version of the SDK, but updating will be an effort, and the observations i pointed out 
    are really HW related - it may be that a more recent SDK has a driver wich handles the issue i described with SW.
    But unless we get a confirmation that a certain SDK version solve the problem i am reluctant to upgrade.

    Best regards

    Peter

  • 0 in reply to Peter Blomqvist
    TI__Intellectual 2115 points

    Hi Peter,

    Knowing the SDK version is a way for me to align on the SW version you are using and try to replicate the issue. As you say, it might be that an HW issue gets handled at the SW level, when discovered. Therefore knowing which SDK version you are using allow me to see the delta between the SW you are running and the latest release. 

    Regards,

    Fausto

  • 0 in reply to Fausto C
    Prodigy 80 points

    It is SDK version 4.10.

    Thanks Fausto!

    /Peter

  • 0 in reply to Peter Blomqvist
    TI__Intellectual 2115 points

    Hi Peter, 

    I have one more question for you when reading you initial post. You are saying that you are using the "XX" UART driver. But you are running your application on a CC1352 device that should be running the UART2CC26X2 driver. Is it just a mistake in the post or you are willingly using the driver for older devices?

    Regards,

    Fausto

  • 0 in reply to Fausto C
    Prodigy 80 points

    Hi Fausto,

    Correct, we do use the "XX" driver on CC1352. One reason is that Contiki for 1352 was built using "XX" driver.
    Initially trying to get HW FC to work at all we tried the "X2" driver but we did have some issues at that time.
    We also have been looking at the differences in the drivers but found nothing obvious.

    Best
    Peter

  • 0 in reply to Peter Blomqvist
    Prodigy 80 points

    One more thing Fausto,

    The documentation for CC1352 states that "The CC13x2 and CC26x2 UART is similar in functionality to a 16C550 UART, but is not register compatible."
    Is this datasheet applicable for CC1352? 
    https://www.ti.com/lit/ds/symlink/tl16c550c.pdf

    It does state that the "AUTO Flow Control" RTS is triggered by FIFO state, but without "AUTO Flow Control" it is controlled
    from the MCR - is this applicable for CC1352 as well? I'm thinking - if UART logic for RTS only is triggered by FIFO state it
    appears as one need to set the RTS manually?

    Best
    Peter

  • 0 in reply to Peter Blomqvist
    TI__Intellectual 2115 points

    Hi Peter,

    I'm looking into this issue and I was wondering:

    1- Have you you used the UART_CMD_RXENABLE/ UART_CMD_RXDISABLE commands in your application? Cause this might be a reason why you are having issues with power consumption. As setting UART_CMD_RXENABLE with UART_control() allows UART to receive continuously even when you are not calling UART_read(). 

    2- When you say you have removed the callback, does it mean you are now using the UART driver in UART2_Mode_BLOCKING or that you are not providing a callback function but still using it in UART2_Mode_CALLBACK?

    Regards,

    Fausto

  • 0 in reply to Fausto C
    Prodigy 80 points

    We did not use the Ecplicit commands to the uart - we used UART in callback mode - which prevents low power as
    long as rx callback is set, when we unset rx callback low power as such works.

    But the problem we experience is that the RTS out of the UART in low power is low - which means 
    that other end is transmitting data that is lost.

    So the question is really - how can we have low power and proper signalling to other end of the UART?

    Best
    Peter

  • 0 in reply to Peter Blomqvist
    TI__Intellectual 2115 points

    And how do you manage to receive data if the you are using UART in callback mode but without a callback function? Not having a callback mechanism will not allow you to know when the RX transaction has completed.

    I'm still investigating the RTS issue you are seeing, as I haven't been able to reproduce it yet and we haven't had any other customer reporting it before. Also is it consistently appearing after a certain time or with what frequency does it appear?

    Regards,

    Fausto

  • 0 in reply to Fausto C
    Prodigy 80 points

    Removing callback was the only way we was able to go to low power - it happens only at "completed" receptions.
    Do you have another recommendation how to enable low power with callback mode?
    Or do we need to use blocking mode?

    We do see the RTS problem consistently: Do you have an SDK version / setup where this works with low power?
    If so that would be a good hint on how to avoid this problem. 

    Best
    Peter
     

  • 0 in reply to Peter Blomqvist
    TI__Intellectual 2115 points

    Hi Peter I have found in the documentation of the UART driver you are using (SDK folder/docs/tidrivers/tidriversAPIs.html -> click on UARTCC26XX.h) a good description of when the device is/isn't allowed to enter standby while using the UART driver:

    I can see the device going into standby both in callback and blocking mode when it is allowed to do so. And I don't see any difference in how the power management is handled between blocking and callback mode. So I believe what you are seeing is falling under one of the conditions highlighted in the documentation. 

    I'm still looking into the CTS problem you're seeing.

    Regards,

    Fausto

  • 0 in reply to Fausto C
    Prodigy 80 points

    There's interesting wording there: 
    "Call UART_readCancel() to disable RX thus assuring that no data is received while entering standby"
    One would like to think that  "assuring no data is received while entering standby" would with FC mean
    that the RTS is de-asserted to block transmission to the TI UART. 
    (We do not have any problems with CTS in TI end, only RTS)

    Best

    Peter

  • 0 in reply to Peter Blomqvist
    TI__Intellectual 2115 points

    Sorry Peter,

    I meant to say RTS. And I'm working with the same SDK version you use (4.10) to see if I can reproduce. So all my power management results are observed on SDK 4.10.

    Regards,

    Fausto 

  • 0 in reply to Fausto C
    Prodigy 80 points

    Fausto, We moved to SDK version 5.20 and tried UART_CMD_RXDISABLE .
    We do not observe any change to RTS issuing the command. 

    Best
    Peter

  • 0 in reply to Peter Blomqvist
    TI__Intellectual 2115 points

    Hi Peter, 

    Sorry for the late reply. 

    I agree with you that this seems to be a specific HW behavior. RTS seems to be only tied to the RX FIFO state and not the RX enable register of the UART  peripheral. This seems to be the intended behavior as it is specified in the technical reference manual and in the TL16C550C datasheet you linked above. However I do understand your use case and it seems useful that RTS gets de-asserted automatically when the UART peripheral is not actively receiving data.

    I filed a ticket with SW R&D to evaluate the possibility of handling this in SW on future SDKs. Though, if that is accepted, it would be on the UART2 driver and not on the UART driver (now deprecated) that you are using.

    One workaround I can think of, to cover your use case, is setting the RTS pin in sysconfig to be "high" when not in use. This causes the GPIO to transition high when the UART driver is closed with UART_close() and the pin is deallocated.

    I also saw that when disabling auto RTS (register UART0:CTL:RTSEN set to 0), the RTS pin can be manually controlled using the UART0:CTL:RTS register. This is something our driver does not support but the peripheral do, in case you want to have full control over the RTS pin.

    Regards,

    Fausto

  • 0 in reply to Fausto C
    Prodigy 80 points

    Thanks Fausto,

    We were aware of that sysconfig can set the PIN high when not in use but it makes perfect sense.
    The other option disabling auto RTS is something that has crossed my mind, i guess it should be doable controlling it via the 
    IRQ for FIFO fill rate.

    Best

    Peter

  • 0 in reply to Peter Blomqvist
    TI__Intellectual 2115 points

    You're welcome Peter. I will close this thread if you don't have additional question. But feel free to post any follow up question later on and we will continue the discussion.

    Regards,

    Fausto