Characteristic Attribute Read Callback does not return complete data buffer

[keegretupmoc]

I have the following characteristic defined:

BT_GATT_CHARACTERISTIC(BT_UUID_WT_SERIVCE_TX,

BT_GATT_CHRC_NOTIFY | BT_GATT_CHRC_READ,

BT_GATT_PERM_READ,

wt_read_tx_str, NULL, dataPacket),

BT_GATT_CCC(on_cccd_changed,

BT_GATT_PERM_READ | BT_GATT_PERM_WRITE),

 

So I can click on either the read or notify to get data.

The dataPacket is basically a c string of 755 bytes (756 null terminated).

When I do a read from the client, the above callback wt_read_tx_str starts getting called.  It looks like it is sending 22 bytes at a time changing the offset. I have debug info and can see it count up to 594 on the offset, and then it just stops getting called.  When that happens 594 bytes appear on the client all at once (which is what I want).

The issue is that my buffer has 755 bytes in it.  Does anyone know why it stops at 594 instead of sending all 755 bytes?  I don't get any errors.  Am I running up against some stack resource?  I am not sure where the callback get's called so I don't know what to look for as to why it would suddenly stop after executing the callback about 27 times.

Here is the beginning and ending of my debug info:

00> Entered connected callback
00>
00> [00:00:15.596,191] <inf> peripheral_uart: Connected to 4F:14:DC:8B:B1:3E (random)
00> [00:00:24.853,057] <inf> wt_service: wt_read_tx_str cb: package offset: 0 size: 755
00> [00:00:24.853,240] <inf> wt_service: wt_read_tx_str cb: returned 22 after call to bt_gatt_attr_read
00> [00:00:24.950,622] <inf> wt_service: wt_read_tx_str cb: package offset: 22 size: 755
00> [00:00:24.950,805] <inf> wt_service: wt_read_tx_str cb: returned 22 after call to bt_gatt_attr_read
00> [00:00:25.048,095] <inf> wt_service: wt_read_tx_str cb: package offset: 44 size: 755
00> [00:00:25.048,278] <inf> wt_service: wt_read_tx_str cb: returned 22 after call to bt_gatt_attr_read

................

00> [00:00:27.485,229] <inf> wt_service: wt_read_tx_str cb: package offset: 572 size: 755
00> [00:00:27.485,412] <inf> wt_service: wt_read_tx_str cb: returned 22 after call to bt_gatt_attr_read
00> [00:00:27.582,733] <inf> wt_service: wt_read_tx_str cb: package offset: 594 size: 755
00> [00:00:27.582,916] <inf> wt_service: wt_read_tx_str cb: returned 22 after call to bt_gatt_attr_read

Thanks in advance!

h.

[Hung Bui]

Hi Harold, 

You may want to capture a sniffer trace of the communication so that we can inspect the connection parameters. 

Could you give us more information about the settings you have ? For example: 
CONFIG_BT_ATT_PREPARE_COUNT

CONFIG_BT_BUF_ACL_TX_SIZE
CONFIG_BT_BUF_ACL_RX_SIZE

CONFIG_BT_CTLR_DATA_LENGTH_MAX

CONFIG_BT_L2CAP_TX_MTU

CONFIG_BT_L2CAP_TX_BUF_COUNT

Which device did you use as the client ? You may want to increase the Data length max and ATT MTU (CONFIG_BT_L2CAP_TX_MTU)  to have higher over the air packet size. 

[keegretupmoc]

Hung,

Thanks for your response.  I will work on getting you the additional information.  I took over an existing app so I will need to do some research.  I am more familiar with the TI BLE processors, but coming up to speed on Nordic.

I did have a question having to do with buffers, etc.  I thought I had read somewhere that the heap/stack needed to be aligned on 4 bytes (32 bit) and as such could only be 256, 1024, 4096, 16384 bytes.  Is that correct?  Because some of the parameters in prj.conf, I think one in particular, had "stack" in its name and was 2048, which if the alignment was true is incorrectly set.  I will find that one in particular, and maybe list them out with their values to see what you think.

Thanks again,

h.

[keegretupmoc]

Hung,

Here's the parameter info, et al:

CONFIG_BT_ATT_PREPARE_COUNT  0

CONFIG_BT_BUF_ACL_TX_SIZE  27

CONFIG_BT_BUF_ACL_RX_SIZE  69

CONFIG_BT_CTRL_DATA_LENGTH_MAX  (not defined)

CONFIG_BT_L2CAP_TX_MTU  65

CONFIG_BT_L2CAP_TX_BUF_COUNT  2

The “client” I am using is a freeware test BLE scanner on an android phone.  It’s called BLE Scanner by blue pixel technologies, version 3.21.  We are working on an iOS app that will be talking to it, but it’s not quite ready yet.

I will work on a sniffer trace soon as well.  I assume the transfer just stops at 594 due to some limitation, not really an error, so it is probably parameter settings as you probably already suspect.

I will try setting the CONFIG_BT_CTRL_DATA_LENGTH_MAX to something greater than 594 to see if that magically fixes it, since it isn't defined and may be defaulting to something around 600.  Or some calculation based on other parameters.

Thanks,

h.

[keegretupmoc]

Btw,

Here are the heap/stack parameters I was talking about:

CONFIG_HEAP_MEM_POOL_SIZE=2048

CONFIG_BT_RX_STACK_SIZE=1024

CONFIG_BT_HCI_TX_STACK_SIZE=640

CONFIG_SYSTEM_WORKQUEUE_STACK_SIZE=256

CONFIG_MAIN_STACK_SIZE=640

CONFIG_IDLE_STACK_SIZE=128

CONFIG_ISR_STACK_SIZE=1024

#CONFIG_BT_NUS_THREAD_STACK_SIZE=512

They are all from prj.conf.  Let me know if they look ok.  Also, I have reduced the CONFIG_HEAP_MEM_POOL_SIZE to 1024 because I am running out of memory.  We probably need a bigger boat...

Thanks,

h.

[Hung Bui]

Hi Harold, 

I don't know what could be wrong here but could you send us your sample code so we can test here  ? 
If you are sending large amount of data I would suggest to increase the ATT_MTU and data length. I don't think using CONFIG_BT_BUF_ACL_TX_SIZE  = 27 would be the best, it would take much longer to send 755 bytes. 

Have you looked at the configuration in the throughput example ? 
I also made a throughput example to be tested with a phone here. It uses notification to send data, not read, but you can refer to the configuration. 

I would also suggest to use our nRF Connect app on the phone to test. 

Regarding your heap/stack size alignment, I don't think there is any issue with size of 2048. As far as I know the size just need to be divisible by 4. 

[keegretupmoc]

Hi Hung,

You can close this ticket.  The data example I was given to transmit was a lot larger than was actually needed and ended up being less than 1/2 of the apparent 594 limitation.  And it doesn't look like we will have anything else needing sizes that big.  So we are up and running!

Thanks,

h.