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.

iOS SensorTag App - OAD Menu - Wrong Chip Detection

Other Parts Discussed in Thread: CC2650

Hi,

Using lastest TI iOS App 4.4

My Problem

After downloading my sensorTag branched project via a debugger to a sensortag.

Opening OAD Menu via iOS App->Sensor View -> FW Download -> TI OAD Profile Menu.

My target is detected as CC254xx, although I am running on a CC26xx. (CC254XX appears in blue.)

This wrong identification leads the FW upgrade to progress in a wrong manner.  

I believe the iOS App behaves as it is FW upgrading a CC254xx chip.  

 

What I already know

The iOS App looks for various indicators to run appropriate checks and present menus according to the target it believes it is running on.

one of them being attDeviceName.

Changing the attDeviceName in code to  "SensorTag 1.0" does cause the iOS App to indentify the target  as a CC254x  although running on a CC26XX.

So now I know that for testing purposes I should keep attDeviceName = "SensorTag 2.0" in my application.

Question

I will be glad to know what additional indicators the iOS App is looking for inorder to identify the chip correctly and thus present the appropriate menus,

since my goal:

is to try to use the OAD menu in the iOS App to check downloading on a CC26XX.

Probabley I have changed a few indicators in my custom application.

In my application I have changed back attDeviceName to "SensorTag 2.0" but with no results. TI iOS App OAD Menu keeps recognizing my target as CC254X.

Is the iOS checking FW_VERSION_STR? devInfo service?, something in the advertsing data (advertData), scanRspData. 

Is it looking for a specific service?. 

I have slightly changed all these in my custom sensortag branched application, but from my debugging, reverting them back to original sensortag project defines doesnt help.

I am probabley overlooking something.

Atttached Image of wrong chip detection:

Will be grateful for some advise

Regards

Tamir

  • Hi Tamir,

    I apologize that this thread is still unanswered. I have notified our mobile developers. You will get an answer soon.
  • Thanks

    Tamir
  • Hi Sean,

    Any progress on this topic?.

    Regards

    Tamir
  • Hi Sean,

    Any progress on this topic?.

    Unfortunately my deadlines are getting closer.

    Happy to hear from you.

    Regards,

    Tamir
  • Tamir,

    This is a known issue that will be eventually be fixed. However, our mobile developer is currently away.

    My best advice is to use BLE Device monitor in the future as it is the most versatile OAD manager.

    Apologies for the inconvenience. 

  • OK thanks,

    My question was a bit different,  I wasnt informing about the known issue.

    I was asking how would my project be detected in the iOS App correctly, trying to emulate sensortag attributes.  

    Will be grateful if the mobile dev could look at this question when he returns, thanks

    In order to progresss I will be using the BLE Device Monitor to check download to a CC2650 as you suggested.

    I have a few questions

    1. Read in the BLE Dev. wiki section "Over-the-Air-Download (OAD) for CC2650 SensorTag"

    that bin files can be downloaded, but didnt see I could change the .hex filter to bin. Is this supported?. (I am using  version 2.1.2)

    2.If I have a super hex file(APP + STACK) that I have created what image type should I choose (0-4) in the Image Type drop down menu prior to download?.

    Thanks

    Tamir

  • Hi Tamir,

    1. It also appears that this wiki is incorrect. I will fix it, and also follow up with the BLE Dev Monitor developer

    2. Based on the STK code, it doesn't matter which image type you choose, so long as you are not depending on updating all of page 31 in flash. The STK baseloader will blindly load your entire new image into flash after it has verified it. See the Bim_safeStart function. Image type checking is only done in "safe" OAD configurations that use the BIM. Since, the STK baseloads, you shouldn't need to worry about it.

    Note the verifications performed on the new image are this:
    1. It will fit in flash (numBlocks < blocksAvail)
    2. Its version is higher than previous versions (newVer > curVer)
    3. Block count must be greater than 0

    The only time the STK app should use the img type is that it automatically assumes images of type 0 are valid regardless of version.
  • I catch the same issue in the OAD programs, So where is the place to set image type ?