CC2340R5: Bluetooth causes thread not to work

Hi,

Thank you for reaching out. I would suggest using 8.10 as your SDK as it has some additional improvements, fixes and new features. We will look into the behavior you are seeing and get back to you as soon as possible.

Best Regards,

Jan

Hi, Jan

After my testing, I found that if I did not connect successfully, but I called the disconnect function, it seemed to cause problems. Or if I start the scan and call the start scan again before pausing the scan, there seems to be a problem. I want to confirm if this is causing my thread to have a problem?

Hello Ryan,

May I ask how do you validate if the connection or disconnection has been established? Are you using BLEAPPUTIL_LINK_ESTABLISHED_EVENT or BLEAPPUTIL_LINK_TERMINATED_EVENT triggered by the the handler callback function?

BR.

David.

Hi , David

I tested and found that when I called BLEAppUtil_invokeFunctionNoData to make the thread disappear, ttt would not be equal to 11, which means it crashed after executing BLEAppUtil_enqueueMsg.

I think it has nothing to do with the connection, because this problem occurs when I call Start Scan and Stop Scan.

Hello Ryan,

I think the problem might be that we are not registering the new thread in ICall(). The ICall BLE-Stack service serves as the application interface to BLE-Stack APIs. When a BLE-Stack API is called by the application internally, the ICall module routes the command to the stack and routes messages from the stack to the application when appropriate. Please take a look at this section of the user guide on how to ICall register the task:https://software-dl.ti.com/simplelink/esd/simplelink_lowpower_f3_sdk/8.10.00.55/exports/docs/ble5stack/ble_user_guide/html/freertos/tasks.html?highlight=icall%20register#creating-additional-icall-enabled-tasks. However I would expect a different error if this is not the case, such as an ICall Abort.

BR.

David.

Hi , David

After testing today, I found out that it seems to be because UART_writeMode is set to BLOCKING mode. Before calling most Bluetooth functions, I will use UART to transmit the current stage of Scan or Connect, etc. If I call UART2_write immediately after calling Bluetooth The function of the bud seems to cause problems. I tested changing the writeMode to NONBLOCKING. The test has been running normally so far. Can this part help me confirm? Is this related to what you said about not registering a new thread in ICall()?

Hello Ryan,

Okay, I see. Could you please take a look at the last answer from this thread that I believe can give us a good starting point to test (regarding the task priority):https://e2e.ti.com/support/wireless-connectivity/bluetooth-group/bluetooth/f/bluetooth-forum/1405164/lp-em-cc2340r5-can-uart2_write-and-uart2_read-not-be-used-in-the-same-task/5417015#5417015. Also, if using the NONBLOCKING mode make sure you have the right buffer size for your application, which I guess you have at the moment considering it is working as expected.

I would have expected an ICall Abort related error if the issue was related to non register tasks.

BR,

David.

Hi David,

1.According this post,Do you mean UART Interrupt Priority set lower , so CC2340 UART thread disappear? 


2.if I set UART write Mode is NONBLOCK , then do I also need to increase the TX Ring Buffer Size?

3.ICall_abort() also happened to me at the time, but at that time I thought it was because I did not use BLEAppUtil_invokeFunctionNoData() to call Bluetooth-related functions.

Hello Ryan,

It think it means the task priority, not the UART interrupt priority. You need to increase the ring buffer size only if you are not receiving the entire amount of data at the moment.

BR,

David