Debugging the Host Controller

Describes how to debug the host controller.

The HCI extension-conduit enables the writing of vendor specific commands to the Bluetooth host controller hardware via the stack. Specific debugging events or command completions are received back through a "secure channel". Event notifications are only available to the one client that issued the command in the first place, and there is only one such client on a device at any one time.

Intended Audience

This document is intended to be read by Symbian platform licensees.

How to send vendor-specific debug commands to the host controller

A wrapper class CHciExtensionConduit is provided to drive a command/event loop on behalf of the client program. The wrapper class provides callbacks into the client-implemented MVendorSpecificHciConduit interface upon reception of a debug or command completion event. On construction, the CHciExtensionConduit registers itself with the Bluetooth stack, which ensures that there can be only one HCI Extension Conduit in existence on a machine at one time. This means that the first such conduit constructed after bootup has sole access to issue vendor specific commands and more importantly receive back vendor specific events.

Basic Procedure

To send vendor specific debug commands to the host controller:

  1. create an array for your vendor specific commands and a descriptor to hold this data

  2. call CHciExtensionConduit::IssueCommandL() to issue the vendor specific command to the hardware, passing it the descriptor containing the raw binary data for the command. The raw binary data should not include the HCI transport header and footer bytes, as the stack will add these automatically to the provided hex command.

  3. define and implement MVendorSpecificHciConduit::CommandCompleted() : this function is called when a vendor specific command issued through the conduit receives a completion from the hardware.

  4. If the command generates debug events, call CHciExtensionConduit::WaitForEvent() to instruct the conduit that vendor debug events are expected back from the hardware. Implement MVendorSpecificHciConduit::ReceiveEvent() to get your specific debug event data generated from the hardware.


       class CDebugEventConsole : public CBase, private MVendorSpecificHciConduit
    static CDebugEventConsole* NewL();

    virtual void CommandCompleted(TInt aError);
    virtual TBool ReceiveEvent(TDesC8& aEvent, TInt aError);

    CConsoleBase*            iConsole;
    CHciExtensionConduit*    iConduit;

 CDebugEventConsole* CDebugEventConsole::NewL()
    CDebugEventConsole* self=new (ELeave)CDebugEventConsole();
    return self;

    delete iConsole;
    delete iConduit;

    TUint8 ActivateInfo[] = //returns response event and couple of extension events
        0x01, 0x02, 0x03, 0x04, //example uses meaningless values, for illustration
        0x05, 0x06, 0x07, 0x08,
        0x09, 0x0A, 0x0B, 0x0C,
        0x0D, 0x0E, 0x0F, 0x10,
        0x11, 0x12, 0x13, 0x14,
        0x15, 0x16, 0x17, 0x18,
        0x19, 0x1A, 0x1B, 0x1C,
        0x1D, 0x1E, 0x1F, 0x20,
        0x21, 0x22, 0x23, 0x24,
        0x25, 0x26


    TPtrC8 ExtensionCommand(ActivateInfo, sizeof(ActivateInfo));
    iConsole=Console::NewL(_L("listening for Events..."),TSize(20,20));
    iConduit = CHciExtensionConduit::NewL(*this);


void CDebugEventConsole::CommandCompleted(TInt aError)
    iConsole->Printf(_L("Cmd Complt: %d\n"), aError);
        aError = iConduit->WaitForEvent();    
        iConsole->Printf(_L("WaitForEvent: %d\n"), aError);

TBool CDebugEventConsole::ReceiveEvent(TDesC8& aEvent, TInt aError)
    iConsole->Printf(_L("Rcvd Event!\n  err %d Length %d\n"), aError, aEvent.Length());
    return ETrue; // Keep receiving events

void DoEventListenerL()
    CActiveScheduler *exampleScheduler = new (ELeave) CActiveScheduler();


    CleanupStack::PopAndDestroy(2); // active shed, myDebug

Where Next?

This tutorial set takes you through all the steps involved in setting up and communicating over a Bluetooth connection.