@Mingta Fan,

Thank you very much for your answers.

We recommend our customers selecting the latest QDID for the version of Bluetooth SDK used on their products. "Link Layer (Bluetooth 5.0 – including coded PHYs)" is an update to our old listing "Link Layer (Bluetooth 5.0)" where the Bluetooth SDK doesn't support Coded PHY. The customers who have used "Host stack (Bluetooth 5.0)" may select "Link Layer (Bluetooth 5.0 – including coded PHYs)" as the Bluetooth specification versions match.

In your case, you should select the components for Bluetooth 5.1. I guess you could use "Host stack (Bluetooth 5.0) 101550" and "Link Layer (Bluetooth 5.0 – including coded PHYs) 124272" if you were using Bluetooth SDK 2.10.x.

Coded PHY is a new physical layer data throughput configuration introduced in Bluetooth 5.0. You may read this document for further information: https://docs.silabs.com/bluetooth/latest/general/connections/using-2m-and-le-coded-phy-bt5

 

@Mingta Fan,

Thanks for the explanation. Understood.

And one more question.

Given that we launch our product with Bluetooth SDK 2.11.5.0, can we skip Bluetooth SIG re-registration with Link Layer (Bluetooth 5.2) 147971 and Host stack (Bluetooth 5.2) 146950 if we migrate to SDK v2.13.x and above after our product launch by distributing OTA update with newer Bluetooth SDK?

@Mingta Fan,

Thanks for your answer.

We understand we should use your pre-qualified BGM11S 145424, Host stack 126252, Link Layer 127618 under our condition with BGM11S and Bluetooth SDK 2.11.5.0 (v2.5.5).

However, we'd like to have a complete understanding by clarifying when to use Link Layer (Bluetooth 5.0 – including coded PHYs) 124272 instead of Link Layer (Bluetooth 5.1) 127618.

In which case should we use Link Layer (Bluetooth 5.0 – including coded PHYs) 124272 specifically?

Could you show us an example if we should use Link Layer Bluetooth 5.0 – including coded PHYs) 124272 instead of Link Layer (Bluetooth 5.1) 127618?

And what does "including coded PHYs" mean?

We have a peripheral IoT product that incorporates the BGM11S (specifically BGM11S22F256GA) with Bluetooth SDK 2.11.5.0 (v2.5.5), and we are looking into Bluetooth SIG registration.

As described in the below document, we believe that we should register with Host stack 126252 and Link Layer 124272 or 127618 along with BGM11S module QDID 145424 based on the BGM11S Data Sheet. Is that correct?

https://www.silabs.com/documents/public/quick-start-guides/qsg139-getting-started-with-bluetooth.pdf#page=8

The above software-based pre-qualified components are two out of the three components to integrate when proceeding with the "Qualification Process with Required Testing". Despite the “Required Testing", customers do not need to do any additional testing, given that the test reports are embedded in the pre-qualified components for the SIG to review.

If so, which Link Layer QDID should we use for Bluetooth SIG registration, 124272 or 127618 ?

For our future reference, can you tell me which Silicon Labs' document we should look through to identify the QDIDs used for Bluetooth SIG registration?

I received an installation python script through a support case and tried it, but it did not work at all for some reasons. After a while, I gave up the command line installation and ended up installing necessary SDK and toolchains on Simplicity Studio GUI with X11 forwarding in my docker container.

Hi baleidec,

Thanks for your feedback. Is it possible for Simplicity Commander to revert the PS key to "not-defined" state for a test purpose?

Which absolute address does the PS key=0x4000 actually indicate?

Regards,

Hayashi

Hi baleidec,

What is the default values in Persistent Storage just after erasing the PS Key area?

I tried to follow KBA_BT_0309 to load a default flag from PS Key, but it fails with ps_load_object / gecko_cmd_flash_ps_load returning 0x502 which seems like meaning ps_key_not_found.

Does it mean gecko_cmd_flash_ps_load always fails until any values are written in PS Key by gecko_cmd_flash_ps_save?

If so, how can we set the default value just after our device with BGM123 is manufactured with our default firmware? Is it possible to flash PS key area by Simplicity Commander?

    uint8_t val;
    uint16_t result;
    gecko_cmd_flash_ps_erase(0x4000); // erase the value

    result = ps_load_object(0x4000, &val, sizeof(val));
    if(result == 0) {
      // value was loaded OK
      print("val=%X\n", val);
    } else {
      // value not OK (either not stored in PS or length of the data does not match the expected value)
      print("Failed to load val w/ err 0x%X\n", result);
    }

Regards,

Hayashi

Hi,

With BGM123, I want my own application to distinguish 1st boot from 2nd or later boot after finishing OTA update so that BGM123 application can automatically start advertising only initial boot just after OTA update. What is the easiest way for my application main to get this kind of flag?

Is there any tailored/dedicated flag in order for application to detect whether the boot is 1st or not? Any recommendations to meet this requirement if you do NOT have any prearranged mechanism for this?

Regards,

Hayashi

@jpitt,

Thanks for your reply. Please let me know once you complete the example python scripts modification.