Value written to database stomps on incoming BLE Write

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

cross mob
Anonymous
Not applicable

Hi all,

I am running into a sticky issue on the BCM20732S.  I have a Characteristic that reads, writes and notifies. I am updating this Char from two places in my code.  I command this value from my app/client, the BLE packet arrives at the BCM20732S, and it normally sets correctly. I also occasionally will sdet this same value (by updating the value in the database) from my serial handler.  It appears that sometimes when I am writing into the database from the serial handler, this is stomping on the incoming value before I can see it.  Apparently the BLE write value arrives, it is saved to the database, my serial handler gets called and overwrites it before I am informed that the value has arrived.

I don't see any way to prevent this from happening without resorting to one Char for commands and a second one for feedback. Has anyone seen this before? Any ideas?

Thanks in advance,

      Aaron

0 Likes
3 Replies
JacobT_81
Employee
Employee
250 replies posted 100 replies posted 50 replies posted

One possible way to prevent this would be to put the received serial data into a buffer, then let the interrupt handler return. This will give the BLE write handler a chance to interrupt with accurate data. Then on the next fine timer loop (or hw timer), write the serial data buffer to the characteristic. A possible addition to the fine timer write would be to make a special condition for writes too close in time using the RTC. Then, when this condition is met, compare both recent writes to decide which is of higher importance to your application's functionality.

Unfortunately, this is a side-effect of hardware level interrupt priorities that will have to be worked around.

Jacob

Anonymous
Not applicable

Thanks Jacob.  So if I do the database write from the Fine Timer thread, this will allow a incoming BLE packet to be completely processed and forwarded to my BLE write handler in one atomic operation (ie without a the Fine Timer thread intervening)?  Thus my BLE write handler will see the exact data as it comes in, without risk of other modifications?

I guess this means that the receive interrupt handler is operating in a higher priority context?

Thanks,

      Aaron

0 Likes

To my knowledge, the fine timer will not interrupt the client write handler. But I don't have an exact table of priorities to reference, I'll have to get back to you on this.

Another idea would be to save the data from the GATT char to a buffer just before you do a serial write to it. Also save the most recent PUART data written. The next time a client write handler event occurs and the data the write handler sees is equal to that of the most recent PUART data, assume it's been overwritten and reference the saved data buffer as that which triggered the write handler.

There are numerous ways to approach the problem, but if this is a common occurrence the safest implementation will be the separation of the characteristics as you first mentioned.

Jacob