I have been developing an application on a BGM13S32F512GA module. Using the Bluetooth SDK 2.12 stack I was able to link and run my program. The program uses the RTCC peripheral and defines the RTCC IRQ Handler. My understanding is that for the EFR32BG13 parts, that the RTCC is available for use the application. That certainly seems to be the case as I have been able to build and run the application.
Upon upgrading to version 2.13.0, it appears that the Bluetooth stack now uses a sleeptimer driver. For my part, the driver is targeted at the RTCC and defines the RTCC IRQ Handler. Consequently, when linking my application against the 2.13 SDK I get a duplicate definition of the handler.
My question is: Has the RTCC been taken over by the Bluetooth stack? Am I now forced to either find another timing resource or re-code to use the same driver that the Bluetooth stack now seems to insist upon (assuming I can get the functionality from the driver that I want)?
Has the RTCC been taken over by the Bluetooth stack?
Not directly but the Bluetooth stack is now using the sleeptimer and the sleeptimer is using the RTCC.
Am I now forced to either find another timing resource or re-code to use the same driver that the Bluetooth stack now seems to insist upon (assuming I can get the functionality from the driver that I want)?
The latter one, you should use the sleeptimer, you can find the documentation here: https://docs.silabs.com/mcu/latest/efr32bg13/group-SLEEPTIMER
That is about what I expected. Whether the Bluetooth stack uses the RTCC directly or not, the library makes references to the sleeptimer functions and that results in breaking my code.
After some effort and experimentation, I was able to make the Bluetooth event handling run out of my own event loop. I have used this event loop for years in many projects. It is honed, well tested and I have confidence in its behavior. Naturally, my event loop also needs a timing resource and the RTCC is an obvious choice. And up until 2.13 that worked.
However, 2.13 of the Bluetooth SDK breaks that. So I have given up. I will run my event loop from inside the non-blocking Bluetooth event loop approach. There seem little other practical choice given the design of the wait code interfaces. This begs the larger question of why are communications protocol libraries supplying an event loop in the first place, but clearly that design ship has sailed already. Seems like the Bluetooth stack thinks it is the center of the computing universe. In my systems I consider it little more than a glorified UART with an overly complicated interface that requires lots of software and computing resources. But I've also written radio control code before and understand the issues.
So now I'm faced with either running my event loop timer queue using a single timer from the sleeptimer driver, with all the overhead and hackery that running two timing queues (one in my event loop and one in the sleeptimer driver) implies, or ripping up my timer services, which I know has been thoroughly tested, and changing them to use the sleeptimer, a module with which I have no experience and upon a brief examination of the source code, does not lend great confidence.
I'm sure whoever decided to make the change to use the sleeptimer had the best of intentions. But adding dependencies causes breakage and release notes that say in effect, "go look at the examples", do not inspire much confidence in me. The most aggravating part is that I have no choice but to do something which I have serious doubts will be an improvement to my overall system design. I have always liked the EFM32 chips and have used them in several projects, even from back in the old Energy Micro days. But the frequent churn of the SDK's and the many problems with "Simplicity" Studio will cause me to look elsewhere on my next projects. Someone up the food chain should take note of what experienced developers need. Not everyone out there is an "example hacker" and examples are not a substitute for effective software documentation.
Have you considered using the callback method instead of the Bluetooth event loop? Check this:
UG136: Silicon Labs Bluetooth ® C Application Developer's Guide -> 5.2.2 Notification for Updating Event Listener
KBA_BT_0909: Scheduling application tasks while running BLE stack -> II. Own main loop extended with Bluetooth event handler
we have the same issue here. Our application does not use em_rtcc.c (not yet), but we use a custom RTC Driver running on a custom RTCC HAL, relying on the info that the MG13 has a dedicated Radio RTC (see datasheet), so thus, the "RTCC is freely usable by the application" (UG136, p.30). Now, we#re very surprised to learn that this seems to be outdated.
We are wondering whether we should write a new HAL for sleeptimer that avoids these conflicts, or whether we should contact technical support.
"RTCC is freely usable by the application" (UG136, p.30). Now, we#re very surprised to learn that this seems to be outdated.
That was true until the very latest SDK, but now when using Bluetooth you have to use the sleep timer. Thanks for bringing that section to our attention, I just created an internal ticket to get it updated.
You should now use the sleep timer, you can no longer use your custom RTC driver/HAL as that would mess up the sleep timer and thus the Bluetooth stack timings.
@andy-boy, could you please provide some more insight into this statement.
...upon a brief examination of the source code, does not lend great confidence.
Is there any particular findings in the source code that you find troubling, and can you please share what those are so that they can be addressed?
As I said in my previous posting, I have only made a brief, casual reading of the sleeptimer source code. I was trying to get an idea of how much additional effort might be required, so my posting here should be taken in that light. What I was concerned about is:
In the end, any developer on one of my teams would not submit code like this because he or she would know it would be summarily rejected. My complaint is that I have little choice but to use it. Yes, I have the source and can fix any bugs, but given the usual churn in the SDK's I have no desire to track any changes I might make against an SDK update. It seems that the sleeptimer is being used by the Bluetooth stack for timers services, but that only calls into question why the Bluetooth software is providing general system services like timing. Sadly, it is what I come to expect of software coming from hardware companies.
I went back to our software design team and they provided some insight into the feedback you provided.
Let me know if you like me to send additional feedback to the software design team.
Out product is using the BGM13S and we have been using the RTCC for our own timing AND for EM4 hibernate as the EFR32BG13 says of the RTCC that it "is freely usable by the application (UG136, p.30)". There's a "hidden" timer that the Bluetooth stack uses, right?
So we're in the middle of a early release hardware roll out and suddenly we find 2.13.0 wants to steal the RTCC. This is very poor form. There isn't even a warning in the release notes!
So - what happens now?
In my view the BT stack should NOT be using the RTCC. This change was ill conceived.
After reviewing sleeptimer, it seems if our app wants to keep using RTCC then I'll need to implement our version of sl_sleeptimer_hal_rtcc to replace the SiLabs version. This is a reasonable compromise as it will provide the minimum disturbance to our existing use of the RTCC. My API will remain intact and the new SiLabs sleeptimer module will also have access to the RTCC.