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.

  • TI Thinks Resolved

Open Source Compiler for CC2540


Is there any open source compiler available for CC2540? We have a small project where we would like to use CC2540 but it is not big enough to justify buying the IAR Workbench.

Best Regards,


  • In reply to Roland King:

    I haven't used it in a while now, but it used to run in VMWare but wouldn't compile.
    The IAR team said you have to purchase for VM support.

  • In reply to Roland King:



    I purchased the IAR compiler and it does work with Parallels... I had to install an "older" ver (8.10.4) though - the most current ver apparently doesn't work in a VM...



  • In reply to Earl Van Wagoner:

    This is a complete mess! And it is TI's fault, in the next round I will take this into account when selecting the chip-sets.

    I asked the IAR sales that I want to run it under Linux (compiler is all  I care because TI has forced us to use theirs to use BLE), and it was suggested to me to run it under Wine.

    Well, Wine is Ok, at least with Wine I could write scripts to automate compile and testing, along with other parts of the software stack, firmware is not the only part after all.

    After an expensive purchase (that took 4 days to process), I found while workbench and everything could work in Wine, the license manager does not allow anything, and thus does not compile the code, effectively making it useless. I have to run Windows in a VM now (maybe downgrade to an older version!!) and hope it compiles a few c files there (even though it pops up a dialog that specifically says it will not run in VM either)!!!!

    Have asked their support few days ago, and am waiting for them to reply to see if it goes anywhere now!

    Funny, you see people here suggest running the 30 day trial multiple times, maybe they knew it is better not to pay ransom.

    This is an unfair advantage TI has done for IAR, to sell an average compiler and a 90's-era IDE for 4000$ at the expense of disgruntled TI customers.

  • In reply to Ehsan Azarnasab:

    Just to add to the every growing count of unhappy customers.. in hope that the more complaints TI receive the more likey they'll listen? Ha, can only hope. 

    I have wished to develop a BLE app for quite some time, but have never bothered due to the ridiculous cost of the IAR compiler. I have now started a contract project where the customer has paid for the IAR compiler for me, but wished they didnt. It truly is a horrible environment.

    I also like the comment: "TI's highly invasive you-are-using-our-library-but-that-means-you-use-our-entire-stack arrangement" from the thread. This really sums it up quite well! 

    After reading through this thread, Nordics solution looks the goods. Sorry TI. 

  • In reply to Richard Tucker1:

    Well this is disappointing. How much effort would it require on TI's part to get a binary BLE library built that is compatible with SDCC? Are they just being too stubborn to run a single command or does it actually require coding effort?

  • In reply to Ttt Hhh:

    Is there a good reason why sdcc can't use the ble libraries?  We can see what is going on in assembly, maybe it would not be a big problem to make the project in assembly and link to the ble binary?  I am frustrated with using IAR because they ship the ble stack with bugs so it won't even compile to start with.  Somebody over there thought it was a good idea to ship a new bluetooth stack and not even check to see if it compiles!  I wouldn't have a job myself if I were that careless.  You can't get printf to work using the stock code from ble stack, it gets stuck on an infinite loop.  On top of that, they hide all previous versions of the bluetooth stack so I have to beg strangers to send me their copy over email.  It is the job of the engineer to handle frustrating situations but all of these issues are not caused by engineering challenges, they are caused by greed on the part of TI and IAR.

  • One more voice for compiler choice.  I am really surprised that CCS does not support the cc254x family.  I'm not impressed with the IAR IDE and have a hard time justifying to my clients why they need to spend $4k on a compiler for a 30+ year old architecture when much newer architectures have multiple compiler options that range from free to expensive.

  • In reply to Chad Kidder:

    Interesting discussion, and options are still available for anyone interested:

    It is possible to utilize the CC254x as a network processor (running the BLE stack), and connect it to Linux, or whatever RTOS your MCU is running with a UART IF.

    1. Program CC254x with the “CC254x_SmartRF_HostTestRelease_All”
    2. Connected it to your hos with a UART IF
    3. Develop your application on your MCU or in Linux/Android using our API, ”TI_BLE_Vendor_Specific_HCI_Guide.pdf”

    This is included in our 1.4.0 BLE stack release.  

    Other options are still available using SDCC for Eclipse  and BTStack

  • In reply to LPRF Rocks the World:

    @LPRF: You are missing the whole point about BLE. BLE is perfectly shaped for small, ultra low power sensors. Low power, low cost development, fast to market, etc. are keywords here.

    Yes it is technically possible to run the stack in split mode and run the host layer on an externally MCU, but why do so? It adds cost at all levels: power budget, pcb area, complexity.

    Besides that, I have to agree with everybody here. IAR is a horrible environment. Really really horrible. What properly hurts the most by paying so much is that the IDE is so bad compared to other free editors. It is a mystery to me why TI goes all in on this IDE.

    Also keeping the whole stack closed source makes debugging much harder, but I guess you have some business reason for doing this.

    The CC2540 is a cool fully embedded IC which provides a perfect solution for most of the applications suited for BLE and in my opinion one of the market leaders. Too bad that that writing code to it is such a pain because of the IDE.

    In hope that you will reconsider IAR.

    Kind regards


  • In reply to Jens Frandsen:

    I follow this thread way too long and have not seen a bit of bending of TI or IAR to support the developer community. I am considering the Nordic nRF51822 in my future designs, given the costly and closed development model of the TI/IAR and the aging MCU core. TI should get their priorities right if they consider staying or gaining a leadership market position in IOT.

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.