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.

CC2564CSTBTBLESW: FreeRTOS event implementation contradicts documentation

Part Number: CC2564CSTBTBLESW

Hi everyone,

I'd like to ask for some clarification here, as I was studying the Bluetopia BTPSKRNL documentation, the BTPS_WaitEvent() specifies the following:

The following function is responsible for waiting for the specified Event to become signalled. It should be noted that signals have a special property, in that multiple threads can be waiting for the Event to become signalled and all calls to BTPS_WaitEvent() will return TRUE whenever the state of the Event becomes signalled.

However, the CC2564CSTBTBLESW 4.2.1.1 implements the Event as a binary semaphore, and uses FreeRTOS xSemaphoreTake() call to implement this method. xSemaphoreTake() always leaves the binary semaphore's status non-signalled, the signalled status is only preserved in the return value. So there's a direct contradiction between the abstract requirement of this API, and how it's implemented. As it seems this problem hasn't been uncovered yet, does this mean that the Bluetopia's internal behavior has been altered to adapt to the binary semaphore's different behavior? Or that this API is used in a way that it makes no difference in the end (e.g. BTPS_WaitEvent() is always followed by BTPS_ResetEvent() call)?

For the record FreeRTOS has a synchronization object that behaves as the documentation expects it, the event group (e.g. xEventGroupWaitBits(event, 1, pdFALSE, pdFALSE, DecrementWait)).

  • Hi Benedek,

    You bring up an interesting observation which is worth exploring and understanding.

    Looking at the implementation of the BTPS_WaitEvent() function, it does seem like it just tries to take a binary semaphore. This implementation is not in of itself problematic, but only when compared to the documentation of the function, which does indicate that when the event gets signaled, all calls should return true.

    As you point out, this implementation of events in the Bluetopia stack has been present for many years and so it is unlikely to be an undiscovered issue. Looking at the Linux Bluetopia implementation, it does appear to use a binary semaphore too. I've attached it here for your reference:

     /cfs-file/__key/communityserver-discussions-components-files/538/BTPSKRNL.c

    Now, the Linux implementation is heavily used, and if this sort of BTPS_WaitEvent() implementation was a bug, then it probably would have been noticed before. I've still investigating how that function is used internally in the stack, but this might take a while longer as there are thousands of calls spread out across the stack.

    At this point, my assumption is that for any given event, there will only ever be one thread waiting for it at a time. As such, you could say that this API is used in a way that it makes no difference in the end. Still, I'll keep checking to ensure that this is the case.

    I suggest you take a look at the attached Linux BTPSKRNL implementation to check and see if that matches up with the FreeRTOS Bluetopia implementation, to double-check our understanding.

    Regards,

    Michael