CCS/EK-TM4C123GXL: Goes Directly to FaultISR When Running GCC Compilation (Fine w/ TI Compilation)?

Terence D said:

However, when I compile with GCC in Code Composer Studio (GCC 6.3.1 and CCS 7.2), the program compiles fine, but when starting in the debugger it goes directly to FaultISR function before it even gets to main - or at least once I startup it doesn't break at main and when I press "pause"  it's in the FaultISR function.

Terence D said:

Or any advice on how I can step through the assembly from the very beginning to see how it ends up in the FaultISR?

Hi guys, thanks for the replies.  After some more fiddling, I *think* I have it now working, but I'm still a little puzzled with what's going on.  I'll explain:

Thinking I may have just altered some esoteric gcc compilation or linking setting that was causing the problem, I started a new project from scratch, copied in the code, did the tweaks mentioned at the CCS 6.1/Linaro GCC page (apologies, should've mentioned in my original post I followed and triple checked those instructions).  After doing this, everything seemed A OK.  So, I chalked it up to me tweaking some esoteric gcc setting and carried on.

Then, after doing some farther development, it happened again!!!  I see no pattern as to why, it just started after making some additions to the code.  Trying various things, without success, I then changed the "-e _start" setting (which clearly had been working) to "-e ResetISR" and it started to work again.  Puzzling - I'm not sure why that is.  I was careful to change one setting at a time between re-attempts to debug.

Chester - Thanks for the link to Auto Run and Launch options.  I was not aware of this.  If it happens again I will use this in hopes of gaining some insight.

cb1_mobile said:

Applaud your systematic & considered approach - good that.
You (are) "culling yourself from the (usual/win) herd" - might you describe your motivation for such "separation?" (and added vulnerability)

:)  Well, cb1_mobile, I have upwards of 20 years professional experience in software development (but am somewhat new to working with MCU's).  With those 20 years comes some maturity to know that no matter how skilled you are there is also something more to learn, and that obfuscating only hinders progress and wastes energy.  (Needless to say, this applies even more so to far less skilled and experienced areas - as in my experience with MCU's).

I am but a humble servant to this profession of software development - standing on the shoulders of giants - and always looking to be farther enlightened.

Additionally, I would be remiss if I were not to mention my gratitude for this forum, the experts (such as yourself) that have helped me along and so eagerly and informatively bestowed their knowledge, time and effort.  Very, very helpful.  I thank you, sir.

-Terence

My friend - such kind words - may I offer deep & appreciative thanks?        Yet - so "far" from the viewpoint of another - who consistently rejects guidance - and steers (only) his "OWN Failed Course!"   (in spite of darkening storm clouds - rising tides - clearly upon the horizon...)

I was attempting to understand the appeal (or "draw") of GCC upon you - when it is very much a "minority usage" here - and w/in similar ARM MCU forums.    As a direct result,  "culling yourself from the herd" FEWER are available to guide/assist you - thus there must be (some) justification for your GCC usage - and it is hoped that the "Slowest GCC User" can "Outrun the fastest Lion!"

Terence D said:

Much of my professional career of software development has involved C and C++ - more recently modern C++ (C++11, C++14). GCC does a very good job of keeping up with these standards.

Even as of CCS 7.2 the default tm4c123gh6pm.lds and tm4c123gh6pm_startup_ccs_gcc.c do not configure the GCC run time libraries to support all features. E.g.:

- Doesn't explicitly set up the heap size

- Calls main() rather than the GCC run-time library start-up function _start which means C++ global constructors are not called.

CCS GNU C Compiler and Linker Setup contains some suggested changes to the Tiva GCC linker scripts and start-up code to address these issues, but to be honest a bit of a mess as have addresses problems as-and-when they occurred rather than getting a complete set of valid GCC linker scripts and start-up code added to CCS.

The TI ARM compiler does a better job of this, since the start-up code in the compiler run time library handles the details rather than having to be implemented in device specific files as with the GCC ARM compiler.

My small tech firm is "required" by our clients to "at all times" make a thorough & best practice selection - from among the multitude of ARM MCUs.     Thus - choosing any "vendor locked" IDE or development aid (i.e. RTOS) must be rejected.

The belief that, "One and Only One vendor's MCUs - will "forever" - best match the clients' feature matrix - is clearly short-sighted & misguided!"      And yet somehow - those who "should know better" entrap themselves - thus "MISS OUT" upon the FAR BROADER SELECTION of ARM - which includes M0, M0+, M3 (once here - alas no more) M4 & M7    (M7 existing for (already) several years!)

Vendor limited IDEs - even when offered for "free" - extract an ONGOING FEE - on a "per-use" basis - and are useless when (another's) superior MCU best matches the client's desire.     Pro IDEs (Keil and IAR) in stark contrast - enable the free, fast, easy migration from ARM vendor to vendor - thus the user is SAVED from (another) Learning Curve!      HIGHLY IMPORTANT!     Both IDEs are provided in "Code Size Limited" formats - for free - such that you may build familiarity and skill.

It is my firm's finding that IAR far outperforms "vendor-limited" versions - and that is expected - as IAR has LONG pre-existed single vendor offerings - has a far larger development & support staff - and a significantly larger, installed user base.    (even though it is NOT free - and supports MULTIPLE Vendor devices!)

Vendor ICDI is not especially famed nor noted as "robust."       Segger J-Link - available at discount - is judged by many as vastly superior - again has been around far longer - in far higher volumes - and is FAR MORE regularly improved & updated.      (and may be purchased at discount as "educational" even though and especially though - you are not "forced" to "claim" educator status!)

Wow, so much info, thanks guys!

Chester Gillon said:

What parts of the C/C++ run time library does your problematic program use?

It's not so much that there's an issue, it's more that I'm interested in features like template metaprogramming, move semantics, lambdas, auto.  Not to mention being able to create a class with encapsulation instead of just a struct.

cb1_mobile, Robert - Thanks for the thoughts on development tools.  Very good point that using non-vendor specific tools are not very portable to different hardware.  I should've thought about this more earlier.  As soon as my first (next) non-TI dev board project comes along it seems pretty obvious that CCS is not going to be the ideal IDE (or even possible to use?) with this non-TI dev board...  Okay, off to checkout IAR.  Hope it at least supports popular C++11 features :) 

Terence D said:

as my first (next) non-TI dev board project comes along it seems pretty obvious that CCS is not going to be the ideal IDE (or even possible to use?)

Not "Proving IDEAL" is FAR too generous!      How about totally restricted to vendor offerings (so very few) - provides NO/ZERO Accommodation for (others') ARM MCUs -  thus FORCING YOU/OTHERS upon an ADDED IDE Learning Curve.      One must step back - and ask, "How & Why would "so limited" a "Value Proposition" be (ever) accepted?"

And - might the greater presence - volume of user base - and (expanded) size/skill of development team of the,  "Far longer existing IDEs" offer substantial "Performance, Ease of Use, and Robustness Advantages?"     (each/every one - confirmed via our findings...)

Indeed - your "hesitancy" in any "vendor limited" launch may prove a "windfall" for your ARM MCU endeavors.   

Robert Adsett72 said:

One note of caution on your desired feature set though. Many are cautious about using templates, RTTI and similar features because of the load they place on the micro. Specifically the heavy use of the heap and stack.  Remember these micros have less volatile memory than 30 year old DOS computers and since the systems must run for days or even years without reset even small leaks or fragmentation are fatal.

Yes, definitely agree and appreciate the advice.  My general rule of thumb with things is to review the assembly to see how much is actually going on.  BTW, another thing I've been doing is simply using the SysTick counter to see how many ticks occur between lines of code - effectively profiling the code.  I also sometimes use a logic analyzer to time sections of code.  Agree/disagree w/ this approach?  (I know I'm getting off topic of the original thread so happy to start a new thread if people would like me to).

Robert Adsett72 said:

That's the reason a specific subset called embedded C++ was created.

Interesting!  I was not aware of this at all.  I just Googled and read up a bit.  I'll have to look into this farther.  Thanks for the info!

cb1_mobile said:

Terence D

as my first (next) non-TI dev board project comes along it seems pretty obvious that CCS is not going to be the ideal IDE (or even possible to use?)

Not "Proving IDEAL" is FAR too generous!      How about totally restricted to vendor offerings (so very few) - provides NO/ZERO Accommodation for (others') ARM MCUs -  thus FORCING YOU/OTHERS upon an ADDED IDE Learning Curve.      

:)  well, I try to not be prematurely pessimistic :)  Point taken.  I appreciate the advice - this might've been a lesson I would've learned the hard way.  I'll likely be moving to a new IDE very soon here.

Terence D said:

 My general rule of thumb with things is to review the assembly to see how much is actually going on.

I file this under "premature optimization" and don't do it. It leads to obsession about things like choosing while loops rather than do loops.  Once the other optimizations have been done, cleanup, algorithm changes etc... and there is still a performance gap then look at the generated code but rather than fooling around with small differences in code arrangements it becomes time to look at moving to assembly.

Also with modern micros such as ARM processors just looking at the assembly is not necessarily a good guide to performance.. You have to consider things like cache, instruction dependencies etc...

There have been reports that such micro-optimization of the code besides making the code harder to maintain also interferes with compilers optimizations, actually making code perform worse.

Terence D said:

another thing I've been doing is simply using the SysTick counter to see how many ticks occur between lines of code - effectively profiling the code.  I also sometimes use a logic analyzer to time sections of code.

I don't use clocks for this. I do use logic analysers. There's a lot more information in a pin toggle observed on a DSO than in a clock measurement. cb1 mentioned Segger. If you are looking at them check out their utilities. You might find systemview (If I recall the name correctly) interesting.

Terence D said:

Interesting!  I was not aware of this at all.  I just Googled and read up a bit.  I'll have to look into this farther.

You might also check out MISRA-C++, if you haven't already.

Robert

Robert Adsett said:

Terence D

 My general rule of thumb with things is to review the assembly to see how much is actually going on.

I file this under "premature optimization" and don't do it.

Hmmm...  Really?  I'm very aware of "premature optimization" and am a big fan of measuring over guessing, but when contemplating doing something in one of two ways I don't think it's a bad thing to look at the length of assembly instructions each generates to at least get a hint.  Example: A look up table verse doing a specific calculation.  If a lookup takes just a few instructions and the actual calculation takes say 50 instructions, as long as the lookup table isn't prohibitively big I'm going to probably implement the lookup table.

Terence D said:

As soon as my first (next) non-TI dev board project comes along it seems pretty obvious that CCS is not going to be the ideal IDE (or even possible to use?) with this non-TI dev board.

Whereas IAR can be used to develop software for devices from multiple vendors, but you have to pay for an IAR licence for any serious program (i.e. a program which is bigger than the free code size limited license).

Chester Gillon said:

you have to pay for an IAR licence for any serious program (i.e. a program which is bigger than the free code size limited license).

At present - and for at least the past few years - IAR's "Code Size Limit" is 32KB.

While my firm has "multiple seats" of "Paid IAR" - the statement that,  "Any serious program must exceed 32KB in size" is clearly subject to dispute.     In financial terms - my firm has realized in excess of 250K (USD) - on several occasions - from code which fit w/in the 32KB limit.     And - beyond the (very) narrow offerings found here - many ARM MCUs (only) reach to that 32KB capacity - and more than a few enjoy GREAT SALES VOLUME!

In summary - size (alone) does not a "serious program" make!       Instead - "Functionality, Resourcefulness, Effective Problem Solving and Generating an ongoing profit stream" - serve as FAR BETTER measures of  "serious."       And you can take that to the bank...