• State Resolved
  • Locked Locked
  • Replies 8 replies
  • Subscribers 52 subscribers
  • Views 6594 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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.

CC2541: Android 8.x.x(Oreo) can't find CC2541 devices at all

Jay Kim
Intellectual 475 points
Part Number: CC2541
Other Parts Discussed in Thread: BLE-STACK

Hello,

After android OS update(7.x.x Nougat to 8.x.x Oreo), phone can't find CC2541 devices at all.

I'm facing this problem with using HM-10, which is Serial to BLE dongle has CC2541 inside.

BTW, I have another Serial to BLE dongle which has NORDIC nRF52832 inside and no problem with Android Oreo.

  • 0
    TI__Guru** 105180 points
    Hello,

    What is your HM-10's BDADDR? Also, what is your ADV data values? If you have malformatted ADV data (e.g., your length byte is not correct in the token), some newer Android OSs will ignore the device.

    Best wishes
  • 0 in reply to JXS
    Intellectual 475 points

    BDADDR  : 00:15:83:00:69:0C

    Regards,

    Jay

  • 0
    Prodigy 10 points

    Hello,

    I have the same problem since I upgraded my Samsung galaxy s8 to Android 8.0 (Oreo).

    Before this update everything worked smoothly.

  • 0 in reply to Saverio Cornacchia
    TI__Guru** 105180 points
    I must admit I don't know why you don't see the device. The behaviour seems to be on the handset side though. One observation is the BDADDR is not a Texas Instruments OUI, but the module vendor may have programmed their own BDADDR. Also, if the Scan Rsp data is not correctly formatted, it may cause the Android to discard the device.

    Here's what I would do: I would take the SimpleBLEPeripheral application from the BLE-Stack v1.4.2 SDK and disable the HAL_LED/LCD defines. Also disable POWER_SAVING if your module doesn't sport a 32k sleep crystal (some HM-10's don't). This will remove any dependencies to the external IOs. After programming to the module with the CC Debugger, you should be able to see the device with this project as I've never had an issue with any Android using this sample project.

    Best wishes
  • 0 in reply to JXS
    Intellectual 475 points
    After check more with sniffering data, I can see HM-10 actually send weird scan response.

    Advertising (length = 7): 02 01 06 03 02 E0 FF
    02 01 06
    -> [Good] AD Type = Flag:
    03 02 E0 FF
    -> [Good] AD Type = UUID

    Scan Response (length = 31): 0B 09 4D 6A 41 6E 4E 73 47 79 4F 73 00 00 00 00 81 00 10 00 FF FF FF FF FF FF FF FF FF FF FF
    0B 09 4D 6A 41 6E 4E 73 47 79 4F 73
    -> [Good] AD Type = Local Name. I had change HM-10's original name "CC41-A" to "JmNaSnYgSo" using AT Command.
    00 00 00 00 81 00 10 00 FF FF FF FF FF FF FF FF FF FF FF
    -> [Abnornal] Some Garbage data

    Maybe since 8.0.0, Google had add more verifying&restriction codes to Android OS.
    android-review.googlesource.com/.../advertise_data_parser.h
    I see there's Android OS patch done to permit zero paddings recently but as regarding HM-10's case,
    it would still rejected by Android OS(higher than 8.0.0) because garbage data also contains none zero values.

    I guess HM-10's manufacturer made their firmware based on SimpleBLEPeripheral example.
    Could you check whether there's some ambiguous code in SimpleBLEPeripheral application which would misguide manufacturers to make bug in there firmware...?
    (something like fix local device name's value size as 31 byte or etc...)

    P.S.
    Screenshot of my previous post was made with "Android OS 7.0 / nRF Scanner app".
    "Android OS 8.0(or higher) / nRF Scanner app" can't detect HM-10 at all.

    Regards,
  • 0 in reply to Jay Kim
    TI__Guru** 105180 points
    Well, that's some good debugging, Jay! Yes, it appears that Android tightened up the processing of ADV/Scan Rsp data to comply with the BT core spec. Thanks for sharing the reference.

    FYI, the SimpleBLEPeripheral project has just the aforementioned name in the Scan Response:
    // complete name
    0x14, // length of this data
    GAP_ADTYPE_LOCAL_NAME_COMPLETE,
    [SimpleBLEPeripheral]

    This is why there is no issue with our out of box example and why I suggested you try this project. It appears your module vendor (or someone else) modified the firmware but didn't comply to the formatting described in BT4.x, Vol 3, Part C, Sec 11 which Android8 now adheres to. The BLE Stack will not enforce this as it's up to the application to comply with the layout. There are some custom applications that don't use this format, that's why we don't enforce it.

    Best wishes
  • 0 in reply to JXS
    Intellectual 475 points
    Thanks for explanations,

    Since we had already deploy our products which include HM-10 in field,
    I need to find if there's any workaround without changing HM-10's firmware.

    Several questions,
    1. Do you think It will be not possible to modify our android application(which we can download at Google play store)
    to clear this problem because Android OS(Oreo) itself rejecting HM-10 in low layer?
    2. Trying to remove garbage data, I will increase LOCAL_NAME as long as I can and see what will happens.
    (As by seeing module vendor's manual, max length of name I can configure using AT command(AT+NAME) is 12 though...)
    Ti's out of box SimpleBLEPeripheral project includes AT command or module vendor add it on their own?
    3. I guess HM-10 is one popular BLE-to-UART module which deployed millions and all of them going to be useless if it's
    application need to be connected to phone(After Android OS Oreo). Do you think it's nonsense asking Google to fix this
    issue for backward compatibility?

    Regards,
    Jay
  • 0 in reply to Jay Kim
    TI__Guru** 105180 points
    No problem. Answers to your questions:

    1. I doubt it. The AOSP link you provided above show the modification to the stack, not the application. Therefore, an app (apk) change likely won't change the behaviour.
    2. I would try this approach to see if a combination of settings/values changes the ScanRsp data to be more compliant.
    3. You could try contacting Android via their support forums; however, the decision to make a change is with them. That's' why I say to focus on finding a solution to #2. I've reached out to some in-region contacts to see if there is any way to have HM-10 issue a firmware update and will update if I have more information. This does also highlight that you should have the appropriate support arrangement with your module supplier when developing & shipping your product.

    Best wishes