baadamff

Profile Data

Screen Name: baadamff

Screen Name*

Title

First Name

Address:

Last Name

URL (i.e. Company, Github, LinkedIn)

LinkedIn account

Company

Phone number

Country

Bio

Indicates required field*

My Activities
Following

Member Action Date

baadamff

Selected an answer for EFR32FG1: non-monotonic TX power regulation

Hello Vladimir,

What you have observed is not unexpected behavior. The actual TX power level response to TX power setting is expected to be different between custom designs due to differences in on-board impendances. The SDK firmware built for this part is adjusted for the particular WSTK evaluation board used as the reference for the EFR32FG1V131F128GM32. Your custom hardware may or may not have similar power setting responses to the WSTK evalution module. To fine tune the power settings for custom hardware, the firmware developer can create custom power curves described in AN1127;

https://www.silabs.com/documents/public/application-notes/an1127-power-amplifier-power-conversion-functions.pdf

You have already taken the first step by characterizing the TX power versus TX power setting on your custom hardware.

Best regards,

Sep 21 2020, 7:59 AM

baadamff

Updated KBA_BT_0911: MIDI over BLE on Knowledge Base

MIDI basics

This article shows how a Blue Gecko can be used as a MIDI controller over Bluetooth Low Energy. At first we give some basic info about the MIDI standard then on the Apple Bluetooth Low Energy MIDI Specification. Finally, we highlight and explain the most important code snippets from the attached sample application which implements a very basic MIDI controller.

The protocol

MIDI is an industry standard music technology protocol that connects products from many different companies including digital musical instruments, computers, tablets and smartphones. MIDI is used everyday around the world by musicians, DJs, producers, educators, artists and hobbyists to create, perform, learn and share music and artistic works. Nearly every hit album, film score, TV show and theatrical production uses MIDI to connect and create. MIDI information is transmitted in "MIDI messages", which can be thought of as instructions which tell a music synthesizer how to play a piece of music. The synthesizer receiving the MIDI data must generate the actual sounds.

Physical layer

The MIDI specification for the electrical interface is based on a fully isolated current loop. The MIDI OUT port nominally sources a +5 volt source through a 220 ohm resistor out through pin 4 on the MIDI OUT DIN connector, in on pin 4 of the receiving device's MIDI IN DIN connector, through a 220 ohm protection resistor and the LED of an optoisolator. The current then returns via pin 5 on the MIDI IN port to the originating device's MIDI OUT port pin 5, again with a 220 ohm resistor in the path, giving a nominal current of about 5 milliamperes. Despite the cable's appearance, there is no conductive path between the two MIDI devices, only an optically isolated one. The data rate on this system is a relatively slow (by today standards) 31,250 bits per second, logic 0 being current ON. The MIDI data stream is a unidirectional asynchronous bit stream with 10 bits transmitted per byte (a start bit, 8 data bits, and one stop bit). The MIDI data stream is usually originated by a MIDI controller, such as a musical instrument keyboard.

MIDI controller and sound module

A MIDI controller is a device which is played as an instrument, and it translates the performance into a MIDI data stream in real time (as it is played). The MIDI data output from a MIDI controller is transmitted via the devices' MIDI OUT connector. The recipient of this MIDI data stream is commonly a MIDI sound generator or sound module, which will receive MIDI messages at its MIDI IN connector, and respond to these messages by playing sounds.

MIDI messages

There are a number of different types of MIDI messages. See the https://www.midi.org for details.

In the example code attached we implemented only Note On and Note Off messages. The Note On message is used for turning on MIDI notes. This is typically sent when a key pressed on keyboard. The Note Off message is used for turning off MIDI notes. This is typically sent when a key released on keyboard.

MIDI over BLE

There are number of solutions where the standard DIN connector and physical layer changed to a more modern medium like USB or Ethernet. Apple defined a custom BLE service for MIDI support. This is now part of the MIDI standard.

This specification can be found here:

https://www.midi.org/specifications/item/bluetooth-le-midi

To support MIDI over BLE the accessory has to fulfill a set requirements collected below.

Connection interval

The accessory shall request a connection interval of 15 ms or less. Apple recommends starting with a request for a connection interval of 11.25 ms and going to 15 ms if the connection request is rejected by the Apple product. Intervals higher than 15 ms are unsuitable for live playback situations.

MTU negotiation

The accessory shall support MTU negotiation. See the MTU Size section in the Bluetooth Low Energy chapter of the Bluetooth Accessory Design Guidelines for Apple Products for implementation details.

Multiple packet transmissions

The accessory shall support sending and receiving the maximum number of Bluetooth Low Energy packets that can fit into the connection interval. MIDI minimum bandwidth requirements may not be met otherwise.

Custom MIDI Service and Characteristic

The GATT should contain the following service and characteristic

Name	UUID
MIDI Service	03B80E5A-EDE8-4B33-A751-6CE34EC4C700
MIDI I/O Characteristic	7772E5DB-3868-4112-A1A9-F2669D106BF3

The MIDI I/O characteristics

Name	Type	Security	Properties	Comment
MIDI I/O	blob	Read, Write, Notify	Pairing required	Shall require encryption. Writes must not expect a response.

Header and Timestamp fields

Additional Header and Timestamp fields has to be added before the standard MIDI message format

Header bit 7 is start bit and set to 1
Header bit 6 is reserved and set to 0
Header bits 0-5 are upper 6 bits of 13 bit timestamp
Timestamp bit 7 is start bit and set to 1

Note that the actual timestamp value is splitted between the Header and Timestamp fields.

The 13-bit timestamp for a MIDI event in any given Bluetooth Low Energy packet is formed from the bottom 6 bits of the Header field and the bottom 7 bits of the Timestamp filed. Timestamps are in expressed in milliseconds, implying that the maximum timestamp range is 8192 ms. Timestamps shall be sent in monotonically increasing order.

Example application

The attached application act as a very basic MIDI controller. It can send MIDI note on and MIDI note off messages when a button pressed or released on the WSTK. Pressing PB0 button repeatedly will play the Imperial March from Star Wars. Pressing PB1 is resetting the sequence so the melody can start from the beginning.

The application is built upon the Simplicity Studio Bluetooth SDK ver. 2.11 and tested with the BGM13S Starter Kit (SLWSTK4305A) but it should work with other EFR32 based Bluetooth enabled targets with minimal changes.

We going to highlight the most important steps which are needed for building a MIDI over BLE compatible device.

GATT definition

The GATT.xml file has to contain the MIDI service definition as it is showed below.

  <!--MIDI Service-->
  <service advertise="true" name="MIDI Service" requirement="mandatory" sourceId="custom.type" type="primary" uuid="03B80E5A-EDE8-4B33-A751-6CE34EC4C700">
    <informativeText>Custom service</informativeText>
    <!--MIDI I/O Characteristic-->
    <characteristic id="xgatt_midi" name="MIDI I/O Characteristic" sourceId="custom.type" uuid="7772E5DB-3868-4112-A1A9-F2669D106BF3">
      <informativeText>Custom characteristic</informativeText>
      <value length="20" type="hex" variable_length="true">0x20</value>
      <properties encrypted_read="true" encrypted_read_requirement="optional" encrypted_write="true" encrypted_write_requirement="optional" notify="true" notify_requirement="optional" read="true" read_requirement="optional" write_no_response="true" write_no_response_requirement="optional"/>
    </characteristic>
  </service>

Enable the bonding before connection

void midi_init_ble_connection(void)
{
    gecko_cmd_sm_set_bondable_mode(1);
}

Set the connection interval to the required 15 ms.

void midi_ble_connected(uint8_t connection)
{
    /* store the connection ID */
    connectionId = connection;
    /* connection parameter constrains for ble MIDI */
    gecko_cmd_le_connection_set_timing_parameters(connection, 0x12, 0x12, 0, 0x64, 0, 0xFFFF);
}

Setup CRYOTIMER for creating 1ms timer for the timestamp

This timestamp has to be included to the MIDI message.

void midi_init_timer(void)
{
    CRYOTIMER_Init_TypeDef cryoInit = CRYOTIMER_INIT_DEFAULT;

    /* General settings */
    cryoInit.enable    = 1;
    cryoInit.debugRun  = 0;
    cryoInit.em4Wakeup = 0;

    /* Clocking settings */
    /* With a frequency of 1000Hz on ULFRCO, this will result in a 1.00 ms timeout */
    cryoInit.osc    = cryotimerOscULFRCO;
    cryoInit.presc  = cryotimerPresc_1;
    cryoInit.period = cryotimerPeriod_1;
    CRYOTIMER_Init(&cryoInit);
}

Setup GPIO interrupt for button press

Here is the PBB0_pressed function registered as a GPIO interrupt service routine and will be triggered for both rising and falling edges. The function is reading the GPIO state and sends a note on or note off message accordingly. The code snippet below shows the recommended way for registering the ISR.

void midi_init_buttons(void)
{
    /* Init GPIO ISR dispatcher */
    CMU_ClockEnable(cmuClock_GPIO, true);
    GPIOINT_Init();

    /* Setup PB0 */
    /* GPIO init for button pins */
    GPIO_PinModeSet(BSP_BUTTON0_PORT, BSP_BUTTON0_PIN, gpioModeInput, 0);

    /* Register GPIO ISR */
    GPIOINT_CallbackRegister(BSP_BUTTON0_PIN, PB0_pressed);

    /* Trigger for both edge */
    GPIO_IntConfig(BSP_BUTTON0_PORT, BSP_BUTTON0_PIN, true, true, true);
...

Function to send a note on message

The midi_note_on() function prepare and send a note on message. First the function gets the timestamp from the CRYOTIMER. The CRYTIMER provides a 32 bit counter but according to the specification we need only the lower 13 bit, so the rest of the bits are masked. Then the function fills the header and timestamp fields. The header byte is 0b10xxxxxx where xxxxxxx is top 6 bits of timestamp. The timestamp byte is 0b1xxxxxxx where xxxxxxx is lower 7 bits of timestamp.

The status byte is 0x90 is 0b1sssnnnn where sss is message type and nnnn is the MIDI channel.

The last two bytes contains the 2 byte long event field in this case it is the note and velocity.

Finally the function sends the message with the gecko_cmd_GATT_server_send_characteristic_notification API function.

void midi_note_on(uint8 note, uint8 velocity)
{
  static midi_data_t note_on;

  /* Get the timestamp from the CRYOTIMER */
  uint32 temp = CRYOTIMER_CounterGet();
  /* Mask it - only the lower 13 bit needed */
  temp = temp & 0x00001fff;
  /* Header byte = 0b10xxxxxx where xxxxxxx is top 6 bits of timestamp */
  note_on.midi_event.header = 0x80 | (temp >> 7);
  /* Timestamp byte = 0b1xxxxxxx where xxxxxxx is lower 7 bits of timestamp */
  note_on.midi_event.timestamp = 0x80 | (temp & 0x003f);
  /* Status byte = 0b1sssnnnn where sss is message type and nnnn is channel */
  note_on.midi_event.status = 0x90;
  /* setting the note parameter */
  note_on.midi_event.note = note;
  /* setting the velocity parameter */
  note_on.midi_event.velocity = velocity;
  /* sending the assembled MIDI message */
  gecko_cmd_GATT_server_send_characteristic_notification(connectionId, GATTdb_xGATT_MIDI, 5, (uint8 const *) &note_on);
}

Testing

Once the application flashed to kit it starts advertise itself. After connection it pairs and bonds with just work method. The application tested with the following IOS apps:

Korg Module
Korg Gadget
Apple GarageBand

References

[1] https://www.midi.org

[2] https://www.midi.org/specifications/item/bluetooth-le-midi

[3] https://en.wikipedia.org/wiki/MIDI

Jun 19 2019, 11:32 AM

baadamff

Updated KBA_BT_0911: MIDI over BLE on Knowledge Base

MIDI basics

The protocol

Physical layer

MIDI controller and sound module

MIDI messages

There are a number of different types of MIDI messages. See the https://www.MIDI.org for details.

MIDI over BLE

This specification can be found here:

https://www.midi.org/specifications/item/bluetooth-le-midi

To support MIDI over BLE the accessory has to fulfill a set requirements collected below.

Connection interval

MTU negotiation

The accessory shall support MTU negotiation. See the MTU Size section in the Bluetooth Low Energy chapter of the Bluetooth Accessory Design Guidelines for Apple Products for implementation details.

Multiple packet transmissions

Custom MIDI Service and Characteristic

The GATT should contain the following service and characteristic

Name	UUID
MIDI Service	03B80E5A-EDE8-4B33-A751-6CE34EC4C700
MIDI I/O Characteristic	7772E5DB-3868-4112-A1A9-F2669D106BF3

The MIDI I/O characteristics

Name	Type	Security	Properties	Comment
MIDI I/O	blob	Read, Write, Notify	Pairing required	Shall require encryption. Writes must not expect a response.

Header and Timestamp fields

Additional Header and Timestamp fields has to be added before the standard MIDI message format

Header bit 7 is start bit and set to 1
Header bit 6 is reserved and set to 0
Header bits 0-5 are upper 6 bits of 13 bit timestamp
Timestamp bit 7 is start bit and set to 1

Note that the actual timestamp value is splitted between the Header and Timestamp fields.

Example application

We going to highlight the most important steps which are needed for building a MIDI over BLE compatible device.

GATT definition

The GATT.xml file has to contain the MIDI service definition as it is showed below.

  <!--MIDI Service-->
  <service advertise="true" name="MIDI Service" requirement="mandatory" sourceId="custom.type" type="primary" uuid="03B80E5A-EDE8-4B33-A751-6CE34EC4C700">
    <informativeText>Custom service</informativeText>
    <!--MIDI I/O Characteristic-->
    <characteristic id="xGATT_MIDI" name="MIDI I/O Characteristic" sourceId="custom.type" uuid="7772E5DB-3868-4112-A1A9-F2669D106BF3">
      <informativeText>Custom characteristic</informativeText>
      <value length="20" type="hex" variable_length="true">0x20</value>
      <properties encrypted_read="true" encrypted_read_requirement="optional" encrypted_write="true" encrypted_write_requirement="optional" notify="true" notify_requirement="optional" read="true" read_requirement="optional" write_no_response="true" write_no_response_requirement="optional"/>
    </characteristic>
  </service>

Enable the bonding before connection

void MIDI_init_ble_connection(void)
{
    gecko_cmd_sm_set_bondable_mode(1);
}

Set the connection interval to the required 15 ms.

void MIDI_ble_connected(uint8_t connection)
{
    /* store the connection ID */
    connectionId = connection;
    /* connection parameter constrains for ble MIDI */
    gecko_cmd_le_connection_set_timing_parameters(connection, 0x12, 0x12, 0, 0x64, 0, 0xFFFF);
}

Setup CRYOTIMER for creating 1ms timer for the timestamp

This timestamp has to be included to the MIDI message.

void MIDI_init_timer(void)
{
    CRYOTIMER_Init_TypeDef cryoInit = CRYOTIMER_INIT_DEFAULT;

    /* General settings */
    cryoInit.enable    = 1;
    cryoInit.debugRun  = 0;
    cryoInit.em4Wakeup = 0;

    /* Clocking settings */
    /* With a frequency of 1000Hz on ULFRCO, this will result in a 1.00 ms timeout */
    cryoInit.osc    = cryotimerOscULFRCO;
    cryoInit.presc  = cryotimerPresc_1;
    cryoInit.period = cryotimerPeriod_1;
    CRYOTIMER_Init(&cryoInit);
}

Setup GPIO interrupt for button press

void MIDI_init_buttons(void)
{
    /* Init GPIO ISR dispatcher */
    CMU_ClockEnable(cmuClock_GPIO, true);
    GPIOINT_Init();

    /* Setup PB0 */
    /* GPIO init for button pins */
    GPIO_PinModeSet(BSP_BUTTON0_PORT, BSP_BUTTON0_PIN, gpioModeInput, 0);

    /* Register GPIO ISR */
    GPIOINT_CallbackRegister(BSP_BUTTON0_PIN, PB0_pressed);

    /* Trigger for both edge */
    GPIO_IntConfig(BSP_BUTTON0_PORT, BSP_BUTTON0_PIN, true, true, true);
...

Function to send a note on message

The MIDI_note_on() function prepare and send a note on message. First the function gets the timestamp from the CRYOTIMER. The CRYTIMER provides a 32 bit counter but according to the specification we need only the lower 13 bit, so the rest of the bits are masked. Then the function fills the header and timestamp fields. The header byte is 0b10xxxxxx where xxxxxxx is top 6 bits of timestamp. The timestamp byte is 0b1xxxxxxx where xxxxxxx is lower 7 bits of timestamp.

The status byte is 0x90 is 0b1sssnnnn where sss is message type and nnnn is the MIDI channel.

The last two bytes contains the 2 byte long event field in this case it is the note and velocity.

Finally the function sends the message with the gecko_cmd_GATT_server_send_characteristic_notification API function.

void MIDI_note_on(uint8 note, uint8 velocity)
{
  static MIDI_data_t note_on;

  /* Get the timestamp from the CRYOTIMER */
  uint32 temp = CRYOTIMER_CounterGet();
  /* Mask it - only the lower 13 bit needed */
  temp = temp & 0x00001fff;
  /* Header byte = 0b10xxxxxx where xxxxxxx is top 6 bits of timestamp */
  note_on.MIDI_event.header = 0x80 | (temp >> 7);
  /* Timestamp byte = 0b1xxxxxxx where xxxxxxx is lower 7 bits of timestamp */
  note_on.MIDI_event.timestamp = 0x80 | (temp & 0x003f);
  /* Status byte = 0b1sssnnnn where sss is message type and nnnn is channel */
  note_on.MIDI_event.status = 0x90;
  /* setting the note parameter */
  note_on.MIDI_event.note = note;
  /* setting the velocity parameter */
  note_on.MIDI_event.velocity = velocity;
  /* sending the assembled MIDI message */
  gecko_cmd_GATT_server_send_characteristic_notification(connectionId, GATTdb_xGATT_MIDI, 5, (uint8 const *) &note_on);
}

Testing

Once the application flashed to kit it starts advertise itself. After connection it pairs and bonds with just work method. The application tested with the following IOS apps:

Korg Module
Korg Gadget
Apple GarageBand

References

[1] https://www.midi.org

[2] https://www.midi.org/specifications/item/bluetooth-le-midi

[3] https://en.wikipedia.org/wiki/MIDI

Jun 19 2019, 11:19 AM

baadamff

Updated Bluetooth Knowledge Base Article List on Knowledge Base

Introduction

This Knowledge Base Article (KBA) aims to act as a “master” KBA which keeps a curated index of all the Bluetooth related KBAs divided into logical categories for an easier and more convenient look-up. It may also include non-KBA content which is relevant for designing your Bluetooth application (e.g. app notes or web pages).

If you are just getting started with Silicon Labs Bluetooth solutions then your starting point should be QSG139: Getting Started with Bluetooth® Software Development. At the end of that document you are presented with the flowchart below which shows what documents should be read and in which order. Additionally you can check out our Bluetooth Training page for more training material.

Knowledge Base Articles List

The content listed below is grouped together into categories to make it easier for you to find what you are looking for. Want to know more about security, or looking for a peripheral example, then head down to the right section and see what KBAs or other relevant content has been created under those topics.

Each category has an associated index number and each individual KBA has its own index number within the category. The KBA's are prefixed with KBA_BT_AABB where AA is the category index and BB is the KBA index within that category. The category index numbers are as follows:

[01] Bluetooth - General
[02] Bluetooth - Advertising
[03] Bluetooth - Stack features
[04] Bluetooth - Performance
[05] Bluetooth - Bluetooth Mesh
[06] Bootloading - General
[07] Bootloading - UART DFU
[08] Bootloading - OTA DFU
[09] Application Examples
[10] Peripheral Examples
[11] Security
[12] Tools
[13] Hardware
[14] Migration
[15] Mobile
[16] NCP

The KBAs with attached example code are marked with this icon .

Note: Do you want to get automatic notifications when new content is added to the list? Just click the Follow button in upper right corner to subscribe to email notifications. We will make comments when new content is created to trigger those notifications.

[01] Bluetooth General

[02] Bluetooth - Advertising

[03] Bluetooth - Stack features

[04] Bluetooth - Performance

[05] Bluetooth - Bluetooth Mesh

[06] Bootloading - General

[07] Bootloading - UART DFU

[08] Bootloading - OTA DFU

[09] Application Examples

[10] Peripheral Examples

Additional Resources

MCU Peripheral Examples on GitHub (also includes EFR32)

[11] Security

[12] Tools

Additional Resources

Simplicity Studio now Treats Bluetooth Modules as Parts

[13] Hardware

Additional Resources

[14] Migration

[15] Mobile

[16] NCP

Jun 19 2019, 11:18 AM

baadamff

Updated KBA_BT_0911: MIDI over BLE on Knowledge Base

MIDI over BLE with Wireless Gecko Soc-s and Modules

MIDI basics

The protocol

Physical layer

MIDI controller and sound module

MIDI messages

There are a number of different types of MIDI messages. See the https://www.MIDI.org for details.

MIDI over BLE

This specification can be found here:

https://www.midi.org/specifications/item/bluetooth-le-midi

To support MIDI over BLE the accessory has to fulfill a set requirements collected below.

Connection interval

MTU negotiation

The accessory shall support MTU negotiation. See the MTU Size section in the Bluetooth Low Energy chapter of the Bluetooth Accessory Design Guidelines for Apple Products for implementation details.

Multiple packet transmissions

Custom MIDI Service and Characteristic

The GATT should contain the following service and characteristic

Name	UUID
MIDI Service	03B80E5A-EDE8-4B33-A751-6CE34EC4C700
MIDI I/O Characteristic	7772E5DB-3868-4112-A1A9-F2669D106BF3

The MIDI I/O characteristics

Name	Type	Security	Properties	Comment
MIDI I/O	blob	Read, Write, Notify	Pairing required	Shall require encryption. Writes must not expect a response.

Header and Timestamp fields

Additional Header and Timestamp fields has to be added before the standard MIDI message format

Header bit 7 is start bit and set to 1
Header bit 6 is reserved and set to 0
Header bits 0-5 are upper 6 bits of 13 bit timestamp
Timestamp bit 7 is start bit and set to 1

Note that the actual timestamp value is splitted between the Header and Timestamp fields.

Example application

We going to highlight the most important steps which are needed for building a MIDI over BLE compatible device.

GATT definition

The GATT.xml file has to contain the MIDI service definition as it is showed below.

  <!--MIDI Service-->
  <service advertise="true" name="MIDI Service" requirement="mandatory" sourceId="custom.type" type="primary" uuid="03B80E5A-EDE8-4B33-A751-6CE34EC4C700">
    <informativeText>Custom service</informativeText>
    <!--MIDI I/O Characteristic-->
    <characteristic id="xGATT_MIDI" name="MIDI I/O Characteristic" sourceId="custom.type" uuid="7772E5DB-3868-4112-A1A9-F2669D106BF3">
      <informativeText>Custom characteristic</informativeText>
      <value length="20" type="hex" variable_length="true">0x20</value>
      <properties encrypted_read="true" encrypted_read_requirement="optional" encrypted_write="true" encrypted_write_requirement="optional" notify="true" notify_requirement="optional" read="true" read_requirement="optional" write_no_response="true" write_no_response_requirement="optional"/>
    </characteristic>
  </service>

Enable the bonding before connection

void MIDI_init_ble_connection(void)
{
    gecko_cmd_sm_set_bondable_mode(1);
}

Set the connection interval to the required 15 ms.

void MIDI_ble_connected(uint8_t connection)
{
    /* store the connection ID */
    connectionId = connection;
    /* connection parameter constrains for ble MIDI */
    gecko_cmd_le_connection_set_timing_parameters(connection, 0x12, 0x12, 0, 0x64, 0, 0xFFFF);
}

Setup CRYOTIMER for creating 1ms timer for the timestamp

This timestamp has to be included to the MIDI message.

void MIDI_init_timer(void)
{
    CRYOTIMER_Init_TypeDef cryoInit = CRYOTIMER_INIT_DEFAULT;

    /* General settings */
    cryoInit.enable    = 1;
    cryoInit.debugRun  = 0;
    cryoInit.em4Wakeup = 0;

    /* Clocking settings */
    /* With a frequency of 1000Hz on ULFRCO, this will result in a 1.00 ms timeout */
    cryoInit.osc    = cryotimerOscULFRCO;
    cryoInit.presc  = cryotimerPresc_1;
    cryoInit.period = cryotimerPeriod_1;
    CRYOTIMER_Init(&cryoInit);
}

Setup GPIO interrupt for button press

void MIDI_init_buttons(void)
{
    /* Init GPIO ISR dispatcher */
    CMU_ClockEnable(cmuClock_GPIO, true);
    GPIOINT_Init();

    /* Setup PB0 */
    /* GPIO init for button pins */
    GPIO_PinModeSet(BSP_BUTTON0_PORT, BSP_BUTTON0_PIN, gpioModeInput, 0);

    /* Register GPIO ISR */
    GPIOINT_CallbackRegister(BSP_BUTTON0_PIN, PB0_pressed);

    /* Trigger for both edge */
    GPIO_IntConfig(BSP_BUTTON0_PORT, BSP_BUTTON0_PIN, true, true, true);
...

Function to send a note on message

The status byte is 0x90 is 0b1sssnnnn where sss is message type and nnnn is the MIDI channel.

The last two bytes contains the 2 byte long event field in this case it is the note and velocity.

Finally the function sends the message with the gecko_cmd_GATT_server_send_characteristic_notification API function.

void MIDI_note_on(uint8 note, uint8 velocity)
{
  static MIDI_data_t note_on;

  /* Get the timestamp from the CRYOTIMER */
  uint32 temp = CRYOTIMER_CounterGet();
  /* Mask it - only the lower 13 bit needed */
  temp = temp & 0x00001fff;
  /* Header byte = 0b10xxxxxx where xxxxxxx is top 6 bits of timestamp */
  note_on.MIDI_event.header = 0x80 | (temp >> 7);
  /* Timestamp byte = 0b1xxxxxxx where xxxxxxx is lower 7 bits of timestamp */
  note_on.MIDI_event.timestamp = 0x80 | (temp & 0x003f);
  /* Status byte = 0b1sssnnnn where sss is message type and nnnn is channel */
  note_on.MIDI_event.status = 0x90;
  /* setting the note parameter */
  note_on.MIDI_event.note = note;
  /* setting the velocity parameter */
  note_on.MIDI_event.velocity = velocity;
  /* sending the assembled MIDI message */
  gecko_cmd_GATT_server_send_characteristic_notification(connectionId, GATTdb_xGATT_MIDI, 5, (uint8 const *) &note_on);
}

Testing

Once the application flashed to kit it starts advertise itself. After connection it pairs and bonds with just work method. The application tested with the following IOS apps:

Korg Module
Korg Gadget
Apple GarageBand

References

[1] https://www.midi.org

[2] https://www.midi.org/specifications/item/bluetooth-le-midi

[3] https://en.wikipedia.org/wiki/MIDI

Jun 19 2019, 11:03 AM

baadamff

Posted KBA_BT_0911: MIDI over BLE on Knowledge Base

MIDI over BLE with Wireless Gecko Soc-s and Modules

MIDI basics

The protocol

Physical layer

MIDI controller and sound module

MIDI messages

There are a number of different types of MIDI messages. See the https://www.MIDI.org for details.

MIDI over BLE

https://developer.apple.com/bluetooth/Apple-Bluetooth-Low-Energy-MIDI-Specification.pdf

With the release of iOS 8 and OS X Yosemite, sending and receiving MIDI data is supported using Bluetooth Low Energy connections on any iOS device or Mac that has native Bluetooth Low Energy support.

To support MIDI over BLE the accessory has to fulfill a set requirements collected below.

Connection interval

MTU negotiation

The accessory shall support MTU negotiation. See the MTU Size section in the Bluetooth Low Energy chapter of the Bluetooth Accessory Design Guidelines for Apple Products for implementation details.

Multiple packet transmissions

Custom MIDI Service and Characteristic

The GATT should contain the following service and characteristic

Name	UUID
MIDI Service	03B80E5A-EDE8-4B33-A751-6CE34EC4C700
MIDI I/O Characteristic	7772E5DB-3868-4112-A1A9-F2669D106BF3

The MIDI I/O characteristics

Name	Type	Security	Properties	Comment
MIDI I/O	blob	Read, Write, Notify	Pairing required	Shall require encryption. Writes must not expect a response.

Header and Timestamp fields

Additional Header and Timestamp fields has to be added before the standard MIDI message format

Header bit 7 is start bit and set to 1
Header bit 6 is reserved and set to 0
Header bits 0-5 are upper 6 bits of 13 bit timestamp
Timestamp bit 7 is start bit and set to 1

Note that the actual timestamp value is splitted between the Header and Timestamp fields.

Example application

We going to highlight the most important steps which are needed for building a MIDI over BLE compatible device.

GATT definition

The GATT.xml file has to contain the MIDI service definition as it is showed below.

  <!--MIDI Service-->
  <service advertise="true" name="MIDI Service" requirement="mandatory" sourceId="custom.type" type="primary" uuid="03B80E5A-EDE8-4B33-A751-6CE34EC4C700">
    <informativeText>Custom service</informativeText>
    <!--MIDI I/O Characteristic-->
    <characteristic id="xGATT_MIDI" name="MIDI I/O Characteristic" sourceId="custom.type" uuid="7772E5DB-3868-4112-A1A9-F2669D106BF3">
      <informativeText>Custom characteristic</informativeText>
      <value length="20" type="hex" variable_length="true">0x20</value>
      <properties encrypted_read="true" encrypted_read_requirement="optional" encrypted_write="true" encrypted_write_requirement="optional" notify="true" notify_requirement="optional" read="true" read_requirement="optional" write_no_response="true" write_no_response_requirement="optional"/>
    </characteristic>
  </service>

Enable the bonding before connection

void MIDI_init_ble_connection(void)
{
    gecko_cmd_sm_set_bondable_mode(1);
}

Set the connection interval to the required 15 ms.

void MIDI_ble_connected(uint8_t connection)
{
    /* store the connection ID */
    connectionId = connection;
    /* connection parameter constrains for ble MIDI */
    gecko_cmd_le_connection_set_timing_parameters(connection, 0x12, 0x12, 0, 0x64, 0, 0xFFFF);
}

Setup CRYOTIMER for creating 1ms timer for the timestamp

This timestamp has to be included to the MIDI message.

void MIDI_init_timer(void)
{
    CRYOTIMER_Init_TypeDef cryoInit = CRYOTIMER_INIT_DEFAULT;

    /* General settings */
    cryoInit.enable    = 1;
    cryoInit.debugRun  = 0;
    cryoInit.em4Wakeup = 0;

    /* Clocking settings */
    /* With a frequency of 1000Hz on ULFRCO, this will result in a 1.00 ms timeout */
    cryoInit.osc    = cryotimerOscULFRCO;
    cryoInit.presc  = cryotimerPresc_1;
    cryoInit.period = cryotimerPeriod_1;
    CRYOTIMER_Init(&cryoInit);
}

Setup GPIO interrupt for button press

void MIDI_init_buttons(void)
{
    /* Init GPIO ISR dispatcher */
    CMU_ClockEnable(cmuClock_GPIO, true);
    GPIOINT_Init();

    /* Setup PB0 */
    /* GPIO init for button pins */
    GPIO_PinModeSet(BSP_BUTTON0_PORT, BSP_BUTTON0_PIN, gpioModeInput, 0);

    /* Register GPIO ISR */
    GPIOINT_CallbackRegister(BSP_BUTTON0_PIN, PB0_pressed);

    /* Trigger for both edge */
    GPIO_IntConfig(BSP_BUTTON0_PORT, BSP_BUTTON0_PIN, true, true, true);
...

Function to send a note on message

The status byte is 0x90 is 0b1sssnnnn where sss is message type and nnnn is the MIDI channel.

The last two bytes contains the 2 byte long event field in this case it is the note and velocity.

Finally the function sends the message with the gecko_cmd_GATT_server_send_characteristic_notification API function.

void MIDI_note_on(uint8 note, uint8 velocity)
{
  static MIDI_data_t note_on;

  /* Get the timestamp from the CRYOTIMER */
  uint32 temp = CRYOTIMER_CounterGet();
  /* Mask it - only the lower 13 bit needed */
  temp = temp & 0x00001fff;
  /* Header byte = 0b10xxxxxx where xxxxxxx is top 6 bits of timestamp */
  note_on.MIDI_event.header = 0x80 | (temp >> 7);
  /* Timestamp byte = 0b1xxxxxxx where xxxxxxx is lower 7 bits of timestamp */
  note_on.MIDI_event.timestamp = 0x80 | (temp & 0x003f);
  /* Status byte = 0b1sssnnnn where sss is message type and nnnn is channel */
  note_on.MIDI_event.status = 0x90;
  /* setting the note parameter */
  note_on.MIDI_event.note = note;
  /* setting the velocity parameter */
  note_on.MIDI_event.velocity = velocity;
  /* sending the assembled MIDI message */
  gecko_cmd_GATT_server_send_characteristic_notification(connectionId, GATTdb_xGATT_MIDI, 5, (uint8 const *) &note_on);
}

Testing

Once the application flashed to kit it starts advertise itself. After connection it pairs and bonds with just work method. The application tested with the following IOS apps:

Korg Module
Korg Gadget
Apple GarageBand

References

[1] https://www.midi.org

[2] https://www.midi.org/specifications/item/bluetooth-le-midi

[3] https://en.wikipedia.org/wiki/MIDI

Jun 19 2019, 10:55 AM

baadamff

Posted WGM110 Direct WiFi - Search and connect on qna

We are currently exploring the potential of using the WGM110 module in a WiFi direct project. One scenario is there maybe multiple WGM110 devices.

We assume the user has already connected to all of the devices and set everything up (for example one touch security).

Based on their mac address etc... we could give each Direct WiFi Device a unique names.

An android application could simply cycle through the list of WiFi direct devices detected and connect to them one by one in order query their functionality (Perhaps json, or a web page might be provided by the WiFi Direct device).

Does this approach seem sensible?

Nov 27 2018, 9:22 AM

baadamff

Posted Using Bluetooth security features in Silicon Labs Bluetooth SDK on Knowledge Base

Using Bluetooth security features in Silicon Labs Bluetooth SDK

This article introduces the Bluetooth security features and terms then summarizes the practical usage of GATT permissions and pairing processes using the Silicon Labs Bluetooth SDK.

Bluetooth Security Basics

The most common threats in wireless communications are:

Passive eavesdropping
Active eavesdropping = Man in the Middle (MITM)
Privacy (tracking)

Bluetooth defines 5 distinct security features against these threats:

Pairing — creating trusted relationships between devices (Key Generation, Key Exchange, Identity Information Exchange)
Bonding — Storing the keys created during pairing for later connections
Device authentication — verification that devices have the same keys (Protected from MITM)
Encryption — data confidentiality (FIPS or NIST approved AES128-CCM algorithm used)
Data signing (Message integrity) — protection against data alteration

These features implemented in different layers of the Bluetooth stack. Let's have a quick look on these.

Pairing

Is the process of creating trusted relationships between devices
Used to generate and exchange security keys
Used to exchange identity information

Bluetooth uses Secure Simple Pairing (SSP) pairing model. The actual pairing process depends on the device I/O capabilities and the security requirements defined by the application.

Just works — For devices without UI. No user interaction required. No MITM protection. In case of Just works pairing there is no possibility to confirm the identity of the connecting devices. Devices will pair with encryption but without authentication.
Passkey entry — User needs to enter a passkey the remote party displays. Provides MITM protection
Numeric comparison — User needs to confirm passkeys both devices display. Provides MITM protection
Out-of-band — Encryption keys exchanged for example with NFC

More details can be found here in the Pairing Processes KBA.

Bonding

Storing security keys for future use
ex. authentication of connections or verifying devices identity

Authentication

Authentication is defined as a way to prove that the device with which you are connecting is actually the device it claims to be and not a third-party attacker
Authentication in the GATT Profile is applied to each characteristic independently. The GATT Profile procedures are used to access information that may require the client to be authenticated

A characteristic may be allowed to be read by any device, but only written by an authenticated device. Similarly, if a characteristic can be written, it does not mean the characteristic can also be read. Each individual characteristic could have different security properties.

Encryption

Encryption protects the data confidentiality and integrity
Paired or bonded devices can encrypt/decrypt data sent within a connection
Bluetooth uses AES-128 as the encryption algorithm

Notice: No encryption of broadcast data

Attribute permissions

Attributes have a set of permissions that controls whether they can be read or written, or whether the attribute value shall be sent over an encrypted link
Attribute permissions are used by the server to determine whether read or write access is permitted for a given attribute
Attribute permissions are established by the GATT Profile so different permissions can be granted for the characteristics and descriptors

Security Levels

Security level is a property of a connection. Using different security features can lead to different security levels per connection. The different levels summarized below.

Security Level	Description
Level 1	No security
Level 2	Unauthenticated pairing with encryption (paired with just work method)
Level 3	Authenticated pairing with encryption (paired with legacy pairing)
Level 4	Authenticated Secure Connections pairing with encryption using a 128-bit strength encryption key (Paired with LE secure pairing which is Bluetooth 4.2 feature)

Privacy

Bluetooth provides privacy protection
Devices can either use public or private (random) addresses

Public address is fixed and unique to a device Random address can change over time and hides the public address from unwanted devices Bonded devices can resolve the public address

Bluetooth 4.2 Security Features

New LE Secure connections feature using Elliptic Curve Diffie-Hellman (ECDH) public-private key pairs for numeric comparison paring method
New numeric comparison paring method. In this pairing method both devices will display a 6-digit passkey. The user must confirm, that the two devices display the same passkey by pressing a button.
Passkey entry and OOB has updated LE Secure Connection variant. But there is no change from application perspective.
LE privacy 1.2 — Identity resolving moved from host to controller for faster and lower power operation

Using security features in Silicon Labs Bluetooth SDK

To use the security features you need to do the following steps:

Set up attribute permissions in GATT
Set up security manager
Set up bonding (enabled/disable/delete)
Increase security level (optional)
Handle security manager stack events by the application

Set up attribute permissions in GATT

The characteristics access and security properties are defined in the gatt.xml file by the XML attribute properties and its parameters, which must be used inside the characteristic XML attribute tags. Alternatively, Visual GATT Editor can be also used for defining the GATT elements and their permissions. The table below describes the parameters that can be used for defining attribute permissions.

attribute property	description
read	Characteristic can be read by a remote device
write	Characteristic can be written by a remote device
bonded_read	Reading the characteristic value requires an encrypted link. Devices must also be bonded at least with Just Works pairing
bonded_write	Writing the characteristic value requires an encrypted link. Devices must also be bonded at least with Just Works pairing
authenticated_read	Reading the characteristic value requires an authentication. In order to read the characteristic with this property the remote device has to be bonded using MITM protection and the connection must be also encrypted
authenticated_write	Writing the characteristic value requires an authentication. In order to write the characteristic with this property the remote device has to be bonded using MITM protection and the connection must be also encrypted
encrypted_read	Reading the characteristic value requires an encrypted link. iOS 9.1 and newer devices must also be bonded
encrypted_write	Writing the characteristic value requires an encrypted link. iOS 9.1 and newer devices must also be bonded

GATT Examples

Here we have 3 example for setting up attribute permissions for a characteristic.

Example 1 — No restrictions

In this case properties ensure that reading and writing the characteristic is without any restriction. It does not require authentication or encrypted link. Any GATT client can read or write it.

Example 2 — Encrypted write

Now let's set up the characteristic differently

In this case reading the characteristic is without any restriction. But writing the characteristic requires encrypted link. Characteristics which requires encryption cannot be accessed without pairing. So writing this characteristic in the first time will trigger the pairing process. The pairing can be just works so it is allowed to not have MITM protection.

Example 3 — Authenticated write

Now let's modify the characteristic properties again.

In this case reading the reading the characteristic is without any restriction. But writing requires authentication. It means the remote device must be bonded with man in the middle (MITM) protection enabled. So the characteristic cannot be accessed in case of just works pairing used. Writing this characteristic in the first time will trigger the pairing process.

Setting up the security manager

The application shall use the gecko_cmd_sm_configure(flags, io_capabilities) API to set up the security configuration. The io_capabilities and flagsparameters affect the security level with which the devices will use in connection and leads to different pairing mechanisms.

The io_capabilities parameter informs the stack about the possible user input and output method that is available on the device. See the available options here below:

Value	Enumeration	Description
0	sm_io_capability_displayonly	Display Only
1	sm_io_capability_displayyesno	Display with Yes/No-buttons
2	sm_io_capability_keyboardonly	Keyboard Only
3	sm_io_capability_noinputnooutput	No Input and No Output
4	sm_io_capability_keyboarddisplay	Display with Keyboard

The flags parameter controls different application specific security requirements. This parameter gives flexibility to the application to decide how strictly use or not use at all the Bluetooth security features. The table below shows the different options:

Bitmask	Description
bit 0	0: Allow bonding without MITM protection
	1: Bonding requires MITM protection
bit 1	0: Allow encryption without bonding
	1: Encryption requires bonding. Note that this setting will also enable bonding.
bit 2	0: Allow bonding with legacy pairing
	1: Secure connections only
bit 3	0: Bonding request does not need to be confirmed
	1: Bonding requests need to be confirmed. Received bonding requests are notified with sm_confirm_bonding events.
bit 4 to 7	Reserved

If the flags parameter is 0, so no application specific requirement set, the pairing method depends only on the IO capabilities of the initiator and the responder device (shown as I and R on the table below).

Responder/Initiator IO capabilities	Display Only	DisplayYesNo	KeyboardOnly	NoInputNoOutput	KeyboardDisplay
Display only	Just Works	Just Works	Passkey Entry(R displays,I inputs)	Just Works	Passkey Entry (R displays,I inputs)
DisplayYesNo	Just Works	Numeric Comparison	Passkey Entry (R displays, I inputs)	Just Works	Numeric Comparison
KeyboardOnly	Passkey Entry (I displays, R inputs)	Passkey Entry (I displays, R inputs)	Passkey Entry (R and I inputs)	Just Works	Passkey Entry(I displays, R inputs)
NoInputNoOutput	Just Works	Just Works	Just Works	Just Works	Just Works
KeyboardDisplay	Passkey Entry (I displays, R inputs)	Numeric Comparison	Passkey Entry(R displays, I inputs)	Just Works	Numeric Comparison

If a device has application specific security requirements (flags parameter is not 0) then the used pairing method and security level of the connection will be different.

MITM - bit 0

Setting the bit 0 forces the MITM protection. In practice it means that our devices will not bond with devices which don't have the io capabilities at least for legacy pairing.

Encryption - bit 1

Setting the bit 1 forces link encryption. In practice it means that our devices will always use encrypted link with bonded devices. Note if the bonding table is full therefore the device can't save the new bond.

LE Secure connections support - bit 2

If both devices support LE Secure Connections, then the value of then bit 2 doesn’t matter. If either one of the devices doesn’t support secure connections i.e. it supports legacy pairing only, then bit 2 comes into play.

If bit 2 set to 1, secure connection is enforced, and the pairing attempt will fail with error code 0x303 (pairing_fail_authentication_requirements error). This is essentially saying that we don’t want to pair with legacy devices. If bit 2 set to 0, the pairing will fall back to legacy pairing methods.

Application level confirmation of bonding request - bit 3

If bit 3 is set then bonding requests need to be confirmed by the application too. This feature gives additional control over incoming bond requests. So the application can reject devices which otherwise could bond. The application notified about the received bonding request by the sm_confirm_bondingstack event.

The application shall accept or reject the bonding request with the cmd_sm_bonding_confirm command.

Set up bonding (enabled/disable/delete)

To enable secure connection (Security Level 2 and above) the application need to allow bonding. The stack provides the gecko_cmd_sm_set_bondable_mode API function to enable or disable the bonding.

Please note if gecko_cmd_sm_configure(flags, io_capabilities) called with flags parameter where bit 1 is set then the bonding enabled automatically.

During application development sometimes it is useful to delete all the bondings to trigger and test the pairing processes. It can be done by the cmd_sm_delete_bondings API.

There are use cases when the application has to manage the bonding table directly. This is out of scope of this article. You can read more about this in a separate KBA.

Increase security level

If the GATT attribute permissions are set correctly the application don't have to increase the security level manually. The security level of the connection will be increased once there is access demand for GATT elements which requires higher security level. If the 2 devices not bonded yet the pairing process also triggered.

However there can be use cases where the application handles the security level of the connections. In those cases it makes sense to call the cmd_sm_increase_security API function in the evt_le_connection_opened event handler.

Handle security manager stack events by the application

During the pairing process there are few stack events that the application has to handle otherwise the pairing and bonding will fail. These events are the following.

evt_sm_passkey_display
The evt_sm_passkey_display event indicates a request by stack to display the passkey to the user during the pairing process. The application shall write the passkey to a display given by the event as passkey parameter. This event only can happen if the device has a display. It is defined in its io capabilities. See [the Setting up the security manager](### Setting up the security manager) chapter above.

evt_sm_passkey_request
The evt_sm_passkey_request event indicates a request for the user to enter the passkey displayed on the remote device. The application has to read the passkey then push it to stack by the sm_enter_passkey command.

If the passkey was valid and the bonding completed the stack raise a evt_sm_bonded event. If the passkey was invalid or the bonding failed because of any other reason the stack will raise a evt_sm_bonding_failed event.

evt_sm_confirm_passkey
This event can happen when the stack is using numeric comparison pairing method. Its indicates a request to display the passkey to the user then asks to confirm that displayed passkey is the same what is displayed on the remote device. The cmd_sm_passkey_confirm has to be called by the application to accept or reject the displayed passkey depending on the users answer.

evt_sm_bonded
This event is triggered after the pairing or bonding procedure has been successfully completed.

evt_sm_confirm_bonding
This event indicates that new bonding request has been received. The application has to call sm_bonding_confirm to accept or reject the incoming bonding request. This feature can be activated by calling the gecko_cmd_sm_configure(flags, io_capabilities) where the bit 2 of the flag parameter is set to 1.

evt_sm_bonding_failed
This event is triggered when the pairing or bonding procedure failed. The possible reasons and errorcodes are documented here.

References

API Documentation

Bluetooth Core Specification

Pairing Processes

Application Layer Security

Bond Replacing Algorithm

OOB Introduction

Secure Connection Example

Authenticating Devices with No User Interface

Nov 07 2018, 8:57 AM

baadamff

Updated How can I extend the Bluetooth examples with UART functionality? on Knowledge Base

Question

How can I extend the Bluetooth examples with UART functionality?

Answer

There are 3 options:

1. Use the standard printf and get functions which are retargeted to one USART or LEUART peripheral.

This option is very easy to use but you cannot send binary data with this.

The easiest way to use printf is through the use of our retargetserial driver. To get started,

copy the following files from the hardware\kit\common\drivers\ folder in the SDK to your project
- retargetio.c, retargetserial.h and retargetserial.c
include retargetserial.h in your main.c
call RETARGET_SerialInit() before the first call to printf()
open hal-config.h and set the definition of HAL_VCOM_ENABLE as shown below
- #define HAL_VCOM_ENABLE (1)

Now you can call printf() anywhere in the application and the output will be directed through the virtual COMPORT. Please remember that printf() can take somewhat long to execute so care should be taken in using it so that Bluetooth connections are not interrupted.

2. Use the em_usart or the em_leuart driver.

These drivers are part of the emlib. They provide an API for the USART and LEUART MCU peripherals.You can find more about the API here:

https://siliconlabs.github.io/Gecko_SDK_Doc/efr32bg1/html/group__USART.html

https://siliconlabs.github.io/Gecko_SDK_Doc/efr32bg1/html/group__LEUART.html

3. Use the uartdrv driver.

This driver is the most flexible from the available options. It is built on the top of emlib. The UART driver support both USART and LEUART peripherals.

The driver is fully reentrant and multiple driver instances can coexist. The driver does not buffer or queue data, but it queues UART transmit and receive operations. Both blocking and non-blocking transfer functions are available. Non-blocking transfer functions report transfer completion with callback functions. Transfers are done using DMA. Simple direct/forced transmit and receive functions are also available.

UART hardware flow control (CTS/RTS) is fully supported by the driver. UART software flow control (XON/XOFF) is partially supported.

In this article we going to set up the uartdrv to use the USART peripheral in few steps. The attached example is demonstrating the initialization and the using of non-blocking RX/TX functions with implementing a simple echo functionality.

Setting up the uartdrv

Step 1 – Add the necessary emlib source files to the project from the gecko SDK. These are the followings:

platform\emlib\src\em_cmu.c

platform\emlib\src\em_core.c

platform\emlib\src\em_dma.c

platform\emlib\src\em_emu.c

platform\emlib\src\em_gpio.c

platform\emlib\src\em_int.c

platform\emlib\src\em_ldma.c

platform\emlib\src\em_leuart.c

platform\emlib\src\em_usart.c

Then add the necessary emdrv source files to the project from the gecko SDK. These are the followings:

platform\emdrv\dmadrv\src\dmadrv.c

platform\emdrv\gpiointerrupt\src\gpiointerrupt.c

platform\emdrv\uartdrv\src\uartdrv.c

Step 2 – Update the include paths of the project.

You need to add the emlib and emdrv include paths as listed below:

platform\emlib\inc

platform\emdrv\common\inc

platform\emdrv\dmadrv\config

platform\emdrv\dmadrv\inc

platform\emdrv\gpiointerrupt\inc

platform\emdrv\uartdrv\inc

platform\emdrv\uartdrv\config

In case using UART over J-Link CDC-on Silicon Labs boards you need the include path for the board and kit abstraction headers also. These headers containing the Virtual COM pin settings. The path for these are below:

hardware\kit\\common

hardware\kit\common\bsp

hardware\kit\common\halconfig

Step 3 – Once the necessary files and include paths are added you need to switch of the automatic sleeping feature of the Bluetooth stack. This is needed because the USART peripheral is not working in EM2. It can be done by setting the gecko_configuration_t.sleep.flags to 0 as shown below.

/* Gecko configuration parameters (see gecko_configuration.h) */
static const gecko_configuration_t config = {
  .config_flags = 0,
  .sleep.flags = 0, // <- DISABLE THE SLEEP HERE
..
}

Step 4 – On Silicon Labs kits you can use the UART over the J-Link CDC. For that you need to route the UART signals from the MCU to the board controller of the kit.

This can be done by setting VCOM enable pin high. Most of the kits it can be done by setting a GPIO by software. But on some kits a 0 Ohm resistor must soldered additionally.

Here is how you can enable VCOM by software.

GPIO_PinOutSet(BSP_BCC_ENABLE_PORT, BSP_BCC_ENABLE_PIN);

Example

The attached uart_echo.c and uart_echo.h implements terminal echo. It can be used in any Bluetooth SDK project once the steps described above are completed.

Calling the UART_EchoInit(uint8_t vcom) sets the VCOM enable pin, configures the uartdrv then start to receive.

Once a byte received the UART_rx_callback called by the uartdrv. The callback immediately transmits the received byte back and start to receive the next byte.

Aug 17 2018, 8:08 AM

baadamff

Replied to How can I use uartdrv on BGM121 with Bluetooth SDK 2.9.2.0?

Hi,

The project in the zip file is using the old SDK.

But you can use the attached .c and .h files in newer SDKs.

-Balázs

Aug 15 2018, 11:08 AM

Level 6

Level 5

Following 1

Siliconlabs