On what thread does WICED RX interrupt handler run?

Tip / Sign in to post questions, reply, level up, and achieve exciting badges. Know more

cross mob
JoOr_4004241
Level 3
Level 3
25 sign-ins 10 replies posted 5 replies posted

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
Moderator
5 comments on KBA First comment on KBA 5 questions asked

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
Moderator
5 comments on KBA First comment on KBA 5 questions asked

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

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

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