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

device disconnect when sending uin32_t

Hi Nordic's community,

I have an issue when writing uint32_t to a characteristic, i don't understand when i write uint16_t or uin8_t, it works ! but don't when i send an uin32_t value to my characteristic ?

My Android device (with Master control panel) disconnect when i try to write to this characteristic...

I add my characteristic like this:

attr_char_value.p_uuid       = &ble_uuid;
attr_char_value.p_attr_md    = &attr_md;
attr_char_value.init_len     = sizeof(uint32_t);
attr_char_value.init_offs    = 0;
attr_char_value.max_len      = sizeof(uint32_t);
attr_char_value.p_value      = (uint8_t*) &initalValueAlarm;

with initialValueAlarm is an uin32_t type variable.

My write funtion handler is like this:

if ( (p_evt_write->handle == p_lbs->led_char_handles.value_handle) && (p_evt_write->len == 4) && (p_lbs->led_write_handler != NULL)) 
	
{
    p_lbs->led_write_handler(p_lbs, *( (uint32_t*) p_evt_write->data )); 
			SEGGER_RTT_printf(0, "%d\n", *( (uint32_t*) p_evt_write->data ));
}

It works perfeclty with uint16_t or uint8_t type but not with uint32_t type, and i don't understand why... Thanks for your help.

EDIT 13/06/2016:

I add two pictures of the nrf master control panel, one with the characteristic and one with the error:

and the error on the NRF MCP:

image description

and the characteristic:

image description

EDIT 14/06/2016:

I add the demo project:experimental_ble_app_blinky.zip folder.

EDIT 15/06/2016:

I add the modified ble_lbs librarie:

ble_lbs.zip

  • Hi. I was not able to reproduce this. Maybe you can post your project files?

  • Hi Martin, thanks for your answer. So, there is no problem to send an uin32_t type data through BLE ? Maybe the data is too long and i need to parse it ? How i can post my project files to the forum please ? Thanks.

  • No that is not problem. An uint32_t is transmitted as a string of bytes as with any other types of data transmitted. It is how you treat the data in the end that matters. Sending an uint32_t should not cause a disconnect. I suspect that something in your code asserts or hard faults when you receive your data, causing your device to reset and consequently disconnect. Have you tried to debug your code and look for asserts?

    The best way to post your code is to put the project files in a zip file. Then edit your original post and attach the zip file there. To keep the zip file small you can also remove the build files (located in "example\pca100xx\s132\arm5_no_packs_build" in the example files for Keil) from the project before you zip it.

  • thanks Martin, but this is my android device which disconnects when i send the value, not the nrf51 DK (my peripheral)... I updated my post to see the error on NRF Master control Panel in my Android smartphone.

  • The error 133 is known to be a bit difficult to debug, since it just signifies a "GATT error" and gives no indication of what's wrong. You will see there is a lot of questions about error 133 (0x85) on this forum and on google. A lot of the cases turns out to be some issue with android versions or phones.

    What phone, Android version, and Softdevice version do you use?

    I also saw a case where the issue was that the phone was caching information about the device and its services. When the user then changed the code and service he got the error. Maybe you can try to clear the BLE cache. A common way to do it is to turn bluetooth off and on again on your phone.

Related