"pop_from_queue" not working.

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

cross mob
ChCh_3584941
Level 4
Level 4
50 sign-ins 25 replies posted 25 sign-ins

I've written a small test program just to verify that I understand the queue API's in the rtos module.

I've  created a thread that simply prints a log message to the PUART and toggles a GPIO, and I've set up an Interrupt routine for a Button.  The goal is to use the message queue to trigger and communicate from the Interrupt Handler to the Thread.

First as a test, If I created and initialized a semaphore, and then 'set' the semaphore in the Interrupt handler and 'get' the semaphore in the thread,  things work as I expect them to:  when the button is pressed, the interrupt is registered, the semaphore is set and the Thread un-blocks and performs its actions.

However, if I replace the semaphore with a queue, (created and initialized with success based on the return values), I can push to the queue successfully from the Interrupt routine (based on the return value and also based on checking the queue occupancy), however, the thread never unblocks on the 'pop' operation.  I have increased the # of buffer pools from 4 to 8, but that does not make  a difference (and, literally, there is nothing else in this test program but the Interrupt handler and the Thread).

I've experimented with different message sizes and different queue lengths to no avail.  All of the _create_, _init_, and push functions seems to operate correctly based on the return values, ... it only seems to be the pop function that is not working.

Any suggestions?

0 Likes
1 Solution

Hi ChCh_3584941 ,

First of all , its mandatory to call wiced_bt_stack_init( ) function in your application even if you are testing a non-BT  functionalities. Because it will ensure all internal initialization of the chip ROM code.

Buffer pool configuration will effect the RTOS and queue functions. The RTOS APIs utilize stack memory for creation of threads and the size will depend on the argument that you pass to the API.

You can also use wiced_bt_create_pool API (Refer wiced_memory.h for API details).

Also more details are available in Application Buffer Pools doc which you already mentioned : Application Buffer Pools (cypresssemiconductorco.github.io)

Regards,

Anjana

View solution in original post

0 Likes
3 Replies
AnjanaM_61
Moderator
Moderator
Moderator
5 comments on KBA First comment on KBA 5 questions asked

Hi ChCh_3584941 ,

Hope you are using CYW20719B2.

Can you please refer to key_ch03_ex03_queue​ available here: CypressAcademy_WBT101_Files/Projects/ch03 at master · cypresssemiconductorco/CypressAcademy_WBT101_F...  and try?

Regards,

Anjana

0 Likes

Thank You.

My mistake (or problem) was that I had commented out the wiced_bt_stack_init( ) function, and I guess this resulted in the buffer pools being not configured properly?

Just out of curiosity, it is possible to manage buffer pools for the queue without the mediation of the Bluetooth Stack?  Again, this is just a matter of curiosity since I have not come across a comprehensive explanation of how the buffer pools operate.  (although I have read the document "WICED Application Buffer Pools", Doc. #002-16403)

0 Likes

Hi ChCh_3584941 ,

First of all , its mandatory to call wiced_bt_stack_init( ) function in your application even if you are testing a non-BT  functionalities. Because it will ensure all internal initialization of the chip ROM code.

Buffer pool configuration will effect the RTOS and queue functions. The RTOS APIs utilize stack memory for creation of threads and the size will depend on the argument that you pass to the API.

You can also use wiced_bt_create_pool API (Refer wiced_memory.h for API details).

Also more details are available in Application Buffer Pools doc which you already mentioned : Application Buffer Pools (cypresssemiconductorco.github.io)

Regards,

Anjana

0 Likes