• State Answer Suggested
  • Locked Locked
  • Replies 12 replies
  • Answers 1 answer
  • Subscribers 52 subscribers
  • Views 3878 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

CC2650 OAD - Wrong image type ! msg

Tamir Dali
Expert 1030 points

Other Parts Discussed in Thread: CC2650, CC2640, BLE-STACK

Hi,

During OAD I recieve message:

"Wrong image type !"

"Image that was selected was of type: B, which is the same as on the periperhal...."

 

Actions I took

1. Using SDK 2.1

2. My Project is branching out from SensorTag project.

3. Enabled FEATURE_OAD.

4. Downloaded hex file image via debugger to CC2650.

5. using options > Output Converter: Created another .bin file for download (gave this image a differnet internal sw version so I can check that download succeded)

6. tried downloading this image via SensorTag App

7. recieved the message above.

 

Questions

Do I have to specify the BANK somewhere prior to bin conversion?.

Have I missed something?.

Thanks in advance

Tamir

  • 0
    TI__Mastermind 33460 points
    Hi Tamir,

    The sensortag OAD method updates the entire internal flash image (128kB) including the interrupt vectors and the BIM/baseloader. In order to successfully use this OAD method, you must also include the BIM in the image. See this latest comment in this thread

    e2e.ti.com/.../1725976

    You need to follow the steps at
    processors.wiki.ti.com/.../CC2650_SensorTag_User's_Guide
  • 0 in reply to Sean2
    Expert 1030 points

    Thanks,

    Following the guide you mentioned. Still have open issues.

    I am using an external flash. Sorry didnt mention that in original post. (I am running on SensorTag, branching out of sensortag prj.)

    After reading a bit I cam across the OAD Users Guide doc, found section 9 - "Building Off-chip OAD".

    I think section 9.3 is what i should follow.

    Questions 

    Concerning building the image(step II in section 9.3):

    1. Are there any considerations I have to take into account specifically when specifying address ranges when creating OAD_IMAGE_FULL (part II in section 9.3) ?

    Should I consider using ICALL_STACK0_ADDR - 1 as the end address(marked in red ) when specifying App placement.

    "$PROJ_DIR$\FlashOnly_OAD_ST_ExtFlash\Exe\MyProject_OADExtFlash.hex":1000:EFFF

    2. Do I need to substitute(ICALL_STACK0_ADDR) : (FLASH_SIZE - RESERVED_SIZE - 1) when specifying stack placement(marked in blue)

    "$PROJ_DIR$\..\..\Stack\CC2640\FlashROM\Exe\MyProject_StackFlashROM.hex":F000:1CFFF.

    Why is it 0x1CFFF in the SimpleBLEPeripheral project?

     

    Concerning the error message.

    I have implemented the steps in section 9.3 on my project and keep getting the error.

    3. Could this error message be because I have first download the hex file via debugger (a configuration project with FEATURE_OAD enabled) 

    and then tried to download the same image but .bin file (coming from different configuration with all of section 9.3 implemented.) 

    The message says: "Image that was selected was of type : B, which is the same as on the peripheral, please select..."

    Thanks

    Tamir

  • 0 in reply to Tamir Dali
    TI__Mastermind 33460 points
    Hi Tamir,

    The guide you linked is written based on a newer OAD method that was adopted by the BLE SDK. For legacy reasons and for compatibility with other RF stacks, the sensortag uses a slightly different OAD method. I do understand that this is confusing, but you will not be able to use the linked guide because of these slight differences.

    The sensortag OAD method will update the entire contents of the internal flash (including the BIM/baseloader). This means that any OTA image prepared for OAD must be in .bin format and must contain the application, stack, and bin. You can merge these hex files and then convert to bin.

    Regarding your error from there the Sensortag user's guide (the only documentation provided for Sensortag OAD method), it states that imageID is always E for sensortag, can you try with this type?
  • 0 in reply to Sean2
    Expert 1030 points

    Hi,

    Sorry but I didnt understand your answer.

    Would like to recap:

    1. The guide that I am looking at is: Over-the-Air Download User’s Guide For BLE-Stack™ Version: 2.1.0. 

    2. I am running on a sensortag would like to add OAD support.

    3. From the Over-the-Air Download User’s Guide For BLE-Stack™ Version: 2.1.0. I think section 9 is what I have to implement.

    4. I have implemented section 9. Created the .bin file, Set HAL_IMAGE_E as specified and sent it to the sensortag app for download.

    5. Tried downloading and the message I recieve on the phone is:

     "Image that was selected was of type : B, which is the same as on the peripheral, please select..."

    My questions are:

    1. Is section 9 what I have to implement in order to support OAD?. If  the answer is yes then I have more questions.

     

     Concerning building the image(step II in section 9.3):

    2. Are there any considerations I have to take into account specifically when specifying address ranges when creating OAD_IMAGE_FULL (part II in section 9.3) ?

    Should I consider using ICALL_STACK0_ADDR - 1 as the end address(marked in red ) when specifying App placement.

    "$PROJ_DIR$\FlashOnly_OAD_ST_ExtFlash\Exe\MyProject_OADExtFlash.hex":1000:EFFF

    3. Do I need to substitute(ICALL_STACK0_ADDR) : (FLASH_SIZE - RESERVED_SIZE - 1) when specifying stack placement(marked in blue)

    "$PROJ_DIR$\..\..\Stack\CC2640\FlashROM\Exe\MyProject_StackFlashROM.hex":F000:1CFFF.

    Why is it 0x1CFFF in the SimpleBLEPeripheral project?

     Is it related to SNV?, What If I am not using SNV, should it be (FLASH_SIZE - RESERVED_SIZE - 1).

    Thanks

    Tamir

  • 0 in reply to Tamir Dali
    Expert 2915 points

    Hi Tarmin,


    spending a lot of time with OAD on the CC26xx family, I learned that the OAD User Guide for Stack 2.1 is not really made for howto using the original SensorTag app.

    As mentioned before, the SensorTag app OAD needs the full image including BIM+Stack+App. You did not mention the IDE you are using. IAR e.g. provides the .bin file while with CCS is a new TI utility available converting .hex files to .bin files.

    Using the TI SensorTag Android App for OAD this should work out of the box, like described in the SensorTag User Guide.

    If you want to follow the OAD User Guide you need to consider about the sample apps BIM + SimplelinkBLEPeripheral + SimplelinkBLEPeripheralStack

    This sample offers OAD for .hex AND .bin files and may confuse you using the SensorTAg app.


    Good luck

    Ralph

  • 0 in reply to Ralph Deffke
    Expert 1030 points

    Thanks Sean & Ralph.

    I finally understood.

    Sean sorry for my stubborness ;).

    The solution was what you were saying all along.

    I indeed created a superhex file with all the elements and converted it to a .bin file

    No need for any special offsets as spcecified in the OAD guide I was using.

    Didnt add any preprocessor values as specified in the OAD guide.

    I was succesfull in creating and downloading the .bin file but still have an open issue when trying to download again.

    I see the message:

    "Wrong Image Type !

    Image that was selected was of type : B, which is the same as on the peripheral, please select antother image."

    Setup:

    Using IAR IDE.

    Using the sensortag App for iOS for OTA download.

    I believe it is related to the fact that my image is somehow marked as  a factory image.

    On a clean TI sensortag with firmware image CC2650SensorTag_BLE_All_v1_20.hex when I OTA download my .bin file, it succeeds.

    Now my image is running.

    But when I try OTA download again with a new .bin file image the APP identifies the running image(mine) as a factory image and the OTA image as a factory image

    causing the APP to show the message and state that the files are the same, aborting the download.

    Question:

    Do you know how I specify the image I am creating is not a factory image. Like CC2650SensorTag_BLE_All_v1_20.hex

    I think this would workaround the issue with the TI sensorTag APP (currently the only APP I have to test download.).

    I thought it would be in dev info or maybe a preprocessor value exits.

    Thanks

    Tamir

  • 0 in reply to Tamir Dali
    Expert 2915 points
    Hi Tamir,

    I have not worked with your scenario but may be I can point you in the right direction.

    At least, the OAD Guide is not too far away from the OTA of SensortTag. And both concepts are similar in using the image header. If you refer the OAD guide for the Meta Data header, you will find a version number in the header data.

    If you debug the firmware (oad.c) you will find that the LSB (bit) of the version number should be different then the one from the current image running OR 0 (Zero). If the version number is 0 any image will be áccepted.

    So if you OTA an image successfully once and you can not download the image a second time, the reason is that it has got the same version number.

    So I suggest that you find out how the version number is set and set it to zero. Then you should be able to OTA the same image as often as you want.

    Sorry I can not help you how the mety data header is managed using IAR. But IAR should create the .bin directly from what I have seen in the docs. I use CCS.

    I am pretty sure that the Version number of the image is what you have to cure.

    I hope this helps

    Ralph
  • 0 in reply to Ralph Deffke
    TI__Mastermind 33460 points
    Hi Tamir,

    Ralph has given you some great pointers.

    Can you explain in more detail how you are converting the super hex to .bin and how you loaded the image into your sensortag app?

    It is the sensortag app that generates the meta data header for the OAD image, there should be a way to force override (where it will generate meta data that will be sure to be downloaded)
  • 0 in reply to Ralph Deffke
    Expert 1030 points

    Thanks again Ralph,

    I see what you meant in oad.c: OADTarget_validateNewImage

    I have read that the TI App(Downloader) is the one incharge of preparing the metadata for off-chip flashes.

    When I downloaded my image to a sensortag running a clean version 1.2(version from SDK2.1, debugger connected), It realy identified that the new image being downloaded is version 0. And download proceeded successfully.

    When I tried simulating a downloaded again to my now running image(debugger connected to the source code), image version verified in OADTarget_validateNewImage was no longer 0.
    How can this be?

    I think the specific issues I am seeing are related to how the TI App interacts with the image I created.
    Seeing it as an old FW Factory image and thus behaving in some kind of predefined way.
    Maybe looking fro version offsets elsewhere, not as expected.

    Thanks again

    Tamir

  • 0 in reply to Sean2
    Expert 1030 points

    Hi Sean,

    Didnt see your post, prior my post to Ralph.

    1. I am creating the super hex using: Python hexmerge and hex2bin as explained in the wiki CC2650_SensorTag_User's_Guide, but also adding the BIM as you pointed out (the wiki is missing this).
    Note: I havent added any preprocessor vars as described in the OAD doc.(vars like HAL_IMAGE_E
    SENSORTAG_HW) Since I understand that I shoudlnt follow the explanation there.
    I only merged my hex files and converted to bin starting from FLASH 0x0000.

    python "C:\Python27\Scripts\hexmerge.py" -o "%1\FlashOnlyOAD\Exe\OAD_FULL_IMAGE.hex" -r "000:1FFFF" --overlap=error "%1\FlashOnlyOAD\Exe\SensorTagAppFlashOnlyOAD.hex":0000:1EFFF "%1\..\..\Stack\CC2650\FlashROM\Exe\SensorTagStackFlashROM.hex" "%1\BIM_ext.hex":1F000:1FFFF && "c:\Python27\Scripts\hex2bin.py" "%1\FlashOnlyOAD\Exe\OAD_FULL_IMAGE.hex" "%1\FlashOnlyOAD\Exe\NewDiscovery.bin"



    2. Downloading the bin file - I am sending it to myself via mail and then opening it via the sensorTag App.

    3. Using IDE IAR. Upgraded to iOS TI App 4.4

    4. As you said the the App generates the Meta data. How do I force it to download?. On what is it keying on in my image and where?.

    I think that the errors I am seeing are because my image is identified by the TI APP as a Factory image.

    In the TI OAD profile screen I see the "Image Type" field, with: Factory 

    and I believe this defines the download behavior of the App.



    For the first OTA download:

    Target running: CC2650SensorTag_BLE_All_v1_20.hex 

    Downloading: My Image

    Result: Success

    For the second OTA download:

    Target running: My image

    Downloading: My image

    Result: Failure, encounter the Wrong Image Type etc.. Message

    I think that if I could somehow force the TI APP to not see me as a factory image then I would be able to download images. The TI App would behave differently. As I stated this is the only APP I have for testing if my integration of OTA is functioning.

    Question

    What should I change in my code so the TI sensortag APP doesnt see me as a Factory Image.? On what is it queing?.



    Thanks

    Tamir

  • 0 in reply to Tamir Dali
    Expert 2915 points
    Hi Tamir,

    once you scored the verify image block in the source, why you are not just skip that piece of code and discard the image validation part for now?

    In your final solution you will have your own app anyway, isn't it ?

    Best wishes

    Ralph
  • 0 in reply to Ralph Deffke
    Expert 1030 points

    Thanks Ralph

    But I think it is related to the TI APP seeing my image as a factory image. Causing it to behave as it does,
    no matter what image I try to download, when my running image is recognized as a Factory image
    the error message is seen.

    Anyway, I tried what you suggested, commented the code but am still seeing the error message.

    Maybe I will open a new post, to shorten this thread.

    Regards


    Thanks