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.

CC254x with Android 6.x Marshmallow, 7.x and 8.x [Updated Apr 2019]

Other Parts Discussed in Thread: BLE-STACK, CC2640, CC2541, CC2540, CC-DEBUGGER

Is there any one tried to get CC254x (even CC26xx) working with the latest Android 6.x Marshmallow? We heard there are issues from multiple sources. We are still looking for any Android 6 device to confirm. Will get back here and let everyone know once we have a device to test it.

Ed (TI): ** Update Dec 9, 2015: See Dec 9 post confirming Android 6.0.1 (Nexus 5) update is now compatible with BLE 1.4.0 and earlier BLE-Stack releases. Peripherals that are Pairing with Android devices that do not yet incorporate this change will need BLE 1.4.1 to remain compatible with smart devices that implement LE Secure Connections (BT4.2) Pairing.

Ed (TI): ** Update October 2016: Reports of compatibility issues with Android N and BLE-Stack 1.4.2/1.4.2 are not related to Pairing. An update to improve the performance of the SNV read operations can be made by replacing the findItem() function in osal_snv.c with the version in the the attached findItem.txt.

findItem.txt
/**************************************************************************************************
  Filename:       osal_snv.c (patched)
  Revised:        $Date: 2013-02-15 10:12:26 -0800 (Fri, 15 Feb 2013) $
  Revision:       $Revision: 33143 $

  Description:    This module contains the OSAL simple non-volatile memory functions.


  Copyright 2009-2013 Texas Instruments Incorporated. All rights reserved.

  IMPORTANT: Your use of this Software is limited to those specific rights
  granted under the terms of a software license agreement between the user
  who downloaded the software, his/her employer (which must be your employer)
  and Texas Instruments Incorporated (the "License").  You may not use this
  Software unless you agree to abide by the terms of the License. The License
  limits your use, and you acknowledge, that the Software may not be modified,
  copied or distributed unless embedded on a Texas Instruments microcontroller
  or used solely and exclusively in conjunction with a Texas Instruments radio
  frequency transceiver, which is integrated into your product.  Other than for
  the foregoing purpose, you may not use, reproduce, copy, prepare derivative
  works of, modify, distribute, perform, display or sell this Software and/or
  its documentation for any purpose.

  YOU FURTHER ACKNOWLEDGE AND AGREE THAT THE SOFTWARE AND DOCUMENTATION ARE
  PROVIDED �AS IS� WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESS OR IMPLIED,
  INCLUDING WITHOUT LIMITATION, ANY WARRANTY OF MERCHANTABILITY, TITLE,
  NON-INFRINGEMENT AND FITNESS FOR A PARTICULAR PURPOSE. IN NO EVENT SHALL
  TEXAS INSTRUMENTS OR ITS LICENSORS BE LIABLE OR OBLIGATED UNDER CONTRACT,
  NEGLIGENCE, STRICT LIABILITY, CONTRIBUTION, BREACH OF WARRANTY, OR OTHER
  LEGAL EQUITABLE THEORY ANY DIRECT OR INDIRECT DAMAGES OR EXPENSES
  INCLUDING BUT NOT LIMITED TO ANY INCIDENTAL, SPECIAL, INDIRECT, PUNITIVE
  OR CONSEQUENTIAL DAMAGES, LOST PROFITS OR LOST DATA, COST OF PROCUREMENT
  OF SUBSTITUTE GOODS, TECHNOLOGY, SERVICES, OR ANY CLAIMS BY THIRD PARTIES
  (INCLUDING BUT NOT LIMITED TO ANY DEFENSE THEREOF), OR OTHER SIMILAR COSTS.

  Should you have any questions regarding your right to use this Software,
  contact Texas Instruments Incorporated at www.TI.com.
**************************************************************************************************/

/*********************************************************************
 * @fn      findItem
 *
 * @brief   find a valid item from a designated page and offset
 *
 * @param   pg       - NV page
 * @param   offset   - offset in the NV page from where to start
 *                     search up.
 *                     Usually this paramter is set to the empty space
 *                     offset.
 * @param   id       - NV item ID to search for
 *
 * @return  offset of the item, 0 when not found
 */
static uint16 findItem(uint8 pg, uint16 offset, osalSnvId_t id)
{
  halIntState_t is;
  
  offset -= OSAL_NV_WORD_SIZE;

  // Calculate the offset into the containing flash bank as it gets mapped into XDATA.
  uint8 *ptrBase = (uint8 *)(HAL_FLASH_PAGE_MAP) +
               ((pg % HAL_FLASH_PAGE_PER_BANK) * HAL_FLASH_PAGE_SIZE);
  uint8 memctr = MEMCTR;  // Save to restore.
  pg /= HAL_FLASH_PAGE_PER_BANK;
  
 
  while (offset >= OSAL_NV_PAGE_HDR_SIZE)
  {
    osalNvItemHdr_t hdr;

    HAL_ENTER_CRITICAL_SECTION(is);
    //HalFlashRead(pg, offset, (uint8 *) &hdr, OSAL_NV_WORD_SIZE);
    MEMCTR = (MEMCTR & 0xF8) | pg;
    for (uint8 i = 0; i < OSAL_NV_WORD_SIZE; ++i)
      ((uint8*)&hdr)[i] = ptrBase[offset + i];
    MEMCTR = memctr;
    HAL_EXIT_CRITICAL_SECTION(is);

    if (hdr.id == id)
    {
      // item found
      // length field could be corrupt. Mask invalid length mark.
      uint8 len = hdr.len & ~OSAL_NV_INVALID_LEN_MARK;
      return offset - len;
    }
    else if (hdr.len & OSAL_NV_INVALID_LEN_MARK)
    {
      offset -= OSAL_NV_WORD_SIZE;
    }
    else
    {
      // valid length field
      if (hdr.len + OSAL_NV_WORD_SIZE <= offset)
      {
        // valid length
        offset -= hdr.len + OSAL_NV_WORD_SIZE;
      }
      else
      {
        // active page is corrupt
        // This could happen if NV initialization failed upon failure to erase
        // page and active page is set to uncleanly erased page.
        HAL_ASSERT_FORCED();
        return 0;
      }
    }
  }
  return 0;
}

Ed (TI): ** Update May 2018: TI has fielded inquires about peripheral devices not detected after upgrading to Android 8. Previously, these devices were detected with the same handset running Android 7 (or earlier). The issue has been traced to improperly formatted data within the peripheral's ADV or scan response (SCAN_RSP) PDU. Specifically, if the length byte in the ADV or scan response does not match the actual payload of the proceeding AD data type (e.g., Manufacture Specific Data), Android 8 will not present the peripheral device to the application. Please ensure that your advertData[] and scanRspData[] arrays properly set the "// length of this data" for the given AD data type. 

Ed (TI): ** Update Apr 2019:TI has released BLE-Stack 1.5.0 for CC254x which is qualified to Bluetooth 5.0. This release addresses the "findItem" SNV limitation described above. Please see the release notes and porting guide which are included with the 1.5.0 SDK for details on upgrading and using this release.

  • Hello,

    Please let us know if you see any issues, and provide a sniffer trace if possible. I do recommend that you are using the latest BLE 1.4.1 (for CC254x) and BLE 2.1 (for CC2640) when you test with Android 6.x.

    Best wishes
  • Hello JXS,

    We did test it on a Nexus 7 (Android 6.0, Build MRA58K). SDK 1.4.0 does not work and SDK 1.4.1 works fine.

    Samson

  • Hi Samson,

    Thanks for confirming. Marking this thread as sticky so others know to use BLE 1.4.1 with Android 6 (Marshmallow). For CC26xx, BLE 2.0 and 2.1 should work as well.

    Best wishes
  • Hi Engineers,

    I'm facing the same pairing issue with Android 6 Marshmallow.
    But this needed upgrade to 1.4.1 stack means only one thing : products already on the market and running 1.4.0 won't work with Android 6, and possibly with any device working under BT4.2...

    That's no good news.

    @TI, do you have any idea to support
  • Update November 23, 2015:

    The Android development team has made a change and pushed it to the AOSP project. Please see the committed change made on Oct 27th: android-review.googlesource.com/

    Change Description:
    "
    Check remote LMP version before enabling secure connections Request remote version information for LE links when connecting and ensure LMP version is >= 8 (Bluetooth 4.2) before setting the LinkKey bits in the pairing request. This is to ensure older remote devices do not get confused by the additional bit(s) in the pairing request.
    "

    This change, when incorporated by the respective phone/tablet manufacturers, will ensure BLE 1.4.0 (and previous releases) are compatible with Android6 / BT4.2. All CC254x SW (e.g. BLE 1.4.0) will report an LMP version of 6 (BT4.0).

    Best wishes
  • Hi, JXS,
    Our product is also designed on BLE 1.4.0 and almost ready for product launch. In recently we also found the pairing problem on Nexus5, Android 6.0.

    We found the problem is at SMP pairing failed and failed reason is "Confirm Value Failed".
    And it seems that "secure connection pairing: Yes" in AuthReq is different from previous Android version.
    Not sure the problem is the same as you mention.

    Do you have any idea about when will Android release fixed version?
    Or I should upgrade F/W to BLE 1.4.1 immediately.
    We are worring about don't know when newest Android version release and even if the version upgrade, still have some Android 6.0 version phones in market and will have pairing problem.

    I need your support and please give me suggestion.

    Thanks,
    Moby
  • Hello Moby,

    TI does not have visibility as to when a respective phone OEM (i.e., LG for Nexus 5) will issue an OTA or ROM update incorporating the patch listed above.

    If you have not shipped your product, I strongly recommend you upgrade your firmware to BLE 1.4.1 which does not have the Android6 LE Pairing compatibility issue.

    Best wishes

  • Hi JXS,

    Thanks for your support. After discussion, we decide to upgrade to BLE 1.4.1.
    But we still have the question about why BLE 1.4.1 won't have pairing problem on Android 6.0.
    I read the release note (readme.txt in stack code), didn't find the answer.

    I know BLE 1.4.1 is full support for Bluetooth Core 4.1 specifications.
    But I read the statement said below.
    Ed (TI): Please see below stating that BLE 1.4.1 is required to support Pairing with smart devices running Android 6 that implement LE Secure Connections (BT4.2) Pairing.

    What's the difference? Pleas help.

    Thank you.

    Best regards,
    Moby
  • Hello Moby,

    CC2541/CC2540 with BLE 1.4.x support the BT4.0 core specification. Support of BT4.1 is offered by CC2640.

    Unfortunately, the actual issue was not included in the original release notes, but involves handling of the LinkKey key distribution field that was added in BT4.2 and thus ignored in BT4.1 and earlier devices. The Android link in the Nov 23rd update makes sure this field is not set for legacy devices.

    Best wishes
  • Hi JXS,

    Thanks for your answer.

    Moby

  • Hi JXS,

    Thanks indeed for your answer and feedbacks.

    Karim.
  • Update:

    I have confirmed successful Pairing with BLE 1.4.0 / SimpleBLEPeripheral & Nexus 5 (hammerhead) running Android 6.0.1. The exact Nexus 5 factory image used: hammerhead-mmb29k-factory-1943f0f5.tgz.

    Using the BLE Packet Sniffer, it is confirmed that Android 6.0.1 is not setting the Link Key bit in the Pairing Request, thus Pairing compatibility with BLE 1.4.0 and prior releases is assured.

    As previously mentioned, TI is not able to comment as to when other Android smart device OEMs will incorporate this change.

    Best wishes

  • Dear JXS,

    Than you for sharing.

    Despite predicting Android versions deployment  is harder than getting the right numbers of the lottery, we could bet that manufacturers will be more enclined to implement 6.0.1 versions. Every one knows that x.0 versions are beta versions ;-).

    This is good news.

    All the best.

    //KaHo.

  • While the issue was beyond TI's control we do wonder why TI versioned 1.4.1 as a minor-minor release. Nothing in the release notes suggested that pairing had been affected between 1.4.0 and 1.4.1.  Had this release been named 1.5.0, or better yet 2.0.0, we would have upgraded sooner and saved ourselves a lot of warranty claims and 1-star reviews.  Furthermore why is 1.4.1 now re-released as of November 2015 ?  It was previously released in May 2015.  Scanning the directory it appears to be just a change to the EULA pdf.  But it is making us nervous.  Can someone at TI confirm the differences between the May and Nov releases of V1.4.1 ? Thank you. 

  • Hello Lou,

    Regarding BLE 1.4.1, this is a maintenance update to the v1.4.0 release. For the revised 1.4.1 installer, there were no changes to the library or run time source code; updates were only made to the packaging of the installer to be consistent with other SDK installers released by TI.

    Best wishes
  • Hi JXS,
    In our case we have shipped our products to retailers and now are getting pairing complaints from Android 6 users. Since the product will not pair to the mobile device, how will we use over the air updates to update the product? Please don't tell me the solution is to take the products back and update them with a wired CC-Debugger type configuration.
    Please help,
    Patrick
  • Hi Patrick,

    Are your users seeing issues with Android 6.0.1+ with the fix integrated (Dec 9, 2015 update above). Have you replicated in your lab?

    Best wishes
  • Hi JXS,
    Wow, that was fast! Our product was released two weeks ago and is just now getting into the hands of customers - although we have stacked distribution partners. After reading this thread, I've asked one of our beta testers (initially reported the problem) to see if he can update to 6.0.1. I'll let you know if he can and if it resolves the issue.
    Thanks again for the quick response.
    Patrick
  • Hi JXS, thank you for your support.  

    The Samsung Edge S7 and S7 still do not pair with 1.4.0 even when running 6.0.1.  Although 6.0.1 did fix this problem for other manufacturers it did not for Samsung.   We are once again dealing with more warranty claims and 1-star reviews. It happens.

    Had we implemented OAD  would that have just updated our App code ? Do you need to pair in order to perform OAD ?  If "yes" to either question, OAD wouldn't have helped with this issue. 

    Again the next time you guys do an update that affects something as critical as pairing, please, please don't dismiss it as a dot dot + 1 release. We are dealing with many returns that could have been avoided had the May 2015 release notes been accurate.

     

  • That's unfortunate that not all OEMs have implemented the AOSP change from 6.0.1.

    Regarding OAD, nothing in the TI-defined OAD service requires security, however, some device manufactures may require, or some phones may decide to initiate pairing prior to OAD.

    Thank you for the feedback on the release notes - we'll make this more clear in future updates. At the time (May 2015), we did not know that Android would make such a change, and the other phone OS did not use this option with legacy devices.

    Best wishes

  • "That's unfortunate that not all OEMs have implemented the AOSP change from 6.0.1."

    I have also heard that there are still problem with LG  devices (G5,G4,G3). Could you ask manufacturers to implement this fix? S7 together with most popular LG devices means that there are millions devices out there that do not work with CC2541 devices that require security.

  • There is another critical issue with Android 7.0 on Google's Nexus 6P. It not only prevents pairing, but non-encrypted read/writes as well. There is no work around other than downgrading the phone to 6.0.1. It affects all TI BLE Stack versions including 1.4.2. I am currently working with an engineer at Google HQ and would appreciate additional support from TI so we can resolve this bug before it is propagated to other phone manufacturers. Here's a link to the post: e2e.ti.com/.../1966708
  • Lou,

    Thanks for letting us know. Let's continue the investigation in the other thread that you referenced. We can then update this post with any findings.

    Best wishes
  • Hi JXS,

    Our customers used Nexus 6P (Android 7.0) to test our BLE device and also got pair problem.
    Our BLE device is BLE 1.4.1 stack and CC2541 chip.
    Here is log file. Nexus6P_2D00_NG.zip

    We are going to get one Android 7.0 phone to test it, will feedback the result later.
    I found your post about improving SNV read operations on October 2016.
    Is this code to solve Android N compatibility issue? (or the pairing issue is from SNV handle?)
    Please give us some suggestion.

    Best regards,
    Moby

  • Hi Moby,

    Based on your sniffer capture it seems that you are experiencing the issue related to the SNV findItem() function. Please see the fix attached to this thread.
  • Hi Lou,
    did you ever try OAD with CC2540? i just cant seem to get it to work!