• State
  • Locked Locked
  • Replies 9 replies
  • Subscribers 54 subscribers
  • Views 2253 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.

RTOS/CC1310: Closing uart (but only in callback mode) adds additional current

Juergen Wickenhaeuser
Prodigy 250 points
Part Number: CC1310


Tool/software: TI-RTOS

Hi Forum,

I found something strange (using Simple Link Studio CC13x0 2.20.0.38): After closing an uart, that was opened in callback mode, the sleep current raised form several uA to something 1 mA (or with the emulator connected (external supply) from 1.8 mA "sleeping" to  2.1 mA).

I found out, that after an active read in callback mode seems to be the problem. Even if the read was canceled before closing.

If I re-open and close the uart again (in blocking mode) everythings works as expected (lines marked with /* TEST.. */

Is this a bug or did I foregt something?

Thanks for your comments,

Juergen

int16_t modem_open(void){

    UART_Params uartParams;
    UART_Params_init(&uartParams);
    uartParams.writeDataMode = UART_DATA_BINARY;
    uartParams.readDataMode = UART_DATA_BINARY; 
    uartParams.readReturnMode = UART_RETURN_FULL;
    uartParams.readEcho = UART_ECHO_OFF;
    uartParams.baudRate = 115200;  

    uartParams.readMode = UART_MODE_CALLBACK;
    uartParams.readCallback = _modem_uart_read_cb;
    uartParams.writeMode = UART_MODE_CALLBACK;
    uartParams.writeCallback = _modem_uart_write_cb;

    modem_uart = UART_open(CC_MODEM_NOFLOW, &uartParams);  // global
    if(!modem_uart) return -1004;  

    UART_control(modem_uart, UARTCC26XX_CMD_RETURN_PARTIAL_ENABLE, NULL); // 
    UART_read(modem_uart, modem_rx_buf , (MODEM_LRX_BUFSIZE/4));  // max 1/4 buffer in one step /***PROBLEM***/

    return 0;
}

void modem_close(void){
    if(modem_uart) {
        UART_readCancel(modem_uart);
        UART_writeCancel(modem_uart);
        UART_close(modem_uart);

        UART_Params uartParams; /* TEST */
        UART_Params_init(&uartParams); /* TEST, def. mode: no callbacks  */
        modem_uart = UART_open(CC_MODEM_NOFLOW, &uartParams); /* TEST, dummy open */
        UART_close(modem_uart); /* TEST, close again*/

        modem_uart=NULL;
    }
}

  • 0
    TI__Mastermind 23636 points
    Hello Juergen,

    It looks like you are doing what needs to be done before setting the device in standby mode. Please try the following:

    add UART_control(uart, UART_CMD_RXDISABLE, 0) after calling readCancel and see if this works. If this does not work try replacing readCancel with UART_control(uart, UART_CMD_RXDISABLE, 0).

    Let me know if it fixes the issue I will be researching on my end while I wait for a reply.

    Regards,
    AB
  • 0 in reply to AB
    Prodigy 250 points

    Hi AB,

    no, both did not help. Only way (currently) seems to be to a dummy open/close.

    (In a non-emulator environment my system needs abt. avg. 10uA (wake up for 100usec each second and a low I_q Voltage regulator in front), with the error above current stays at 1.100 mA. )

    Best regards,
    Juergen

  • 0 in reply to Juergen Wickenhaeuser
    TI__Mastermind 23636 points
    I will forward this to the appropriate team to determine if it is a bug or expected behavior.
  • 0 in reply to AB
    TI__Mastermind 23636 points
    Hello Juergen,

    Can you provide some more information on your setup? If you run the uartecho example on your setup and switch between both CB mode and blocking mode, do you see the same behavior.

    The UART team is taking care of the issue at the moment but we need more information.

    Thanks in advance,
    AB
  • 0 in reply to AB
    Prodigy 250 points

    Hello AB,

    ok, I isolated the Error on a CC1310 Launchpad. The Software opens/closes the uart with both versions, and sleeps 10 secs inbetween. If closing "twice" the current goes down to 2uA on my Launchpad, if flosing "single", the current stays arround 0.7 mA

    HowTo:

    • install the project "empty" from the demos for the cc1310 launchpad, rplace empty.c with my version and add the modem_k.h/.c
    • Compile and download
    • remove ALL jumpers and supply the lauincpad with 3.3V
    • the GREEN/YELLOW LED is on, when modem is opened., the RED is used by the modem-driver
    • Now you should see: abt. 2 seconds: 4mA, modem active and alternating each 10 secs: 0.7mA / 0.002 mA

    I hope this helps ;-)

    There is another thing, that I wondered: I use a Semaphore to Signal that an TX-Block is in Transition (line 112 of modem_l.c) . The TX-Finish callback releases the Semaphore (line 143). But in some very rare cases, this seems not to work. So I added a timout to the semaphore (line 121) (because I know the time a outgoing block will need).. Is there a reason why the callback is not triggered?

    Thanks and with kind regards,

    Juergen

    6574.mode_close_nosleep.zip

    PS: BTW (and off-topic and as a 3.rd thing): In my leisure-time I have designed an "Arduino-like"-Version of the Launchpad, including a 2G/3G/LTE-Modem. This board is equipped with a 16MB Flash. It can can store data and periodically transfer it to a server (written in PHP).Since the system is normally "sleeping", it can run with 4 AA batteries for many years, while periodically be "online".

    Everything is running very stable and the libs will be Arduino-style (so very easy to use), while TI-RTOS does the real work in the background. We plan to use this board for education (so it is completely open source). However, for (more difficult) C programming, the XDS110-emulator as it comes with the launchpad is a perfect tool! Is it possible to buy a larger bunch of launchpads from TI? Do you have contacts? As mentioned, the board is for education, where always money is rare... Thanks for any help!!!

    Here the first pictures and shematics and  data:

  • 0 in reply to Juergen Wickenhaeuser
    TI__Mastermind 23636 points
    Hello Juergen,

    Thank you for the detailed description of your debug/problem, this will help us in trying to figure out what could be the cause of this problem.

    As for the Launchpad request, what quantities are we looking at?

    Regards,
    AB
  • 0 in reply to AB
    Prodigy 250 points

    Hmm, I really have NO idea... It is still a hobbyist-project, but I see a very big chance for this kit to jump into the gap between toy and professional industrial IoT solution (because it is equipped with an secure AES-Bootloader with FOTA via Mobile-Internet or local radio, uart, ... ). I think something between 100 and 10 000 could be absolutely realistic. If anything is running fine, we consider also versions with BLE 5.0 (CC1352) et.al...

  • 0 in reply to Juergen Wickenhaeuser
    TI__Mastermind 23636 points
    Hello Juergen,

    We have tried to re create the issue and no luck. Are you still having this problem? Have you updated to latest SDK?

    Regards,
    AB
  • 0 in reply to AB
    Prodigy 250 points

    I can reproduce it with a standard CC1310-Launchpad, connected to a Mobile Modem (Type Telit GE866) over RX/TX/CTS/RTS. The modem sends some dummy bits on power up. So this mght be flagged as (errorneous) characters, which prevent the deep sleep after closing in callback. This is the only thing what I could imagine, but after powering down, the modem is completey disconnected from any CC1310-signals. Since my work-arround is running fine, I can live with that.

    I would suggest: If the problem rises again (e.g. when migrating to the another CC), I'll post it again.

    Best regards, Juergen

    (Btw: about the requested Launchpads (from which only the XDS110-emulator-part is needed): together with some students from our local University (KIT), we are thinking of  founding a new company for the new IoT-platform. Until now everything is running excellent).