Bluetooth systems are growing in popularity for wirelessly connecting sensors in factories, office buildings, and industrial settings to computers that gather the data for analysis and control. While the Bluetooth system is robust, there is often custom firmware installed in the Bluetooth devices, and sometimes that firmware has issues or needs improvements. One of our customers is an Engineering Design & Development company for the defense and medical industries, and they had developed a custom Bluetooth Tag for their client—but it had a bug. Our customer was not able to fix the problem because their firmware designer no longer worked for them. There was no time to hire a replacement, so MSRK Design was asked to identify and fix the problem with the Tag’s firmware.
Identifying the Problem:
The original designer had met the original goals by using tools provided by the Bluetooth chip vendor, CSR. The Tag was able to Bond and establish a Serial Port Profile with other CSR devices. But the client was having trouble connecting to their other product, which was based on a ConnectBlue module; plus, they added the requirement that the Tag respond to AT commands. The connection was intermittent, and the Tag would not respond to some of the AT commands.
We installed the ConnectBlue design tools, duplicated the intermittency, and evaluated the problem by reviewing the code and by running the code in Debug mode. We determined that when the AT command was sent to establish a serial port connection, the tag responded by establishing multiple SPP connections with the same service name. In addition, there were unhandled states in the SPP initialization that would cause the firmware to crash.
Fixing the Problem:
We revised the firmware to fix those two problems, but in the process of thoroughly testing the Tag we uncovered yet another problem with the Bluetooth states.
The Hidden Problem:
On a normal power up the firmware put the Tag in the headsetLimbo state, did some initialization and then put the Tag in the headsetConnDiscoverable mode. After receiving the Bond command the Tag was sent to the headsetConnected state. But then the firmware was sometimes sending the Tag back into the headsetConnectable state while it was already in the headsetConnected state. If this happened the Tag was no longer able to Bond or establish a serial port connection, even with a power cycle! We were able to trace the events that caused the lockup to requesting a Bond after the device was already bound, or by initiatingEventPowerOff or EventPairingFail actions while the Tag was connected that the sent the tag to the headsetConnectable mode.
Fixing the Hidden Problem:
We reviewed the firmware again, and decided that there were too many unneeded states, possibly leftover from another project. In order to be able to Bond, the Tag needed to be Connectable and Discoverable. The existing code used both the headsetConnectable state and the headsetConnDiscoverable state. But if the headsetConnectable state is active, then the device has to become discoverable occasionally to be able to Bond and there was no code to do this. We changed the code to just use the headsetConnDiscoverable state, so that when the Tag is not bound it will always be Connectable and Discoverable, which met the design goal. Finally, we cleaned up the code by removing other unnecessary Headset states (such as volume, mute, call waiting, etc.) that were unused for the Tag operation.
We fixed the Bluetooth Tag problem for our customer within one week, including finding and fixing another serious problem. We delivered the code along with the Build and Programming Instructions documents to our customer. In addition, we demonstrated how to program the Tag, Bond the Tag, and establish an SPP. After our customer was satisfied that the Tag was working, they delivered a working device to their client who was very pleased as well.