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.

SmartRF05EB provides exactly the same debug functionality as CC Debugger, so why does the customer need to do this?

Other Parts Discussed in Thread: CC2540, BLE-STACK, ADS1292

With reference to the title of this post, which is a direct response from TI.

Because CCDebugger is £55 and SmartRFEB05 is £250!!!!, Silly..

I don't work for a global blue-chip company,  my customers and I have what we call budgets and £1500+VAT for the MONOPOLIZED IAR COMPILER for this device has stretched my budget already, not to mention how much time has been wasted before there was some admission that the fault actually lies with the Compiler and incompatibility with tools that are being talked about in technical references as if they were made for each other.

Others have posted about the same problem I have been experiencing recently. That is;

John Pelochino said:
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

If you can't understand why engineers stop developing and allow their annoyance to waste precious time COMPLAINING, then please click-away now.... Because I am about to ridicule IAR's Compiler....

The weakest link in developing BLE products based on TI products is the IAR Compiler (Incluing the non existent C-Spy and incompatibility with Debugger - even the latest edition 8.2.x).

It is not reasonable to accept limited functionality of tools and I personally do not accept that the 'SOLUTION' to this particular problem (comment out bits of your perfectly valid code, to AID the Compiler) is hacking significant parts of your code, like commenting out the SLEEP function. What good is that? How would IAR like it if I said, here's £900, just comment out the remaining £600 from your invoice....

The mandatory IAR  8051 Compiler that goes with this tool-chain is not even worth a fraction of the  £1500+VAT. It is day light robbery and from my experience you are buying yourself a nightmare. A false dense of security.

And the irony is, there is no other choice!!! TI, what were you thinking???

I have spent around 80% of time developing a BLE product on resolving IAR Compiler and Debugger issues.

The sad thing is, IAR feel no shame or the urge to fix these issues and patches are few and far in between.

If I had known more about just how poor IAR tools and technical support is, before deciding to develop a BLE system, I would have decided not to be involved until (if ever) TI release their own Compiler/Debugger Tools or get someone other than IAR involved. 

IAR should not even be in the game of developing Engineering Tools. Because evidently, they are not very good at it. On the other hand, they are perfectly good at safeguarding their IP, license temrs, at Security and enforcing licensing agreements and developing Dongles to go with their Tools-sets to instil fear in you in case you consider taking your work AND DONGLE home to make up for the time you lost fixing IAR BUGS in tools they have sold you- to use on your PC/laptop at home, because you for fear of losing or misplacing yet another latyer of security you have to accept to have the privilege of using something you have purchased ( the license does allow multiple PC installations so long as the Compiler is only used on one PC at a time).  Lost your dongle? Too bad, you need another £1500 Compiler to continue using what you have already paid for... 

And don't let me get started with just how paranoid IAR is when it comes to protecting their dysfunctional C-Compiler for this device. If they had spent half the time debugging the Compiler and EWB IDE than The IAR SYSTEMS LICENSE MANAGER application which LEAVES TRACES ON YOUR PC ONCE YOU HAVE INSTALLED IT AND NO MATTER WHETHER YOU USE WINDOWS OR IAR UNINSTALLER IT STAYS THERE MAKING A FRESH INSTALLATION PRACTICALLY IMPOSSIBLE.

The license management is overly engineered, you have to seek their approval with anything you do in terms of getting value for your 'licensed copy' or simply getting it to do what you have paid IAR because they claim it does.

Why am I so negative about this?

Well. When I asked for support IAR replied, "We can't provide consultancy services specific to your project". They pretended that there is no known issues with CCDebugger working with their Compiler. However, The CCDebugger Tool being totally incompatible with IAR EWB was a huge shock for me and it is not a specific problem to me or my project. Everyone who thinks they can use it to develop and debug code is making as big an assumption as I have made. CCDebugger currently does not support the CC2540 SoC for Debugging. You can program your target with it but you can not Debug! This is what I have been told by IAR a couple of days ago, after several days of e-mails goingback and fort explaining my exact set-up andright pfrom the start I made it clear that it was the Debugger I was having a problem with.

IAR's response of, we are doing you a favour and making an exception to taking others' source code and testing it on their behalf - but not using the CCDebugger in our tests, which is what you have a problem with, was appalling. 

I couldn't believe this. I had doubted myself for days, trying to figure out what I was doing wrong. It never occurred to me that the only Debugger tool available for this device isn't compatible with the Compiler. !!! In my opinion it is  unfair of IAR, and TI - I guess, to NOT make this crystal clear. I have not come across a single post on this forum that makes this fact clear by TI or IAR representatives. It's like buying a brand new car that doesn't have a reverse gear..

It is misleading and disappointing. If I had not committed to delivering a solution to my customer, I would have taken this much more seriously and demanded value for money - perhaps a refund and scrap the whole project! Now I'm committed to the project, to my customer, the IAR Compiler and a sub-standard Technical Support from IAR and have no choice but to live with it. 

The absence of a Debugger is a huge handicap from an engineering prospective. IAR should retract all documentation, marketing and bragging about C-Spy and Debugging elements out of their marketing and promotions for this Compiler. I would go further than that and insist that they made it clear that the compiler as sold for £1500+VAT for the CC254x should come with clear notices to say YOU WILL NOT BENEFIT FROM DEBUGGING YOUR PROTOTYPES USING the TI CCDebugger - ONLY COMPILE & BURN YOUR CODE AND USE YOUR INTUITION TO FIGURE OUT WHAT IS WRONG AND THIS MAY BE DOWN TO YOUR CODE OR DOWN TO US WITHOLDING FACTS FROM YOU. And that is NOT THE DEFINITION OF DEBUGGING.

  • And before I am totally crucified and kicked out of this forum, I definitely didn't get the following message when I first posted a comment about and hour ago; Not until I went back to thank someone for their response; (weird - ????)

    "You have posted to a forum that requires a moderator to approve posts before they are publicly available.

    If the administrator has configured this forum to support email notifications you will receive an email when your post is either approved or denied (if you have emails enabled in your profile). 

    Return to the Low Power RF Bluetooth® Low Energy & ANT Forum forum"

    If criticism is not acceptable and if this is a way to shut me up, then so be it.

  • Hi Tamer,

    I see you are getting answers and support in the other thread from M, but I wanted to give you a reply here as well.

    As discussed in the other thread there is definately some misunderstandings in the communcation between you and IAR. As you have found out already, both the SmartRF05EB and the CCDebugger can be used to program and debug CC-devices. If you are using the SmartRF05EB, you can connect the CCDebugger to that board and use it for debugging, but why would you?

    The difference between the SmartRF05EB and the CCDebugger is that the first is meant as an evalution tool with all the required stuff to start working with our products, including things like buttons, LCD, breakout headers for GPIOs, power supply (from USB power) AND a programmer/debugger. The SmartRF05EB is primeraly designed to be used with our Evaluation Modules (EMs), but can also be used as a separate programmer/debugger. The CCDebugger is just what its name implies, a programmer and debugger. To use it you simply have to connect the 2 debug signal (clock and data), reset, power and ground correctly to the CC-chip you are using and you are good to go.

    As for the approval of posts, this is to avoid spam, not to filter out "unwanted" messages.

    Cheers,

    Fredrik

  • Tamer,

    If you could please explain the original problem you had with the CC Debugger, we will be more than happy to help. The statement that "CC Debugger currently does not support the CC2540 SoC for Debugging" is not correct and we would like to clear up any misunderstanding between you and IAR.

  • Thank you for offering to help.

    I really appreciate it and I realize that I should have turned to this forum for guidance and assistance with development tools, instead of to IAR, even though the problem appears to be rooted to IAR EWB IDE - Compiler.

    I sincerely do not have the will or luxury of time to repeat details or symptoms of what essentially appears as compatibility issue between IAR EW IDE for the 8051 (CC2540SoC) and CCDebugger.

    All I want is to debug, step through and add breakpoints to my code - to develop software. To use the tools (Compiler/Debugger).

    I have been and am still able to compile code and run on my custom BLE device. And I believe that rules out a lot of issues to do with hardware, device drivers or installation related issues (though I did start with the IAR 30 day evaluation version of their compiler and later migrated, enduring great technical pains during the process of replacing it with a licensed+dongled version - and I do not know if there are residues in my system from that switch over).

    From what I can see, there is a distinct difference between churning out HEX files from the IAR Compiler and Using it with CCDebugger to debug/ step through my code, the latter simply doesn't work for me, whether I have my custom board attached to the CCDebugger (which IAR definitely can see as I have to choose when I ask to DonwloadAndDebug from within the IDE) or the SRF05EB  v1.8 - as target devices.

    I now have three CCDebuggers, bricked and now fully recovered these in trying to get IAR EW IDE to behave like a Debug environment. I have followed instructions/Guides during implementation and my CCDebuggers had been updated with firmware using SmartRF Studio 7.

    All program target devices without any problems (Using SmartRF Flash Programmer).

    None work with IAR IDE as a Debugger Tool.

    I really do not know how else to simplify the problem, and what I have so far tried to address it. So far, efforts to do so have been spread across many e-mails exchanged between IAR and myself - over the past few weeks and some of their answers have not only confused me more but have been unreliable to say the least.

    For now, I can compile and burn my code into my target device. Power it up and use BTool to talk to it, so I am not totally crippled by lack of a Debugger but I am certainly hampered and would have felt far more confident as a developer and be more efficient that the current state of affairs.

    When you consider the whole evolution of a product of this nature (The TI CC25xx family and plethora of development tools - software and hardware), collaboration with third parties such as IAR, it is inevitable that there are going to be issues - bugs and human errors to further complicate matters and my conclusion is that there must be more to it. For example, why wasn;t my upgrade from evaluation version of the Compiler to Full version not as smooths as claimed. Why did I need to go back and forth to IAR  to upgrade. That was not straight forward either and I do wonder if there are residues in my installation from it?? Because it certain seems straight forward to plug in the CCDebugger into my USB port, see it acknowledged by my PC and IAR EW IDE and then to click the Play Button (Download and Debug)...

    Thanks again for at least 'listening'.

    Tamer.

  • Fredrik,

    You replied to e-mails I sent directly to IAR technical support.

    But here at E2E forum, it shows you as 'TI Employee'.

    Are you the same Fredrik?

    If so, who do you work for / represent?

    TI or IAR?

    Tamer.

  • Hi Tamer,

    I have not answered any emails sent by you to IAR, that must be another Fredrik.

    I work for TI Low Power RF.

    I will leave it to M to continue the support on the CCDebugger issue, as he is the expert on our development tools.

    Fredrik

  • It's a bit difficult to help without knowing what you mean by "debugging doesn't work". From your description, it seems that you have three working CC Debuggers, and you can program the flash on your CC2540 devices using these debuggers with SmartRF Flash Programmer. However, debugging from IAR "does not work". Can you describe the symptoms/error messages or whatever that indicates that debugging doesn't work?

    As a reference, I went through all the steps for using IAR EW8051 + CC Debugger to debug some software running on a CC2540. The attached document shows what I observed. What do you do differently? Where does things start to go wrong?

    6787.Debugging CC2540 with CC Debugger using IAR.pdf

    ..

  • I'll start again.

    I'm using IAR EW IDE 8.2.1

    I have a CCDebugger

    I have installed v1.3 Stack

    I want to Debug a custom board which has the header topology recommended in section 6.2.1 Minimum connection for debugging of CCDebugger User Guide. I am not powering my board from the CCDebugger (Header pin 9 not connected).

    Due to difficulties in getting the CCDebugger to work with my IAR Compiler,  I have tried all avenues, including upgrading my stack from v1.2 to v1.3, learning how to brick and unbrick the CCDebugger, etc.

    With the v1.3 stack installed, I have also removed my code from the equation and returned to (included with v1.3 stack) SimpleBLEPeripheral IAR Project and hope to run this on my target board.

    I have created a new IAR EW IDE Project Configuration based on the CC2540 config, with 'Factory Settings' set to DEBUG.

    I have created a second IAR EW IDE Project Configuration based on the CC2540 config, with 'Factory Settings' set to RELEASE.

    Using the RELEASE version of this demo-code, I can compile, use SmartRF Flash Programmer, burn and run the code on my custom board. Use BTool to find and connect to it, query by UUID and see lots of data coming back from my BLE device.


    I connect CCDebugger to my PC and to target device, I press RESET and can see Green LED.

    Using DEBUG configuration of the same project, I click Download & Debug,

    IAR:Target Selection: I Choose CC Debugger with ChipType:2540 (my target! &correct)

    Download and Verify Correct, PC at HAL_BOARD_INIT(); 

    BTool can talk to it.....Get Data Back...


    All seems great! until I ask to PAUSE execution or debug session.... OR each time it hits a break-point in the conde, IAR locks up, grey faded screen. Only way to exit the infinite loop is to END TASK in Wndows. Kill IAR and start over again with all its' settings lost - workspace not as last used as a result.


    The reference design standard tools do not appear to work with one another.


  • I have read the document you have posted.

    It concurs with my set-up, except unless the there is a difference between what you suggest on page 4 onwards and the DEFAULT settings.

    I will compare these shortly.

    The one thing that is not clear from your document is whether the KeyFob is powered externally or from the CCDebugger (pin 9). I'm not sure if has any bearing.


    I'll go and compare the settings to see if there any differences.


    Thanks.

  • Good. Let me know if you see any differences in the project set-up. I will also try the same project as you (SimpleBLEPeripheral).

    I power the KeyFob from the battery (not from the debugger).

    One thing that strikes me as odd is your IAR version number. I've never heard about v8.2.4. In IAR, on the menu bar, can you please select Help --> About --> Product Info... What does the dialog window display? Mine looks like this:

  • FYI - I just tested the SimpleBLEPeripheral example, and that also worked fine out of the box (no trouble debugging, both before and after having established a link to the keyfob from BTool).

  • Some of the OPTIONS settings were not the same in my setup, even though mine are 'default values'..

    Changing my settings  has made some difference but hasn't cured my problems....

    Downloads to CCDebugger quicker now and gets there.  But IAR EW IDE still locks-up, grey screen - forever....

    It looks like i need to realy get my head around the Linker-filel lnk51ew_CC2540F256_banked.xcl

    I am still confused about HALNODEBUG and POWER_SAVING pre-processors, which seem to prevent my code from compiling if enabled/disabled.

    Any tips on where to start, to understand this - any references? Have tried CC2540 datasheet (Code, Memory Space for correlation with xlc file but not very obvious)...

    IAR DOES NOT HANDLE ERRORS GRACEFULLY.

    IAR Locks up, infinite-loops...

    It does not work it out that I have been sat waiting for it to stop trying for 10 minutes, what ever it is looping for ever for.....

    I then have to kill IAR, restart it, and as a consequence, it forgets all of my settings - my last project ladida...

    I note your installation is 8.20.2 and 6.4.8.253


    I don't understand why I have go through layers and layers and layers of License Manager issues, simply to get an update patch - to 8.20.2, my last experience left me in feat of touching my current set-up. AS it took me three days to get IAR to approve and allow me to use my licensed copy after eval-version expired and caused painstaking issues.

    I am really beginning to hate IAR. What is wrong with this company?  Frigging paranoid monopolizing vultures!!! 



    Despite this diiference between our isntallations, according to IAR's release notes, there is absolutely no difference between the two - the update from 8.20.1 to 20.20. is

    "

    2. IAR Embedded Workbench for 8051 - Service Pack 8.20.2
    Released Mar 5, 2013.

    This service pack has been made to address the following:

    A bug fix caused the compiler to generate more code when moving 8-bit data from __data to __data memory and from __idata to __data memory.

    The source browser did not recognize the __sfr keyword making it impossible to use go-to-definition and go-to-declaration.

    Fixed a problem when you got a fatal error when selecting CY7C68xxx Cypress devices.

    "

    So, if we can trust IAR, then our dev-environments/ Compiler are no different....


    You say, you have  successfully tested (can debug) with sample projects.


    Tell me, are you entering DOWNLOAD AND DEBUG mode? (There;s also debug without download)

    Also, Are you able to set up break-points and actually get there, then step through and verify PC and registers are doing what they're supposed to?


    Thank you.

  • The fix in the compiler from version 8.20.1 to 8.20.2 is quite important, so I would really recommend that you try to get that patch from IAR. I know the license update stuff has been quite painful (yes, we also went through this when we upgrade), but now it works fine.

    Regarding the pre-processor defines, these should be described in the CC254x Bluetooth Low Energy Software Developer's Guide (www.ti.com/lit/swru271) on the BLE-STACK product page.

    Yes, I am downloading and debugging (running the code and single stepping on the actual target). I have included an IAR project for CC2540 you can use for testing. It doesn't include the stack or anything, just a simple app you can use to verify that you're able to download and debug using IAR. Please try it at let me know if it works for you. 

    blinky_iar_ew8051_8_20_2.zip
  • This is why I believe there is a problem with IAR - or my installation of v8.20 of it.

    But IAR are technical support is not very helpful and they get offended when I report on-going issues with my IAR compiler/installation.

    I have beeen crying out for assistance for over a month now!

    Frigging Pathetic...!

  • I am also using the CC Debugger, CC2540 BlueRadios Dev Board (Rev D) and IAR 8051 IDE, and or the TI KeyFOB dev Kit

    In main() I have added some simple "LED" test code to the example project SimpleBLEPeripheral (no other changes have been performed to the project and or code).

    The step into and step over appear to not be working correctly with the debugger for the associated LED APIs, when the step icon is selected the PC goes into run mode or hits the next break point set several lines down related to the LED calls outlined below. What is interesting is that the "step" commands work at restart of main, but do not work after initialization.

      #if defined ( POWER_SAVING )
        osal_pwrmgr_device( PWRMGR_BATTERY );
      #endif
        
        
       HAL_TURN_ON_LED1();   <-- set breakpoint and run to this break point. Select icon step into, or single step, or next statement, and the system performs like a go command was entered (halt is required to see where the code PC is located).
       HAL_TURN_OFF_LED1();
       HAL_TURN_ON_LED2();
       HAL_TURN_OFF_LED2();
       HAL_TURN_ON_LED3();
       HAL_TURN_OFF_LED3();

      /* Start OSAL */
      osal_start_system(); // No Return from here

    Misc:

    8.20.2 IAR IDE

    6.4.8.2543 IAR common components

    I understand that this code has not been ported to the BlueRadio dev board, so I have also tried this on the TI Key FOB CC2540 Mini DK 1.1 with the same results.

    When Halt is selected, after step was selected with the LED code above, the system does appear to perform single step operations. So why are these single step operations sometimes ignored by the IDE and CPU? IProbably not related  to the "sleep", and the debugger not retaining the break point configured by the "IDE" after the step command has been selected? Is debugging symbols off for these LED files (located in ../Target/CC2540EB/Drivers)?

    Default Preprocessor settings:

    INT_HEAP_LEN=3072
    HALNODEBUG
    OSAL_CBTIMER_NUM_TASKS=1
    HAL_AES_DMA=TRUE
    HAL_DMA=TRUE
    POWER_SAVING
    xPLUS_BROADCASTER
    HAL_LCD=FALSE
    HAL_LED=TRUE
    CC2540_MINIDK

    Also note if

    HALNODEBUG is changes in the preprocessor to xHALNODEBUG, the following error occurs:

    simplekeys.c  
    Linking
    Error[e46]: Undefined external "halAssertHandler::?relay" referred in OSAL_Memory ( D:\Texas Instruments\BLE-CC254x-1.3.1\Projects\ble\SimpleBLEPeripheral\
    CC2540DB\CC2540DK-MINI Keyfob\Obj\OSAL_Memory.r51 )
    Error while running Linker
     
    Total number of errors: 1
    Total number of warnings: 0

  • I added a bit of code to the "Blinky" project to attempt to get SPI working and encountered similar debugger failures.  

  • Hi Eric,

    Which blinky project are you referring to? The one from the CC2530DK User's Guide? Or something else?

    Are you using IAR EW8051 v8.20.2?

    What debugger failures did you get?

  • M - 

    I am referring to the project attached to your post to this thread on Mar 14 2013 08:50 AM.

    I am using IAR EW8051 v8.20.2.  Detail view shows the following (snipped for relevance, let me know if you want more):

    === Install subdirectory: 8051 ===

    IAR Assembler for 8051
    8.20.1.40829 (8.20.1.40829)
    C:\Program Files (x86)\IAR Systems\Embedded Workbench 6.4\8051\bin\a8051.exe
    13/Oct/2012 04:14:26, 854528 bytes

    IAR C/C++ Compiler for 8051
    8.20.2.41139 (8.20.2.41139)
    C:\Program Files (x86)\IAR Systems\Embedded Workbench 6.4\8051\bin\icc8051.exe
    04/Mar/2013 14:42:58, 13191680 bytes

    The common components is at version 6.4.8.2543.

    I took the main function and added an attempt at code to communicate with an ADS1292 via SPI as a master.  I can run to breakpoint, but I can not reliably single step.  Single step works maybe 20% of the time.  More commonly, it will act as though I had hit run, or it will not advance the program at all.  Frequently, IAR crashes.  An IAR crash can sometimes be recovered from by hitting reset on the CC Debugger, but perhaps 5% of these frequent crashes require me to pull the USB connection to the debugger and/or force quit IAR.

  • It appears that debugging works as expected until the first time I attempt to use the SPI peripheral.  I can single step / etc correctly until I write to U1DBUF.  After this occurs, all bets are off.

    I'm beginning to think that this debugger setup is not capable of handling interrupts, as similar frustrations occurred when I was attempting to debug with the BLE stack active (right now there is nothing other than the SPI code to reduce the number of variables).

    I believe I've disabled any relevant interrupts... but I'm not positive.  How can I be sure that I didn't miss something here?

  • Reading the posts, I can see what is ahead, if and when, I get past

    Warning[w2]: Symbol ?ESP is redefined in command-line
    Fatal Error[e72]: Segment SLEEP_CODE must be defined in a segment definition option (-Z, -b or -P)
    Error while running Linker

    Using IAR  evaluation version 8.3   SimpleBLEPeripheral - CC2540  Device CC2540F128  CPU Core Plain,

    Code Model: Banked  Linker: $TOOLKIT_DIR$\config\devices\Texas Instruments\lnk51ew_CC2540F128_banked.xcl

    I have the Smart RF0f Eval Board Rev 1.8.1  What do I need to change to get the linker to work, where do I comment out the Segment SLEEP_CODE?   Three days of trying different options....  appreciate some direction.  Thx.


  • Hi Michael,

    You should use the linker file that comes with the BLE installer - it is tailored for the stack and defines the SLEEP_CODE segment. You'll find them here: C:\Texas Instruments\BLE-CC254x-1.3.2\Projects\ble\common\cc2540. The default linker files that comes with the IAR installer does not specify any application specific segments.

    The ?ESP warning is due to a change in the IDE in 8.30 when running the linker. The ESP symbol was previously taken from the linker command file, but now it is set directly on the command line when ivoking the linker from the GUI, so the definition in the linker file is redundant. You can simply remove it from the linker file to remove the warning.

     

  • Hi ,
    I know its an old post but I thought I would give it a try.

    I am trying to run the sample project  "SimpleBLECentral" but have an issue while compiling. It gives an error "Fatal Error[e72]: Segment SLEEP_CODE must be defined in a segment definition option (-Z, -b or -P) "
    what can I do to fix it?
    I am using "IAR ver 8.3" and am using "CC2540DK ver 1.8.1.3"  with "CC2540F256_banked " is the linker file .
    Please help me with this.
    Thank you,
    Smriti