long write: receiving partial data only

RE: long write: receiving partial data only

yacine — Fri, 12 Jan 2018 14:14:52 GMT

if confirmed, this should be known.

RE: long write: receiving partial data only

Petter Myhre — Fri, 12 Jan 2018 13:01:29 GMT

If Android can't do a proper long write, I would recommend to handle it at the application level.

RE: long write: receiving partial data only

yacine — Fri, 12 Jan 2018 12:56:52 GMT

I also tested to directly write 85B using classic android write and it works a bit better. doing this, on the peripheral I receive a MEM_USER_REQ and WRITE_EXEC, which looks good. but after parsing the user memory, I figured out that only the first batch has been sent bu the client. this is why I suppose the problem is on android side.

I asked on stackoverflow about this.

any advice would help.

RE: long write: receiving partial data only

yacine — Fri, 12 Jan 2018 12:56:42 GMT

Thank you Peter for support.

So far I think the problem is on android side: see details here.

I tried 2 things at the client:

what they call long write in the rxandroidble library is in fact a sequence of classic writes + the data is automatically "sliced". this result on the nordic peripoheral side into a sequence of independant WRITE_REQ or WRITE_CMD, depending if I activated or not the parameter write_wo_response in the firmware. I suppose I could reassemble the data at the app level, but it would be a workaround. similar to the app-handled case nordic MSCs describe. this was the subject of this post

RE: long write: receiving partial data only

Petter Myhre — Fri, 12 Jan 2018 08:49:01 GMT

Could you please explain to me exactly what the problem is? What are you seeing and what are you expecting?

RE: long write: receiving partial data only

yacine — Thu, 11 Jan 2018 18:32:09 GMT

peter,

still stucked with my problem: is there something to do in the characteritic description in order to exoplicitly saying the given char will receive long writes ? ... e.g. like extended char. I did not find any but who knows ?

thanks

RE: long write: receiving partial data only

yacine — Wed, 10 Jan 2018 10:17:43 GMT

yes this is what I (try to) do. ok thanks, then it is normal I dont receive the ATT Prepare Write requests at the app level. I will investigate the central side. thx

RE: long write: receiving partial data only

Petter Myhre — Wed, 10 Jan 2018 09:49:07 GMT

It seems to me you are doing this, then you will only receive BLE_EVT_USER_MEM_REQUEST and BLE_GATTS_EVT_WRITE with BLE_GATTS_OP_EXEC_WRITE_REQ_NOW.

The stack will receive ATT Prepare Write requests, but these will not be notified to the application.

RE: long write: receiving partial data only

yacine — Tue, 09 Jan 2018 16:04:57 GMT

hello peter,

I have the intuition that the problem is on the central side again.

I think I manage correctly the user memory:

handle = *(uint16_t*) mem_buffer.p_mem;
//        offset = *(uint16_t*) (mem_buffer.p_mem+2);
      len = *(uint16_t*) (mem_buffer.p_mem+4);
      buffer = (uint8_t *) (mem_buffer.p_mem+6);

AFAIK I should receive first the successive BLE_GATTS_OP_WRITE_REQ and then, when the transfer is finalized, the BLE_GATTS_OP_EXEC_WRITE_REQ_NOW. isn't it ?

RE: long write: receiving partial data only

Petter Myhre — Mon, 08 Jan 2018 13:40:11 GMT

What do you expect the length to be? 73? This is just the first write, if you have done several writes you should find the next write after the first.

See this for user memory layout for Queued Writes.

RE: long write: receiving partial data only

yacine — Fri, 05 Jan 2018 13:19:44 GMT

the char description:

static uint32_t schedule_cal_char_add(ble_tds_t * p_tds, const ble_tds_init_t * p_tds_init){    
            	ble_gatts_char_md_t char_md;
            	ble_gatts_attr_t    attr_char_value;
            	ble_uuid_t          ble_uuid;
            	ble_gatts_attr_md_t attr_md;
            
            	memset(&char_md, 0, sizeof(char_md));
            	char_md.char_props.write         	= 1; 
                    char_md.char_props.notify         	= 1;
            	char_md.p_char_user_desc         	= NULL;
            	char_md.p_char_pf                	= NULL;
            	char_md.p_user_desc_md           	= NULL;
            	char_md.p_cccd_md         			= NULL;
            	char_md.p_sccd_md                	= NULL;
            
            	memset(&ble_uuid, 0, sizeof(ble_uuid));
            	ble_uuid.type = p_tds->uuid_type;
            	ble_uuid.uuid = BLE_UUID_TDS_SCHEDULE_CAL_CHAR;
            
            	memset(&attr_md, 0, sizeof(attr_md));
            	BLE_GAP_CONN_SEC_MODE_SET_OPEN(&attr_md.read_perm);
            	BLE_GAP_CONN_SEC_MODE_SET_OPEN(&attr_md.write_perm);
            	attr_md.vloc    					= BLE_GATTS_VLOC_STACK;
            	attr_md.rd_auth 					= 0;
            	attr_md.wr_auth    					= 0;
                attr_md.vlen       					= 1;
            
            	memset(&attr_char_value, 0, sizeof(attr_char_value));
            	attr_char_value.p_uuid    = &ble_uuid;
            	attr_char_value.p_attr_md = &attr_md;
            	attr_char_value.init_len  = 0;
            	attr_char_value.init_offs = 0;
            	attr_char_value.max_len   = BLE_TDS_MAX_LONG_WRITE;
            
            	return sd_ble_gatts_characteristic_add(p_tds->service_handle,
            			&char_md,
            			&attr_char_value,
            			&p_tds->schedule_cal_handles);
            }