Adding Bluetooth support to a WEC7 kernel

Recently I had to add Bluetooth support to a custom board running Windows Embedded Compact 7. The Bluetooth module was CSR compatible connected to UART2. To enable the driver for this module you'll have to add the following registry settings to platform.reg:

; @CESYSGEN IF CE_MODULES_BTHCSR
[HKEY_LOCAL_MACHINE\Software\Microsoft\Bluetooth\Transports\BuiltIn\1]
    "driver"="bthcsr.dll"
    "flags"=dword:1
    "name"="COM2:"
    "baud"=dword:1c200
    "resetdelay"=dword:300
; @CESYSGEN ENDIF

You'll have to adjust the baudrate and COM port to match your configuration. The Bluetooth universal loader (SYSGEN_BTH) first looks for PnP devices (like USB/SDIO) and if it can't find any of those it will look for devices listed in the above Bluetooth\Transports\BuiltIn key in the order they are listed.

When I first added support for Bluetooth I just clicked all of the available items in the catalog:

  • Bluetooth Profile Management APIs (SYSGEN_BTH_BTHUTIL)
  • Bluetooth Stack with Universal Loadable Driver (SYSGEN_BTH)
  • Bluetooth HID - Keyboard (SYSGEN_BTH_HID_KEYBOARD)
  • Bluetooth HID - Mouse (SYSGEN_BTH_HID_MOUSE)
  • Bluetooth HS/HF and Audio Gateway Service (SYSGEN_BTH_AG)
  • Bluetooth PAN (SYSGEN_BTH_PAN)
  • Bluetooth Settings UI (SYSGEN_BTH_SETTINGS)

After rebuilding the OS Design the universal loader just did not want to load the driver I specified under the Bluetooth\Transports\BuiltIn key. Without (premium shared) source code of the universal loader it was very difficult to find out what was going wrong. All I could go on was the debug messages outputted by the Bluetooth Module, which I enabled by adding this key to the device's registry (in OSDesign.reg):

; Debug Zones
[HKEY_LOCAL_MACHINE\DebugZones]
        "BTD"=dword:E404

Unfortunately the debug messages did not give any clue as to why it did not want to load the driver I specified. In the end I decided to just select the Universal Loadable Driver (SYSGEN_BTH) in the catalog and deselect everything else, just to get rid of all other unrelated Bluetooth messages. To my surprise all of a sudden the driver did load!

I copied the reginit.ini from the release folder to a temporary folder, selected all Bluetooth components again and rebuilt the kernel. I then compared the reginit.ini of the kernel with only the universal loader component selected with the reginit of the kernel with all Bluetooth components selected. That way I discovered the culprit component was the Bluetooth Profile Management APIs (SYSGEN_BTH_BTHUTIL) component.

This component adds the following registry settings:

[HKEY_LOCAL_MACHINE\Software\Microsoft\Bluetooth\sys]
   "Power"=dword:0                  ; Radio off by default
   "ScanMode"=dword:0               ; Radio is not discoverable
   "DisableAutoSuspend"=dword:1     ; Allow suspend when connected

This disables the radio by default, hence the driver did not load.

So, when you want to enable Bluetooth at boot and you include the Bluetooth Profile Management APIs component, you'll have to override these registry values either inside platform.reg or OSDesign.reg:

; @CESYSGEN IF CE_MODULES_BTD
; @CESYSGEN IF OSSVCS_MODULES_BTHUTIL
[HKEY_LOCAL_MACHINE\Software\Microsoft\Bluetooth\sys]
   "Power"=dword:1                  ; Radio on by default
   "ScanMode"=dword:3               ; Radio is discoverable
   "DisableAutoSuspend"=dword:1     ; Allow suspend when connected
; @CESYSGEN ENDIF OSSVCS_MODULES_BTHUTIL
; @CESYSGEN ENDIF CE_MODULES_BTD

Comments

Hi Michel,

Many thanks for this tip, it helps me.

I have a question regarding the BTD service. My BT chip have to be configured via UART (MAC address, ...). In the previous versions of WinCE (5 & 6), before sending these settings, we was able to stop the BTD service by calling a DeviceIoControl on BTD0: with IOCTL_SERVICE_STOP on "card". There were also a public sample named BtLoader which was implementing this feature.
In WEC7, this sample does not exist anymore and the service seems to be not stoppable...
Do you have any lead to stop this service?

Thank you in advance.

Olivier.

Is it still a service? Try simply unloading the driver, see http://guruce.com/blogpost/load-unload-or-reload-a-driver-at-runtime

Thank you Michel, I will try to unload the BTD0: driver instead of trying to stop the service.

Michael,

Great post!

Although, I am confused as I am not sure where the CE_MODULES_BTHCSR,CE_MODULES_BTD and OSSVCS_MODULES_BTHUTIL
are? Are they created by the catalog files selected?

I am using a Laird BTM511 (CSR v.5 chip) Bluetooth development board that has a FTDI USB to RS232 converter chip. The platform I am building with is a Freescale i.MX53 Quick Start Board and the Adeneo BSP for the board. I have also loaded in my subproject folder of my OS design the FTDI Virtual COM Port Driver for ARM.

I am curious if this method above is going to work for me in using a external module. I changed the above com port to 0 as that is what the USB coverter chip is configured for and to use 9600 baud. I would like to use the Silverlight For Embedded Control Panel (CtlPnl2.exe) in my Silverlight Project. Will your method still work?

Hi,

CE_MODULES defines are set by sysgen (in ceconfig.h) according to the modules you selected in the catalog.

All that I described will still work with the FTDI driver. You just have to make sure the FTDI driver loads before the Bluetooth components (so set the "Order" value of the Bluetooth components to load after the "Order" value of the USB stack).

You may be interested in our new module the Opal, based on the iMX53 from Freescale. It's got Bluetooth already on-board. More information about the Opal will be released soon, but if you want some preliminary documentation then please contact me directly (or through the contact page).

I am facing problem in the registry. i think something went wrong in registry key. Its not working now. How can i rollback.

To roll back the registry just remove the settings you added to platform.reg (or project.reg, or OSDesign.reg, depending on which CE version you're working on), and do the appropriate build action as described here: http://guruce.com/blogpost/what-to-build-when

Hi Michel,

I found this blog post very informative. I am currently trying to add Bluetooth support to a WEC7 iMX53 platform using a WT21 HCI Bluetooth module from BlueGiga. I followed all your advice but I still can't tell if the Bluetooth driver is loading - I see no messages relating to BTD from the kernel debug. I've checked the settings in the registry and they all seem to be in order.

Could you tell me how you determined the driver was loading? Or if there any basic test applications I can run to check it's functioning? I did select the Silverlight BT settings panel from my OS catalogue but it doesn't appear anywhere on my desktop or control panel.

One final question, could you tell me what the various values for the "flags" parameter in [HKEY_LOCAL_MACHINE\Software\Microsoft\Bluetooth\Transports\BuiltIn\1] represent? I've tried searching online but haven't managed to find a description. I ask because by default the WT21 module configures itself to use EVEN parity and I'm not sure how to tell Windows is should use even parity when communicating with the module.

Many Thanks,
Simon

Hi Simon,

The easiest way to see if the driver is loading is by checking the debug output. Usually I create a small, tiny debug kernel with KITL enabled and just select whatever I need to debug or configure a new driver. This is quick and you don't have to deal with much clutter in the debug output window.

AFAIK the flags value is dependent on the driver. There should also be some CETK BT tests you can perform.

Is there have BLE support on native WEC 7 or WEC 2013 BT stack??
What is the BT version available in those??

Thanks and Regards

Nothing has changed in that regard since CE 6.0, so the following post is, AFAIK, still valid: https://social.msdn.microsoft.com/Forums/en-US/a0d722f0-4f76-4330-a18e-6...

Hi Michel,
Can you suggest me any Bluetooth applications, that can be used to validate wince or wec Bluetooth profiles.

No, sorry...