cancel
Showing results for 
Search instead for 
Did you mean: 

STM32WB55 max MTU value

APort
Associate III

Hello,

We successfully using 247 as MTU values in our STM32WB55 system.

We did try to use 512 CFG_BLE_MAX_ATT_MTU as max MTU value noted in SHCI_C2_BLE_Init() - (517 according to BLE5 spec)

The connection and mtu negotiation is working successful (512 bytes), however, we could not transfer any actual data.

But then, we noticed that TL layer explicitly limits all traffic to 255 bytes (CFG_TLBLE_MOST_EVENT_PAYLOAD_SIZE & HCI_COMMAND_MAX_PARAM_LEN)

So, the question is: what's the actual maximal MTU value supported?

If 512, how should it work with IPC packet limitation?

If 247, any future plan to support larger MTUs? (tested on v1.10 full FW)

Thanks in advance

2 REPLIES 2
Remi QUINTIN
ST Employee

​The maximum value for ATT_MTU is 512. But there is a limitation resulting from the communication mechanism in between the M4 and M0+ cores.

Events from the RF stack sent to the M4 core have a length encoded on 8 bits. So the limit is more at 252 (which is the maximum HCI buffer size).

Please have a look at the programming manual PM0271 “ble-stack-programming-guidelines�?.

APort
Associate III

Thanks Remi,

After spending pile of time on this issue I think I got to the root of it.

The MTU is indeed 512, it will work. However, the interface is limited to sending data 245bytes at a time.

The thing is that there's entire set of functions to support large MTUs denoted "long" or "ext";

For example aci_gatt_update_char_value_ext() doing the same thing as aci_gatt_update_char_value() just with 16bit offset, so you can fragment your data into chunks.

Now, the confusing bit, is that some interfaces already support 16bit sizes (e.g. aci_gatt_attribute_modified_event_rp0) other, don't.

Basically, what worked for me, is looking at all places where you set size .. if its 8bit value, then there's different interface to do it; else it is this one.

I understand it was probably made like this for historic and backward compatibility reasons, just not very comfortable, efficient or intuitive.

Hope it will change somewhere in the future,