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

Parents
  • 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.

Reply
  • 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.

Children
No Data
Related