Long Attributes

RE: Long Attributes

Lionel Sacks — Tue, 17 Jun 2014 07:13:14 GMT

Could I echo the request of Elecmike2k !

RE: Long Attributes

Elecmike2k — Mon, 02 Jun 2014 03:57:35 GMT

Hi Ole,

My project needs long write and I would like to start with the example code you provided: ble_app_lbs-long-write.zip. Unfortunately when I click it, it says "This Page is Unavailable". Could you send an working link to this file please? Thanks, Michael

RE: Long Attributes

Artem Zemlyanukhin — Fri, 13 Sep 2013 13:17:39 GMT

Thank you, your answer helped to me!

RE: Long Attributes

Carles — Fri, 13 Sep 2013 12:29:33 GMT

Hi there,

But why do I have to set p_data = data + offset? I already set offset..

Because auth_reply.params.read.offset refers to the offset within the attribute value, not the offset from the pointer you provide. You are expected to always provide an updated pointer to the data you want to send back, but that offset you provide is where inside the attribute value the data pointed by by p_data will be written to. Remember that when you set update = 1 the data will actually be written to the local attribute (in your case in user memory) as well as sent over the air as a response.

So I guess if update = 0, p_data and offset values do not matter

Correct

But I need to use update = 1 because actually I have array strings (each of 64 bytes) and in different cases I want to point in 'sd_ble_gatts_rw_authorize_reply' different rows fo my array.

Then you are already doing the right thing. But remember, you could also do something else instead: Because the value is in your own memory, you could simply set update to 0 but then modify your value buffer (the one you provided in sd_ble_gatts_characteristic_add() (p_value in ble_gatts_attr_t) so that it fits whatever you want to send back. This may actually be quicker and more efficient than using update = 1 depending on how your application is structured.

RE: Long Attributes

Artem Zemlyanukhin — Fri, 13 Sep 2013 12:21:45 GMT

Hi,

I have an issue with Read Blob, could you help to solve it please?

I have attribute 'att1' with 64 bytes length allocated in user ram (BLE_GATTS_VLOC_USER). I use authorized read.

For example, 'att1' contains zeroes. Because MTU = 23, I need 3 ReadBlobRequests to read it.

In BLE_GATTS_EVT_RW_AUTHORIZE_REQUEST event handler I must set parameters for 'sd_ble_gatts_rw_authorize_reply' and call it.

At first, I used following parameters:

auth_reply.type = BLE_GATTS_AUTHORIZE_TYPE_READ;
auth_reply.params.read.offset = offset;
auth_reply.params.read.p_data = data;
auth_reply.params.read.update = 1;

'data' and 'att1' is not the same (so I set update = 1). For example 'data' points to array that contains numbers from 0x00 to 0x3F.

Here are the results from Master Control Panel:

[17:15:26.5] Received Read Blob Response, offset 0, value (0x): 00-01-02-03-04-05-06-07-08-09-0A-0B-0C-0D-0E-0F-10-11-12-13-14-15 [17:15:26.5] Received Read Blob Response, offset 22, value (0x): 00-01-02-03-04-05-06-07-08-09-0A-0B-0C-0D-0E-0F-10-11-12-13-14-15 [17:15:26.5] Received Read Blob Response, offset 44, value (0x): 00-01-02-03-04-05-06-07-08-09-0A-0B-0C-0D-0E-0F-10-11-12-13

If you can see melody_offset does not matter...

Then I changed parameters to:

auth_reply.type = BLE_GATTS_AUTHORIZE_TYPE_READ;
auth_reply.params.read.offset = 0;
auth_reply.params.read.p_data = data + offset;
auth_reply.params.read.update = 1;

then:

[17:17:37.2] Received Read Blob Response, offset 0, value (0x): 00-01-02-03-04-05-06-07-08-09-0A-0B-0C-0D-0E-0F-10-11-12-13-14-15 [17:17:37.3] Received Read Blob Response, offset 22, value (0x): 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00 [17:17:37.3] Received Read Blob Response, offset 44, value (0x): 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00

And at the end:

auth_reply.type = BLE_GATTS_AUTHORIZE_TYPE_READ;
auth_reply.params.read.offset = offset;
auth_reply.params.read.p_data = data + offset;
auth_reply.params.read.update = 1;

And after that I got results that I need:

[17:19:09.5] Received Read Blob Response, offset 0, value (0x): 00-01-02-03-04-05-06-07-08-09-0A-0B-0C-0D-0E-0F-10-11-12-13-14-15 [17:19:09.6] Received Read Blob Response, offset 22, value (0x): 16-17-18-19-1A-1B-1C-1D-1E-1F-20-21-22-23-24-25-26-27-28-29-2A-2B [17:19:09.6] Received Read Blob Response, offset 44, value (0x): 2C-2D-2E-2F-30-31-32-33-34-35-36-37-38-39-3A-3B-3C-3D-3E-3F

But why do I have to set p_data = data + offset? I already set offset..

Also I tried to reset update field and assign to auth_reply.params.read.p_data pointer to 'att1'. In this case, all three are correct methods. So I guess if update = 0, p_data and offset values do not matter. But I need to use update = 1 because actually I have array strings (each of 64 bytes) and in different cases I want to point in 'sd_ble_gatts_rw_authorize_reply' different rows fo my array.

RE: Long Attributes

Artem Zemlyanukhin — Fri, 06 Sep 2013 12:27:21 GMT

Thank you,

You are right, TI software buffers PrepareWritesReqs and sends after I send ExecuteWriteReq. I checked this with sniffer, thank you for advice!

RE: Long Attributes

Ole Morten — Fri, 06 Sep 2013 10:52:29 GMT

For completeness, I'll try to answer these questions separately:

This is to be expected, as it is the Execute Write event, as you can see in the op field of ble_gatts_evt_write_t. This event will never have a length or a value, and if you need to see the values written, you'll have to either parse the memory buffer you provided yourself (see the format description in the softdevice headers) or use sd_ble_gatts_value_get() as you've done.
This extra write is the Execute Write.
This is actually a bug in my code that I didn't notice when testing. The intention was just to see that the same memory area was released afterwards, but to check this, you have to compare the actual memory pointer, i.e. p_data field of the memory block. However, since the memory allocation is static anyway, it doesn't really matter in my case.
See my comment on your other reply below.
This shouldn't be possible. When I sniff the link, I can see responses going over the air. Not sending such responses would be a spec violation, and trigger a GATT timeout, most likely causing a disconnect, so I believe this must be a bug in the TI tool.

RE: Long Attributes

Ole Morten — Fri, 06 Sep 2013 10:46:39 GMT

When testing with an iPhone, I don't have as fine-grained control as you have on when the different requests are sent, so I can unfortunately not duplicate your testing exactly.

However, I can't understand how what you say about the sequence of events is possible, since the stack will have no memory or anywhere to store the queued writes if the application haven't provided a memory buffer.

Are you sure that the TI tool you're using isn't buffering the writes somewhere and send them all at once when you do the execute? If you have access to a sniffer, can you see the packets going over the air, without the corresponding events on the nRF51 side?

When I sniff a link while doing a long write, I can see that there are Prepare Write Responses sent for each Prepare Write Request, and then an Execute Write Response for the last Execute Request, but since all the events happen automatically, it isn't easily possible for me to correlate the time in the sniffer and the time on the serial interface.

RE: Long Attributes

Artem Zemlyanukhin — Fri, 06 Sep 2013 06:50:40 GMT

Hi,

Last post is mine, forgot login.

I understood my 1 and 2 questions. Those BLE_GATTS_EVT_WRITE/BLE_GATTS_EVT_RW_AUTHORIZE_REQUEST events with len = 0, data = 0 were 'BLE_GATTS_OP_EXEC_WRITE_REQ_NOW'.

And I want to expand 4 question. Not only 'BLE_EVT_USER_MEM_REQUEST' event stack generates after 'Execute Write Request'. If I use Authorization for attribute, stack generates BLE_GATTS_EVT_RW_AUTHORIZE_REQUEST(BLE_GATTS_OP_EXEC_WRITE_REQ) events also only after 'Execute Write Request'.

But in your documentation I saw Message Sequence Charts, where was following sequence:

-client send PrepWriteReq1 -stack generates BLE_GATTS_EVT_RW_AUTHORIZE_REQUEST -server send PrepWriteResp1 -client send PrepWriteReq2 -stack generates BLE_GATTS_EVT_RW_AUTHORIZE_REQUEST -server send PrepWriteResp2 -client send PrepWriteReq3 -stack generates BLE_GATTS_EVT_RW_AUTHORIZE_REQUEST -server send PrepWriteResp3 -client send ExecWriteReq -stack generates BLE_GATTS_EVT_RW_AUTHORIZE_REQUEST -server send ExecWriteResp

In fact I have following sequence:

-client send PrepWriteReq1 -client send PrepWriteReq2 -client send PrepWriteReq3 -client send ExecWriteReq -stack generates BLE_GATTS_EVT_RW_AUTHORIZE_REQUEST (BLE_GATTS_OP_PREP_WRITE_REQ) -stack generates BLE_GATTS_EVT_RW_AUTHORIZE_REQUEST (BLE_GATTS_OP_PREP_WRITE_REQ) -stack generates BLE_GATTS_EVT_RW_AUTHORIZE_REQUEST (BLE_GATTS_OP_PREP_WRITE_REQ) -stack generates BLE_GATTS_EVT_RW_AUTHORIZE_REQUEST (BLE_GATTS_OP_EXEC_WRITE_REQ_NOW)

And I don't know when stack send PrepWriteResps and ExecWriteResp

Best Regards, Artem Zemlyanukhin

RE: Long Attributes

Guest — Wed, 04 Sep 2013 13:51:33 GMT

Hi,

Thanks a lot for code example. I tested it, it works but not completely.

At first to get additional information I added at the end of 'on_ble_evt' some code:

if(p_ble_evt->header.evt_id == BLE_GATTS_EVT_WRITE) { sprintf(buffer, "Event 0x50: 0x%lx 0x%lx\r\n", p_ble_evt->evt.gatts_evt.params.write.len, *(uint8_t *)p_ble_evt->evt.gatts_evt.params.write.data); simple_uart_putstring(buffer); }

I can't ability to use iPhone now, so I used TI usb-dongle (CC2540) with their software.

Here is the sequence of my actions:

Connect with device
Send first 'Prepare Write Request' handle = 0x11, offset = 0, data = 01
Send second 'Prepare Write Request' handle = 0x11, offset = 1, data = 02
Send third 'Prepare Write Request' handle = 0x11, offset = 2, data = 03
Send 'Execute Write Request'
Send 'Read Request'

Here is log:

start Event: 0x10 Event: 0x12 memory requested, 0x1 Event: 0x2 Event: 0x50 Event 0x50: 0x0 0x0 Event: 0x3

As you can see (also I sow it via debug) stack don't give me data in 'BLE_GATTS_EVT_WRITE' (len = 0, data = 0). But when I tried to read attribute after these operations, I received in 'Read Respnse' correct data: 01 02 03. In other words new attribute value was set, but I couldn't receive this new value in handler ('BLE_GATTS_EVT_WRITE' event). I viewed in debuger value of 'queued_write_buffer' (member of 'mem_block' union) passed as parameter in sd_ble_user_mem_reply. 'queued_write_buffer' had correct value: { 0x11, 0x00, 0x00, 0x00, 0x01, 0x00, 0x01, //first write (handler, offset, length, value) 0x11, 0x00, 0x01, 0x00, 0x01, 0x00, 0x02, //second write 0x11, 0x00, 0x02, 0x00, 0x01, 0x00, 0x03 //third write }

I tried to set attr_md.wr_auth = 1. In this case data in 'BLE_GATTS_EVT_RW_AUTHORIZE_REQUEST' event handler is correct. I sent for example 3 PrepareWrite packets: - 2 bytes (0x01 and 0x02) with offset = 0 - 2 bytes (0x03 and 0x04) with offset = 2 - 2 bytes (0x05 and 0x06) with offset = 4

and I received 4 (not 3) 'BLE_GATTS_EVT_RW_AUTHORIZE_REQUEST' events: - for first write with correct data - for second write with correct data - for third write with correct data - extra event with data = 0, offset = 0, len = 0.

when I sent 2 writes, I received 3 events. and in case of 1 write, I received 2 events. What does this extra event mean?

What does it mean 'if (&p_ble_evt->evt.common_evt.params.user_mem_release.mem_block == &mem_block)' in 'BLE_EVT_USER_MEM_RELEASE' case? It's never true...
As I read in your docemetation, stack send to application 'BLE_EVT_USER_MEM_REQUEST' event after first 'Prepare Write Request' but really it does it only after Send 'Execute Write Request'.
Also my dongle didn't receive 'Prepare Write Response' packets, it received only 'Execute Write Response'. Is this possible? Or this bug of TI software?

RE: Long Attributes

Bastiaan — Wed, 04 Sep 2013 13:51:33 GMT

Hi,

Thanks a lot for code example. I tested it, it works but not completely.

At first to get additional information I added at the end of 'on_ble_evt' some code:

I can't ability to use iPhone now, so I used TI usb-dongle (CC2540) with their software.

Here is the sequence of my actions:

Connect with device
Send first 'Prepare Write Request' handle = 0x11, offset = 0, data = 01
Send second 'Prepare Write Request' handle = 0x11, offset = 1, data = 02
Send third 'Prepare Write Request' handle = 0x11, offset = 2, data = 03
Send 'Execute Write Request'
Send 'Read Request'

Here is log:

start Event: 0x10 Event: 0x12 memory requested, 0x1 Event: 0x2 Event: 0x50 Event 0x50: 0x0 0x0 Event: 0x3

when I sent 2 writes, I received 3 events. and in case of 1 write, I received 2 events. What does this extra event mean?

What does it mean 'if (&p_ble_evt->evt.common_evt.params.user_mem_release.mem_block == &mem_block)' in 'BLE_EVT_USER_MEM_RELEASE' case? It's never true...
As I read in your docemetation, stack send to application 'BLE_EVT_USER_MEM_REQUEST' event after first 'Prepare Write Request' but really it does it only after Send 'Execute Write Request'.
Also my dongle didn't receive 'Prepare Write Response' packets, it received only 'Execute Write Response'. Is this possible? Or this bug of TI software?

RE: Long Attributes

Ole Morten — Tue, 03 Sep 2013 12:15:43 GMT

There shouldn't be any problems making this work. I just did a quick test, as in the attachment, and I'm not able to see any problems when testing with iOS.

If you take this zip, place it in Boards/nrf6310/ble/, you should be able to see everything working, as long as you have replaced the softdevice headers included in the SDK with the ones from the 6.0.0 zip.

If you don't get it working, I'd be interested to see what this example outputs on the UART.

ble_app_lbs-long-write.zip

RE: Long Attributes

Artem Zemlyanukhin — Tue, 03 Sep 2013 12:06:33 GMT

Hi,

As I see in ble.h, 'BLE_EVT_USER_MEM_REQUEST' is a member of enum BLE_COMMON_EVTS:

enum BLE_COMMON_EVTS { BLE_EVT_TX_COMPLETE = BLE_EVT_BASE, /< Transmission Complete. */ BLE_EVT_USER_MEM_REQUEST, /< User Memory request. */ BLE_EVT_USER_MEM_RELEASE /**< User Memory release. */ };

For example, event 'BLE_EVT_TX_COMPLETE ' is used in GLS service. It is processed in 'ble_gls_on_ble_evt' calling from 'ble_evt_dispatch'. So I suppose, BLE_EVT_USER_MEM_REQUEST event I must handle in function calling from 'ble_evt_dispatch' too. But stack don't call 'ble_evt_dispatch' with such event..

Can I use any new options for attributes which I need to Long Read?

Thank you for your response!

RE: Long Attributes

Carles — Tue, 03 Sep 2013 11:02:31 GMT

Hi there,

I am guessing the issue here is that the SDK does not support BLE_EVT_USER_MEM_REQUEST yet, so that is why is not being handled in ble_evt_dispatch.

I will let the people in charge of the SDK know of this and see if they can help you out.

Regards,

Carles

RE: Long Attributes

Artem Zemlyanukhin — Mon, 02 Sep 2013 13:07:17 GMT

Hi Carles,

I have some questions about Write Long.

Because Master Control Panel 3.4.0 doesn't support 'Prepare Write' and 'Execute Write' I use CC2540-based usb dongle (from TI) and BTool software to test Write Long. I decided to implement 'GATTS Queued Writes: App handled, one or more attributes require authorization'. But I can't catch 'BLE_GATTS_EVT_RW_AUTHORIZE_REQUEST' after I send PrepareWriteRequest or ExecuteWriteRequest via BTool. As I saw in your Message Sequence Charts, I also have to handle 'BLE_EVT_USER_MEM_REQUEST' and call 'sd_ble_user_mem_reply'. But I don't know where I can handle 'BLE_EVT_USER_MEM_REQUEST' event, stack doesn't call 'ble_evt_dispatch' with corresponding event. Do you have any example how to use Write Long?

Best Regards, Artem Zemlyanukhin

RE: Long Attributes

Artem Zemlyanukhin — Thu, 22 Aug 2013 11:39:16 GMT

Carles, Thanks a lot, try to test 6.0.0-1.alpha version!

RE: Long Attributes

Carles — Thu, 22 Aug 2013 11:26:48 GMT

Hi there,

Read Long as a GATT server has been supported since very early versions of the SoftDevice.

Version 6.0.0-1.alpha of the SoftDevice adds Write Long (and Reliable Write) support to the SoftDevice GATT server.

Hope that helps,

Carles

RE: Long Attributes

Artem Zemlyanukhin — Thu, 22 Aug 2013 11:23:58 GMT

Yes, my device is only GATT Server, so I need to receive Requests and send Responses.

RE: Long Attributes

Carles — Thu, 22 Aug 2013 11:15:45 GMT

Do you need them only as a GATT server? i.e. your nRF51 application will only act as a GATT server?