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.

Android App does not work with SensorTag

Other Parts Discussed in Thread: CC2650STK, CC2640, CC2650

The latest version of the Android App on Google Play Store does not work with the SensorTag. It throws error "BLE SensorTag has sopped" after attempting to connect

Thanks, Zaffer

  • Hi Zaffer,

    I'm assuming this is v2.20 of the apk that you are using. What phone make/model. Also, just to confirm, this is CC2650STK (SensorTag 2.0)?

    Best wishes
  • Yes JXS, v2.20 on my MotoX w/ Android 4.4.2 doesn't work after i updated from v2.0. same problem on a Samsung Note Edge with v2.20. The older v2.0 is still working on a Samsung S5 that hasn't been updated to v2.20

    Thanks, Zaffer

  • Hello. We just verified that there are no problems with Samsung Galaxy S5, Android 5.0, and SimpleLink Sensor Tag 2.20. Can you try this? If it isn't working for you then possibly your hex is corrupt or there is some other issue.

  • the S5 with v2.0 is our only working setup right now and i don't want to take a chance and break it. do you have any other models to try?

    Thx, Zaffer
  • We also verified that these work:
    - Note 4 with Android 5.0.1
    - Galaxy S4 with Android 4.4.4
  • strange. Is new SensorTag FW required to work with v2.20 apk?
  • Anyone else in the community have problems when they updated to Android Simplelink SensorTag v2.20 apk?
  • FYI i just reprogrammed the sensor tag with the SensorTag project from the 2.0.0 installer and it still works. So no, you do not need new SensorTag FW.

    I'm not sure what your problem could be. Have you tried turning bluetooth off / on? Perhaps a sniffer capture would tell us something.
  • Yes tried just about everything. The App launches but then throws an error 'Unfortunately BLE SensorTag has stopped'. After 'Discovering Services' and prior to the error there is a pop-up window that says 'Found 11 out of 34 characteristics on this device'. Could that give a clue to the problem?

    Zaffer

  • I have some additional information that may be helpful to this thread:

    I have two SensorTags which I unboxed and connected to successfully without issue. I used them both simultaneously and individually. last week I received a debugger devpack and attempted to test it out by building the firmware for the SensorTag and downloading it to one of them.

    After I built the latest firmware that I downloaded with the latest CCS and downloaded it to the SensorTag, that one SensorTag has the exact same symptoms as described in this thread. I can connect to the SensorTag and when the services are discovered and the android app is preparing to display the sensor values on the screen, the android app stops.

    It seems like there is a change to the firmware source or the app in the google play store that is not compatible and this is causing the crash.

    One more thing: the "virgin" SensorTag I have with the factory firmware in it will still work with the app.

     

  • I just tried the following with HTC One M8:
    - Update the SensorTag Android App to 2.20 from 2.00
    - Start out with a SensorTag flashed with original HEX file. Can connect and read out all characteristics
    - Update FW to 1.01. Can still connect and read out all sensors.
    - Compile and download IAR SensorTag project to device. Can still connect and read out all sensors.

    It seems this is more related to the Android side than the FW on the SensorTag.

    Does the issue go away if you clear all data from the application? (Settings->Applications->BLE SensorTag-> Clear data/cache)
    If not, can you post the log file dump from Android either here or send it through the Android crash notification popup?

    Thanks,
    Svend
  • Hi Svend,

    I just sent the crash report from the popup when the application crashed. I get multiple instances of the popup when the app fails, but I only reported the initial crash popup.

    Is the image of the factory HEX file available somewhere that I can put back in my SensorTag and see if reverting to the older version fixes the issue?

    For what it's worth, I compiled the sensortag firmware and stack using CCS. I don't know if it matters, but you said you use IAR, so that is one thing different.

    Doug
  • It shouldn't matter whether CCS or IAR is used to compile the FW image as long as they are both set up correctly.
    The original HEX file can be found under ble_cc26xx_2_00_00_42893\Accessories\HexFiles.

    .:Svend
  • Hi Svendbt,

    The V2.20 of the TI BLE Sensor Tag Android application available on Google Play crashes when attempting to connect with SensorTag firmware built from the example source in simplelink\ble_cc26xx_2_00_00_42893, using CCS V6.1. The EVOThings applications also crash when trying to connect with this version of firmware.

    I tracked the problem to an invalid Firmware Revision String being generated and loaded into the device. Changing the following line in devinfoservice-st.c

    static const uint8_t devInfoFirmwareRev[] = TOSTRING(VERSION)" ("__DATE__")";

    to read as follows:

    static const uint8_t devInfoFirmwareRev[] = __DATE__;

    This fixes the problem. I am now able to use V2.20 of the TI Android BLE Sensor Tag application as well as the TI Sensor Tag application available from EVOThings.

    Bruce
  • Bruce,

    Thanks for the feedback. I will forward it to our FW developers so they can have a look at this.

    .:svend
  • Bruce,

    I was told that they are aware of it and have planned to fix it. VERSION needs to be defined in the CCS project as a compiler preprocessor symbol for it to be recognized.

    .:svend
  • Thanks Bruce. The firmware starts up without crashing now.

    I did manage to get the Android application to crash with this fix applied by accidentally pressing the OTA Firmware Download button in the application.  It could be something similar.

    In both cases, the Android app really should have a bit more robust validation on the data so it can exit gracefully instead of crashing.

    Thanks for tracking down the issue.

    - Doug

  • Indeed, I'm experiencing the exact same.

    So, out the box SensorTag 2 works, then compile stock SensorTag source and load it, then the Android app crashes after discovering services and want to display the 'info' screen with all the peripheral readouts (if I can call it that).  If you use RF Flash Programmer 2 1.6.x and load the hex that came with the stack, it works fine again.  There is something wrong with the source I expect.

    On a side note.  I searched my but off for the binary/hex and couldn't find it.  Read again that it comes with the BLE stack and looked again and I can only find CC2640 hex files, but decided to take a chance and load the CC2640_SmartRF_SensorTag.hex file and it works.  I think this is also named incorrectly.

    If TI could scour through the source and pinpoint where the issue, it would be great.  Anything I can do from my side to help, just shout.  Amped to get into it.  I suspect enough people already sent the Android bug report, but I can do so if required.

    Cheers

    JD

  • Sorry, my bad, I missed this page of the thread, only see the technical details now.
  • Hi JD,

    kowalski5233 said:
    So, out the box SensorTag 2 works, then compile stock SensorTag source and load it, then the Android app crashes after discovering services and want to display the 'info' screen with all the peripheral readouts (if I can call it that).  If you use RF Flash Programmer 2 1.6.x and load the hex that came with the stack, it works fine again.  There is something wrong with the source I expect.

    Yes there is an issue when using CCS to compile the program as mentioned a few posts up:

    kowalski5233 said:
    On a side note.  I searched my but off for the binary/hex and couldn't find it.  Read again that it comes with the BLE stack and looked again and I can only find CC2640 hex files, but decided to take a chance and load the CC2640_SmartRF_SensorTag.hex file and it works.  I think this is also named incorrectly.

    CC2640/CC2650 is equal except for that the CC2650 supports multiple protocols. Since the SensorTag supports other protocols as well it is using the CC2650.

    Regards,
    Svend

  • Hi Svend.

    Yes, sorry, when my post viewed after hitting 'reply' I saw I'm on a new page and the fix was already discussed. Somehow missed the second page of the thread (fail).

    Thanks for the quick feedback! TI seems to be more on it on the forums, really good to see. Have a good day!
  • svendbt said:
    Bruce,

    I was told that they are aware of it and have planned to fix it. VERSION needs to be defined in the CCS project as a compiler preprocessor symbol for it to be recognized.

    .:svend

    Thanks, this should be advertised more (sticky note) as it is an unavoidable blocker for starters. Also for newbies like me : compiler preprocessor symbols are in :
    Properties -> Build -> ARM Compiler -> Advanced Options -> Predefined Symbols -> Pre-define NAME (--define,-D)

    and add there +

    VERSION=1

  • Hello,

    Thank you for the feedback. The compile issue with CCS will be fixed in the next SDK release.
    FYI, the procedure to access Preprocessor Symbols is also documented in the BLE SW Developer's Guide (SWRU393), refer to section "2.6 Accessing Preprocessor Symbols".

    Best wishes
  • Thanks but still crashes with changes made above. I have CC2650ST_0120 defined.