• State Verified Answer
  • Replies 19 replies
  • Subscribers 63 subscribers
  • Views 9160 views
  • Users 0 members are here
Attachments (0)
Nordic Case Info
  • Case ID: 100338
Options
This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

Long Attributes

Artem Zemlyanukhin

Hi, I need to have long attributes. So I need 'Read Blob' operation for read and Queued writes ('Prepare Write' and 'Execute Write'). Does Soft Device for nrf51822 support mentioned commands?

Best regards, Artem Zemlyanukhin

Parents
  • 0

    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

  • 0 in reply to Ole Morten

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

    1. 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.

    2. This extra write is the Execute Write.

    3. 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.

    4. See my comment on your other reply below.

    5. 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.

Reply
  • 0 in reply to Ole Morten

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

    1. 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.

    2. This extra write is the Execute Write.

    3. 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.

    4. See my comment on your other reply below.

    5. 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.

Children
No Data
Related