Problem on download and debug using IAR

Hello Amir,

Can you try updating your IAR tools and see if that solves your issue?  Otherwise, please make sure the correct set-up files are being used.

-c

Our group uses IAR (paid, multi-seat) and we've never noted such issue.

Do try Craig's suggestion - should that fail I'll post "screen caps" - showing the key elements of our set-up.

Note that we use "J-Links" with each of our IAR workstations - your identification of your JTAG/SWD "probe" would be helpful. 

Also - we use another's Cortex M4 primarily (that @ 180MHz) - and have no experience with your 129x MCU...(might it be a, "too new" debug method/device - employed upon your new 129x board?)  IAR may need some time to properly react should the debug method have changed - upon your board...

As always - your report of any "past usage" (success or failure) of your IAR IDE would limit our "guess work."  (that's always appreciated)  Is this new use - with this 129x board - your only failure experience?

Hello.

Thank you for your assistance. As you recommended, I installed the new version of IAR (7.2) from the IAR site, and I succeeded to download and debug the firmware code (currently still from the examples code).

But I've got another issue: as an example, I downloaded into the device the simple 'Blinky' firmware (which blinks the board's user led by using a simple counter). After a few experiments, in which I only updated the period duty-cycle duration, after I downloaded it the IAR couldn't turn into the debug stage. I got the next screen:

 

(On the Disassembly window there is a message "unavailable when executing".)

When I select the option "Reset will do system reset" under the "TI Stellaris" menu (or alternatively after I press the Reset button), the IAR can perform 'Download and debug' successfully. But then I see that the blinking period is much slower...

If instead I select another example code and download it, the IAR turns into the debug section successfully again. (But turning back to the 'Blinky' example, I can see again that the running is much slower.)

 

-       Why does the IAR "sometimes" fail to turn into the debug stage? Is the JTAG connection lost?

-       Why after the Reset the blinking period is much slower? Is there any latency due to communication on the running device?

-       Why is the ROM Component ID = 0 and the Device ID = 0 (unknown)?

-       I noticed that the included device on the board is XM4C129NCZADI1, silicon revision 1 (and not TM4C…). What are the consequences of this on the device behavior?

 

Thanks a lot,

Amir

Harshal Pulekar said:

reply me through my email. 

That would defeat the very purpose of such an user forum as this.

A basic introduction and tutorial for the IAR WB is found in the accompanying documentation/help.

f. m. said:

That would defeat the very purpose of such an user forum as this

Certainly right!

And, despite the fact that cb1 might not agree, I'd suggest such poster to use CCS instead. I doubt that CCS will lack any functionality that a fresh developer might require for a long time...

By the way, any link to a post/page showing the "advantages" provided by tools like IAR? I started my embedded life with fully licensed IAR, and after a while we moved to CCS and never had to go back - but we are certainly "low end users"...

Bruno Saraiva said:

By the way, any link to a post/page showing the "advantages" provided by tools like IAR?

CCS is fine if you:

• stay with TI MCUs
• get along with Eclipse

Especially the first point is critical for commercial users that want to support multiple platforms/vendors.

Makes sense, f.m. - thanks!!!
As for the second point... "geting along - or not" might not be an option sometimes... :)
Still, it's an IDE. More "modern" environments, particularly when you move to PC/Android development, come with many more bells and whistles - and useful ones to say. But I wonder if IAR or other commercial embedded-focused IDE's have these "modern" things...
At least when I transitioned, they didn't.
No plans here to support/use a different vendor so soon... I am not saying one particular brand is perfect, but the learning cost of getting used to another one is higher than the benefits that we as a company could expect in the near future.

Bruno Saraiva said:

As for the second point... "geting along - or not" might not be an option sometimes... :)

You are correct - this is mainly a point for one's private projects. Companies use to disregard your/my preferences.

Eclipse has some peculiarities that earned it a group of disciples (and a group despising it, too). One thing is the virtual project folder mapping, bearing almost no resemblance to the file system, including the cumbersome file import.

The second point is the source code parser. Supposed to "help" editing, he scares a lot of people (especially novices) when in disagreement with the compiler. Did you ever have the editor warning/error "Could not resolve symbol xxxx", but the build process went through without errors ?

And third, I don't like most of the default settings of the Eclipse editor, and some of the "features" you can't even turn off. I use to disregard software that believes it knows better what I want+need ...

I'd be in the despise camp, editor discussions tend to produce holy wars. I think though this deserves a longer response. Not to convert the apostate heathen but to explain why some of us have an issue with IDEs in general and Eclipse as a particular incarnation in particular.

Hopefully, with a little thought later.

Robert

As "card carrying, apostate heathen" I must note:

• far fewer "crashes" and or JTAG Lockouts under IAR
• faster downloads
• direct calculation & display of "MCU Cycle Count"  (as opposed to code-write under lesser IDE)
• spectacularly "speeds/eases" the (necessary in time) migration to (other) vendor MCUs as the IDE "remains the same!"
• and as f.m. noted - the most useful ability to provide "Vendor Agnostic" ARM MCU support ... (noted/appreciated (especially) by heathens...)

cb1 said:

the most useful ability to provide "Vendor Agnostic" ARM MCU support

Non-IDE solutions tend from agnostic to atheist :) Certainly not vendor specific.

Robert

But something properly written later.

cb1 said:

...the most useful ability to provide "Vendor Agnostic" ARM MCU support ...

BTW, Eclipse was originally thought to be exactly that - an OS and toolchain - independant development environment, written in Java. In many incarnations, however, I experienced it mainly as ressource hog, with the opposite of above mentioned points  ...

Thank you - yet (young) staff question, "Does apostate heathen" lean (more) toward "agnostic or atheist?"