1294 will only run while debugging

Paul B said:

Any suggestions on how I debug this issue?

Which compiler are you using?

The reason for asking is that the use of the GNU ARM compiler with SemiHosting enabled can cause the program to only run while debugging - see GNU examples for EK-TM4C123GXL fail to start unless debugger connected

Thanks Chester for your reply.

I connected tot he running target like you selected and it is stuck in the FaultISR.
I'm using the TI v5.1.9 compiler.

Any idea why the LM Flash Programmer does not work? Since that is using the ROM Boot loader it seems more hardware related.

Amit,

I uninstalled the driver and installed the driver from TivaWare_C_Series-2.0.1.11577 and the LM Flash Programmer software now works correctly. Thank you very much, I would have never found this without your help.

Paul.

Poster "Paul" wrote, "I would have never found this without your help."

May this post stand as "Vote #2" for that same sentiment?

Good/great as your availability & assistance is - should not this (very) inside info be better high-lighted - saving all from (quite predictable) delay/frustration?

Amit Ashara said:

but yet to see the light of new release.

And that (better, faster - seeing the light) is exactly the point!

Critical "insider data" (stockpiled) @ HQ - may not be best for your (hapless) client/users.  (poster Paul proves that)

Should not such data be "promoted" - placed w/some prominence - (by part no.) so that becalmed users may, "save themselves?" 

We note that (immediately) upon receiving that "insider-only" info - Paul quickly/easily dispatched his issue.  Such data - remaining "secret" - may not best serve your clients...

Thank you, Amit.  Your firm is not unique in, "locking down" such data.  Yet - as multiple business studies have revealed - "Quick, transparent communications" to your client-users proves superior to, "hoarding vital data - for too long - viewed only by, "insider eyes!""

There's the choice to, "Hide Weaknesses" or, "Parade Weaknesses."  No one expects perfection - these devices are highly complex.  Yet - allowing "known issues" to "stockpile @ HQ" clearly fails your clients & lessens the (rightful) pressure upon vendor staff to resolve such issues.  (i.e. one does not "have to fix" that which is denied!)

All vendors incur errata - goes w/the territory.  Getting (even) preliminary "fix" data out to your users - sooner rather than later - seems more motivating both to your client-users and to heralded, "fix staff."  (they may actually have to better apply themselves - gain larger budgets - and - more than once - client-users may suggest solutions and/or valid work-arounds - which never could occur if "insider data" remains (as is the case now) essentially restricted/hidden!)

May I share an "outsider" secret - we (know) that your firm (and similar others) are imperfect!  Placing known issues - quickly - in a searchable, central repository will not cause you to "lose face" in the eyes of most here.  Hiding or restricting those issues - sharing only "upon demand" (as just happened here) - is not famed for building trust or good client-user relations...

Our past success - taking small tech firm public - provided many of the methods/madness I (on occasion) attempt to share here - for the betterment of your forum...

Amit Ashara said:

have updated the "Diagnosing Common Development Problems and Tips for TM4C Devices" thread

Indeed - but (we suspect) for only that SINGLE issue!

How many (more) "known fixes or issues" remain "locked away" - @ HQ - thus unavailable to the becalmed/frustrated masses?  That's the "REAL" issue - is it not?   This clearly is not a "single issue" - instead it's much more a caring/alerting PROCESS!

Would be useful to learn which of the earlier post assertions "miss" your 100% agreement...  Love to know why "secrecy and/or critical data hoarding" (appear) to trump, "User Saving" quick/full disclosure.

Paul B said:

I am using a 1294KCPDT micro. The only option in Project Properties - CCS General for the device variant is a 1294NCPDT. I believe the only difference between the two is the amount of Flash memory, but could the bus error be related to this?

To set the correct amount of flash for the TM4C1294KCPDT change the linker command file to:

MEMORY
{
    FLASH (RX) : origin = 0x00000000, length = 0x00080000
    SRAM (RWX) : origin = 0x20000000, length = 0x00040000
}

[I checked CCS 6.01 and that has the TM4C1294KCPDT  and TM4C1294NCPDT devices available when creating a new project - not sure why the TM4C1294KCPDT  is missing from CCS  5.5]

Paul B said:

When I apply power to board and then attached the debugger to the running target it is stuck in the FaultISR.
I discovered that the NVIC_FAULT_STAT register indicates there has been an Imprecise Data Bus Error.

One of the causes I found for an error like this is the access of an invalid register.

See http://www.ti.com/lit/pdf/spma043 to understand how to analyze the reason for a FaultISR.

Debugging a ARM Cortex-M Hard Fault contains a hard-fault handler which can be used to save registers at the point of a hard fault to help determine the state of the program. The hard fault handler in that referenced freetos web site using GCC syntrax - there is an example for the TI compiler in 0257.TIVA_flash_write_bug.zip

Paul B said:

This appears to be a location in ROM?

Given that an Imprecise Bus Fault has occurred (NVIC_FAULT_STAT register is 0x0000.0400) I think you are going to have to disassemble the ROM around that address to determine the cause (as suggested by the Diagnosing Software Faults in Stellaris® Microcontrollers Application Report).

Also, according to Exception Dump Decoding Using the CCS Register View if you copy the  PC, SP and LR values from the exception stack frame into the corresponding registers in the CCS register view, CCS will usually provide a very useful call stack back trace in the debug window. If you can get a valid call stack back trace, will give a clue about the location in your code which triggered the problem. [I haven't tried this myself]

I'm not sure I understand what you are saying. This is what is in Flash at location 0.

Paul.

hello_test.zip

Hello_test.zip contains the modified hello project and a screen shot of the development environment after it is stuck in the FaultISR.

Thanks,

Paul.

This has gone on too long to capture my complete attention but perhaps (something) w/in the debug pod is (necessary) for correct operation - and is missing when that connection is pulled!

Usual suspects would be missing or inadequate JTAG pull-ups and/or Reset pull up and cap filter or the proper power routing to each/every MCU power pin and correct value caps upon the MCU's charge pump pin(s).

Poster would reduce wear/tear upon Amit by trying his suggested (known good, now) code upon a 2nd (ideally know good) board.  Single board "anomalies" are a "bear" to test/troubleshoot - (and this appears NOW likely suspect) and such consideration for the "lone" vendor expert seems (most) respectful and appropriate...

Paul B said:

I agree that it may be hardware related. I have checked and rechecked everything

You appear logical/methodical - yet in the effort to assist - we benefit from more specifics in your response.

Have you installed external pull-up Rs on each/every JTAG pin - in close proximity to the MCU?  If so - what are their values?  (relying upon MCUs internal Rs often proves troublesome)

What's the value of pull-up on MCU Reset line?  Is it close to the MCU's Reset - and accompanied w/bypass cap?  Have you ohmed out this R - to insure it's not mis-marked or misplaced?  (we've seen (somewhat) similar issues when the Reset pull-up was excessive)

Did you produce several such boards?  (our group always builds 3-5 proto boards - so that "A-B" tests may be accommodated - seems "false economy" to build only one)  (your time/effort - and that of those here - are not free!)   Should you have additional boards - does the issue persist - across those others?

As Amit reports using 25MHz xtal (and as that seems much more common in this vendor's Apps) urge you to make that change - and report.

When all else fails - have you scoped each JTAG, Reset, Boot-Loader "entry pin" and "charge pump" pin(s) - both when debugging and later - w/debug pod disconnected?  Does this investigation reveal or highlight any difference?

And for Amit - cannot tell if you employed any (or the same) boot-loader trigger pin - as poster Paul?  Believe that (all) this detail is necessary - boot-loader has great appeal (too much, we believe) yet extracts a huge price in delayed development & user frustration...  (that same variety of "boot-method" adds grave complications - very few users succeed quickly/cleanly - pointing to further detail - and more complete examples as, "next!"

Hi Amit,

From poster's very first post I quote, "I have configured BOOTCFG to use a push button to enter the USB boot loader."

There exists various "sprinklings of clarity" - but a well organized - detailed listing of fact- has not emerged to (apparently) either your/my satisfaction...

Greetings Amit,

Even some 40 posts in - poster's issue - and full, orderly disclosure of necessary (and sought) facts - remains clouded.

As with any boot-load scheme - great (spectacular?) attention to detail & methodical procedures must be enforced.

Poster has provided much needed data - but it's interspersed throughout this thread - complicating your job. (and that of your (semi-qualified) assistants...)

To my mind - this is a predictable result of the forum's failure to provide tight, methodical, post-creation (and construction) guidance.  Forum gains no advantage through your exhaustion - and doubtful that any future (similarly impaired) forum reader - will persist thru this (pardon) ramble...

There are 10K pull ups on the 4 JTAG lines. The JTAG connector is less than 0.25" from the chip and traces are short.

Reset has a 10K to VCC and a 0.1uF to ground. I also tried 10K without the capacitor and 1K/0.1uF. Parts are very close to chip.

There is a combined 3.52uF capacitance on VCC around the chip, and 3.3uF/0.1uF on the LDO pins.

I'll test with a 25MHz crystal today.  Tested with 25MHz crystal - issue remains.

I'm using the built-in ROM boot loader in USB mode. Pin PF3 has a 10K to VCC and a push button switch to ground.

This is the code I use to configure BOOTCFG

	volatile unsigned long regVal;
	regVal = HWREG(0x400FE000 + 0x1D0);       		//BOOTCFG
	if (regVal & 0x80000000) {                      //committed yet?
		HWREG(0x400FD000 + 0x000) = 0x75100000;    	//FMA=BOOTCFG "address"
		HWREG(0x400FD000 + 0x004) = 0x0000AC12;		//Port F3 low to initiate boot loader
		HWREG(0x400FD000 + 0x008) = 0xA4420008;    	//FMC=key+commit
		SysCtlDelay(100000);          			
	}

The USB boot loader with LM Flash Programmer works well, but the main software gets stuck in FaultISR after a reset or power up.

I have two boards, and they act the same.

Great that - under Amit's guidance - Paul persisted and solved issue.   Hurray.

That said - we too noted his, "0000.AC12" values for BOOTCFG Register.

Paul characterizes as, "nugget of knowledge" - yet may we ask where Amit's "0xFFFF.ACFE" (fixing) value can be found.  (in the MCU literature)

Congratulations to Amit/Paul - yet the "how & where" of that (apparently) hidden (and fixing) value deserves (some) explanation...