Bad Controller Handle (error -121) and unable to access the DAP (-1170)

Peter Drexel said:

Now, I was able to connect up to this processor beforehand and I was able to download the barebones "typical_tivaTM4C123BE6PZ" sample project and inserted a "while(1);" at the start of main. Once I disconnected, I was unable to reconnect. I have tried this with 2 of our custom boards (at least its consistent).

 Hi Peter, your writing is not so clean, from this sentence I feel as you get programmed just one time?

 Anyway, connecting to something other the XDS100 interface is working as expected?

 I read you checked connection to JTAG, are power supply and more important VCCD decoupling and voltage on specs?

 Chip stay cold or get hot?

Hello Peter,

There are two contradictory statements. The first is that the while statement is at the beginning of the main function and the other is that the clock is being locked at 80MHz.

Can you post the code as there may be something with the code too?

Did you try reducing the TCK frequency or use the Stellaris ICDI to unlock the device using the UNLOCK procedure.

Regards

Amit

Robert,

Sorry for any and all of the confusion. Yes, I was able to connect and download the sample program once. Now I cannot connect to the processor. I get the -121 and the -1170 errors.

I am able to use this XDS100 debugger to download and debug other processors. It does pass the Test Connection test where you modify the target configuration.

The power supply is stable and we are able to connect and debug the other processor on this board using the 3.3V. I'm not sure what you mean by the VCCD, is that supposed to be VDDC instead? As is stands right now, the two VDDC pins are connected and they have a 10uF cap going to ground, which is larger than the 4uF max. I can change that out. I am getting 1.213V for VDDC. My VCC is at 3.3V

The chip is cold. 

Let me know what else you want me to take a look at.

Amit,

Thanks for the quick response.

The while statement in the begining of the code was something I put in there to prevent it from doing anything bad and messing up the processor. As this was the first time on a new board I wanted to ease my way in. 

By 80MHz, that's the default CPU clock frequency for this product. Does that clear those parts up? Let me know if I need to clarify things differently.

I have attached my code for you to take a look at. Let me know if I left something out. I'm a bit new with CCS6.0

0624.typical_TivaTM4C123BE6PZ.zip

I was using the default 1MHz TCLK frequency. I tried the adaptive with the user specified limit at 1.0Mhz and I still had the same issue. Do you recommend a value to try for the TCLK?

Thanks,

~Peter

Hello Peter,

1MHz TCK is OK and adaptive will not work as we do not support RTCK which is required for Adaptive clocking.

Thanks for sending the CCS project (and as it seems it involves RTOS, it will take me some time to get my devices locked up.. if I can)

Also an important thing to note is that if there is code in Flash then the System Clock will remain at 16MHz PIOSC till the PLL is locked by the user code and not 80MHz.

Regards

Amit

Amit, 

I just replaced the old locked CPU with a fresh CPU and now I'm seeing the same issue with a fresh CPU without loading any software to the chip.

I did see a new error once, and that was a -1063 device ID is not recognized or supported by the driver. I have not been able to replicate this since. Not sure if this helps any. 

~Peter

Amit,

Here is some more information.

We have 10K pullups on of the JTAG lines. We used to have the ability to mux the JTAG with a M4C129. On the custom board I was able to connect to the M4C129 and debug on it. I have since bypassed the muxing capability in order to isolate the issue with this processor. 

If you think of anything else that you might need, give me a heads up.

Thanks,

Peter

Hello Peter

When you mentioned bypass the Muxing, then did you physically remove the mux chip and re-wire the board? If yes, then I suspect a timing issue with the mux output may be skewing the data

On the other hand if it hard tieing the mux control, then I am not sure as to what the cause may be w/o having the board to debug.

Also was the 10K pull up before the mux or after the mux? Reason, the Mux switchover may have been causing an issue.

Regards

Amit

Hi Amit,

So I bypassed the mux by physically removing the mux chip and re-wired the incoming JTAG.

There was a 10K before and after the mux, but with removing the mux hardware, we removed one of the 10Ks. With the mux removed the problem is hiding somewhere else. I only mentioned the muxing to note that I could communicate using the JTAG interface.

~Peter

Hello Peter

My suspicion would be the timing variation which can break DAP communication with JTAG. Please note that the Test Connection is nothing but a simple Shift and capture.

My bet would be on the sampling of the TDO by the Debugger is getting messed up.

Regards

Amit

I'll jump in to add some comments. The customer's board has a TM4C129x, TM4C123x, and single JTAG connector on it. There is a virtual mux between then JTAG connector and the TM4Cs. It is implemented with buffers in which the outputs are enable to allow connection from the JTAG connector to either the TM4C123x or TM4C129x. There are 10K pullups to 3.3V on each side of the mux/buffer for each of the nets (TCK, TMS, TDI, TDO). In this configuration, they can get the XDS100 to connect to the TM4C129x (as well as everything else associated wih the debugger).. When the mux/buffers is configured to connect the XDS100 to the TM4C123x, they get the "not able to connect" error as described.

They removed the mux and one set of pullup resistors from the board and added wires to hardwire the JTAG connector to the TM4C123x. This leaves 10K pullup resistors on each JTAG net. This was done to eliminate the mux/buffer. They still get the "not able to connect" error.

This unable to connect to the TM4C123x happends on both of their boards. They also replaced the TM4C123x on a board, thinking it may be in a locked state. The new part demonstrated the same error.

What are all the factors that can result in this error? It sounds like a hardwar probelm but we can't figure out what it is.

Hello Tom,

Which JTAG Signal line was it on which the buffers were removed?

Regards

Amit

Buffers were removed for TCK, TMS, TDI, and TDO.

So it was unable to connect with all four signals through the buffer as well as all four signals bypassing the buffer.

Hello Tom,

Looks to me to be a timing marginality being seen by the TM4C device. You may want to review the timing skew and the JTAG timing requirements from TM4C

Regards

Amit

Can you please explain your thoughts on reviewing the timing? Niether direct connect of JTAG connector or through buffer does not connect and the traces are short (a few inches).

Hello Tom,

All the signals are seeing an equal amount of delay if the trace lengths are matched on the board and assuming that the buffers have the same timing from input to output.

However, the launch of the JTAG TDI and TMS from the debugger or capture of the TDO with respect to TCK may not be meeting the requirement from the TM4C device with sufficient margin.

As I read the post, removing one of the buffers allows the debug to happen. I would suspect that the removal of one the buffer allows the timing to be met.

Regards

Amit

No, debugging on the 129 works. It never works on the 123.

Hello Tom,

Can you possibly share the schematics of the custom board.

Regards

Amit

Amit, 

I can share some of it. I'd rather not post it right up here. Is there a good way to just send you guys the files?

Thanks,

~Peter

Peter,

You can send it to me, and I can route it out to Amit and any other needed members of the Applications team.

cpl@ti.com

Best,

Cameron P. LaFollette

Thanks Cameron. Its on its way.

Minor update. We've made a little progress. We put the mux chip back in and lifted all of the pins on the 123 chip and then re-soldered the JTAG, power, and the reset pins and now we can connect! Hooray!

Now, our manufacturing person is going through and soldering down a pin and trying to see if we can still connect and moving onto the next one. Does anyone have a suggestion on which pins might be the culprits? I recommended the NMI pins (pin 100 and pin 40).

Thanks again,

~Peter 

[edit wording]

Hello Peter,

That is good news indeed. A GPIO Pin even NMI, if triggered will cause the CPU to to go into the default NMI Handler. However JTAG debug is something that happens outside the CPU's functional path.

Do keep us posted, so that we can help out if a Pin is indeed isolated.

Regards

Amit

2nd update:

So after rewiring all of the pins to the processor we were able to consistently connect to the 123 CPU. We then went to load a program and we got stuck in a weird place in the software. It seems to be that we're in a routine in the exit.c file (the loader_exit() subroutine). We then move to the abort() routine and hang out indefinitely.

/****************************************************************************/
/*  EXIT.C v5.1.7                                                           */
/*                                                                          */
/* Copyright (c) 1995-2014 Texas Instruments Incorporated                   */
/* http://www.ti.com/                                                       */
/*                                                                          */
/*  Redistribution and  use in source  and binary forms, with  or without   */
/*  modification,  are permitted provided  that the  following conditions   */
/*  are met:                                                                */
/*                                                                          */
/*     Redistributions  of source  code must  retain the  above copyright   */
/*     notice, this list of conditions and the following disclaimer.        */
/*                                                                          */
/*     Redistributions in binary form  must reproduce the above copyright   */
/*     notice, this  list of conditions  and the following  disclaimer in   */
/*     the  documentation  and/or   other  materials  provided  with  the   */
/*     distribution.                                                        */
/*                                                                          */
/*     Neither the  name of Texas Instruments Incorporated  nor the names   */
/*     of its  contributors may  be used to  endorse or  promote products   */
/*     derived  from   this  software  without   specific  prior  written   */
/*     permission.                                                          */
/*                                                                          */
/*  THIS SOFTWARE  IS PROVIDED BY THE COPYRIGHT  HOLDERS AND CONTRIBUTORS   */
/*  "AS IS"  AND ANY  EXPRESS OR IMPLIED  WARRANTIES, INCLUDING,  BUT NOT   */
/*  LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR   */
/*  A PARTICULAR PURPOSE ARE DISCLAIMED.  IN NO EVENT SHALL THE COPYRIGHT   */
/*  OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,   */
/*  SPECIAL,  EXEMPLARY,  OR CONSEQUENTIAL  DAMAGES  (INCLUDING, BUT  NOT   */
/*  LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,   */
/*  DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY   */
/*  THEORY OF  LIABILITY, WHETHER IN CONTRACT, STRICT  LIABILITY, OR TORT   */
/*  (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE   */
/*  OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.    */
/*                                                                          */
/****************************************************************************/
#include <stdlib.h>
#include <_lock.h>

void                     (*__TI_cleanup_ptr)(void) = NULL;
void   _DATA_ACCESS      (*__TI_dtors_ptr)(int)    = NULL;

/****************************************************************************/
/*                                                                          */
/* LOADER_EXIT -							    */
/* 									    */
/* SET C$$EXIT LABEL SO THE DEBUGGER KNOWS WHEN THE C++ PROGRAM HAS	    */
/* COMPLETED.  THIS CAN BE REMOVED IF THE DEBUGGER IS NOT USED.		    */
/*                                                                          */
/****************************************************************************/
static void loader_exit(void)
{
#if defined(EMBED_CIO_BP)
   __asm("         .global C$$EXITE");
#if defined(__32bis__)
   __asm("C$$EXITE:.word 0xDEFED0FE");
#else
   __asm("	 .align  4");
#if defined(__big_endian__)
   __asm("C$$EXITE:.half 0xDEFE");
#else
   __asm("C$$EXITE:.half 0xD0FE");
#endif /* __big_endian__ */
#endif /* __32bis__      */

#else  /* !EMBED_CIO_BP */
   __asm("        .global C$$EXIT");
   __asm("C$$EXIT: nop");
#endif
}

/****************************************************************************/
/* EXIT() - NORMAL PROGRAM TERMINATION.                                     */
/****************************************************************************/
extern void exit(int status)        
{
   /*-------------------------------------------------------------------*/
   /* MUST LOCK WHEN ACCESSING GLOBALS, like __TI_dtors_ptr,            */
   /* __TI_cleanup_ptr                                                  */
   /*-------------------------------------------------------------------*/  
   _lock();

   /*-------------------------------------------------------------------*/
   /* BOTH ATEXIT FUNCTIONS AND STATIC OBJECT DESTRUCTORS ARE           */
   /* REGISTERED IN A LINK LIST TO BE PROCESSED BY THE FUNCTION POINTED */
   /* TO BY __TI_dtors_ptr.  PROCESS THEM NOW.                          */
   /*-------------------------------------------------------------------*/
   if (__TI_dtors_ptr)  (*__TI_dtors_ptr)(status);

#if defined(_C_IN_NS)
   /*-------------------------------------------------------------------*/
   /* _C_IN_NS IS A FLAG WE SET ONLY IN DINKUMWARE HEADERS. SO US IT TO */
   /* TELL IF IT IS IN DINKUMWARE.                                      */
   /* FOR DINKUMWARE LIBRARY, CALL CLOSEALL() TO CLOSE ALL IO STREAMS.  */
   /* CLOSEALL() is a DINKUMWARE FUNCTION DEFINED IN FCLOSE.C TO CLOSE  */
   /* ALL OPENED IOSTREAMS.                                             */
   /*-------------------------------------------------------------------*/
   closeall(); 
#else
   /*-------------------------------------------------------------------*/
   /* IF FILES ARE POSSIBLY OPEN, __TI_cleanup_ptr() WILL BE SETUP TO   */
   /* CLOSE THEM.                                                       */
   /*-------------------------------------------------------------------*/
   if (__TI_cleanup_ptr)  (*__TI_cleanup_ptr)();
#endif

   _unlock();
   abort();
}

/****************************************************************************/
/* ABORT - ABNORMAL PROGRAM TERMINATION.  CURRENTLY JUST HALTS EXECUTION.   */
/****************************************************************************/
void abort(void)
{
    loader_exit();
    for (;;);   /* SPINS FOREVER */
}

We do have an eval kit (EK-TM4C123GXL) that we repurposed to have the same 123 chip as our custom board. Using the same exact project that I was trying to load in our custom board, I can load the project into the eval kit without an issue. The main difference is that on the eval board we only connected the necessary pins for JTAG communication.

Our next step is to take the CPU off of our custom board again, rewire only the pins necessary for JTAG and connect and load the program.  If that works, then we go pin by pin (again) to see where it breaks.

Hello Peter,

So if I read the test correctly, connecting all the pins again the TM4C123 gets connected over JTAG but the software does not work properly on the custom board?

The original issue of the JTAG not connecting is still unresolved. If you have a spare board (and time) it would be important as well, since the SW now behaves differently as there may be a link to consider as well.

Regards

Amit

Good Morning Amit,

Yes, the software does not work correctly. We never actually get to the main loop. We are in this exit function. Does the exit.c file mean anything to you at all? Why would I be in there? How do I get there? What is its purpose? How could that code be called if the program never calls it?

~Peter

Hello Peter,

I would look at the NVIC's FAULTADDR and FAULTSTAT register to begin with. The address is 0xE000ED28 and 0xE000ED38.

Regards

Ami

Amit,

We got the processor back down to just the JTAG and power and we were stuck. We then took our brownout protection circuit off the system and we're able to connect and debug some code! Its actually working!

Now, we need to see whats going on with our reset circuit, but that's not something that we should be able to handle that.

Thanks for all the help guys!

~Peter

In the interest of, "Apples to apples" was that, "Brownout protection circuit implemented exactly the same on your 129 board?"  Any circuit differences - especially regarding power and/or reset - should have been closely monitored...

Cb,

The two processors plus two other devices were all on the one brownout protection circuit. We implement a similar design in some of our other products. The thought was that we were treating them all as apples, but its looking like someone is an orange, mayhaps a banana.

Hello Peter

The Brownout threshold of TM4C123 is higher than TM4C129. That indeed means that the voltage dip will be recognized by the TM4C123 before it can reset TM4C129.

Is the on board LDO supplying enough current to not cause a load regulation dip

Regards

Amit

Amit Ashara said:

Brownout threshold of TM4C123 is higher than TM4C129

Amit's mighty, "Insider info" once again comes to the rescue.

But - as he notes - why is that brownout triggering during debug/programming? 

While he looks @ LDO I don't know if that's been established - whatever is providing your 3V3 - or the voltage being monitored for, "brownout" appears in need of, "Stiffening!"  (if it triggers during debug/programming you've little safety margin...)

Dawns that with your mention of multiple MCUs - other components - you may be overstressing 3V3 or (more likely) that input voltage being "monitored for brownout!"  (my guess!)

This had to be making you Krazy - so glad it appears now under control...

Hello cb1,

I should have been more precise in stating that this BOR threshold is based from the data from the two data sheets. But why during debug/programming, is something very strange. Could it be that the voltage is not in fact at 3.3V but closer to 3.0V~2.9V already.

Regards

Amit

Hello Amit,

In the past - most of our MCU designs had to withstand the rigors of automotive, marine - even spacecraft.  (one of ours successfully flew w/the Shuttle)  And - most always - we "sniffed for brownout" far ahead of our 3V3 (or 5V) Regulators. 

Our objective was the, "earliest possible detection" of pending, "Loss of Power."  This, "forewarning" gave us the time to save critical data - and order a safe/methodical system shut-down.

So - it may be that my '"sense" of "brownout" exceeds/extends upon the MCU-centric meaning.

As to 2V9-3V0 - that's bad practice - is it not?  We "bin test" each/every 3V3 regulator to insure we're "centered" w/in the MCU's spec.  If a 3V3 regulator descends to 2V9 - usually - that's a strong indicator of that 3V3 regulator being, "Voltage starved" itself.  And - as mentioned atop this post - that can  be detected early - so as not to bring torment to any MCU.  (this is no weakness w/in your parts - it's bad system design - in my (humble) book...)

Hello cb1,

Thanks first of all on the experience that you bring in to the forum to share.

Sometimes using two devices with similar functions (123 and 129 are not very similar) allows for such misses. Some time back I had replaced a ADC (manufacturer name withheld) on my hobby circuit, with a sequential numbering on the device w/o realizing that previously NC was not an external reference pin/

Regards

Amit

@Amit,

That's likely happened to us all, my friend.  (Amit's replacing one device w/closely marked {yet different performing} 2nd...)

While Petrei/Roberto/I/others cannot equal the "inside/specialty info" and the great time/effort you regularly bring/display here - on some occasions our broad-based experience has relevance - may speed/enhance the efforts of others.  (and - surely beats "other" manifestations of, "court ordered, community service")  kidding... (damn car likes to speed - I'm blameless!)

Likely that I too would have failed to check 129 vs 123 spec - as (appears) to have plagued our poster.  Yet - first thing we'd always be sure to check is, "adequacy of power" and proper "reset" circuit.  Some way/how - it appears that was missed. 

As a, "Sanity check" - nearly every board we design/build employs at least one led - which executes short/simple/early blink code - confirms that the MCU "sorta works" - and clearly marks any (unwanted) recurring Reset!  Such would have "saved" this poster - would it not?  (if we can conclude that JTAG failed due to MCU drifting in/out of reset...)

For the record - as so much of your time/energy was invested here - surely hope poster will properly, "close this loop!"