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.

Linker error with latest bluetooth and IAR

Other Parts Discussed in Thread: CC2540, CC2541DK-MINI, BLE-STACK, Z-STACK, CC2530, CC2640, ADS1293, CC2541, TIDA-00096

Hello,

I just installed the latest BLE 1.4 and downloaded the IAR compiler. No choice but to use the latest version which is 8.30.1.

The linker fails when trying to build any of the projects. I notice this has happened before with IAR releases. This seems to be a different error than last time. The evaluation license does not let you download previous compiler releases.

Any ideas?

Linking
Error[e16]: Segment ISTACK (size: 0xc0 align: 0) is too long for segment definition. At least 0xe more bytes needed. The problem occurred while processing the segment placement command  
"-Z(IDATA)ISTACK+_IDATA_STACK_SIZE#08-_IDATA_END", where at the moment of placement the available memory ranges were "IDATA:4e-ff"
   Reserved ranges relevant to this placement:
   IDATA:8-1f           VREG
   IDATA:21-40          VREG
   IDATA:41-42          XSP
   IDATA:43-43          DATA_I
   IDATA:44-4b          DATA_Z
   IDATA:4c-4d          IDATA_Z
   IDATA:4e-ff          ISTACK
   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

Thanks!

  • I had the exact same problem and I just change the number of virtual registers from 16 to 8 

  • Thanks Luis, but that does not seem to work in this case.

    This is clean install of TI BLE 1.4.and IAR 8.30.1

    The virtual registers are set to 16 already in the options. And get this linker error:

    Error[e16]: Segment ISTACK (size: 0xc0 align: 0) is too long for segment definition. At least 0xe more bytes needed. The problem occurred while processing the segment  
    placement command "-Z(IDATA)ISTACK+_IDATA_STACK_SIZE#08-_IDATA_END", where at the moment of placement the available memory ranges were "IDATA:4e-ff"

    I tried doubling the # of virtual registers to 32 and it changes the error somewhat:

    Error[e16]: Segment ISTACK (size: 0xc0 align: 0) is too long for segment definition. At least 0x25 more bytes needed. The problem occurred while processing the segment  
    placement command "-Z(IDATA)ISTACK+_IDATA_STACK_SIZE#08-_IDATA_END", where at the moment of placement the available memory ranges were "IDATA:65-ff"

    Can someone at TI please suggest how to compile any of the projects?

    Thanks,

  • After a second reading.....changing the virtual registers to 8 (lowering from 16) allows SOME (not all) of the projects to compile.  Will now see if they continue to function.

    Thanks Luis

  • I had this same problem and fixed it by changing the istack size to 0xb0, not sure if it will cause the stack to overflow now.  Does anyone at TI test new releases before removing access to old releases?

  • Dear Chris,

    a change has been made within compiler/build chain that require change within TI project files in order for them to work well with IAR Embedded Workbench for 8051 version 8.30:

    The since 8.30 deprecated internal symbol “_NR_OF_VIRTUAL_REGISTERS” is not to be used any more within the XLINK linker command line extension files (.xcl)! This makes it necessary to change a line in the .xcl files that places the virtual registers (placed in a segment named VREG) to be changed as described below:

    What to look for in the old versions of the .xcl files is where virtual registers are placed:

    -Z(DATA)VREG+_NR_OF_VIRTUAL_REGISTERS=08-7F

     How it must look in 8.30 and later versions:

    -Z(DATA)VREG =08-7F

    This change needs to be made in the .xcl files used with EW8051 version 8.30 and later, otherwise errors such as the one you reported might start to occur. The simplest way to identify this error is when you in the XLINK error message finds two occurances of VREG placements, such as

    "...

       IDATA:8-1f           VREG

       IDATA:21-40          VREG

    ...

    Error while running Linker”

    The solution to get the stuff to fit into the idata area suggested by XLINK, to take down the size of the ISTACK is unfortunately of course a very risky thing to as such, and the solution is NOT to decrease the size of one of the run time stacks NOR decreasing the number of virtual registers to be used in the application. The solution is as I mentioned before instead to remove the deprecated linker command file symbol!

    Best regards

    /L

  • I have the same problem - but in all my sample projects the linker files are : lnk51ew_cc2530b_banked_rom_data.xcl lnk_banked_rom_data.xcl But they are missing! They should be in ..Projects\ble\common\cc2540 but are not - so I don't have any link files to edit as in the solution posted! Have these files been renamed - but the project files not updated or can I download these link files from somewhere. I am using the latest download for BLE1.4 and the current evaluation download for IAR (8.30.1) Best Regards Simon Taylor
  • Sorry Guys, I might be misleading you and myself here! The 2 'missing' xcl files I refer to in the previous post are in the project file - in the 'tools' directory. But I now see on looking in the project options - Linker, that the actual xcl file used is ti_51ew_cc2540b.xcl - which is not missing. So I do have an xcl file to put the recommended changes in for iar 8.30. Can someone confirm that the entries in the projects to the previously mentioned xcl files are actually not relevant ( i.e this is just a bit of bad housekeeping). Thanks Simon T
  • Did anyone find a solution to this problem?

    Siddharth

  • This works boss but what does this mean what is the number of virtual registers?

  • Dear Siddhart,

    the 8051 has only got 8 native memory mapped registers (r0-r7) (for sure in 4 register banks, but only 8 accessible at the time). To make better use of its very scarce HW resources that a C compiler needs in terms of space to use for register allocation, such as to be able to use register variables and also other compiler optimizations IAR have the concept of virtual registers (which is basically just yet another part of RAM) as a working space to be able to handle almost as cheap as the real machine registers.

    You find more information on Virtual Registers in IAR C/C++ Compiler User Guide (page 81 in 8.30 doc) .

    The change is merely that the size of VREG segment (which contains the virtual registers that the application uses) is now placed without the usage of the deprecated symbol to the linker, it is calculated by usage of other UBROF information. (You can still specify how many virtual registers you will use in the same manner as previously by changing "--nr_virtual_regs N" if you use command line build, or if you are using the IDE by changing 'General Options>Target>Number of virtual registers' list drop box value.)

    /L

  • first,you should find this file C:\Texas Instruments\BLE-CC254x-1.4.0\Projects\ble\common\cc2540\ti_51ew_cc2540b.xcl,open it and find "-Z(DATA)VREG+_NR_OF_VIRTUAL_REGISTERS=08-7F",please change it to "-Z(DATA)VREG=08-7F"

  • I wasn't able to make it work with

    Z(DATA)VREG=08-7F

    I had to add a "+0" after VREG as shown below before it would link.  I thought to add the "+0" since I was removing "+_NR_OF_VIRTUAL_REGISTERS".

    -Z(DATA)VREG+0=08-7F

    Otherwise, the linker complained that "=08-7F" file was not found.  I'm Using IAR 8.30.1 and have CC2541DK-MINI Kefob workspace selected.

    SM

  • Hi,

    As mentioned by Lars, IAR has in the 8.30.1 release changed the way virtual registers are handled and placed. This means that the linker configuration files must be changed as proposed in the aforementioned posts.

    On December 20th 2013, IAR released v8.30.2 with updated linker configuration files for Texas Instrument devices.

    From the IAR 8.30.2 release notes:
    This update corrects errors in the runtime libraries, and linker configuration files for Texas Instruments devices. When the installation is finished - run the License Manager application so that the runtime library installation (IAR Embedded Workbench for 8051 - Library Source) of the 8.30.1 release is removed and the new Library Source component for 8.30.2 is installed instead.

    Please note that libraries built with previous versions of IAR Embedded Workbench for 8051 need to be rebuilt to link correctly with an application built with version 8.30 of the compiler.

    From what I understand, this means that TI BLE 1.4 libraries are not compatible with IAR Embedded Workbench v8.30.2. 

    Br,
    TIABO

  • TIABO,

    Can you please confirm whether the TI BLE 1.4 libraries will work with IAR EW 8051 8.30.2?

    If the libraries need to be rebuilt, that should be trivial and probably already done internally. Hence, how do we obtain the new libraries that support IAR EW 8051 8.30.2? 

    Thanks,

    Mike

  • Hi Michael,

    As stated in the BLEv1.4 release notes; "All projects have been migrated from IAR v8.10.4 to IAR 8.20.2. In order to
    build all projects, be sure to upgrade to IAR v8.20.2."

    The libraries have been compiled with IAR v8.20.2 and we can't guarantee that newer versions of IAR will work 100%.

    Best Regards 

    Joakim

  • Can't someone at TI be bothered to change 1 line of code so the ble stack will compile? Why do you hide all previous versions of the ble stack if you won't maintain the current version?

  • Thank you, i have changed that line in ti_51ew_cc2540b.xcl and

    work perfectly.

    Regards

     

    Luis Valseca

     

     

  • So what do you recommend we do?

    1. stick with BLE stack 1.3.2 and IAR 8.11.4

    2. downgrade IAR to 8.30.1 and change the linker configuration files by hand

    3. use IAR 8.30.2 and await updated libraries from TI

    4. something else?

    thanks, Stuart

  • Thanks Luis...I just had the same issue and changing the setting helped

  • i was able to downgrade back to IAR 8.20.2 i believe.  Found here :http://www.iar.com/Products/Wireless-solutions/Tools-for-TI-wireless/

    I had to un-install and re-install but everything seems to work for now.  

  • I had the same issue with BLE stack 1.4 and IAR 8.30.3. I changed the number of virtual registers from 16 to 12, and it compiled.

  • I have just installed today the latest BLE-STACK from Ti and the latest eval 8051 from IAR version 8.30.3 from April 4th and I am having the same problem.

    I gather I should make this :

    -Z(DATA)VREG+_NR_OF_VIRTUAL_REGISTERS=08-7F

     How it must look in 8.30 and later versions:

    -Z(DATA)VREG =08-7F

    edit

    but I need to know which file.

    My linker Configuration File option points : $PROJ_DIR$\..\..\common\cc2540\ti_51ew_cc2540b.xcl

    but there is no such file.

  • Would you mind making a new post with your question? This thread is cluttered and OP never listed any answers as suggested or verified. 

    This post by IAR should give you some insight:

    http://supp.iar.com/Support/?Note=95811

  • The answer has been posted in 2 or 3 threads by now.  It blows my mind that TI hasn't fixed this yet.  Its 1 line of code, fix it!!

  • Hi Steven,

    In my case, I have observed that if there's a space before the '=' sign, the '"=08-7F" file was not found' will pop up. 

    <from ti_51ew_cc2540b.xcl>

    <from Build Window>

    But after getting rid of the space, it was linked successfully.
    -Z(DATA)VREG=08-7F

    Regards,
    Kristoffer

  • thank you, i had the same problem and the solution that you give work perfectly,

    regards

    Luis Valseca from Madrid , Spain

  • Hi,

    I have attached a linker file that should work with the latest IAR 8051. 

    Please replace your old linker file with this if you are not comfortable modifying the linker file yourself.

    Regards,
    Svend

    5355.ti_51ew_cc2540b.xcl

  • The solution that Lars gives is very likely NOT CORRECT. I followed Lars' solution, and it enabled me to link the application, but then when I ran it, I noticed a very strange bug. 

    I just spent the whole day debugging. It turned out that the bug was caused because the XSP register was mapped to the same memory location as the V15 register. Very likely this was caused because I changed this:

    -Z(DATA)VREG+_NR_OF_VIRTUAL_REGISTERS=08-7F
    -Z(DATA)PSP,XSP=08-7F

    into:

    -Z(DATA)VREG=08-7F
    -Z(DATA)PSP,XSP=08-7F

    as suggested by Lars. 

    I have no solution as yet for this problem.

  • This turned out to a combination of a bug in the IAR linker, and the fact that the TI libraries are too old for the current version of IAR. The linker does not recognise that V15 is used in one of the libraries. Therefore, it thinks it is not in use in the application, and the memory location can be used for XSP.

    I have made a work-around by not removing _NR_OF_VIRTUAL_REGISTERS from the *.xcl files altogether, but instead using:

    -Z(DATA)VREG+2=08-7F

    This tells the linker to allocate 2 extra virtual registers that it does not know about.

    But really, TI needs to update their libraries for the latest version of the tool (likely only a couple of hours of work), and/or IAR needs to fix this bug (probably a backward-compatibility problem).
  • Can anybody confirm that it is a correct/valid solution?
    (IAR only mentioned to change to -Z(DATA)VREG=08-7F)

    I presume this issue is specific to BLE-CC254x-1.4.0?
  • What more confirmation is there other than a published statement from the person who MADE the compiler? IAR acknowledged the problem and posted the solution. They even made the word solution bold and provided an explanation. Do you think IAR is lying?

  • Dear Sir,

    I greatly appreciated you taking your time to explain to me how stupid I am.

    Just to dig my hole deeper, I just wonder if you are referencing the same posting from IAR: Technical Note 95811

    (supp.iar.com/Support)?

    If so, could you please one more time, explain to me if I should use line
    -Z(DATA)VREG=08-7F
    vs.
    -Z(DATA)VREG+2=08-7F

    as it was referenced in one post and was the essence of my question in the first place.

    I look forward to your helpful, unkind response,
    Mikhail Galeev
  • I don't understand why the +2 was added. It seems like user4228845 is reserving 2 bytes of valuable DATA addresses for nothing. Your number of virtual register (VREG) is determined in your project options so I think the +2 option is a waste, not considered meaningful to IAR while compiling, and unused during run time.

    You'll have to excuse the bad manners. How happy do you get when trying to provide a clear answer, and the feed back is "Did you really mean that"?

    I am referencing that technical note that I posted earlier in this thread. (supp.iar.com/Support)

    TL;DR

    -Z(DATA)VREG=08-7F //is what you want

  • The evaluation version of IAR 8.10 is available for download from IAR.com. It should be compatible with BLE stack 1.4.0.

    https://www.iar.com/iar-embedded-workbench/texas-instruments/ti-wireless/

    Br,
    TIABO

  • Hi

    Im a beginner using IAR v9.10. i have downloaded source code from IAR. While compiling getting the Error
    "Error[e46]: Undefined external "?V1" referred in AF ( C:\Texas Instruments\Z-Stack Energy 1.1.0 - Copy\Projects\zstack\SE\SampleApp\CC2530DB\ESP - Coordinator\Obj\AF.r51 )
    ..
    Error while running linker
    ..


    Reducing the virtual registers to 8 from 16 allows SOME (not all) of the projects to compile.
    I also tried changing

    -Z(DATA)VREG+_NR_OF_VIRTUAL_REGISTERS=08-7F

    to

    -Z(DATA)VREG =08-7F

    Didnt help me..

    Can anyone help me..

    Thanks:)
  • That's a compilation error that doesn't involve your linker file.

    IAR is looking for something called V1 due to AF.c
  • Im getting 15 errors ..
    "Error[e46]: Undefined external "?V1" referred in AF ( C:\Texas Instruments\Z-Stack Energy 1.1.0 - Copy\Projects\zstack\SE\SampleApp\CC2530DB\ESP - Coordinator\Obj\AF.r51 ) "
    "Error[e46]: Undefined external "?V2" referred in AF ( C:\Texas Instruments\Z-Stack Energy 1.1.0 - Copy\Projects\zstack\SE\SampleApp\CC2530DB\ESP - Coordinator\Obj\AF.r51 )
    ..like this till V15...
  • Thanks I found solution.
    Refer below link, that may help others to solve the problem.
    supp.iar.com/Support;from=search+result
  • Please provide me the link to download the latest version of z-stack for cc2530..

  • Divyashree,

    Please start a new thread on unrelated questions so it is easier to find unanswered questions.
    The Z-Stack download page is the first search result on Zstack both on Google and on TI.com search. You can even press the link auto-generated on your own post for the download link.

    Best regards,
    Svend
  • Yes, IAR acknowledged the problem and posted a solution that does not work in all situations. The reason why the +2 is needed with the TI BLE stack was clearly explained in my original post, so please go back and reread that before you start to be abusive to people.

    You can use IAR's official new solution, as posted here by TIABO: to use the older 8.10 version of IAR with the TI BLE stack. (Note you will have to KEEP the "+_NR_OF_VIRTUAL_REGISTERS" part in that case).
    Or you can use my +2 work-around with the latest IAR version.

    But please do not go around second guessing answers without own experience in them.
  • I have just moved from v1.3 to 1.4 of the stack and updated my compiler from 8.20 to 9.3.

    What a bloody nightmare!!!

    Honestly, I really don't understand how the duty of maintaining compatibility between Compilers, the Stack and our Code becomes the developers "problem".

    I note that there are absolutely no TI or IAR members commenting on this topic.

    We as developers really should not be responsible for these kinds of problems.... And I'm getting sick of the lack of functionality in the IAR EW8051 environment. I can't even copy and paste the frigging Errors it has spewed at me to share with you guys, so that I can get some help.

    As I have said before, this whole BLE platform has been MONOPOLIZED between IAR and TI and there is absolutely nothing we can do other than to BEND OVER A BARREL and let them continue to SHAFT US.

  • Can anyone please point me to a well documented tutorial to explain how to configure the IDATA, PDATA and XDATA Stack and Heap sizes to suit the IAR EW8051 environment for the CC2540 ?

    Thank you in advance..
  • Hey Joe,
    I'm sorry to hear that you have to struggle so much to get your code ported. We are well aware of the challenges introduced with IAR having their own roadmap for their IDE. The R&D are trying their best to keep everything streamlined. We do have a porting guide on our wiki;
    processors.wiki.ti.com/.../LPRF_BLE_Porting_Projects
    Please let us know if we are missing some step and we'll add it. The IDE version for each of our releases are defined in the release notes. Going beyond these version might cause challenges which we haven't seen ourselves. That's what this forum is all about, to share problems and get help.

    If you are curious about other compilers (and newer/better Bluetooth Smart offerings) from us, please have a look at CC2640. It's ARM based and as of now we also support Code Composer Studio (CCS) and we have open source compilers support on the horizon.

    Have a nice day.

    Best Regards
    Joakim
  • Joakim,
    Thank you for this.

    I will visit the link and follow instructions to see if I can get back on track.

    I am delighted to hear to hear that there are other Compilers on the horizon.

    You might remember that Microchip Inc paved the way some time ago by introducing free compilers and other 'tools' for their MCUs and reaped the benefits by taking a significant share of the MCU market. At the end of the day, it makes sense for chip manufacturers to consider how designers are going to make use of their ICs, particularly when there is programming involved.

    I am working on a project based on the CC2540 that is going to be putting 100k units per annum on the market place plus there are other BLE projects on the horizon - and I'm just one developer.. Now when you think about the scale of sales for TI in this single case, what is the significance of the cost of a compiler to TI? You might ask what is the significance of it to you? Well I am just the engineer in the loop and I am paid a fixed rate for my contributions in all this. In my opinion, there should really be a budget in place to take care of the need for the developers' Compiler needs when giants like TI are designing their ICs. If this is not taken care of then embedded systems may too be heading down the Open Source route. Look what happened to Microsoft and many others with the advent of Linux..

    It is not that I have anything against IAR but when developers get stuck on something that is beyond their control (like the significant changes needed just because they need to update their compiler or stack), they are at the mercy of the vendors. In this instance I have been waiting for over two days for IAR to get back to me so that I can continue coding.

    If you look at the solution (in fact a "workaround" IAR suggests at netstorage.iar.com/.../workaround.s51 to a similar problem) there's no way any developer is going to come up with what is suggested there unless they know about the innards of the Compiler. So it is uncomfortable to be totally dependent on the Vendor particularly when they are charging a handsome ransom for this privilege.

    By the way, this forum is great and without it, I think most of might just throw in the towel and move on, may be to develop compilers rather than applications, which is where the money seems to be...

    At the end of the day, the developers' time is governed by their end customers who expect solutions in return for their investment and I have e-mails in my inbox waiting for an answer to when the next update to the firmware will be delivered so that the whole product development process is deemed to be making progress.

    Thanks again for your response. I really appreciate it.
    JB.
  • Joe,

    Thanks for providing your experiences on how it has been working with this.

    I just want to comment on the reasons for the decision we made on only supporting IAR on the 8051 devices.
    First of all it comes down to the need for certifying our BLE stack with Bluetooth SIG which is an extensive and costly job. This is a job we need to do for every compiler we support as we cannot provide the full stack as source due to the need for protecting TI's IP.

    Since our new CC2640 is ARM based we can now deliver a precompiled certified library which will work across all ARM compilers since ARM provides an application binary interface which all ARM compilers must conform to. This makes it much easier to support any compiler and currently we support IAR and CCS.

    For high-volume applications it is also worth noting that commercial compilers such as IAR and Keil (with all their quirks and bugs) generates much more efficient code which allows you to buy devices with smaller flash. Saving 10 cents on a million devices might in many cases be worth the pain of having to use them :]

    Best regards,
    Svend
  • I understand...

    I will certainly be taking a close look at the ARM Cortex based CC2640 for my next project.

    Keep up the good work!!

    ;-)
  • hI JOAKIM but where could we download the 8.20.2 ? and is that OK install two more version IAR in the same PC
  • This fixed my issues with compiling projects for TIDA-00096 (ADS1293 with CC2541), thanks!