CCS/TM4C1294NCPDT: XDS100V3 and TM4C1294XL DAP issues and (Error -1170 @ 0x0)

Dear Jacobi.
Thank you very much for the answer! The issue did indeed appear on our developed hardware, but after using the evaluation kit (TIVA) with the debugger, we were surprised to see the exact same issue happen. We were suspecting hardware to be the issue, but it is hard to tell the issue, when it is appearing on the TIVA as well.
No changes have been done to the TIVA kit, since I read somewhere in the manuals that the debug IN option is available without modification of the board. I am powering the TIVA through the OTG (with the jumper config).

I am providing here to most abstract code snippet, where the issue happens. When I am stepping over the functions, the error appears when stepping over "IO_Analog_Initialize();":

void IO_Initialize()
{
	IO_Watchdog_Initialize();
	IO_EEPROM_Intialize();
	IO_SPI_Initialize();
	IO_Digital_Intialize();
	IO_Analog_Initialize();
	IO_PWM_Initialize();
	IO_UART_Initialize();
	IO_SMbus_initialize();
}

When I step into the IO_Analog_Initiliaze();, the code looks as the following, and I can step over all the functions, without the error appearing.

#include <stdint.h>
#include <stdbool.h>
#include "inc/hw_memmap.h"
#include "driverlib/rom_map.h"
#include "driverlib/sysctl.h"
#include "driverlib/gpio.h"
#include "driverlib/adc.h"
#include "driverlib/interrupt.h"
#include "driverlib/timer.h"
#include "inc/hw_ints.h"

#include "include/Event.h"
#include "include/IO.h"

#define ADC_RESOLUTION (double) 0xFFF
#define ADC_VOLTAGEMAX (double) 3.3
#define ADC_VOLTAGEMIN (double) 0

IOAnalogChannelCollection IO_Analog_Channels;
Event IO_Analog_ScanComplete;

static bool _initialScanPerformed = false;
static uint32_t IOAnalogBuffer[sizeof(IOAnalogChannelCollection) / sizeof(IOAnalogChannel)];

void IO_Analog_Initialize(void)
{
	Event_InitializeEvent(&IO_Analog_ScanComplete, "AnalogComplete");
	IO_Util_EnablePeripheral(SYSCTL_PERIPH_ADC0);

	memset(&IOAnalogBuffer[0], 0, sizeof(IOAnalogChannelCollection));

	MAP_ADCReferenceSet(ADC0_BASE, ADC_REF_INT);
	MAP_ADCHardwareOversampleConfigure(ADC0_BASE, 4); 

	uint8_t sequencer = 0;
	uint32_t index = 0;
	
	MAP_ADCSequenceDisable(ADC0_BASE, sequencer);
	MAP_ADCSequenceConfigure(ADC0_BASE, sequencer, ADC_TRIGGER_PROCESSOR, 3);
	MAP_ADCSequenceStepConfigure(ADC0_BASE, sequencer, index++, IO_Analog_Channels.Spare0.ADCInputChannel);
	MAP_ADCSequenceStepConfigure(ADC0_BASE, sequencer, index++, IO_Analog_Channels.PDU_24V.ADCInputChannel);
	MAP_ADCSequenceStepConfigure(ADC0_BASE, sequencer, index++, IO_Analog_Channels.PDU_12V.ADCInputChannel);
	MAP_ADCSequenceStepConfigure(ADC0_BASE, sequencer, index++, IO_Analog_Channels.PDU_5V.ADCInputChannel);
	MAP_ADCSequenceStepConfigure(ADC0_BASE, sequencer, index++, IO_Analog_Channels.PDU_4V5.ADCInputChannel);
	MAP_ADCSequenceStepConfigure(ADC0_BASE, sequencer, index++, IO_Analog_Channels.PDU_3V3.ADCInputChannel);
	MAP_ADCSequenceStepConfigure(ADC0_BASE, sequencer, index++, IO_Analog_Channels.Force.ADCInputChannel);
	MAP_ADCSequenceStepConfigure(ADC0_BASE, sequencer, index++, IO_Analog_Channels.PullForce.ADCInputChannel| ADC_CTL_IE | ADC_CTL_END);

	sequencer = 0;
	MAP_ADCSequenceEnable(ADC0_BASE, sequencer);
	ADCIntRegister(ADC0_BASE, sequencer, ADC0_Seq0Handler);
	MAP_ADCIntEnable(ADC0_BASE, sequencer);
	IntPrioritySet(INT_ADC0SS0,0);

	//Make sure an initial scan has been performed
	IO_Analog_BeginScan();

	while(!_initialScanPerformed)
		IO_Util_BlockForMs(1);

    	MAP_SysCtlPeripheralEnable(SYSCTL_PERIPH_ADC1);

    	MAP_ADCHardwareOversampleConfigure(ADC1_BASE, 16);
    	MAP_ADCSequenceConfigure(ADC1_BASE, 3, ADC_TRIGGER_PROCESSOR, 0);
    	MAP_ADCSequenceStepConfigure(ADC1_BASE, 3, 0, ADC_CTL_CH19 | ADC_CTL_END | ADC_CTL_IE | ADC_CTL_SHOLD_256);
    	MAP_ADCSequenceEnable(ADC1_BASE, 3);
   
    	ADCIntRegister(ADC1_BASE, 3, TouchScreenIntHandler);
    	IntPrioritySet(INT_ADC1SS3,IO_InterruptPriority);

    	MAP_ADCIntEnable(ADC1_BASE, 3);
    	MAP_IntEnable(INT_ADC1SS3);
}

void IO_Analog_BeginScan()
{
	MAP_ADCSequenceConfigure(ADC0_BASE, 0, ADC_TRIGGER_PROCESSOR, 3);
	MAP_ADCProcessorTrigger(ADC0_BASE, 0);
}

The error is as well also not appearing if I am just "running" the code.
What can be the issue?

Additionally, I can provide you with some fresh data from todays testing. When using the XDS100V3 with our developed board, I can step in the code until the same point, but if I run the code, I get a new error, which I do not get on the TIVA (eval kit):

CORTEX_M4_0: Can't Run Target CPU: (Error -2134 @ 0x0) Unable to control device execution state. 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 7.0.48.0)

I am attaching my schematic here over the JTAG interface on the developed board:

I have read various topics about the JTAG interface - some say that TCK should be pulled down, others say it is just as good to pull it high. Can this be the issue? Or is there some other explanation to why I get the additional error -2134 on the developed board? (in comparison to not getting it on the TIVA, with same setup)

carlsen81 said:

When I am stepping over the functions, the error appears when stepping over "IO_Analog_Initialize();"

Do note the following: (extracted from your code - those 2 function calls noted - are 5 calls apart):

• MAP_ADCHardwareOversampleConfigure(ADC0_BASE, 4);
• MAP_ADCSequenceStepConfigure(ADC0_BASE, sequencer, index++, ...

Concerns are these:

• Might MAP_ADCSequenceStepConfigure() become 'confounded' by the use of 'index++'? (especially if the MCU's 'ROM version' of that function is employed!)
• Vendor's Charles provided a terrific, in-depth, recent review of, 'ADC Hardware Oversampling'. (again - the use of 'index++' especially when HW Oversampling is deployed - appears 'risky.')

My 'caution' may be misplaced ... your 'replacing' any/all occurrences of  'index++'  with (boring) hard-coded values - appears a 'quick/easy' means to  'test that caution/concern'...    

In general - I'm 'all for'  use of such clever, adaptive, & expansive functional  'add-ons'  ...  provided that they,  'Do NO Harm!'      And that (harm) - or freedom from such - has (yet) to be (positively) determined...

The in-depth examination of, 'ADC Hardware Oversampling' appears here:    (a (very) full cup of coffee ... and/or other (legal) stimulant - may be required...)

https://e2e.ti.com/support/microcontrollers/tiva_arm/f/908/p/712037/2643942?tisearch=e2e-sitesearch&keymatch=ADC%20Hardware%20Oversampling#2643942

Dear cb1,

Thank you for the reply! I have tried to remove the parts that you are mentioning in the following order:

1) Comment out the Oversampling function call, to avoid using it --> no change in the error 1170 message when stepping over
2) Change the index++ to hardcoded values, along with the 1) --> no change in the error 1170 message when stepping over
3) Do 2) without 1) --> no change in the error 1170 message when stepping over

Reverted back, since no change was seen on the various points that you mentioned. 

Ralph Jacobi (UF):

I did change the setup on the developed board to the one that is found in your application guide, but the same error happened again when trying to run the code with the debugger on the system. That is a crucial thing that I have to fix, since I am not able to 1) run the code on the HW with the debugger, and 2) insert breakpoints on the developed HW with the debugger. It simple loses the target when a breakpoint is inserted...

Sorry the picture quality, I went for the quick'n'dirty "screenshot".

Any suggestions are still very much appreciated!! 

Dear Jacobi,

Thank you for your time, I have updated your list below - it was almost correct but with small modifications it appears as my experience in the lab:

1) If stepping over IO_Analog_Initialize, the Error -1170 DAP access lost occurs
2) If using custom board w/ XDS100v3, you can single step to IO_Analog_Initialize, and then trying to run from this point, you get "Can't Run Target CPU: (Error -2134 @ 0x0)", along with Error -1170 DAP access lost
2a) If you just free run instead of single step to IO_Analog_Initialize, you don't have an error, correct? If I free run on TM4C1294XL no issue - but on my board I get "Can't Run Target CPU: (Error -2134 @ 0x0)" whenever I free run instantly
3) Breakpoints do not work beyond IO_Analog_Initialize? Or is it just within the function that they don't work?  They never work on developed board. They work on TM4C1294XL
3a) Was breakpoint operation tested on the LaunchPad as well? See above.
4) The ICDI does not exhibit any of these behaviors Correct - everything works on both TM4C1294XL and my developed board when using the ICDI, but I do not like to use a modified TM4C1294XL inside my product.