Aslak,

Thanks so much for the response! It works now. I had taken a detour to a previous version of the compiler, but now back to 8.20 and this fixed my issue. Please let me know if a permanent fix is made.

Thanks,

John

Thanks Aslak, 

This solved the issue quickly... but could you elaborate on the solution, what exactly this change does which solves the issue?

Thanks,

Adam.

Hi Adam,

As you perhaps noticed, a C-instruction was replaced with an asm instruction. This causes the new way IAR8.20 compiles the instruction under no-optimize (two asm instructions) to be replaced with the old way.

By only using one asm instruction we ensure that the sleep enable instruction is correctly aligned with regards to the flash memory address as was intended, and also that the function fits inside the already defined SLEEP_CODE segment.

Best regards,
Aslak 

I have exactly the same problem and my opinions about it.

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.

Hi Tamer,

I can't answer for IAR. However, I have no problems using CC Debugger with IAR (using 8.11.4 for compatibility with the BLE codebase) to debug my projects. IAR Embedded Workbench offers via the CC debugger at least the common stuff like memory view, register view, variable watch, breakpoints, single-stepping (although it sometimes gets confused with optimization on), stack view, terminal output via debugger (albeit slow) etc.

I have also used 8.20 with the above mentioned code-change without issue. Is the combination of CC Debugger and IAR Embedded Workbench not working out for you?

Best regards,
Aslak

Hi Tamer,

First, let me assure you that CC Debugger is compatible with IAR EW8051 (it has been since version 7.51), and it works very well for debugging software running on our CCxxxx 8051-based system on chips.

I'm very sorry if you've had a bad experience with IAR and with their support. They, just like us (TI), try to help out the best they can. 

If there's anything you need specific help on from our side (getting up and running with IAR and our kits and devices), let us know and we will try to help through the forums.

Thanks for your response.

Realizing everyone here is happy, I have carried this conversation to another location - as a discussion, since the problem referred to in this thread has been resolved.

at http://e2e.ti.com/support/low_power_rf/f/660/t/249714.aspx 

I'm glad it works for you.

So, where did you get 8.20.4 from??

My IAR EWB tells me there are no updates, that I have the latest version at 8.2.1, when I click Product Updates....from within IAR IDE, it takes me to;

http://supp.iar.com/updates/?product=EW8051&version=ALL 

where it states;

Available Versions Product: IAR Embedded Workbench for 8051 Version Release date LMS 8.20 Nov 6, 2012 LMS2 8.11 Feb 9, 2012 LMS2 8.10 May 26, 2011 LMS1 7.60 Jun 30, 2010 LMS1 7.51A Apr 21, 2009 LMS1 7.50A Jun 24, 2008 LMS1 7.40B Mar 6, 2008 LMS1 7.40A Feb 26, 2008 LMS1 7.30B Sep 14, 2007 LMS1 7.30A Aug 17, 2007 LMS1 7.21A Apr 17, 2007 LMS1 7.20A Oct 28, 2005 LMS1

The link at 8.20 above goes to another page where it states nothing about a 8.2.4 update/patch;

Product Updates Product: IAR Embedded Workbench for 8051 Version: 8.20 LMS: LMS2 Released: Nov 6, 2012 1. Install version 8.20 Integrated development environment and optimizing C/C++ compiler for 8051/8052 and compatible devices. A new text editor and source browser are introduced in this version. The new features include auto completion, parameter hint, code folding, block select, block indent, bracket matching, zoom and word/paragraph navigation. The new source browser adds features like Go to Declaration and Find All References to symbols. The version control integration has been extended with support for Subversion (SVN). The C-SPY Silabs driver now includes support for SFR paging and banked xdata. The C-SPY Infineon DAS driver now supports setting software breakpoints in the program memory XRAM area. Release notes To download, log in to your My Pages account. 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.

Thanks a gain for your comments,

Only other thing I would like to ask is, does your CCDebugger interface to your target board have more than the 5-lines, CC,CD,VDD, GND and Soc RESET ???? Ot less than this, I think my hardware is okay but you say yours works and mine doesn't, so I wonder what the difference might be.

Regards,

Thanks for your comments.

I have to go by what is published, official documents available to us and more importantly by what I am told by the Vendor or IAR.

Here's a quote from IAR, following best part of a week of e-mails to and fro'...

"We have talked to TI and we got it confirmed that TI recommend that you should debug using USB and not the CC Debugger with SRF05EB."

That is a direct quote, verbatim!.

What else can I say? I rest my case and shall retract into my cave until I figure out how to feel good about this.

Regards,

Tamer.

Tamer,

I've been in contact with IAR, and I think I'm starting to understand what's causing the confusion. Please correct me if I'm wrong.

So, if the information I have is correct, you have been using a SmartRF05EB (05EB - the big mother board with LCD++) and a CC2540EM. The 05EB has integrated the CC-Debugger, so once you connect the 05EB to a PC via the USB connector, you should be able to use IAR to debug the software running on the CC2540 (sitting on the CC2540EM) directly. In this case, no need to use a CC Debugger - it's already on the 05EB.

Now, if you still want to use the CC Debugger to debug the CC2540 on the assembly 05EB+CC2540EM (or any other assembly with the CC2540), you need to disable the debugger part of 05EB to get exclusive access to the debug interface of the CC2540 chip. 

Please take a look at the first page of the SmartRF05EB schematics in the User's Guide (http://www.ti.com/lit/swru210). It shows how the various bocks on the 05EB are interconnected with a set of jumpers on headers P1 and P10. By removing all of the jumpers on P1, you isolate the USB block (basically disconnect the debugger on the board), and you should now be able to connect the CC-Debugger to the appropriate signals on that header to take control of the debug interface of CC2540. 

So what about the two 10-pin debug headers already on the 05EB? They have different roles: The one labelled "USB Debug" is for programming the CC2511 USB controller on the 05EB. I.e. mostly used internally by the team developing the board. The other one, labelled "Ext Soc Debug" works exactly like the debug connector on the CC-Debugger: Connect your own target to this connector and the 05EB will operate just like a CC-Debugger.

I hope this helps.

Thanks again for your suggestions.

I do not know what it is that I have said or not said but I am not trying to debug the Evaluation Board with a CCDebugger.....

If we forget TI and IAR for a moment. Let's assume we are generalizing. I have a design that I need development tools for. A Compiler, Programmer and a Debugger, if I could afford it, an Emulator.

If I identify a solution and turn to a vendor and purchase their compiler - (forget Debuggers and the SRF05 or any other gadgets for a moment). When I begin coding and decide a Debugger would be useful, I do not ask the vendor if they have an eval board that costs 5 times as much and doubles up as a debugger. I do not go ahead and design my product with sockets that the vendor has chosen for their evaluation boards and modules that go with it. Not when there is a standard debugger for the device I'm using  for £50...

There is a distinction between an Evaluation Board and a Debugger Tool. Not being the expert on how these tools can be utilized or what the simplest route to development,  I sought advice from the vendor on how to utilize the official debugger for the damily of device I'm using and make it work with the Compiler.

I just need a tool that is simple and bespoke for the job I want to put it to use, like the CCDebugger for my CC2540 SoC.

I do not know why that sounds like I want to use a CCDebugger to (for some reason) debug an SRF05EB .......

It's crazy because I want to know what if the SRF05EB never existed. And if didn't, then would I still be able to debug my custom board using a CCDebugger - as long as I have designed my board with the suggested Figure 15 - SmartRF05EB External SoC Debug Connector, in section 6.13 Debug Connector for External SoC of swru210a.

And if so, why is my IAR Compiler not allowing me to do this?

Why is the vendor and focusing on EvalBoards and referring me to user guides for setting up eval boards as debuggers or programmers?

I don't understand why, when I ask for help because the official debugger tool (CCDebugger) doesn't work with in my  IAR EWB IDE, I got this response;

"This is what I have discovered so far.

We did just use the USB connection when we did the testing for the V8.20 release.

And as you discovered (thank you for insisting that I should check this more

carefully) there is a difference when debugging via the CC-Debugger.

Something happens (I do not know why yet) and the code in the hardware appears differently.

For example, when I run the code via USB then it just works. When I run it via the CC-Debugger then I get all the verification warnings you got and I do not reach main() any more.

I can still step around in the code on assembler level but it resets before I reach main().

You can make the situation somewhat better by turning off the download verification (menu Project > Options > Texas Instruments > Download > Verify download = false).

Our plan is now to investigare why there are differences and work on fixing the incorrectness while debugging with the CC-Debugger.

This will occur today and next week.

So as I said before, to work with the source code / project it is possible to use the USB connection as a temporary workaround.

"

That basically leaves us with a 'temporary workaround' in terms of having a development kit for a live project.

Great!

Thank you TI and Thanks you IAR, I really feel valued as an engineer who has chosen your products and expertize in this field as a trusted vendor. Only to have my posts monitored (?) and (certainly) restricted for asking questions..

Tell me something. is this across the board for this thread/forum?

Did you see this message when you posted your comments?

Bizarre!

Hi Tamer,

Sorry for adding to the confusion. I obviously don't have the full history of your support case with IAR, so I may have misunderstood the issue at hand. And it also seems like IAR has misunderstood your original problem and added to the confusion by talking about the eval board and the debugger. The reply you are referring to above from IAR doesn't make much sense to me.

So, please give me a try to get this issue sorted out. For starters, the CC-Debugger is the right tool for debugging and working with your custom board. If you follow the recommendations in the debuggers' user's guide for the debug connector on your board you should be all set. If it doesn't work, I will do what I can to fix the issue and help you get it up and running.

Would you mind sharing your original problem? 

As for your comment about the forum: You are free to ask whatever question or raise whatever concern you may have, as long as it stays on topic.

hi everybody,

i am started with the cc2540 mini development kit and i have do all demo test. now i want do to modified a little my program.i want to make first the keyfob all time discovery like the usb dongle and make the make the dongle with push button discovery.i  have modify mein simpleBLEPeripheral.c of this line :

// uint8 initial_advertising_enable = FALSE;
       uint8 initial_advertising_enable = TRUE;

and becom this linker error after build: Fatal Error[e72]: Segment BANKED_CODE must be defined in a segment definition option (-Z, -b or -P)
Error while running Linker

i have try to correct this,but it is not work.

make my idea sense?what i try to do? how can I do that? I'm just in the process of trying to understand how all this works, before trying to program a app again later.

thx for rply

hi,

I just change this line and after I got this error.

thx

Hello,

I have error similar to the above.

Segment ISTACK(size:0xc0 align:0) is too long for segment definition. At least 0xd more bytes needed. The problem occured 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:4d-ff".

Can you please help me in resolving this issue.