10 Replies Latest reply on Apr 14, 2016 11:21 PM by yvrac_2202791

    Non secure OTA update

      I have implemented the OTA update on my board.


      In fact, the update by HCI or OTA works fine (by Android or Windows example provided by the SDK). The functionalities of the firmware are correctly updated.

      But I would to check the firmware version by the Android application. So with the Android update application I check the characteristic Application Info, the issue is that the version returned by the firmware is false: the value is always Major=1, Minor=1, even the right value is 1.2 or 1.3 (defined by: #define MY_APP_ID 0x0476,  #define MY_APP_VERSION_MAJOR 1, #define MY_APP_VERSION_MINOR 3, for WS_UPGRADE_CHARACTERISTIC_APP_INF definition).


      Note: the application ID is correct.


      What do you think I have forgotten or wrongly done ?

        • 1. Re: Non secure OTA update

          Does a power reset after OTA help? yvrac_2202791

          • 2. Re: Non secure OTA update

            I did hardware resets and power resets without any success.

            • 3. Re: Non secure OTA update

              I couldn't reproduce this issue but I am working on a tag3 board. Can you use the OTA update sample app available in the SDK and try it out on your board?



              • 4. Re: Non secure OTA update

                I have implemented the update functions from this application, but OK, I will try to test the OTA update sample app "as is" on my board this week

                • 5. Re: Non secure OTA update

                  I tested today the OTA update sample on my board, and it works.

                  I compared the 2 applications, and I discovered that  I declared the device name with 24 characters. I reduced the length to 16 char and it works ! It feels as a side effect !

                  What is the maximum authorized length for the device name (I saw in the forum that it is also  limited by the advertising length) ?

                  • 6. Re: Non secure OTA update

                    There are constraints on the advertising packet and scan response payloads. The maximum size is 31 octets each as per the BT Specification but it can be shorter. I'm not sure where the payload length is defined in the SDK code, but lets take a look.

                    • 7. Re: Non secure OTA update

                      So, if I understand (it is not so clear in others topics), each field of advertising or scan response can be 31 bytes long.

                      For example, if I use this classical function to define and start advertising:

                      void my_start_ADV()


                          // advertise first vendor specific service

                          if (sizeof(my_uuid_main_service) > 1)




                              // total length should be less than 31 bytes

                              BLE_ADV_FIELD adv[3];

                              BLE_ADV_FIELD scr[1];


                              // flags

                              adv[0].len = 1 + 1;

                              adv[0].val = ADV_FLAGS;

                              adv[0].data[0] = LE_LIMITED_DISCOVERABLE | BR_EDR_NOT_SUPPORTED;


                              adv[1].len = sizeof(my_uuid_main_service) + 1;

                              adv[1].val = sizeof(my_uuid_main_service) == 16 ? ADV_SERVICE_UUID128_COMP : ADV_SERVICE_UUID16_COMP;

                              memcpy(adv[1].data, &my_uuid_main_service[0], sizeof(my_uuid_main_service));


                              // Tx power level

                              adv[2].len = TX_POWER_LEN+1;

                              adv[2].val = ADV_TX_POWER_LEVEL;

                              adv[2].data[0] = bleprofile_p_cfg->tx_power_level;


                              // name

                              scr[0].len = strlen(bleprofile_p_cfg->local_name) + 1;

                              scr[0].val = ADV_LOCAL_NAME_COMP;

                              memcpy(scr[0].data, bleprofile_p_cfg->local_name, scr[0].len - 1);


                              bleprofile_GenerateADVData(adv, 3);

                              bleprofile_GenerateScanRspData(scr, 1);





                          // start device advertisements.  By default Advertisements will contain flags, device name,

                          // appearance and main service UUID.

                          bleprofile_Discoverable(HIGH_UNDIRECTED_DISCOVERABLE, NULL);



                      in this case, could the local_name be 31 bytes long (as scan response payload), or should  the total adv fields + scr length be less than 31 bytes ?


                      • 8. Re: Non secure OTA update

                        Hi Yves,


                        I think the relevant part of the BT spec. is in Volume 6 - Core system package for Low Energy - section 2 details Air Interface Packet format.





                        • 9. Re: Non secure OTA update


                          The adv and scr are separate packets so they can each be 31 bytes.


                          But remember each field has two bytes header (length and value).

                          So that leaves 29 bytes for actual data.


                          You can find more about adv packets in the following link:

                          Advertiser and Scanner



                          • 10. Re: Non secure OTA update

                            Thanks guys. It confirms that I understood.