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.

CC2540 128k with the new 1.3 BLE Stack

Other Parts Discussed in Thread: CC2540

Hey,

I tried to port a project run by a CC2540 128k from BLE 1.2.1 to BLE 1.3 but I didn't succeed. After following the porting guide everything compiles fine but the linker is unable to create the image showing the following error:

Linking
Error[e104]: Failed to fit all segments into specified ranges. Problem discovered in segment XDATA_N. Unable to place 2 block(s) (0xc02 byte(s) total) in 0xbd7 byte(s) of  
memory. The problem occurred while processing the segment placement command "-P(XDATA)XDATA_N=_XDATA0_START-_XDATA0_END", where at the moment of  
placement the available memory ranges were "XDATA:1329-1eff"
Error while running Linker

Project settings described below:

Device: CC2540F128.i51
Linker configuration: C:\Texas Instruments\BLE-CC254x-1.3\Projects\ble\common\cc2540\ti_51ew_cc2540f128b.xcl

Edit when I try to build SimpleBLEPeripheral with CC2540F128 workspace as suggested here http://e2e.ti.com/support/low_power_rf/f/538/p/235017/858661.aspx#858661 I get the following linker error:

Linking
Error[e16]: Segment SLEEP_CODE (size: 0x9 align: 0) is too long for  
segment definition. At least 0x1 more bytes needed. The problem  
occurred while processing the segment placement command  
"-Z(CODE)SLEEP_CODE=_SLEEP_CODE_SPACE_START-_SLEEP
_CODE_SPACE_END", where at the moment of placement the  
available memory ranges were "CODE:7ff8-7fff"
   Reserved ranges relevant to this placement:
   CODE:7ff8-7fff       SLEEP_CODE
   BIT:0-7              BREG
   BIT:80-97            SFR_AN
   BIT:a0-af            SFR_AN
   BIT:b8-c7            SFR_AN
   BIT:e8-ef            SFR_AN
   BIT:f8-ff            SFR_AN
Error while running Linker

Edit: A workaround for the second linker problem is described here http://e2e.ti.com/support/low_power_rf/f/538/p/235981/828065.aspx#828065 . Turns out it is related to the IAR Embedded Workbench version 8.20.1. Doesn't fix my initial linker error though.

Any advice is welcome

  • I'd like an answer on this as well. I am trying to get a bluegiga ble112a (which includes a cc2540 128k) to run a TI blue tooth low energy stack. I don't care which version as long as it's not buggy and works with iphone. Can someone please describe all the steps involved in getting the BLE samples (such as SimpleBLEPeripheral) to work with the cc2540 128k? The source code I have right now is in a directory called BLE-CC254x-1.3 so I do not know if I am looking at sources which require the 1.3 stack.

  • Hi guys,

    I didn't have any issue when compiling and linking the BLE Stack v1.3 SimpleBLEPeripheral CC2540F128 project with IAR 8.20.1. With the workaround you mentioned with hal_sleep.c.

    The XDATA warning is about, well, XDATA. Maybe you have too much memory reserved in variables to fit on the chip?

    To reproduce - hopefully, download the 1.3 stack, open <stack install>\Projects\ble\SimpleBLEPeripheral\CC2540DB\SimpleBLEPeripheral.eww in IAR 8.20, make the change suggested in http://e2e.ti.com/support/low_power_rf/f/538/p/235981/828065.aspx#828065 and compile.

    Best regards,
    Aslak 

  • Linking Error[e16]: Segment SLEEP_CODE (size: 0x9 align: 0) is too long for segment definition. At least 0x1 more bytes needed. The problem occurred while processing the  segment placement command "-Z(CODE)SLEEP_CODE=_SLEEP_CODE_SPACE_START-_SLEEP_CODE_SPACE_END", where at the moment of placement the  available memory ranges were "CODE:7ff8-7fff"    Reserved ranges relevant to this placement:    CODE:7ff8-7fff       SLEEP_CODE    BIT:0-7              BREG    BIT:80-97            SFR_AN    BIT:a0-af            SFR_AN    BIT:b8-c7            SFR_AN Error while running Linker   Total number of errors: 1 Total number of warnings: 0

  • Hi Joe,

    maybe you have fixed the error already but already mentioned the IAR compiler 8.20 has an anomaly with code generation in a specific case outlined in the link above. This shows itself by additional instruction being emitted as part of the halSetSleepMode.  The workaround is well documented already but I have outlined the fix below for you. This resolved the issue with IAR 8.20 and BLE Stack v1.3 at least - file is hal_sleep.c:

    #pragma optimize=none
    void halSetSleepMode(void)
    {
      // WARNING: DO NOT ADD ANY ADDITIONAL CODE; THIS IS A FIXED SIZED SEGMENT!
      //PCON = halSleepPconValue;
      asm("MOV      0x87,halSleepPconValue"); // workround for 8.20
      // Disallow waking ISR from running in order to give the highest priority to LL_PowerOnReq().
      EA = 0;
    }
     

    Hopefully this fixes your issue.

    Garry

  • Hi All,

    The issue has been communicated to IAR and will be fixed asap. Probably by a patch (8.20.1 presumably). In the meantime you can use the workaround. 

    Best Regards