• State TI Thinks Resolved
  • Locked Locked
  • Replies 5 replies
  • Answers 2 answers
  • Subscribers 51 subscribers
  • Views 327 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

CC2640R2L: BLE application getting crashed on CC2640R2F

sudhanshu shekhar
Intellectual 640 points
Part Number: CC2640R2L

Hi

I am currently working on CC2640R2L using simple peripheral plus observer as the base project in SDK version 4_20_00_04.

All my applications work fine, but there was an observation related to my connection mode.

In my GATT profile I have configured my characteristics to support maximum 20 bytes data transfer at a time.

But when in connection mode with my mobile app if the data size getting transferred exceeds 20 bytes my application gets crashed and my watchdog reset happens to recover from this.

So an additional check at the length of the data received saves my application from this scenario.

My query was that can I expect the same behaviour when in advertisement mode i.e. if any advertisement packet exceeds that of what supported by BLE application?

Also when data exceeds 20 bytes while in connection mode what triggers my application to get crashed?

Regards

Sudhanshu

  • 0
    TI__Guru** 101460 points

    Hi Sudhanshu,

    It is always difficult to comment with such a limited knowledge of your code base. Here, I guess the issue comes from some data corruption. Assuming a 20-byte data buffer is allocated, writing more data will necessarily lead to a corruption of the adjacent memory region. As you have mentioned, the best practice is to double check the data size every time before attempting to write a buffer.

    A similar behavior and a similar solution should be expected for the advertisement mode. There too, data corruption (and potentially system crash) has to be expected if the length of the data is larger than the buffer.

    I hope this will help,

    Best regards,

  • 0 in reply to Clément
    Intellectual 640 points

    Hi Clement

    Thanks for the clarification.

    I have one more doubt that when in scanning mode what so ever advertisement packets my BLE application receives is there any chance that advertisement data can exceed 31 bytes.

    Regards

    Sudhanshu 

  • 0 in reply to sudhanshu shekhar
    TI__Guru** 101460 points

    Hi Sudhanshu,

    Actually, you cannot know the length of all the advertiser out there. So there are chances the advertising data length exceeds 31 bytes. With that being said, the scan reports are dynamically allocated by the stack. So the issues we have discussed so far should not impact scanning.

    Best regards,

  • 0 in reply to Clément
    Intellectual 640 points

    Hi Clement

    I agree with your point. Under the GAP_DEVICE_INFO_EVENT I receive the device information which tells about the data packet received.

    So just because I am using BLE 4.2, additional check was not there for the length of data getting received.

    is it possible that BLE 4.2 can receive advertisement packet of more than 31 bytes?

    I doubt that my destination buffer is of 31 bytes, so whenever I receive a packet after scanning and receive the GAP_DEVICE_INFO_EVENT I copy the data received to this buffer. So in case if the data received exceeds 31 bytes, there is a fair chance that my application can crash.

    Regards

    Sudhanshu

  • 0 in reply to sudhanshu shekhar
    TI__Guru** 101460 points

    Hi,

    I did not get you were refering to the buffers held by the application. My answer is similar to before. Every time you perform a data copy, you should check the data length, otherwise, sooner or later something unexpected may occur.

    Best regards,