• State Suggested Answer
  • Replies 2 replies
  • Answers 1 answer
  • Subscribers 88 subscribers
  • Views 954 views
  • Users 0 members are here
Attachments (0)
Nordic Case Info
  • Case ID: 270541
Options
Beware that this post is related to an SDK in maintenance mode
More Info: Consider nRF Connect SDK for new designs
This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

NRF52 SDK 17.0.2 - Function ble_advdata_uuid_find can only find 128 Bit service uuids ?

marco c.

Hi,

I noticed that the value raw_uuid_len in function ble_advdata_uuid_find() in module ble_advdata.c is fixed at the value UUID128_SIZE.

So the function can only find vendor specific uuids with 128Bits.

For explanation. In my project I try to find peripherals that offer the Nordic DFU service  that has the 16Bit UUID 0xFE59. This fails because of the described behavior.

When I set the value raw_uuid_len to UUID16_SIZE the Nordic DFU service can therefore be found in the advertising data of the peripherals.

Is the fixed value for raw_uuid_len in function ble_advdata_uuid_find() a bug or is it wanted like that ?

Or am I doing something wrong?

Thanks in advance.

Parents
  • 0

    I found the cause.

    There was an upgrade of the compiler a few days ago. I use the compiler from the gnu arm embedded toolchain (arm-none-eabi-gcc) on a arch linux system and the compiler was recently updated from version 10.3.0 to version 11.1.0. In retrospect it was around this time that the described behaviour began to appear. Downgrading the compiler to version 10.3.0 solved my problem. The examples from the SDK also do not work correctly if they were compiled with gcc version 11.1.0.

    Can anybody confirm this?

Reply
  • 0

    I found the cause.

    There was an upgrade of the compiler a few days ago. I use the compiler from the gnu arm embedded toolchain (arm-none-eabi-gcc) on a arch linux system and the compiler was recently updated from version 10.3.0 to version 11.1.0. In retrospect it was around this time that the described behaviour began to appear. Downgrading the compiler to version 10.3.0 solved my problem. The examples from the SDK also do not work correctly if they were compiled with gcc version 11.1.0.

    Can anybody confirm this?

Children
Related