• State
  • Locked Locked
  • Replies 5 replies
  • Subscribers 51 subscribers
  • Views 278 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.

CC2340R5: The second UART2_Open will fail after usleep(200000)

Ryan Li
Intellectual 480 points
Part Number: CC2340R5

Tool/software:

SDK version:7.40.00.64

CCS version:12.7.0

After I first use UART_write to transmit the message, UART2_open will fail if the UART is turned off for 200ms and then turned on. I observed that the process failed after entering HwiP_disable(). Is it related to the ISR context call? If so, how should I solve it?

  • 0
    TI__Mastermind 35030 points

    Hi,

    I tried this and don't see the same issue. (This is with my assumption that uart_write_flag != 0, and output[0] != 0).

    In your case, is it possible at all that uart_write_flag is 0?
    If yes, then it is possible that code sequence looks like:

    1. UART2_open
    2. usleep(200000);
    3. UART2_open

    In this case, the second UART2_open is expected to fail.

    In this exact code, I'd recommend to place the first UART2_open within the block "if(uart_write_flag)".

    Thanks,
    Toby

  • 0 in reply to Toby
    Intellectual 480 points

    Hi,Toby

    I can run the project normally using uart2callback, but as long as I use the basic_ble project, the situation described in the article will occur. After testing, I found that this situation will occur when "appMain" is called.

  • 0 in reply to Ryan Li
    TI__Mastermind 35030 points

    What I think is happening is that UART2_open may be called twice in a row, without a UART2_close in between.

    Is UART2 only used/managed in a single thread? Or are there multiple threads attempting to access it?

    This may happen in a BLE project because there are multiple tasks running (BLE app, BLE stack, etc).

    Can you try this:

    Toby said:
    In this exact code, I'd recommend to place the first UART2_open within the block "if(uart_write_flag)".

    Or any other method to ensure that:

    1. UART2_open / UART2_close is one-to-one
    2. UART2_open is not called twice in a row

    For example, a mutex/semaphore could help.

  • 0 in reply to Toby
    Intellectual 480 points

    Hi, Toby,

    I confirm UART2 only used in a single thread. 
    I try to place the first UART2_open within the block "if(uart_write_flag)". but still happen.

    I speculate that although usleep(200000) is used, the execution thread may run to execute Bluetooth or it may not actually execute UART2_close, so this situation occurs?

  • 0 in reply to Ryan Li
    TI__Mastermind 35030 points
    Ryan Li said:
    I speculate that although usleep(200000) is used, the execution thread may run to execute Bluetooth

    Yes, that is very possible. The current task will yield after you call usleep, so then other tasks can run. Then Bluetooth stack task can run. Or Bluetooth stack task could pre-empt the application task (I believe by default the stack task is higher priority than the app task).

    But after the stack task yields, then the app task should resume closing UART.

    If the first "if(uart_write_flag)" block is entered, and the second "if(output..." block is expected to enter, then by the time this UART thread calls usleep, the UART_close would've finished executing.

    Can you place some counters at end of UART_open and end of UART_close to confirm?

    You can copy directly the UART files into your project to single step through. Specifically the ones here: \source\ti\drivers\uart2