This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

Long write error, GATT INVALID ATTR LEN

Good evening,

I am trying to implement queued write (long write) into ble_app_uart example. I am using s110_v7.1, nrf51822(pca10028), can not find version of sdk it is one of the older ones, probably sdk6.

This is how BLE events ar handled:

 case BLE_EVT_USER_MEM_REQUEST:
        
        mem_block.len = QUEUED_WRITE_BUFFER_SIZE;
        mem_block.p_mem = &queued_write_buffer[0];
        err_code = sd_ble_user_mem_reply(m_conn_handle, &mem_block);
					//simple_uart_putstring("User mem request \r\n");
						if (err_code != NRF_SUCCESS)
						{
							sprintf((char*)debug_string11,"ERROR USER_MEM_REQ\r\n");
							simple_uart_putstring(debug_string11);
						}
						else
						{
							sprintf((char*)debug_string11,"USER_MEM_REQUEST OK\r\n");
							simple_uart_putstring(debug_string11);
						}
        break;
			
     case BLE_EVT_USER_MEM_RELEASE:
					
        if ((p_ble_evt->evt.common_evt.params.user_mem_release.mem_block.p_mem == mem_block.p_mem)&&(p_ble_evt->evt.common_evt.params.user_mem_release.mem_block.len == mem_block.len))
        {
            //memory released do nothing. 
							//simple_uart_putstring("User mem released \r\n");
						sprintf((char*)debug_string13,"USER_MEM_REQUEST OK\r\n");
						simple_uart_putstring(debug_string13);
        }
					break;
					
   case BLE_GATTS_EVT_WRITE:
							//simple_uart_putstring("Evt Write \r\n");
			sprintf((char*)debug_string10,"BLE_GATTS_EVT_WRITE\r\n");
								simple_uart_putstring(debug_string10);
        break;

These are passed to the events:

#define QUEUED_WRITE_BUFFER_SIZE        350
static uint8_t queued_write_buffer[QUEUED_WRITE_BUFFER_SIZE];
static ble_user_mem_block_t mem_block;

This is what I receive in nrf sniffer:

image description

This is from nrf connect app in my tablet:

image description

Could not find what is the problem of error in dev zone, nor in the net. If there is lack of information let me know. Thank you.

-------------------------------------------------------UPDATE-----------------------------------------

Have found that I havent changed where I am puttin characteristics in tx_char_add and rx_char_add. I have them changed to:

//MODIFIED************************************************************************
attr_md.vloc              = BLE_GATTS_VLOC_USER;//BLE_GATTS_VLOC_STACK;
//********************************************************************************

//MODIFIED************************************************************************
   attr_char_value.max_len   = QUEUED_WRITE_BUFFER_SIZE;//BLE_NUS_MAX_RX_CHAR_LEN
 //********************************************************************************

Now I see that characteristics <20 and >20 size of bytes are sent without error. Unfortunately, if I receive something from pca10028 tablet do not recognise symbols. In addition to this, in nus service I have made that every received characteristic will be replied with somekind of response. Right now I do not receive any response from pca10028 if received characteristic exceeds 20 bytes. here are screenshot of tablet:

image description

this is my logg in UART:

image description

sniff of long write: was it successful???

image description

what are your oppinions why I do I receive those "? ? ? ?" instead of my reply? why I do not receive response in table exceeding 20 bytes?

  • I am using s110_v7.1. , sdk 6. Should I use a newer SDK? I have not made any modifiactions to handle long write in nus_data_handler. Would s130 be able to send notifications longer than 20 bytes? if not which softdevice would be able?

  • Well. What is it that you actually want to achieve? S130 v2 is capable of increasing the ATT MTU and thus sending larger notifications. If you want to move to a new SDK I recommend using SDK 12.3.0, this is the latest SDK supporting nRF51.

    1. My goal is to collect data from sensors and send it via BLE NUS to a master device. In addtition to this, master will be sending commands to the slave device via same NUS. Apart from different size and little change on power consumption what will be different if I will use s130 v2? I think that the easiest way would be to use s130.

    2. Well I would like to move to a newer one but there is a lot of code written so this would take a lot of time.

    3. Is it enough to increase MAX MTU size in code to be able to send longer notification?

    1. Do you need to send one notification? Would it be possible for you to split them up? Changes in what regard? The release notes should include the changes.

    2. Exactly, I can't decide if a migration is worth it or not. That is why I'm asking about why you need to send one big notification.

    3. I double checked the information I gave you about S130 v2 supporting configurable ATT MTU, it seems this was incorrect, and an error in the documentation. Sorry. Configurable ATT MTU is not possible on the nRF51 series, this was first available on S132 v3, so the nRF52 series.

    1. There is just a requirement set for the device that it must able to transmit >20bytes at the time. It can be split while being sent but receiving device has to see it as a one piece of information.

    2. Could SDK 12.3 be helpful for me while sending larger packets or disassembling, assembling them?

    3. I saw both statements in s130 v2 specification aswell and I was confused.

Related