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.

CC2640R2F: CC2640R2F

Part Number: CC2640R2F
Other Parts Discussed in Thread: BLE-STACK, CC2640, UNIFLASH

Hi,

I am working with a custom board without the 32Kh crystal !

I am working on a OAD project for this board.

I am having a hard time to get it to work :-(

I came across a strange issue...  when I add the ccfg_app_ble_rcosc.c file to my Persistent project

and compile it, no added switches or whatever ... The BLE stack fails to link due to insufficient space.

If I cannot build the project with RCOSC enabled I will not be able to connect to my board.

Stranger then that... if I compile my Persistent app without the ccfg_app_ble_rcosc.c is not and then compile 

the stack it will build properly.

Even more stranger then that, if I load the stack, add all that is necessary files to my persistent app to use RCOSC,

build it and load it I am able to connect to my board

Any ideas what is going on here ???

Thanks,

Noam.

  • Hi Noam,

    We have a chapter in the BLE-Stack User's Guide about using the flash memory the best way. Please see: dev.ti.com/.../creating-a-custom-bluetooth-low-energy-application.html
  • Hi Marie,

    Thanks for the advise. I will read the suggested chapter but I do not think this will help.

    The problem is not optimization but rather something else. I checked the code size for the persistent app (in the map file) and it did 

    not changed much. Actually I think it does not even come close to the limit.

    Actually if you add a file to the build but do not call any function the optimizer should not link any code, hence no change in code size.

    I was asking about what is in the added file (#include 's etc..)  that can causes the stack not to link.

    If I was not clear let me add some info. During the compile time the make process estimates the persistent application code size and as

    a result updates the Start address for the stack. Normally it is 0x13000 but in the case I have raised it is set to ZERO ?

    There is an error in the build process or something that is not documented.  I think read every post and document regarding to how to

    configure the CC2640 to work with crystal-less project but the problem I am facing is not mentioned anywhere. I took a en example code

    for OAD on chip project and only triad to add the must code for crystal-less setup, that's all...

    BR,

    Noam.

  • Please provide the following:
    1. SDK (e.g. simplelink_cc2640r2_sdk_1_35_00_33)
    2. BLE-Stack Version # (get this from docs/<component>/release_notes)
    3. IDE/Toolchain with version # (e.g. CCS 8.0 + TI ARM Compiler 18.1.1LTS, IAR 8.20.2):
    4. Clear steps to reproduce the build issue using TI SDK named above.
    5. Text file attachment of verbose build log.
    6. Attach linker file used if there are any changes from the default linker files included with the installer named above.
  • Hi,

    Per your request:

    SDK is simplelink_cc2640r2_sdk_2_40_00_32

    TI BLE-Stack 3.02.02.00

    Toolchain is either CCS 8.3 or 9.0

    How to reproduce:

    1. Compile all 4 projects, no problems !

    2. Add file ccfg_app_ble_rcosc.c to the persistent app project, do not not add anything else !

    3. recompile persistent app project, no size change noticed (in map)

    4. recompile stack project, now it fails on link time due to insufficient space.

    Excluding ccfg_app_ble_rcosc.c from persistent app project, do not not add anything else and recompile.

    Recompile stack project, now it compiles and link.

    I have found a way to overcome the above, something that I think TI should do:

    1. I have copied ccfg.c file to my local path.

    2. I have changed my local ccfg.c to be the same as ccfg_app_ble_rcosc.c

    3. I changed the include in ccfg_app_ble.c in the BIM project to include my local file and not the ccfg from the SDK

    4. I added USE_RCOSC define in my persistent and user app + all related code.

    Now all is compiling without linker problems in stack and I am able to run it all without the 32K crystal.

    however I do have another problem... when I load my application from the CCS environment I can run it and debug it

    but when I disconnect the launchpad and reset my own device my application is not called. All that I see in

    BLE sniffer is the persistent application ??

    Thanks,

    Noam.

  • Are you using matching versions of BIM and application? (debug / nondebug and secure / nosecure)?
  • Hi Tim,

    Yes I am using a matching version. I started my project based on TI OAD on chip example and continued from there...

    At the moment I have a functional project working without a crystal and without the the file ccfg_app_ble_rcosc.c.

    As I have written before I have modified the the BIM project and changed the file ccfg_app_ble.c to include my modified ccfg.c file and not

    the SDK own ccfg.c file. As all the parts of the OAD project uses the same CCFG it works just fine.

    I am not able to burn the application whatever I am doing. The only way it is burned is actually running the BTool and loading the application with OAD.

    I have triad to flash the application from the CCS IDE, i triad using Flash Programmer 2 and UniFlash... nothing so far worked for me. Is there a simple

    way to burn the production and/or test app ?

    BR,

    Noam.

  • There is a section in the User's Guide that describes how to make a production image: dev.ti.com/.../creating-a-production-image.html
  • Hi Tim,

    I have read that but for some reason could not make it.

    BR,

    Noam.

  • Can you provide more information about what step in the guide you are having problems with?
  • Hi Noam,

    is your issue solved?

    Looking forward to hearing from you soon

    best regards

    Karim

  • Hi Karim,

    This issue is not solved yet. I am straggling with something else that is more important.

    BR,

    Noam.