TM4C1294NCPDT: EXAMPLE OUT OF BOX FAILURE

Feel your pain!    Really!     And you must be advised - you are FAR (very far) from being alone!

Christopher Weber said:

I create a new one, and it doesn't even work.

As vendor/friend Charles suggests - you are far better advised to 'Start from a 'KNOWN WORKING (i.e. vendor supplied/tested) PROJECT' - rather than attempting to 'Create your own.'

Why is that?      (Staff/I - read your mind/hear you!)     The IDE has MANY 'Nooks & Crannies' - for those attempting to 'create their own' - success most always (likely always) proves elusive.    In no way is this any reflection upon you - your desire and/or capabilities.    It is - instead - the 'Bowing to Reality' - which (should) warrant consideration.    Note that  'your code's addition/placement' - w/in the  vendor's 'known good project' - insures that all of those (often hidden/obscure) 'IDE Nooks/Crannies' - have been 'FULLY MANAGED' - for you!     (Your attempt to 'create' - minus that 'IDE Expertise' - can never compete!)

It should also be noted - what IS the motivation - for 'Always and ONLY - the 'urge' to, 'CREATE ONE's OWN PROJECT?'     (that's NEVER/EVER explained!)

It proves easy to, 'Add your own code - w/in the existing vendor project - run & check  it - and then 'carefully & systematically' - remove vendor's example code.    (ideally one piece/section at a time - always testing/confirming - after each piece of vendor's code - is excised.    (killed/banished)     This 'method' - most always - saves you the time (and great effort) demanded to become an 'IDE Maven' - while enabling your project's success!    (which IS the goal - is it not?)

Such guidance clearly - deserves better (i.e. some) vendor promotion.    (clearly their current 'method' is failing - that's widely known - perhaps 'one day'...)

Piggy-Backing your code - w/in a Vendor Supplied/tested Project - is 'absolutely the way to go!       Allez!

Charles Tsai said:

Hi Chris,
There is a project0 example plus various TivaWare examples under <TivaWare_Installation>/examples/boards/ek-tm4c1294xl. Please import these projects into CCS to try them. You can start with the project0, hello, or blinky. These projects all have the device fully initialized.

Charles,

Nope.

The only "examples" folder I have is "tirtos_tivac_2_16_01_14_examples"  in "C:\ti\tirtos_tivac_2_16_01_14".  And CCS finds nothing in there to import.  See:

I seached for any examples, and there is nothing that follows your "<TivaWare_Installation>/examples/boards/ek-tm4c1294xl."  folder tree. 

And I tried making CCS search from a root level, and got a massive list of things named "com_ti_rtsc_tirtos_example_xxx".  After digging through the list of over 300 of them, I selected example #141, and tried to import it (C:\ti\tirtos_tivac_2_16_01_14\resources\ek_tm4C1294XLEvaluationKit\driverExamples\tiDriverExamples\emptyExamples\com_ti_rtsc_tirtostivac_example_141.projectspec )

It won't import, it gives me this error:

Considering the TivaWare installation is older than CCS (I was using this almost 2 years ago with CCS 6.2, now I'm on 7.2 ) I don't see why updating is necessary...  and fails anyway.

Cannot complete the install because one or more required items could not be found.
Software being installed: CCS Flash Content 8.1.0.1297 (com.ti.dsflash.win32.feature.group 8.1.0.1297)
Missing requirement: Debug Server - Win32 7.4.0.1313 (com.ti.ccstudio.debugserver.win32.feature.group 7.4.0.1313) requires 'com.ti.ccstudio.installer.win32.feature.group 7.4.0.00015' but it could not be found
Cannot satisfy dependency:
From: CCS Flash Content 8.1.0.1297 (com.ti.dsflash.win32.feature.group 8.1.0.1297)
To: com.ti.ccstudio.debugserver.win32.feature.group 7.4.0.1313

And this "super informative" message appears:

All this, when all I want is a simple "empty example project with Main.c"...  which doesn't work with the GCC compiler...

Hi Chris,

 Please download the TivaWare from this link which provides a suite  of software tools for the development of Tiva C Series-based MCU applications.

 Once you download them you will find many examples as shown below.

The TivaWare examples are non TI-RTOS based. If you want to run some TI-RTOS examples, you will use CCS Resource Explorer to import these examples. I will suggest you start with the TivaWare examples first and once you are familiar with the device you can move on to play with the TI-RTOS examples. 

cb1_mobile said:

Piggy-Backing your code - w/in a Vendor Supplied/tested Project - is 'absolutely the way to go!       Allez!

int main(void)
{
	return 0;
}

I used CCS 8.1.0 to create a new "Empty project (with main.c)" using the GCC 7.2.1 compiler for a TM4C1294NCPDT and the program went to the Fault ISR when started a debug session. I.e. the default linker scripts supplied with the "latest" CCS 8.1.0 still have the problem.

Christopher Weber said:

So I can find nothing that tells it to jump to "ResetISR" when the debugger loads.

Taking your Project0 example for the GCC ARM, before the "Entry(...)" was added to the GCC linker script, the entry point in the ELF header is the address 0x208 which is the start of the .text segment shown in the .map file:

$ ~/ti/ccs810/ccsv8/tools/compiler/gcc-arm-none-eabi-6-2017-q1-update/arm-none-eabi/bin/readelf -l Project0/Debug/Project0.out 

Elf file type is EXEC (Executable file)
Entry point 0x208
There are 5 program headers, starting at offset 52

Program Headers:
  Type           Offset   VirtAddr   PhysAddr   FileSiz MemSiz  Flg Align
  EXIDX          0x020b0c 0x00000b0c 0x00000b0c 0x00008 0x00008 R   0x4
  LOAD           0x010000 0x00000000 0x00000000 0x006d4 0x006d4 R E 0x10000
  LOAD           0x020000 0x20000000 0x000006d4 0x00438 0x00438 RW  0x10000
  LOAD           0x020b0c 0x00000b0c 0x00000b0c 0x00008 0x00008 R   0x10000
  LOAD           0x030438 0x20000438 0x20000438 0x00000 0x00240 RW  0x10000

 Section to Segment mapping:
  Segment Sections...
   00     .ARM.exidx 
   01     .intvecs .text .rodata .eh_frame 
   02     .data .jcr 
   03     .ARM.exidx 
   04     .bss 

Whereas after the "ENTRY(ResetISR)" was added to the linker script the entry point in the ELF header is now 0x2f1 which the map file shows is the address of the ResetISR function:

$ ~/ti/ccs810/ccsv8/tools/compiler/gcc-arm-none-eabi-6-2017-q1-update/arm-none-eabi/bin/readelf -l Project0/Debug/Project0.out 

Elf file type is EXEC (Executable file)
Entry point 0x2f1
There are 5 program headers, starting at offset 52

Program Headers:
  Type           Offset   VirtAddr   PhysAddr   FileSiz MemSiz  Flg Align
  EXIDX          0x020b0c 0x00000b0c 0x00000b0c 0x00008 0x00008 R   0x4
  LOAD           0x010000 0x00000000 0x00000000 0x006d4 0x006d4 R E 0x10000
  LOAD           0x020000 0x20000000 0x000006d4 0x00438 0x00438 RW  0x10000
  LOAD           0x020b0c 0x00000b0c 0x00000b0c 0x00008 0x00008 R   0x10000
  LOAD           0x030438 0x20000438 0x20000438 0x00000 0x00240 RW  0x10000

 Section to Segment mapping:
  Segment Sections...
   00     .ARM.exidx 
   01     .intvecs .text .rodata .eh_frame 
   02     .data .jcr 
   03     .ARM.exidx 
   04     .bss 

Note that when writing the Program Counter, the least significant bit sets the T bit in the Execution Program Status Register; where 0 = ARM state and 1 = THUMB state. The Cortex-M only support THUMB state, and the incorrect entry point of address 0x208 has the least significant bit clear and will probably cause as INVSTATE exception (hard fault) to occur when the debugger attempts to write the PC of of the incorrect entry point.

Christopher Weber said:

And the map files shows the entry point as _c_int00_noargs... Where did it get that from?

Christopher Weber said:

The vector table reset entry points to ResetISR as I would expect. So on the GNU... even if the debugger did not set the correct start point during the debug session, I see that a power cycle does go to the correct entry point (via the vector table).