• State Resolved
  • Locked Locked
  • Replies 31 replies
  • Subscribers 54 subscribers
  • Views 2639 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.

Simple Peripheral OAD not working

taneka fields
Intellectual 620 points

Other Parts Discussed in Thread: CC2640

We are trying to test the simple_peripheral_em example off chip OAD via CCS.  We added our board files to the code, compiled, and downloaded the FlashRom image to our custom board.  when we power our board, the board advertises SimpleBLEPeripheral.  Great.  Next, we create the FlashOnly_OAD_ExtFlash image by following the steps in the OAD User Guide section 8.4 using the exact same code.  We run the merge.bat file to create the _all and _stack_oad hex files.  the files are created successfully.  Next, we download the simple_peripheral_cc2650em_app_stack_oad.hex file to our custom board.  when we power up the board, the board no longer advertises.  when we go back to the flashRom image, the board advertises again.  Please help.  

  • 0
    Intellectual 620 points

    Hi TI.  We used the simple_peripheral ble 2.2 example and merged our code into it.  We can compile and run our code succesffuly with FlashRom.  We are now attempting to compile our code for OAD.  When we switch our build to FlashOnly_OAD_ExtFlash, the compiler complains that our code no longer fits into memory.  when analyzing the map file, we noticed that the flash length for our app no longer matches the example map file.  for both projects, the flash begins at 0x1010 as described in cc26xx_app_oad.cmd.  For the example, the flash length is 0x1dff0 (0x2000 - (2*0x1000) - 0x10) as described in cc26xx_app_oad.cmd.  for our app, the flash length is only 0xe010.  We cannot figure how to fix this issue.  We have tried forcing FLASH_OAD_IMG_MAX_LEN to 0x1dff0, but the map file remains unchanged and the compile error persists.

  • 0
    Intellectual 620 points
    We were able to address this issue and our OAD app compiles. Next, we try to use the merge file to create the super hex files. We see the message "data overlapped at address 0xf000". the _stack_oad.hex and _all.hex files are never created.
  • 0 in reply to taneka fields
    Intellectual 620 points
    From further testing, we enabled FEATURE_OAD into our FLASH_ROM app just to be sure that we fit within the 0xf000 space allowed for the application. We fit with 0x29e of flash to spare. Unfortunately, when we take this same code and use the FlashOnly_OAD_ExtFlash build, it appears the app no longer fits according to the merge.bat. Is there anything we can do to address this issue? We planned to use the OAD Off chip implementation which is why we migrated to BLE 2.2.
  • 0 in reply to taneka fields
    TI__Genius 10980 points
    Hi,

    Can you describe how you were able to address the initial issue? And can you provide any details to recreate the issue?

    -Nathan
  • 0 in reply to Nathan Siegel
    Intellectual 620 points
    we switched back to FlashROM and continued to develop. Upon switching back to FlashOnly_OAD_ExtFlash, we made changes to FLASH_OAD_IMG_MAX_LEN within c26xx_app_oad.cmd. This time the changes took effect. We backed out our modifications and rebuilt the project. We are now seeing the correct length in the map file.
  • 0 in reply to taneka fields
    TI__Genius 10980 points
    To confirm, are you still seeing any issues?

    -Nathan
  • 0 in reply to Nathan Siegel
    Intellectual 620 points
    Yes. we are still unable to get the merge.bat file to work. We migrated to BLE2.2 to take advantage of the external flash for OAD as our code consumes most of the available flash. Now, that the migration is complete, we are ready to configure our app for OAD. Because we require bonding, our app flash range is 0xf000 in FlashRom mode. We have few bytes to spare. However, we fit. We are following the "Over the air Down user's guide". We added applicable files and compiled our code using cc26xx_app_oad.cmd instead of cc26xx_app.cmd. we also built the bim app for cc2640. Next, we are trying to run merge.bat to create the OAD files. Here, we are stuck as we receive the error "data overlapped at address 0xf000" when running the file. Digging into the merge file, the app no longer has full use of the 0xf000 flash space. Instead, we are limited from 0x1000 to 0x1dfff. We are only interested in placing the application image to external flash. it is unclear how to move further. we cannot reduce our code down to fit within the OAD external boundaries.
  • 0 in reply to taneka fields
    Intellectual 620 points
    So that we can continue to understand OAD, we disabled gap bond manager and set osal_snv=0 in our stack to gain an additional 8kb of code. we then rebuilt our app in flashRom mode and ensured the length increased from 0xf000 to 0x11000. it did and the application continued to work as expected minus pairing/bonding. At this point, we have 0x2cac free in flash space and are only using 0xe354. We, then, switched the mode to FlashOnly_OAD_ExtFlash and recompiled. the map file is reporting that the app is using 0x10842 (an increase of 0x24ee) with only 0xd7ae free. Now, running the merge reports "data overlap at 0x11000". How can this be? Can TI please assist?
  • 0 in reply to taneka fields
    TI__Mastermind 25035 points
    Hi,

    When you switched the mode to FlashOnly_OAD_ExtFlash, did you recompile the stack and then app? Can you verify in the map file that it is using memory past address 0x11000?

    Best wishes
  • 0 in reply to Zahid Haq
    Intellectual 620 points
    yes. we recompiled the stack after disabling the gap bond manager and setting osal_snv=0. we, then, recompiled our app in flashrom mode to ensure the application worked before transitioning to FlashOnly_OAD_ExtFlash. We noticed that no matter the stack size (0xf000 or 0x11000) the map file for the FlashOnly_OAD_ExtFlash application always has the flash origin of 0x1010, length of 0x1dff0, unused of 0xd85a. We also compared the application map files for the simple_peripheral example for both flashrom and FlashOnly_OAD_ExtFlash modes. The used flash increased by 0x30fa. With this increase in flash size simply to enable OAD, it appears that we may not be able support this feature as we cannot afford to lose this amount of flash space. Please advise.
  • 0 in reply to taneka fields
    TI__Mastermind 25035 points

    It looks like your application has reached the flash limitation in our current CC2640 device. We plan to release a version of this device with more flash space available for the application. Please contact your local TI FAE representative for sampling timeline.

    Also to save more space in the stack, some features can be removed by commenting it out from the build_config.opt file under TOOLS folder:

    /* Include GAP Bond Manager */

    /*-DGAP_BOND_MGR*/

    /* BLE v4.1 Features */

    /* -DBLE_V41_FEATURES=L2CAP_COC_CFG+V41_CTRL_CFG */

    /* -DBLE_V41_FEATURES=L2CAP_COC_CFG */

    /* -DBLE_V41_FEATURES=V41_CTRL_CFG */

    /* BLE v4.2 Features */

    /* -DBLE_V42_FEATURES=SECURE_CONNS_CFG+PRIVACY_1_2_CFG+EXT_DATA_LEN_CFG */

    /* -DBLE_V42_FEATURES=SECURE_CONNS_CFG+PRIVACY_1_2_CFG */

    /* -DBLE_V42_FEATURES=PRIVACY_1_2_CFG+EXT_DATA_LEN_CFG */

    /* -DBLE_V42_FEATURES=SECURE_CONNS_CFG+EXT_DATA_LEN_CFG */

    /* -DBLE_V42_FEATURES=SECURE_CONNS_CFG */

    /* -DBLE_V42_FEATURES=PRIVACY_1_2_CFG */

    /*-DBLE_V42_FEATURES=EXT_DATA_LEN_CFG*/

    You can try removing GAP Bond Manager (pairing and bonding), BLE 4.1 features (simultaneous master/slave role) and BLE 4.2 features as shown above based on your application requirements.

    Best wishes

  • 0
    TI__Genius 10980 points
    Hi,

    When using FlashOnly_OAD_ExtFlash, make sure that BIM has been flashed on the device, and that BIM and stack are both flashed before the app image is. If BIM was not correctly flashed on the device, then that would explain why it advertises with the flashRom image but not the FlashOnly_OAD_ExtFlash image.

    -Nathan
  • 0 in reply to Zahid Haq
    Intellectual 620 points
    Hi Zahid. Thanks for the reply. In our build_config. opt, we only have "DHOST_CONFIG=PERIPHERAL_CFG", "DGAP_BOND_MGR", and "DHCI_TL_NONE" enabled. all other options are disabled. We tried to remove the gap bond manager and set OSAL_SNV=0 to gain another 8k of space. When we run the merge file with our updated stack, the error message becomes "data overlap at 0x11000" instead of the previous error of "data overlap at 0xf000". I can only assume that even with the additional 8k, the app is still over the limit. Please confirm our thinking.
  • 0 in reply to taneka fields
    TI__Mastermind 25035 points
    Hi,

    Can you attach your app and stack map files here to confirm?

    Thanks
  • 0 in reply to Zahid Haq
    Intellectual 620 points

    Hi Zahid. i have attached a zip file that includes our application flashrom image; our app and stack FlashOnly_OAD_ExtFlash images when we have gap bond manager and osal_snv=1; and our app and stack FlashOnly_OAD_ExtFlash images when we disable gap bond manager and set osal_snv=0. Thansk again for your help.map_files.zip

  • 0 in reply to Nathan Siegel
    Intellectual 620 points
    Hi Nathan. we have been unsuccessful in getting the FlashOnly_OAD_ExtFlash images to work. To discount our code completely, we followed the example as stated in the OAD user guide and used simple_peripheral_cc2650lp with no code changes. We compiled the stack and application in the flashrom configuration. When we power up our custom board, the board advertises as SimpleBLEPeripheral. We can connect to the board. Upon disconnecting, the board goes back to advertises indicating proper operation. Now, we begin following the user guide starting at 8.2. (1)We compile the BIM and download it to the board. (2a)We compile the application flashrom image and download it to the board. (2b)We compile the application FlashOnly_OAD_ExtFlash image and download it to the board. (3)we run the merge file to create the _all and _stack_oad hex files. we download the simple_peripheral_cc2650lp_app_stack_oad.hex file to the board. We power cycle the board and the board fails to advertise. We tried downloading the simple_peripheral_cc2650lp_all.hex file. After power cycling the board, the board fails to advertise. At this point, it is not clear what the issue is as the code is Out of the box with no code changes. If we download the flashrom image, the board advertises again. Please advise.
  • 0 in reply to Zahid Haq
    Intellectual 620 points

    Hi Zahid.  as previously mentioned, we have tried disabling gap bond manager and setting osal_snv=0 to gain an extra 8k of flash.  unfortunately, we still receive the error message "data overlapped  at address 0x11000".  i have enclosed our map files for when we enabled gapbondmgr and osal_snv=1; map file for our flashrom image; and map file for when we disable gapbondmgr and osal_snv=0.  At this point, we are simply trying to determine if OAD is even possible with our current application.  Please advise.8304.map_files.zip

  • 0 in reply to taneka fields
    TI__Genius 10980 points
    Hi,

    You do not seem to be following the guide correctly. While setting up the device for OAD, it should never be flashed with the flashRom image. Build and download BIM, build and download cc2650lp_stack, and then build and download cc2650lp_app – FlashOnly_OAD_ExtFlash.

    -Nathan
  • 0 in reply to taneka fields
    TI__Intellectual 2285 points
    Hello,

    I looked at the app_gap_osal_1.map and stack_gap_osal_1.map files together.

    For the app,
    The flash length is defined as 1dff0 (close to 122864) and the used portion is 1074e (67406)
    For the stack,
    The flash length is defined as 1f000 (126976) and used portion is fc60 (64608).
    But here, more importantly, the load origin for the stack is set to f000 (61440). This will overlap with the used portion of your app (as per above).

    Similarly, for the no_gap_no_osal:

    App defined as length 1dff0 and used space is 1074e
    Stack load origin at 11000.
    This should be ok – since 11000 is over the 1074e.
    But this is causing your merge to fail with a overlap at 11000 error. (per your comment).

    I analyzed our examples (just took simple_peripheral) and noted the following:
    In the app, the flash length is defined as the end of usable app space and the start of the stack space. See bold and highlight below.

    For Simple_peripheral_app:
    ******************************************************************************
    TI ARM Linker PC v15.12.3
    ******************************************************************************
    >> Linked Fri Nov 04 12:08:22 2016

    OUTPUT FILE NAME: <simple_peripheral_cc2650lp_app.out>
    ENTRY POINT SYMBOL: "ResetISR" address: 00004e5d


    MEMORY CONFIGURATION

    name origin length used unused attr fill
    ---------------------- -------- --------- -------- -------- ---- --------
    FLASH 00000000 0000f000 00007b6c 00007494 R X
    FLASH_LAST_PAGE 0001f000 00001000 00000058 00000fa8 R X
    SRAM 20000000 00004368 00002189 000021df RW X

    For simple_peripheral_stack:
    ******************************************************************************
    TI ARM Linker PC v15.12.3
    ******************************************************************************
    >> Linked Fri Nov 04 12:02:38 2016

    OUTPUT FILE NAME: <simple_peripheral_cc2650lp_stack.out>
    ENTRY POINT SYMBOL: "startup_entry" address: 0000f001


    MEMORY CONFIGURATION

    name origin length used unused attr fill
    ---------------------- -------- --------- -------- -------- ---- --------
    FLASH 00000000 0001f000 0000fc53 0000f3ad R X
    SRAM 20000000 000048e7 0000057c 0000436b RW X


    SEGMENT ALLOCATION MAP

    run origin load origin length init length attrs members
    ---------- ----------- ---------- ----------- ----- -------
    0000f000 0000f000 0000ec53 0000ec53 r-x


    Can you try modifying your app flash size to 11000 and see if the merge fail still occurs?

    regards,
    Prasanna.
  • 0 in reply to PRS
    Intellectual 620 points
    Hi Prasanna. thanks for helping. the map zip contains five map files.
    (1)the flashrom image map file. This map file has the boundary of 0x0 to 0xf000. the boundary is 0xf000 because our stack using gapbondmgr and osal_snv=1. We included this file to show that our app uses 0xe318 of flash in flashrom mode.
    (2-5)The other four map files are for FlashOnly_OAD_ExtFlash images with gapbondmgr/osal enabled/disabled. in FlashOnly_OAD_ExtFlash mode, the application range is 0x1010 to 0x1dff0 (20000h-2*1000h-10h) as set by cc26xx_app_oad_cmd. In this mode, the app seams to miraculously grow to 0x1074e. We don't believe the OAD code adds such a significant amount to our application code. We believe this is the root issue.

    looking at the simple_peripheral_lp.out file the flash length is 0x0 to 0xf000. this looks like flashrom mode and not FlashOnly_OAD_ExtFlash. please advise.

    We upgraded our compiler to 5.2.6 as instructed in the original BLE v2.2 port guide. Now, it reads compiler should b 5.2.7. We will update our compiler as well to the latest of 15.12.3 and retest.
  • 0 in reply to Nathan Siegel
    Intellectual 620 points
    Unfortunately, we remain stuck.

    Step A. We have reverted back to the flashrom image of simple_peripheral. this software works on our board. it advertises and we can connect and query characteristics. we added FEATURE_OAD to the predefined symbols, added {SRC_EX}/profiles/oad/cc26xx to the search path, added ${CG_TOOL_HEX} -order MS --memwidth=8 --romwidth=8 --intel -o ${ProjName}.hex ${ProjName}.out to build steps, added oad.c, added oad_target_external_flash.c, and added Middleware. After recompiling, the OAD enabled code works on our boards. we are able to see the new OAD characteristics (0000fff0-0-1000-8000-00805f9b36fb and f000ffc0-9451-4000-b000-0). We can connect and query characteristis.

    Step B. Now, we add NO_ROM=1,OAD_IMG_E=1, disable cc26xx_app.cmd, and enable cc26xx_app_oad.cmd. We recompile the code. We use the SmartRF Programmer2 to download the BIM (.../ble_sdk_2_02_00_31/examples/util/bim_extflash/cc2640/ccs/FlashOnly_LP/bim_extflash.hex). We use the SmartRF Programmer2 to download simple_peripheral_cc2650em_app.hex. At this point, the board no longer advertises.

    Next, we try to debug the code via CCS6 debugger. We set a breakpoint in SimpleBLEPeripheral_processStateChangeEvt() and watch the "newState" variable . The debugger stops in SimpleBLEPeripheral_processStateChangeEvt() and newState == GAPROLE_STARTED. We continue the debugger. The debugger stops again in SimpleBLEPeripheral_processStateChangeEvt() and newState == GAPROLE_ADVERTISING. However, when we run our BLE scanner, the board is not found. this appears to be the issue. according to the OAD user guide, there are no changes to the stack compiling methods. We continue to use the flashrom image of the stack. Why would the advertising stop? the code worked find before we executed step B. If anyone has overcome this issue, please advise. we have spent a couple of weeks on this issue with no success.
  • 0 in reply to taneka fields
    TI__Genius 10980 points
    Hi,

    You should be able to use the FlashOnly_OAD_ExtFlash configuration instead of all of the changes that you made. In order to ensure that it will work, please start from scratch and use these steps exactly:

    1: Build and download BIM
    2: Build and download the stack
    3: Build and download the FlashOnly_OAD_ExtFlash app

    In order to make sure that you are not overwriting anything, make sure that you re-download the stack before flashing the device with the FlashOnly_OAD_ExtFlash app.

    -Nathan
  • 0 in reply to Nathan Siegel
    Intellectual 620 points

    Hi Nathan.  we tried the steps exactly on our lauchpad hardware and we still see the same issue.  After pressing the reset button, the board fails to advertise.  Before flashing, the launchpad advertised as "C2650 LaunchPad" so we know the hardware works. i have to assume there is a problem with how we are compiling since the code has not been changed at all.  we are using CCS 6.1.3.00034.  We are using compiler v15.12.3.  We have also tried compiler version 5.2.6.  i have enclosed the build files for the BIM, app code and app build files, and stack code and build files.  We tried performing a force mass erase to clear the previous launchpad software before beginning the steps.  Same issue of the board failing to advertise.  At this point, we are frustrated and at a loss.  Please advise.bim_extflash.zipsimple_peripheral.zip

  • 0 in reply to taneka fields
    Intellectual 620 points
    Hi Nathan, when you test the simple_peripheral_cc2650lp_app on your launchPad, do your files match what we have enclosed? Can you send us your related OAD hex files for bim, stack, and flash so that we can compare? Are you using CCS or IAR?
  • 0 in reply to taneka fields
    TI__Genius 10980 points
    Hi,

    We were able to recreate your issue. When we use the simple peripheral project straight from the sdk, we have no issues getting it to advertise, but when I used your files I can see the issue. Your simple_peripheral_cc2650lp_app_linkInfo.xml file is different, and it looks like the linker is causing part of the stack image to be overwritten. What are you doing that is changing this file? The length of the flash memory according to the map file is 0001dff0, which conflicts with the stack.

    -Nathan
  • 0 in reply to Nathan Siegel
    Intellectual 620 points

    Hi Nathan.  Thank you for continuing to dig into this issue with us.  When using FlashOnly_OAD_ExtFlash mode, the OAD user's guide says to exclude cc26xx_app.cmd and include cc26xx_app_oad.cmd as the linker file.  Inside cc26xx_app_oad.cmd,  the FLASH_OAD_IMG_START starts at FLASH_APP_BASE + FLASH_OAD_IMG_HDR_SIZE (0x1000+0x10) or 0x1010 as shown in the map file.  the FLASH_OAD_IMG_MAX_LEN ends at FLASH_LEN - (2 * FLASH_PAGE_LEN) - FLASH_OAD_IMG_HDR_SIZE (0x20000-(2*0x1000)-0x10) or 0x1dff0 as shown in the map file.  We have not made any changes to the linker file.  Please advise if we should hardcode the FLASH_OAD_IMG_MAX_LEN as the one provided does not seem to work.

    cc26xx_app_oad.cmd

    #ifndef FLASH_APP_BASE

    #define FLASH_APP_BASE 0x00001000
    #endif /* FLASH_APP_BASE */

    #define FLASH_OAD_IMG_HDR_SIZE 0x10
    #define FLASH_OAD_IMG_START FLASH_APP_BASE + FLASH_OAD_IMG_HDR_SIZE
    #define FLASH_OAD_IMG_MAX_LEN FLASH_LEN - (2 * FLASH_PAGE_LEN) - FLASH_OAD_IMG_HDR_SIZE

    #define FLASH_LEN 0x20000
    #define FLASH_PAGE_LEN 0x1000

    /* RAM starts at 0x20000000 and is 20KB */
    #define RAM_APP_BASE 0x20000000
    #define RAM_LEN 0x5000
    /* RAM reserved by ROM code starts. */
    #define RAM_RESERVED_OFFSET 0x4F00 

  • 0 in reply to taneka fields
    TI__Guru** 105180 points

    Hi taneka,

    Further to Nathan's observation, the issue you are experiencing is related to incorrect linking, or more specifically, not including the ccs_linker_defines.cmd file during the build / link process. This condition is resulting in incorrect (overlapping) SRAM addresses with the stack's ROM which manifests in the inability to Advertise.

    In the \simple_peripheral\ccs\app\FlashOnly_OAD_ExtFlash\makefile you should see the following:

    ORDERED_OBJS += \
    "C:/ti/simplelink/ble_sdk_2_02_00_31/examples/cc2650lp/simple_peripheral/ccs/config/ccs_linker_defines.cmd" \
    "C:/ti/simplelink/ble_sdk_2_02_00_31/src/common/cc26xx/ccs/cc26xx_app_oad.cmd" \

    However, in your makefile, the line containing the ccs_linker_defines.cmd is not present. This causes the cc26xx_app_oad.cmd to select incorrect linker values for flash and SRAM. I'm not sure why this is occurring as there is a known issue with CCS 6.1.x which results in reversed link order, however, the file is always present.

    In any event, applying the link order workaround from the "Known Issues / Workarounds for BLEv2.2.0" section of the Porting Guide found on the TI BLE Wiki should address this condition by manually inlining the ccs_linker_defines.cmd file.

    Best wishes

  • 0
    Prodigy 70 points

    Make sure you have the legal product, the pirate one's flash is not working.

  • 0 in reply to KaikaiWang
    Intellectual 620 points
    Hi JXS. thank you kindly!!!! Looks like we followed the porting guide for the flashrom version. however, for flashonlyoad_extflash, we missed adding "-l ccs_linker_defines.cmd" to cc26xx_app_oad.cmd. Now the launchPad board is advertising. Thanks again Nathan and JXS!!