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

Nus profile seems to cause system reset if the data length too long.

iphone5_b.psdm370_android6_b.psdlong_write_error.pngI using SDK11. I porting nus profile to my system and make a customer's UUID. I use Lightblue on iPhone 5 to connect my system. I sent a data through my customer's UUID. My system work fine when the data length is less than or equal 20 bytes. It will cause system reset if the data length is great than 20 bytes. Was the softdevice error, or I made something wrong?

Parents
  • The system is probably reset because APP_ERROR_CHECK() is called with something else than NRF_SUCCESS (0x00000000) somewhere. If you call ble_nus_string_send() with a longer length than 20 bytes it will return NRF_ERROR_INVALID_PARAM.

    The maximum ATT MTU with the S130 v2 is 23 bytes, the header is 3 bytes, so up to 20 bytes of data is allowed.

  • Uh.. you probably don't want to follow up using an answer.

    Anyway, I have never encountered any system reset due to SoftDevice, whether I use custom BLE services or nRF SDK's BLE Service.

    Following @petter 's suggestion, you should look at all places APP_ERROR_CHECK is used. Or quicker, add the preprocessor DEBUG in compiling option. This change APP_ERROR_CHECK to trap the firmware in an infinite loop at errors rather than reset the system. You can then use debug mode and see where the system freeze. Also when it froze, take a look at app_error.c. There are some global variables storing which line in which file trigger the error.

Reply
  • Uh.. you probably don't want to follow up using an answer.

    Anyway, I have never encountered any system reset due to SoftDevice, whether I use custom BLE services or nRF SDK's BLE Service.

    Following @petter 's suggestion, you should look at all places APP_ERROR_CHECK is used. Or quicker, add the preprocessor DEBUG in compiling option. This change APP_ERROR_CHECK to trap the firmware in an infinite loop at errors rather than reset the system. You can then use debug mode and see where the system freeze. Also when it froze, take a look at app_error.c. There are some global variables storing which line in which file trigger the error.

Children
No Data
Related