CCS/MSP430F5244: Debugging issue

Hi,

Please check:
e2e.ti.com/.../231760

Hope this helps,
Rafael

Hi Rafael,
Sorry, I couldn't find the solution through this link. I tried rebuilding code, but it didn't help me.

Rafael,

I found the issue, calling the below function again and again causing that issue, if I comment calling that function then control works properly. I'm pasting that code below. Please let me know if  I'm doing anything wrong in the below function.

uint8_t Flash_WriteData(uint8_t* FlashAddress,uint8_t* DataAddress,uint16_t Len){
	uint16_t i=0;
	uint8_t LocArray[10],LoopCnt=0;
	memcpy(LocArray,FlashAddress,10);          // read the 10 databytes from the address where we want to write now
	for(i=0;i<Len;i++){
		LocArray[i]=DataAddress[i];
	}
	FCTL3 = FWKEY;                            // Clear Lock bit
	FCTL1 = FWKEY+ERASE;                      // Set Erase bit
	*FlashAddress = 0;                          // Dummy write to erase Flash seg
	FCTL1 = FWKEY+WRT;                     // Enable long-word write
	for(i=0;i<10;i++){
		FlashAddress[i]=LocArray[i];
		while(FCTL3 & BUSY){
		 if(LoopCnt++<100)
			 return (ERROR);
		}
	}
	FCTL1 = FWKEY;                            // Clear WRT bit
	FCTL3 = FWKEY+LOCK;                       // Set LOCK bit

	return (0);
}

Regards,

Dhananjay

Dhananjay,

Thanks for sending the snippet of code where this happens. I see you are calling the Runtime Support Library (RTS) function memcpy(). As the linked reference mentioned, the message shows up when a function from the RTS is accessed but the CCS debugger is not able to find its source code. You can verify this by putting a breakpoint at line 4 above and, when the device stops at it, you can then run a "Step Into" (press F5) to see the debugger display the screen you see.

This is normal for the functions from the RTS, given they are usually only auxiliary functions where most people are not concerned with its internal operations.

Additional details can also be seen n the short quicktip video below:
www.youtube.com/watch

Hope this helps,
Rafael

desouza said:

I see you are calling the Runtime Support Library (RTS) function memcpy(). As the linked reference mentioned, the message shows up when a function from the RTS is accessed but the CCS debugger is not able to find its source code.

Also, the "No source available for <address>" message can show up if the program has crashed such that the program counter is at a location which doesn't contain valid code.

In this case the message was "No source available for "0xe6774", and for a MSP430F5244 the address 0xe6774 doesn't contain any valid memory which therefore suggests the program has crashed.

Perhaps the CCS debugger "No source available for <address>" message could be improved by CCS indicating if the address is outside of the sections for the downloaded program, thus indicating a possible crash.

[One complication is that on some devices there are ROM functions which it is valid for the program counter location, but whose address is outside of the sections of the downloaded program.]

Dhananjay,

Chester has a good point. What I suspected it was a consequence of normal operation it is, in fact, a derailment of your code.

(just a parenthesis to the original discussion)

Chester,

>>Perhaps the CCS debugger "No source available for <address>" message could be improved by CCS indicating if the address is outside of the sections for the downloaded program, thus indicating a possible crash.

This is performed by the use of device dependent GEL scripts that can configure each and every detail of the memory map of the device. In certain cases the GEL is incomplete or non-existing (case for the MSP430 devices) and therefore the error message is misleading.

The debugger engine itself (called Debug Server) is independent of the configured device by design. This is partitioned this way so the development of the Debug Server core can be as independent and reusable as possible to support a wide range of cores (MSP430, DSPs, ARM, etc.)

Regards,
Rafael

If it so, Program should crash each and every time when I call the memcpy(), but it's not the case for me, very often I get that message. That means I hope some times it's working properly. Please let me knw if I'm wrong.

Regards,

Dhananjay

Dhananjay,

One detail that I find suspicious and may explain the inconsistent behaviour: there is a mix between a fixed array length of 10 and what is passed as an argument (the variable Len). For example, if Len > 10 you will perform out-of-bounds writes to the array LocArray in the first for() loop, which has unpredictable results.

I would double-check all these potential pitfalls in the whole code.

Hope this helps,
Rafael