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!
Solved! Go to Solution.
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.
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.
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.
-------------------------------------------------------------------------------
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.
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?
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.
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.
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.
-------------------------------------------------------------------------------
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.
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.
-------------------------------------------------------------------------------
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.
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.
Note that I use the latest version of the Test-Tool.
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?
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.
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.
Note that I use the latest version of the Test-Tool.
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?
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.
-------------------------------------------------------------------------------
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).
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?
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.
-------------------------------------------------------------------------------
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.