MAC addresses

The Smart Ready software will make use of one of three possible MAC addresses. These are 1] the address burned in the radio chipset by the third party manufacturer, 2] the address stored in the Smart Ready software's own bootloader (referred to as the factory address, being configured during production and taken from the range of addresses assigned to Bluegiga or Silicon Labs), and 3] the temporary/user address stored in the PSKey 44 (0x2c) which can be written and activated during runtime with the BGAPI/BGScript command dumo_cmd_system_set_bt_address.

When some address exists in the PSKey at boot, this will be used by the stack. If the PSKey is erased during runtime, the current temporary address is kept active, but only until the next reboot. If the PSKey does not exists at boot, then the factory address will be in use. This is the normal condition in most cases.

You can check at any time the current MAC address in use by launching the command dumo_cmd_system_get_bt_address.

The only case when the radio chipset’s address is in use is when the PSKey does not exist and at the same time the factory address is the invalid ff:ff:ff:ff:ff:ff.

Re-flashing considerations

Provided that the factory address is correctly configured in production, notice that the bgupdate.exe (and the update functionality in BGTool) will take care of reading it from the current bootloader and injecting it back when the generic new firmware image will be written.

A generic .bin firmware image created with the bgbuild.exe contains the bootloader and has the address set to ff:ff:ff:ff:ff:ff.

Also the dfu.exe obtained from the SDK is designed to preserve the factory address.

However, the factory address will go lost (that is, will be replaced with the all Fs address in the firmware image) when re-flashing over the SWD interface or when implementing your own ST-based DFU functionality.

In these cases, if you wish your module to keep on using the original factory address, that is, you do not want your module to start using the radio chipset’s address, then you will have two options:

1] read the current address beforehand with the dumo_cmd_system_get_bt_address, and use the dumo_cmd_system_set_bt_address to set it back as the user address (notice here that in general there is no way to preserve any PSKey across a re-flash), or

2] arrange for your re-flash routine to read the current address stored in the current bootloader and then inject it into the bootloader that you are going to write to the Flash memory: the factory MAC address is stored in the very last 8 bytes of the bootloader (and no CRC is applied to those bytes).

Additional reading: please make sure to have a look also at the knowledge-base article about re-flashing at http://community.silabs.com/t5/Bluetooth-Wi-Fi-Knowledge-Base/Programming-the-BT121/ta-p/173579

With the iWRAP software you are given the option to include the localization information in the HID profile configuration command (the parameter is named country_code). The exact syntax for the configuration command is:

SET PROFILE HID {features} {subclass} {version} {country_code} {BTlang} {USBlang} {service_name}

And here is what iWRAP User’s Guide says about the parameter country_code:

“Country code for localization information, for example the language of the key caps of a keyboard. Set to zero if not localized.”

The following table specifies the valid country codes as seen in the document named Device Class Definition for HID 1.xx (pages 22-23), which is available at the USB Implementers Forum website (http://www.usb.org/developers/hidpage/):

As you might have already noticed, changing the country code does not re-map characters across different languages. Why is this happening?

In the following example with German and US keyboard layouts, I will refer to the HID Usage Tables 1.xx document, also available at the USB Implementers Forum website mentioned above (pages 53-59).

Let's take for example HID raw report “0x 01 00 00 1c 00 00 00 00 00”.

Looking at page 54 of the mentioned Hut1_12v2.pdf we see that 0x1c corresponds to US keyboard character “y” found at AT-101 key position 22. Now, as the footnote 4 at page 59 of Hut1_12v2.pdf reminds, this character might be re-mapped, and this is indeed the case for example with a German-localized host where the re-mapped character is “z” according to the fact that it is this very character and not the “y” to be found at AT-101 key position 22 of the German keyboard layout.

Figure 1. US keyboard layout

Similarly, let's take for example HID raw report “0x 01 00 00 1d 00 00 00 00 00”.

Now, looking at page 54 of the Hut1_12v2.pdf we see that 0x1d corresponds to US keyboard character “z” (found at AT-101 key position 46) which is re-mapped by the German-localized host to “y”, which is also found at AT-101 key position 46, but of the German keyboard.

Figure 2. German keyboard layout

Summarizing:

• “y” is in position 46 of the German keyboard, so HID raw report should contain value 0x1d
• “y” is in position 22 of the US keyboard, so HID raw report should contain value 0x1c
• “z” is in position 22 of the German keyboard, so HID raw report should contain value 0x1c
• “z” is in position 46 of the US keyboard, so HID raw report should contain value 0x1d

As you can see in the example, the language setting from HID descriptor (country_code) is a localization information required by the Bluetooth specification and does not have any influence on the HID raw reports that are being sent.

iWRAP software itself does not implement keyboard layout re-mapping across different languages and there are no technical possibilities to do that. In order to include such feature in your design, you would need to implement it in the attached MCU, while referring to the various keyboard layouts which are documented e.g. here:

http://www-01.ibm.com/software/globalization/topics/keyboards/registry_index.html

References:

1. Bluetooth HID Profile – iWRAP Application Note, https://www.bluegiga.com/en-US/download/?file=09rQlqb5QzOabHxbSYzmOQ
2. Device Class Definition HID, http://www.usb.org/developers/hidpage/HID1_11.pdf
3. HID Usage Tables version 1.12, http://www.usb.org/developers/hidpage/Hut1_12v2.pdf
4. IBM Globalization - Keyboard Layouts, http://www-01.ibm.com/software/globalization/topics/keyboards/registry_index.html