TM4C1294NCPDT: Programming/Run issue with TM4C1294

Hello Richard,

If it can be programmed at all, then that would usually indicate that the issue may be with the firmware itself.

Do you have JTAG access? If so you can use CCS Uniflash to Unlock the device. Then I would recommend trying some simple TivaWare code to see if the oscillator works correctly with a basic program on the board. If so then we can debug how your code might be impacting the startup.

Ralph,

Well. I unlocked the processor and programmed the kernel hello example. As soon as the code is programmed I get the following error:-

CORTEX_M4_0: JTAG Communication Error: (Error -1170 @ 0x0) Unable to access the DAP. Reset the device, and retry the operation. If error persists, confirm configuration, power-cycle the board, and/or try more reliable JTAG settings (e.g. lower TCLK). (Emulation package 8.4.0.00006)
CORTEX_M4_0: Failed to remove the debug state from the target before disconnecting. There may still be breakpoint op-codes embedded in program memory. It is recommended that you reset the emulator before you connect and reload your program before you continue debugging

Richard.

Ralph,

Well I did some more testing. The following code runs without any issues.

#include <stdint.h>
#include <stdbool.h>
#include "driverlib/sysctl.h"
/**
* main.c
*/
int main(void)
{
volatile uint32_t counter = 0;

while(1){
counter++;
};
}

The following code fails after setting the external oscillator.

#include <stdint.h>
#include <stdbool.h>
#include "driverlib/sysctl.h"
/**
* main.c
*/
int main(void)
{
volatile uint32_t counter = 0;

SysCtlClockFreqSet((SYSCTL_XTAL_25MHZ |
SYSCTL_OSC_MAIN |
SYSCTL_USE_OSC), 25000000);
while(1){
counter++;
};
}

Richard.

Ralph,

Same result.

int main(void)
{
volatile uint32_t counter = 0;

SysCtlClockFreqSet((SYSCTL_XTAL_25MHZ |
SYSCTL_OSC_MAIN |
SYSCTL_USE_PLL |
SYSCTL_CFG_VCO_480), 120000000);
while(1){
counter++;
};
}

CORTEX_M4_0: JTAG Communication Error: (Error -1170 @ 0x0) Unable to access the DAP. Reset the device, and retry the operation. If error persists, confirm configuration, power-cycle the board, and/or try more reliable JTAG settings (e.g. lower TCLK). (Emulation package 8.4.0.00006)
CORTEX_M4_0: Failed to remove the debug state from the target before disconnecting. There may still be breakpoint op-codes embedded in program memory. It is recommended that you reset the emulator before you connect and reload your program before you continue debugging

Hello Richard,

Can you share the part number for your crystal?

Have you double checked the part number on your PCB? Had one case of a wrong part number being installed before so would be good to cross check.

What capacitor values have you used?

Have you checked with an ohmmeter that all connections are being made correctly?

I suspect that issue relates to the crystal somehow.

Ralph,

NX3225GA-25.000M-STD-CRG-2, 2K resistor and two 10pf caps.

Richard.

Good job Ralph,

Wow - (that) is surprising!    For many years - working w/MANY ARM MCUs - from multiple vendors - we've rarely (or never) noted such a "tight" xtal bypass 'cap' requirement.   Especially so when "One & only one" programming attempt succeeds!

May we ask if "25MHz" is the upper limit of the MCU's external, crystal acceptance?   (we believe the 25MHz frequency was chosen to enable Ethernet or USB operation - is that correct?)

Due to the "tightness & apparent unforgiving" nature of that specification we must wonder if 'that xtal's use" should continue (be blessed) as:

• the xtal, bypass caps & MCU age
• temperature transitions to (near) extremes
• process variations occur - among the xtal, caps and/or MCU

Might those original caps have been "accurately" measured - and confirmed to be 10pF?   (Poster noted they had been measured)

And - as poster originally noted, "Used this processor on many designs without issue" had those (past) designs succeeded while employing the (most recent) xtal & bypass caps?    

That "One & only one" programming limitation (remains) chilling!    Should not (some) concerns continue?    Is it not fair/proper to note that the "Fix" has not had (sufficient) time to be truly tested?

Hi cb1,

cb1_mobile said:

May we ask if "25MHz" is the upper limit of the MCU's external, crystal acceptance? 

Yes it is.

cb1_mobile said:

And - as poster originally noted, "Used this processor on many designs without issue" had those (past) designs succeeded while employing the (most recent) xtal & bypass caps?   

Would be interesting to know.

cb1_mobile said:

Due to the "tightness & apparent unforgiving" nature of that specification we must wonder if 'that xtal's use" should continue (be blessed)

It's actually the xtal used on our EK-TM4C1294XL LaunchPad and we have not had issues with that or returns (that we are aware of) for such an issue so I think the xtal is pretty robust.