Non secure OTA update

Tip / Sign in to post questions, reply, level up, and achieve exciting badges. Know more

cross mob
Anonymous
Not applicable

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 ?

0 Likes
1 Solution
Anonymous
Not applicable

Hello.

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

James

View solution in original post

10 Replies
BoonT_56
Employee
Employee
500 likes received 250 likes received 100 likes received

Does a power reset after OTA help? yrt

0 Likes
Anonymous
Not applicable

I did hardware resets and power resets without any success.

0 Likes

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?

cgariss

0 Likes
Anonymous
Not applicable

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

0 Likes
Anonymous
Not applicable

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) ?

0 Likes

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.

0 Likes
Anonymous
Not applicable

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)

    {

        ble_trace0("my_start_ADV...");

        // 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);

    }

    blecm_setTxPowerInADV(0);

    // 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 ?

0 Likes

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.

santol

0 Likes
Anonymous
Not applicable

Hello.

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

James

Anonymous
Not applicable

Thanks guys. It confirms that I understood.

0 Likes