Jira 871 CurieBLE: Large characteristics (64 bytes) crash board when attempting to write to them

[kgillespieatmosphere]

It appears that I am unable to write to a characteristic that is 64 bytes long.

Any attempts to write to the characteristic seems to crash the board. I know that with BLE it's required for the communication to chunk the writing. My app works with another BLE chip set but doesn't work with the Curie any hints?

BLECharacteristic credentials("bfe433cf-6b5e-4368-abab-b0a59666a403", BLERead | BLEWrite, 64);

As you can see this characteristic is 64 bytes long. The firmware works so long as no attempt is made to write to it.

Using CurieBLE driver with version 2.0.0 RC4.

[sgbihu]

Which API you used? I test with .writeValue, it doesn't crash. So can you share your test sketches?

[SidLeung]

@sgbihu , please share your sketch here for comparison. Thanks.

[kgillespieatmosphere]

This would be a write coming from the central not internal on the embedded device it's self. Yes .writeValue works, write with response from a central device to the Curie over BLE does not.

I will send my example but there isn't much to it.

[sgbihu]

My test key code is:

unsigned char test_1[64]; credentials.writeValue(test_1, sizeof(test_1));

By the way, the stack only send out the 20 Bytes. Because the BLE protocol has this limitation. You'd better not use 64 Bytes.

[kgillespieatmosphere]

So the Curie BLE stack doesn't handle long writes? There are methods in many BLE stacks, Android and iOS both support, to send what is know as a long write, sometime queued writes, your data is automatically chunk-ed into 20 bytes segments.

As far as I know the central sends a begin reliable write message, and then call write characteristics for as many 20 bytes segments as it needs then the peripheral device will appended that data to the characteristic until the central then sends the end reliable write message.

This feature exists and works well with other chip sets. Nordic has an example here https://github.com/NordicSemiconductor/ble_app_hrs---LongWrite

But I am guessing I can't expect this feature anytime soon for Curie?

[sandeepmistry]

Hi @kgillespieanaren,

It would be great if you can share a minimal sketch that can be used by us to reproduce the issue. As well as steps that we can use to reproduce the issue.

@SidLeung @sgbihu Last time I checked, iOS tries to negotiate an MTU of 158 bytes, need to see if the CurieBLE accepts this but it might fallback to the minimum MTU of 23 bytes, which will trigger the long or reliable write on the iOS or Android central side.

[kgillespieatmosphere]

longWriteTest.zip

In this example we keep printing the I'm alive message on an interval. Once we attempt to write to the characteristic with UUID "bfe433cf-6b5e-4368-abab-b0a59666a403" with any length of data the device stops responding, BLE disconnects and the "I'm alive!" message stops displaying over UART.

Expected results would be that it continues to work and receives the data over BLE from the write command. You can use a simple BLE debugging app on android or iOS to write to the characteristic. Such as "BLE Scanner" for Android which I did in my test, also my own application causes this problem as well on both iOS and Android. My app works correctly on two other manufacturers BLE chipsets.

[sgbihu]

Find the root cause and give the solution.

[SidLeung]

Jira 868 was created to track this issue.

[kgillespieatmosphere]

I just gave you fix @SidLeung and it does correct the crashing issue with the curie. Although as explained before it appears to be limited to 20 bytes. Odd behavior though when I write the following sting

123456789012345678901234567890

and then read it back I get

12345678901234567890"

The trailing quotation mark is pretty interesting, also that the Android device thinks it's getting 21 bytes back.

[sgbihu]

Hi @kgillespieanaren ,

In my test, I don't find the issue you described except some dirty value. The dirty value doesn't be cleared in the constructor.

I test on IOS with nRF Connect. I try to write "1234", and read again, it will back 64bytes include the write value. Because the curie BLE only response the real length for long characteristic.

So can you post your test environment. I try to duplicate it first.

[kgillespieatmosphere]

@sgbihu

I get the same result when I read back as well, I can see up to the 20th byte written correctly and then the rest is garbage, I just had to tell my app to print all data not just null terminated string data. So I do get the 64 bytes back from the read, but only 20 bytes of it matches what I sent during the write request. So I don't think we are seeing anything different.

So I guess my question is do you have an example, or some docs on how to do a long characteristic?

Thanks for the quick feedback!

[SidLeung]

PR #463 addresses the long write issue. If the reading is proved to be incorrect, another ticket will be open to track it.

[SidLeung]

A Jira ticket, 871, is opened to track the written data size issue.

[russmcinnis]

@SidLeung jira 871 mentions that PR463 fixes this issue.