cancel
Showing results for 
Search instead for 
Did you mean: 

WICED Studio Bluetooth

JoOr_4004241
New Contributor II

I'm using WICED Studio v6.2 to develop an application for the CYW20719. I will be using the peripheral UART to communicate with another application running on an MCU. I'm using a RX buffer and a TX buffer to handle the serial data and using a separate wiced_mutex_t object to control access to each buffer.

I call wiced_hal_puart_register_interrupt() to install my RX data handler. In order to prevent any deadlock issues, I'd like to know on what thread my RX interrupt handler will run. Is it actually an interrupt service routine that interrupts the main app thread or is it running on a different thread?

0 Likes
1 Solution
AnjanaM_61
Moderator
Moderator

Hello,

It comes in the application thread.

There is no direct interrupt to the user. The user gets a callback which he needs to register.

(Refer : /20719-B1_Bluetooth/apps/snip/hal/puart in WICED SDK)

Thanks,

Anjana

View solution in original post

3 Replies
AnjanaM_61
Moderator
Moderator

Hello,

It comes in the application thread.

There is no direct interrupt to the user. The user gets a callback which he needs to register.

(Refer : /20719-B1_Bluetooth/apps/snip/hal/puart in WICED SDK)

Thanks,

Anjana

View solution in original post

JoOr_4004241
New Contributor II

Anjana,

Thank you for your response.

So, if I lock/unlock a mutex in my registered RX handler callback function and lock/unlock the same mutex in another part of my main application thread, is there a potential for a deadlock (RX callback runs between the lock/unlock in the main app thread) or would the mutex be ineffective because both locks are requested on the same thread?

Joe

0 Likes
AnjanaM_61
Moderator
Moderator

Hi Joe,

There should not be deadlock . However it depends upon your application implementation.

If you explain the sequence of lock & unlock mutex in your application , we may able to understand the context better.

Thanks & Regards,

Anjana