TIVA C "Debug Port error occurred" after compiling

Hello Alex,

The SysCtlDelay is called from the precompiled driverlib. Since the path is embedded, it will pop the message indicating it cannot find the source code. If you recompile the driverlib and use the recompiled version, then the source code will not give an error.

Alexander Ahrens said:

I tryed erasing and unlocking with the LM FLASH but nothing happens,

What were you expecting?

Regards

Amit

Alexander Ahrens said:

Then flashing is finished the CSS didn't jump in the main rountine and I have no resume button. If I cklick on the suspend button I get the error

"CORTEX_M4_0: Error: Debug Port error occurred." on the console and "No source available for "SysCtlDelay() at C:/.... 0x817d00b0{4}" in a new c window

The reported address 0x817d00b0 is not part of the valid memory map, which could explain the "CORTEX_M4_0: Error: Debug Port error occurred."

To debug where the crash is occurring, under CCS Project Properties -> Debug -> Auto Run and Launch Options -> Auto Run Options untick "On a program load or reset" and "On a reset". When the CCS debug session is started, after flashing the processor will be left at the reset vector and you can single step the start-up code to find the point at which the failure occurs (although CCS may only display assembler for some of the start up code).

Alternatively, Can you post the CCS project which is failing to reach main as may be able to identify what is causing the failure to reach main?

Hello Chester

I tryed your suggested chances but I get the same error messanges befor I can do anything, furthermore CCS give me the this error "No source available for "0xffffffff"

2388.SD_Card.zip

Hi Alexander,

Do U have check mark in the debug settings, the box is checked to jump to (main) on run? The instruction pointer is jumping to the end of address space? That assumes debug writes the program to flash (total bytes), for what ever reason. 

Possibly may even be a minor program bug or memory configuration issue in(startup_ccs.c / prog_ccs.cmd) causing the debug simulator jumping to end of address space?

Alexander Ahrens said:

I tryed your suggested chances but I get the same error messanges befor I can do anything, furthermore CCS give me the this error "No source available for "0xffffffff"

Some comments:

1) When attempted to compile the code got errors about QEI_CONFIG_INVA and QEI_CONFIG_INVB not being defined. To prevent the compilation errors added the following to QEI.c:

#define QEI_CONFIG_INVA 0x00000200
#define QEI_CONFIG_INVB 0x00000400

Where these definitions in your TivaWare, or did you have to add them to TivaWare?

2) The FaultISR resets the processor:

// This is the code that gets called when the processor receives a fault interrupt.
static void FaultISR(void)
{
	SysCtlReset();	// Reset the processor
    while(1) {}  // Enter an infinite loop.
}

Can you try commenting out the call to SysCtlReset() from the FaultISR and see if the processor ends up in the FaultISR?

[Not sure if the failure triggers entry to the FaultISR which resets the processor which then confuses debugging.]

Debug simulator won't jump to the main routine dynamically. One must enter in debug settings the program Run function name and check the box for what ever function() now a compiled (symbol) is the very start of your code, often simply the symbol (main).  You can find the reset jump instruction or entry Symbol in the debug folder created during CCS compile with your program name + suffix (map).

Alexander Ahrens said:

The processeor ended in the FaultISR after I deletet SysCtlReset(), A bit debugging shows that the main is reached, but then my programm get called, interruptCtrl() is the first, the processor jumps to the FaultISR. The compiler give me no errors and with the first program, init(), there is no problem.

[There is probably a bug in the program which causes entry to the FaultISR, but I haven't had a chance to study the program yet]

Alexander Ahrens said:

The processeor ended in the FaultISR after I deletet SysCtlReset(), A bit debugging shows that the main is reached, but then my programm get called, interruptCtrl() is the first, the processor jumps to the FaultISR. The compiler give me no errors and with the first program, init(), there is no problem.

	QEIIntClear(QEI0_BASE,QEI_INTDIR);

The FaultISR occurred because the code had not enabled the QEI0 or QEI1 peripherals before attempting to access them. To stop the FaultISR the QEI0 and QEI1 peripherals were enabled by adding the following to the init function (after the SysCtlPeripheralEnable(SYSCTL_PERIPH_HIBERNATE):

	SysCtlPeripheralEnable(SYSCTL_PERIPH_QEI0);
	SysCtlPeripheralEnable(SYSCTL_PERIPH_QEI1);

[Following this change the program was waiting in the VS1063sendCMD() for the VS1063 to be ready - which isn't fitted on the board I was using]

Alexander wrote: @ BP101 the box is unchecked, after flashing the debugger goes to the reset routine.

In the absence of any further posts from Alexander or confirmation of first post being answered.

Best debug simulations producing fewer crashes etc.. have at least one break point set and placed after the reset jump into (main). One must Pause MPU before attempting any stepping. Better debug simulations occur by stepping into (F5) the first few instructions often an MPU clock, stepping over (F6) others up to the first set break point. Then set other desired break points or traverse to previously set ones like this; Highlight desired break point, right click on drop menu, select (move to line) before hitting F5 or F6. That puts the debug simulator instruction pointer at the break point location.

Perhaps turning off any debug settings to process interrupts during single stepping may avert interrupt exception handlers from stopping the simulation. Then one can view the debug Registers and may get a glimpse of what is going on or not going on. The ICDI debug simulator is a bit touchy at best and requires much patients and strategy. May require a few MPU core resets in the process just to get the debug ball rolling especially if program bugs are the issue.

Good luck Mr. Phelps this tape will self destruct in 5.4.3.2 ....

Hello Chester,

thank you and all others for your help, I know enable all peripherals at first and it works.