USB-KW41Z - MTU Exchange - Changing gAttMaxMtu_c has no effect

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

USB-KW41Z - MTU Exchange - Changing gAttMaxMtu_c has no effect

Jump to solution
3,043 Views
chilipp
Contributor III

Hello,

I want to decrease the maximum MTU size of a USB-KW41Z for testing purpose from 247 to e.g. 150.

So I changed the gAttMaxMtu_c define within the ble_constants.h file from 247 to 150.

Unfortunately, executing an MTU-Exchange still produces requests / responses with a maximum MTU size of 247.

Is it possible at all to change the maximum MTU size for the USB-KW41Z? Somewhere I read that the maximum MTU size of 247 results from the Bluetooth Core Specification Version 4.2 - but actually I was not able to find such requirement (What I did was searching the complete specification for "247" - no results regarding any MTU size) and as far as I know the only official specified limit for the ATT_MTU is its lower bound of 23.

Kind regards!

Labels (1)
0 Kudos
1 Solution
2,918 Views
chilipp
Contributor III

What a pity!

Yet it seems as simple this:

File: ble_globals.c

 

uint16_t gAttMaxMtu = gAttMaxMtu_c;

 

And within the source code of the "host" static libraries:

 

extern uint16_t gAttMaxMtu;

 

while using the "gAttMaxMtu" variable for every reference to the currently used and hard coded (variables) value of "247".

Nevertheless, if there is any possibility for an SDK update or news about this topic, I would appreciate a notification!

Kind regards.

View solution in original post

0 Kudos
11 Replies
3,028 Views
nxf56274
NXP Employee
NXP Employee

Hi,

Which example do you use? bluetooth 4.0 and 4.1 are 23. But 4.2 and 5.0 are 247.

From the picture, you will know the ATT data maximum value is 247.

11.PNG

Have a great day,
TIC

-------------------------------------------------------------------------------
Note:
- If this post answers your question, please click the "Mark Correct" button. Thank you!

- We are following threads for 7 days after the last post, later replies are ignored
Please open a new thread and refer to the closed one, if you have a related question at a later point in time.
-------------------------------------------------------------------------------

0 Kudos
3,017 Views
chilipp
Contributor III

Thank you for the reply!

The Bluetooth Core Specification in question is Version 4.2.

Thank you for clarifying where the "247" for the upper bound MTU size comes from.

Unfortunately that does not solve my issue.

Currently, the USB-KW41Z is programmed with the SDK(2.2.2)-Provided sample application "usbkw41z_kw41z_wireless_examples_bluetooth_ble_fsci_black_box_bm".

We drive the dongle via FSCI from the Computer. This is working fine.

Once a BLE-Link-Layer connection is successfully established to a remote peer BLE device, we trigger an MTU-Exchange via FSCI for that particular connection.

As a result, the Dongle issues an "Exchange MTU Request" with "Client Rx MTU: 247".

I want to decrease the supported "maximum MTU size" from 247 to e.g 150.

Therefore I changed line 82 in the "ble_constants.h" file to:

 

/*! Maximum possible value of the ATT_MTU for this device. This is used during the MTU Exchange. */
#define gAttMaxMtu_c                    (150)

 

After a fresh clean-build and downloading the modified version to the USB-KW41Z, the Dongle still issues an "Exchange MTU Request" with "Client Rx MTU: 247" for a triggered MTU-Exchange via FSCI.

MTU-247.JPG

So it seems changing "gAttMaxMtu_c" has no effect.

How can I set a custom "Maximum MTU size", e.g. decrease from the default 247 to 150?

0 Kudos
3,001 Views
nxf56274
NXP Employee
NXP Employee

Hi,

I am working on it. I use frdm-kw36. The example is w_uart. This example has the exchange process. I insert some code to test if it changed. 

1_3.PNG

1_1.PNG

1_2.PNG

Here is the result. I can change it. When I modify the gAttMaxMtu_c as 151, the result is 'not changed'. Hope you can get some ideals in this example. I will go on working on this.

66.PNG

 

Have a great day,
TIC

-------------------------------------------------------------------------------
Note:
- If this post answers your question, please click the "Mark Correct" button. Thank you!

- We are following threads for 7 days after the last post, later replies are ignored
Please open a new thread and refer to the closed one, if you have a related question at a later point in time.
-------------------------------------------------------------------------------

0 Kudos
2,995 Views
chilipp
Contributor III

Thank you for your efforts!

I see you call the GattClient_ExchangeMtu function with 2 parameters:

GattClient_ExchangeMtu(peerDeviceId, gAttMaxMtu_c);

Unfortunately, the SDK for the USB-KW41Z seems to ship with another "gatt_client_interface", since there is no GattClient_ExchangeMtu function that takes 2 parameters.

../source/wireless_uart.c: In function 'BleApp_StateMachineHandler':
../source/wireless_uart.c:744:21: error: too many arguments to function 'GattClient_ExchangeMtu'
  744 |                     GattClient_ExchangeMtu(peerDeviceId, gAttMaxMtu_c);
      |                     ^~~~~~~~~~~~~~~~~~~~~~

The only one available is

/*! *********************************************************************************
 * \defgroup GATT_CLIENT GATT - Client APIs
 * @{
 ********************************************************************************** */
/*!
* Copyright (c) 2015, Freescale Semiconductor, Inc.
* Copyright 2016-2017 NXP
* All rights reserved.
* 
* file
*
* SPDX-License-Identifier: BSD-3-Clause
*/

// ...

/*! *********************************************************************************
* \brief  Initializes the MTU Exchange procedure.
*
* \param[in] deviceId       Device ID of the connected peer.
*
* \return  gBleSuccess_c or error.
*
* \remarks If gBleSuccess_c is returned, the completion of this procedure is signalled
* by the Client Procedure callback.
*
********************************************************************************** */
bleResult_t GattClient_ExchangeMtu
(
    deviceId_t      deviceId
);

// ...

Also, since I'm using the FSCI implementation/blackbox example, I would not be able to edit the explicit implementation that is executed when the FSCI command for "Exchange MTU" arrives if I had to, because the FSCI handling is all done within a pre-compiled library (as far as I know).

I attach the SDK manifest for further SDK information.

0 Kudos
2,976 Views
nxf56274
NXP Employee
NXP Employee

Hi,

I use fsci example for device. And modified the gAttMaxMtu_c to 150. The device advertised and phone connected to the device. Then the phone request the MTU. I captured the packet. The device MTU doesn't change. I am not sure why this happen. 

Have a great day,
TIC

-------------------------------------------------------------------------------
Note:
- If this post answers your question, please click the "Mark Correct" button. Thank you!

- We are following threads for 7 days after the last post, later replies are ignored
Please open a new thread and refer to the closed one, if you have a related question at a later point in time.
-------------------------------------------------------------------------------

0 Kudos
2,950 Views
chilipp
Contributor III

Hi,

this is exactly the kind of behavior I have experienced.

I also tried your previous suggestion and looked at the MTU-Exchange in the TestTool, but there is no explicit parameter for setting the desired MTU size except for the latest BLE stack (?) version 1.6.6.

BLE_1.6.6.JPG

Unfortunately, the NXP-USBKW41Z does not support that version. The latest supported version for the USB-KW41Z is version 1.2.8. But that version (1.2.8) - and any version prior to 1.6.6 - does not provide a parameter for setting the desired MTU size during MTU exchange.

BLE_1.2.8.JPG

Note that I use the latest version of the Test-Tool.

TestTool.JPG

Nevertheless, as you already said, you experienced the same issue as I did.

Is there any possible workaround to fix this issue until a SDK update is released?

I suspect that the MTU size is hard-coded into the library "lib_ble_4-2_host_fsci_cm0p.a".

Maybe there is a chance to flip some bytes within the library to achieve the goal of setting a custom value for the used maximum MTU size during the MTU-Exchange?

0 Kudos
2,949 Views
chilipp
Contributor III

Hello,

this is exactly the kind of behavior I have experienced.

I also tried your previous suggestion and looked at the MTU-Exchange in the TestTool, but there is no explicit parameter for setting the desired MTU size except for the latest BLE stack (?) version 1.6.6.

BLE_1.6.6.JPG

Unfortunately, the NXP-USBKW41Z does not support that version. The latest supported version for the USB-KW41Z is version 1.2.8. But that version (1.2.8) - and any version prior to 1.6.6 - does not provide a parameter for setting the desired MTU size during MTU exchange.

BLE_1.2.8.JPG

Note that I use the latest version of the Test-Tool.

TestTool.JPG

Nevertheless, as you already said, you experienced the same issue as I did.

Is there any possible workaround to fix this issue until a SDK update is released?

I suspect that the MTU size is hard-coded into the library "lib_ble_4-2_host_fsci_cm0p.a".

Maybe there is a chance to flip some bytes within the library to achieve the goal of setting a custom value for the used maximum MTU size during the MTU-Exchange?

0 Kudos
2,939 Views
nxf56274
NXP Employee
NXP Employee

Hi,

when you choose the command, there is a button 'Raw' in ide. This can show the command packet data. And then you can modifiy this command. Do not forget to change the check bit. 

Have a great day,
TIC

-------------------------------------------------------------------------------
Note:
- If this post answers your question, please click the "Mark Correct" button. Thank you!

- We are following threads for 7 days after the last post, later replies are ignored
Please open a new thread and refer to the closed one, if you have a related question at a later point in time.
-------------------------------------------------------------------------------

0 Kudos
2,931 Views
chilipp
Contributor III

Hello,

I tried that approach but without success.

To eliminate potential error sources while calculating the checksum, I extended the Test-Tools XML file (BLE_1.2.8.xml) by adding one additional parameter for the GATTClient-ExchangeMtu.Request command as follows:

 

<Parm>
	<ParmName>MTU</ParmName>
	<ParmDesc>Desired MTU</ParmDesc>
	<ParmSize>2</ParmSize>
	<ParmType>tInt</ParmType>
	<ParmLastValue>96</ParmLastValue>
	<ParmDefaultValue>17</ParmDefaultValue>
</Parm>

 

--edit-- also tried with ParamSize 1 - also without success --end edit--

Unfortunately, even though the Dongle replies with "gBleSuccess_c" for "GATTClient-ProcedureExchangeMtu-Indication" it still issues the "Exchange MTU Request" with "Client Rx MTU" = 247 (I captured the air-traffic to verify).

TestToolBle1.2.8WithMtu.JPG

MTUAirTrace.JPG

I guess the MTU size used for the MTU-Exchange is hard coded (at least for the current SDK for the USB-KW41Z) and not taken from the defined "gAttMaxMtu_c" - even though the comment for that define states "This is used during the MTU Exchange." and some other code depend on that value (buffer sizes etc.). In my opinion, this can be considered as bug.

Will there be a bugfix sometime, and if so, when can it be expected?

0 Kudos
2,924 Views
nxf56274
NXP Employee
NXP Employee

Hi,

I asked our internal engineer, he told me the mtu function which has only one parameter won't use the gAttMaxMtu_c. So the modification of gAttMaxMtu_c won't take effect. And they do not sure if they will update sdk to solve this problem. I have to say it is unfortunate. 

Have a great day,
TIC

-------------------------------------------------------------------------------
Note:
- If this post answers your question, please click the "Mark Correct" button. Thank you!

- We are following threads for 7 days after the last post, later replies are ignored
Please open a new thread and refer to the closed one, if you have a related question at a later point in time.
-------------------------------------------------------------------------------

0 Kudos
2,919 Views
chilipp
Contributor III

What a pity!

Yet it seems as simple this:

File: ble_globals.c

 

uint16_t gAttMaxMtu = gAttMaxMtu_c;

 

And within the source code of the "host" static libraries:

 

extern uint16_t gAttMaxMtu;

 

while using the "gAttMaxMtu" variable for every reference to the currently used and hard coded (variables) value of "247".

Nevertheless, if there is any possibility for an SDK update or news about this topic, I would appreciate a notification!

Kind regards.

0 Kudos