Due to the U.S. Thanksgiving holiday, please expect delayed responses during the week of 11/22.

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

MSP430FR5962: Debug config build bricking after disconnecting FET

Part Number: MSP430FR5962

I have some very strange behavior going on and I'm not able to pinpoint why exactly it's happening.  Everything runs exactly as expected in both release and debug configurations with the FET attached.  However, on a debug load, disconnecting it from the FET tool causes it to brick completely.  When doing a simple load & program without the debugger, the device will not boot (again, only in debug).

I tore apart my code and added everything back in one by one until narrowing it down to one function, inside a switch case.  What's interesting is that it doesn't seem to be a specific line or function that breaks it- uncommenting anything inside that switch case will cause the device to brick as I explained.  And this code is not even being called at run time - it's existence in the .code section breaks the device - and ONLY when the FET tool is disconnected.

// Works
case(CASE_1):
	if (!parsing_string) {
		return IBL_ERROR_LEX;
	}
	// commented_code1
	// commented_code2
	break;

// Device bricks when unplugging FET tool (even though this code is never reached)
case(CASE_1):
	if (!parsing_string) {
		return IBL_ERROR_LEX;
	}
	un-commented_code1
	un-commented_code2
	break;

I thought this could possibly be a stack size issue, but again - the code is never even called anyways.  I tried more than doubling (160 -> 1024) the stack size anyways but it didn't make a difference.  I'm thinking this is a compiler issue somehow, but the build settings are nearly identical between release and debug - including optimization level.

  • Hi, Brett, 

    I never ran into this issue before. What is the un-commented_code? How about commenting the if () {} as following? 

    case(CASE_1):
        //if (!parsing_string) {
        //    return IBL_ERROR_LEX;
        //}
        un-commented_code1
        un-commented_code2
        break;
    Thanks,
    Lixin 
  • char *ibl_strchr(const char *s, const char c) {
    	while (*s != (char)c)
    		if (!*s++)
    			return NULL;
    	return (char *)s;
    }
    
    // Example 1: Works 
    case(CASE_1):
        if (!parsing_string) {
            return IBL_ERROR_LEX;
        }
        // parsing_string = ibl_strchr(parsing_string, 'x');
        break;
    
    // Example 2: Device bricks when unplugging FET tool (even though this code is never reached)
    case(CASE_1):
        if (!parsing_string) {
            return IBL_ERROR_LEX;
        }
        parsing_string = ibl_strchr(parsing_string, 'x');
        break;
    
    // Example 3: Bricks as well, even though it's just adding the "parsing_string += 1;" and nothing else...
    case(CASE_1):
        if (!parsing_string) {
            return IBL_ERROR_LEX;
        }
        parsing_string += 1;
        break;

    This function is used in many places so I don't think it is a problem.  I did try inlining it just in case the function call was a problem, but it makes no difference.

    Commenting the if statement made no difference.  The if statement is actually the only thing I can keep in the switch case without it bricking.  You can see in example 3, I try adding something as simple as "parsing_string += 1;" and it bricks.

  • 1. What it the IDE tool do you use? CCS, or IAR? Could you update it to latest revision and see if there is any improvement? 

    2. Could you check the MSP430FR5962 Errata bug CPU47? And try the workaround to see if there is any improvement? 

  • You're a life saver!

    FRAM2                   : origin = 0x10000,length = 0x13FF8 // 0x14000 -> 0x13FF8 Changed for CPU47 Device Errata

    This did it.