function call fails when function address is specified

Kevin Russell said:

I wanted to locate the function at a specific location in Bank D

What is the specific address at which you are locating this function?

Kevin Russell said:

However when the call is executed the PC steps right over the function call as if it was not there.

Do you mean that the function code is not executed at all? Or just that the debug actions (step into etc) do not seem to follow the code execution? Would you be able to send us a simple project that can be used to reproduce the issue? That could help us identify if it is a compiler issue or a device/hardware issue and allow us to redirect the issue to the appropriate forum.

At the moment I have to believe that it would run if not in debug. The disassembled code looks correct to me. As an experiment I wrote a trivial function that behaves the same way.

#pragma LOCATION (0x21000)

int ExecuteFlash(int a)

{

int i=7;

i*=a;

return(i);

}

if you create a call to this function it is formed correctly as shown below

$C$L20:
0052de:   40B1 0006 0018      MOV.W   #0x0006,0x0018(SP)
128        a=ExecuteFlash(a);
0052e4:   411C 001A           MOV.W   0x001a(SP),R12
0052e8:   13B2 1000           CALLA   #ExecuteFlash
0052ec:   4C81 001A           MOV.W   R12,0x001a(SP)
130        break;

The debugger will skip over the call as if it is not there

however if you load the PC with 0x21000, the code is executed although you get a message the source code does not exist

ExecuteFlash
0CCF 0A5F 8C0F 0FCC 0110 FFFF FFFF FFFF FFFF
FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF
FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF

this is from the memory view at 0x2100                

I did setup the code again and used code to toggle an led. Without  the debugger attached the processor does a soft reset when it is to execute that code...It does not work even though it looks ok.

Kevin Russell said:

I did setup the code again and used code to toggle an led. Without  the debugger attached the processor does a soft reset when it is to execute that code...It does not work even though it looks ok.

It contains the following code:

#include <msp430.h>				

#pragma LOCATION (toggle_led, 0x21000)

void toggle_led (void)
{
	P1OUT ^= 0x01;				// Toggle P1.0 using exclusive-OR
}

int main(void) {
	WDTCTL = WDTPW | WDTHOLD;		// Stop watchdog timer
	P1DIR |= 0x01;					// Set P1.0 to output direction

	for(;;) {
		volatile unsigned int i;	// volatile to prevent optimization

		toggle_led ();

		i = 10000;					// SW Delay
		do i--;
		while(i != 0);
	}
	
	return 0;
}

I didn't get exactly the same behaviour as you, since found that:

1) When run outside of the debugger the LED flashes, so the code is running OK.

2) In the debugger when attempt to "Step Into (F5)" the toggle_led function the debugger steps over the function.

3) In the debugger when "Assembly Step Into (Shift+Ctrl+F5)" into the toggle_led function the debugger does step into the assembler of the toggle_led function in the address 0x21000 in flash, however the the debugger reports there is no source available for the toggle_led function:

Therefore, it appears that the #pragma LOCATION is correctly placing the function at the requested address, but something goes wrong with the handling of the symbolic debug information. Not sure if the problem is in the debug information generated by the compiler, or the processing of the debug information by the CCS debugger.

I found the same results, but as a an experiment I made the Release the default re-setup all the compiler and linker parameters. I found the call actually worked and I could set breakpoints within the disassembly window. Other portions of the IDE still reported the code did not exist, but the program did break and did execute correctly. I believe the issue is in the CCSv6 IDE. The code is properly compiled and linked.

Kevin Russell said:

I found the call actually worked and I could set breakpoints within the disassembly window. Other portions of the IDE still reported the code did not exist, but the program did break and did execute correctly.

I was able to observe the same behavior. The code does execute correctly and you can step into it using the Assembly Step Into, however CCS does reports that there is "No source available for toggle_led....", so it looks like there may be something going on in the way the debugger is processing the debug information associated with that function.

I have filed a bug against CCS for this to be looked at and analyzed further. The tracking # is SDSCM00050764. You can track its status using the SDOWP link in my signature.