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.

CCS/LAUNCHXL-CC2640R2: OAD fails

Part Number: LAUNCHXL-CC2640R2

Tool/software: Code Composer Studio

Hi guys!!!

I have a problem with the update over the air. Using the program Btool, the firmware is successfully completed. We are developing a program for flashing through the air on the Android. 

Preparatory stages are successful, which are given in the manual. The block size is returned to 0x14. after the start of the update, we get the package: 0x12 0x09 0x04 0x00 0x00 0x00
When we send a block with index 4, we get an error: OAD_INCOMPATIBLE_IMAGE 9 Stack and flash boundary mismatch, program entry mismatch. How can we solve this problem?

  • Hello,

    I'm assuming you are using the same OAD binary with BTool as you are with your Android app. Since BTool is successful, it's likely to be something wrong with your parsing and transport of the metadata in your Android app. I would use a BLE air sniffer to see the differences between the known good reference (BTool) and your application.

    Best wishes
  • How can I make a sniffer out of the lunchpud cc2640r2 ?
  • We got logs from the android and BTool. We checked the metadata, and found no differences. 

    Metadata from Btool:

    -Type : 0x01 (Command)
    -OpCode : 0xFD96 (GATT_WriteLongCharValue)
    -Data Length : 0x1C (28) byte(s)
    ConnHandle : 0x0000 (0)
    Handle : 0x000E (14)
    Offset : 0x0000 (0)
    Value : 4F:41:44:20:49:4D:47:20:01:01:FF:FF:01:01:BD:91:
    00:00:30:30:30:31
    Dump(Tx):
    0000:01 96 FD 1C 00 00 0E 00 00 00 4F 41 44 20 49 4D ..........OAD IM
    0010:47 20 01 01 FF FF 01 01 BD 91 00 00 30 30 30 31 G ..........0001

    Metadata from Android:

    Master: Write characteristic f000ffc1-0451-4000-b000-000000000000 with value 4f 41 44 20 49 4d 47 20 01 01 ff ff 01 01 bd 91 00 00 30 30 30 31

     

    Android log:

    Master: In characteristic f000ffc5-0451-4000-b000-000000000000 in 00002902-0000-1000-8000-00805f9b34fb write 01 00

    Master: In characteristic f000ffc1-0451-4000-b000-000000000000 in 00002902-0000-1000-8000-00805f9b34fb write 01 00

    Master: Write characteristic f000ffc5-0451-4000-b000-000000000000 with value 01

    Slaver: Changed f000ffc5-0451-4000-b000-000000000000 send 01 14 00

    Master: Write characteristic f000ffc1-0451-4000-b000-000000000000 with value 4f 41 44 20 49 4d 47 20 01 01 ff ff 01 01 bd 91 00 00 30 30 30 31

    Slaver: Changed f000ffc1-0451-4000-b000-000000000000 with value 00

    Master: Write characteristic f000ffc5-0451-4000-b000-000000000000 with value 03

    Slaver: Changed f000ffc5-0451-4000-b000-000000000000 with value 12 00 00 00 00 00

    Master: Write characteristic f000ffc2-0451-4000-b000-000000000000 with value 00 00 00 00 14 4f 41 44 20 49 4d 47 20 2d 64 71 34 01 01 fe 00

    Slaver: Changed f000ffc5-0451-4000-b000-000000000000 with value 12 00 01 00 00 00

    Master: Write characteristic f000ffc2-0451-4000-b000-000000000000 with value 01 00 00 00 14 ff ff 01 01 ff ff ff ff bd 91 00 00 50 00 00 00

    Slaver: Changed f000ffc5-0451-4000-b000-000000000000 with value 12 00 02 00 00 00

    Master: Write characteristic f000ffc2-0451-4000-b000-000000000000 with value 02 00 00 00 14 30 30 30 31 bc 91 00 00 2c 00 ff ff 00 fe 00 ff

    Slaver: Changed f000ffc5-0451-4000-b000-000000000000 with value 12 00 03 00 00 00

    Master: Write characteristic f000ffc2-0451-4000-b000-000000000000 with value 03 00 00 00 14 18 00 00 00 00 a0 00 00 c9 20 01 00 08 04 00 20

    Slaver: Changed f000ffc5-0451-4000-b000-000000000000 with value 12 00 04 00 00 00

    Master: Write characteristic f000ffc2-0451-4000-b000-000000000000 with value 04 00 00 00 14 6c 3c 00 20 01 fe 00 ff 79 91 00 00 00 00 00 00

    Slaver: Changed f000ffc5-0451-4000-b000-000000000000 with value 12 09 04 00 00 00  

    We compare with the image from the manual and we all have the same actions:

  • We solved the problem by adding delay between the parcels.
  • How can I increase the size of blocks? At us now the full packet sends on 20 byte. How to get to 244?
  • Hi Heinrich,

    This can be done by performing an MTU Exchange and completing the Data Length Update procedure as shown in the sniffer capture you referenced. Your downloader must be capable of supporting larger MTUs in order to get to a block size of 244.

  • Thank you for your answer, more people like you on the forum who do not answer simply "read the documentation." Thank you.