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.

MSP430G2231: Load program error using MSP-FET

Part Number: MSP430G2231
Other Parts Discussed in Thread: MSP-FET

Hi there,

I am trying to load a program to an MSP430G2231 device via Spy-Bi-Wire interface using MSP-FET.

I have inherited the board (ie not my hardware design but I understand it has been used successfully in the past).

The MSP-FET is new (purchased via RS last week), serial number 19010144A (2nd generation)

The first time I tried to load the program I got an Load program error, saying data verification error occurred, with values at address x do not match.

I just tried reloading and it seemed to work ok (debug console started, and said processor was running).

Then I tried making a small change to the program and loading again, and initially i got a "can't detect device" error. I had to disconnect the MSP-FET and power cycle the board and then reconnect before I could connect. But now I get the data verification error every time I try and program it. The address of verification error seems to change between 0xF800 and 0xFFF0, but I can't work out any logic behind what determines which address is the error.

The program is extremely simple - I am just initialising the ports and setting a GPIO pin as output and high. Entire user source code is:

#include <msp430.h>

int main(void)
{
	WDTCTL = WDTPW | WDTCNTCL;	// reset watchdog timer

	// Port 1 initialisation
	//P1.0 n/c++
	P1DIR &= ~(1<<0); //P1.0 set to input
	P1REN |= (1<<0); // P1.0 enable pull up/down resistor
	P1OUT &= ~(1<<0); //P1.0 pull down
	//P1.1 n/c
	P1DIR &= ~(1<<1); //P1.1 set to input
	P1REN |= (1<<1); // P1.1 enable pull up/down resistor
	P1OUT &= ~(1<<1); //P1.1 pull down
	//P1.2 Watchdog_Feedback pin - connected directly to main microprocessor input (STM32F429 PE4)
    P1DIR |= (1<<2); //P1.2 set to output
    P1REN &= ~(1<<2); // P1.2 disable pull up/down resistor
    P1OUT &= ~(1<<2); //P1.2 set low (0)
    //P1.3 KICK_WATCHDOG pin - connected directly to main microprocessor output (STM32F429 PE3)
    P1DIR &= ~(1<<3); //P1.3 set to input
    P1REN |= (1<<3); // P1.3 enable pull up/down resistor
    P1OUT &= ~(1<<3); //P1.3 pull down
    //P1.4 n/c
    P1DIR &= ~(1<<4); //P1.4 set to input
    P1REN |= (1<<4); // P1.4 enable pull up/down resistor
    P1OUT &= ~(1<<4); //P1.4 pull down
    //P1.5 n/c
    P1DIR &= ~(1<<5); //P1.5 set to input
    P1REN |= (1<<5); // P1.5 enable pull up/down resistor
    P1OUT &= ~(1<<5); //P1.5 pull down
    //P1.6 n/c
    P1DIR &= ~(1<<6); //P1.6 set to input
    P1REN |= (1<<6); // P1.6 enable pull up/down resistor
    P1OUT &= ~(1<<6); //P1.6 pull down
    //P1.7 n/c
    P1DIR &= ~(1<<7); //P1.7 set to input
    P1REN |= (1<<7); // P1.7 enable pull up/down resistor
    P1OUT &= ~(1<<7); //P1.7 pull down

    //Port 2 initialisation
    //Start by setting P2 pins 6 & 7 to be GPIO as they are set to primary module function (XIN / XOUT) on reset
    //NB although user guide talks about P2SEL2 register, it isn't implemented according to datasheet.
    P2SEL &= ~0xC0; //clear P2SEL bits 6 & 7

    //P2.6 n/c
    P2DIR &= ~(1<<6); //P2.6 set to input
    P2REN |= (1<<6); // P2.6 enable pull up/down resistor
    P2OUT &= ~(1<<6); //P2.6 pull down
	//P2.7 Controls +GND_SWITCHED net. Low (0) for +GND_SWITCHED to be pulled high, High (1) for +GND_SWITCHED to be connected to 0V.
    //When low, the relay outputs are effectively disabled - no 0V for coils.
    //When high, the relay outputs are enabled - coils will function as normal.
    P2DIR |= (1<<7); //set P2.7 to output
	P2REN &= ~(1<<7); // P2.7 disable pull up/down resistor
	P2OUT |= (1<<7);   //set P2.7 high - enable relays
	//P2OUT &= ~(1<<7); //**OCP** temp

	while(1)
	{
	    WDTCTL = WDTPW | WDTCNTCL;  // reset watchdog timer
	}
}

The error messages I get are:

The hardware schematic showing jtag interface is:

Can you give me any clues as to what the problem might be?

Many thanks,

Oliver.

  • Hi Oliver,

    I recommend reading through this post on the Data verification error. 

    Also I recommend trying to program with the blinky example. This is a simple GPIO toggle and helps to isolate if the program you're programming is the cause or if there is another cause.

    Regards,

    Luke

  • Hi Luke,

    thanks. Unfortunately I've not been able to make any progress on this. I have tried using the blinky example project in CCS "msp430g2xx1_P1_01.c" (and also the assembler version) using all the default settings, which as I understand it should work. The hardware board does not have any external memory or anything.

    As far as I can tell from the documentation, with a simple hardware and software setup there is no requirement to add a GEL file in the target configuration settings (under initialization settings)?

    I wanted to try and examine the memory map using the tools > memory map option, but this never appears because the load fails.

    I also tried slowing the JTAG clock rate down to "slow" but this made no difference.

    Have you got any more thoughts on where I should start with this? It's really difficult to see how far the system is actually getting in the load process before it fails. (Other toolsets I've used show you the load progress).

    Thanks,

    Oliver.

  • Hi Oliver,

    There is an option for verbose outputs depending on which section you need. Considering it is the memory verification if you right click on the project then project properties->debug->MSP430 Flash Settings -> enable Verbose output. This will give you further information.

    Have you personally been able to program the device before? (I see that you've inherited the board so there may have been some setting previously). You should be able to program the example I linked without a memory error.

    Here are a couple of options that you can try (this error message can appear for a variety of reasons)

    1. Verify JTAG connections (a loose connection can cause errors with the JTAG programming)
    2. Create a fresh CCS workspace (this gets rid of any artifacts related to other debug configurations or settings)
    3. Erase main and information memory (this helps create a clean slate from the previous programming) (I recommend backing up the memory from the information section to keep the TLV data)
      1. Erase main, information and IP memory
    4. Turn off memory verification, program a verified good program, then reenable the memory verification

    Regards,

    Luke

  • Hi Luke,

    thanks for your continued help.

    To answer your question first: this is the first time I have tried to program the device, so no, I have never been able to program it reliably. However having spent quite a lot of time on it yesterday I did get to the point when I could program the device erratically. I have come to the conclusion it is most likely a hardware problem not software, because it doesn't matter whether I use the blinky example, or my original one - sometimes it programs successfully, and sometimes it doesn't. When it is successful, I see a programming process dialog box pop up showing the progress. When it doesn't work, this box never appears, there is just a delay, and then I get the verification error. Does this indicate that it's not even starting the programming process? Once a connection is established it seems to be reliable.

    (Note very occasionally I get a "Error connecting to the target: Could not find device" message as well, but this normally goes away if I cycle the power and disconnect / reconnect the MSP-FET).

    One of the things that I noticed was that the hardware implementation is slightly out of spec, as the capacitance to 0V on TDI/TDO is two 47nF in series, so slightly over the max spec of 22nF. So I modified the board to bring this within limits (at ~12nF), but this doesn't seem to change the erratic programming behaviour. Sometimes I can program it several times in succession without errors, and then suddenly it will give the verification error again.

    I'm not sure if it is a speed related thing or not - I have set the JTAG clock speed to "SLOW" in the target configuration. Is it possible to slow it down even further? Ultimately what I need to do is program some hardware that is already deployed in the field (very possibly with the MSP430 devices completely unprogrammed - they are just an auxiliary uC for a bit of the board that has not been used up til now). So my issue is that it will be very awkward if the programming is not reliable, and at the same time it won't be possible to modify the boards (e.g. with the change to capacitance on TDO/TDI).

    Thanks also for your other ideas - I am not able to try them just now, as don't have access to the hardware, but will try next week. I'm interested in point 3 - does the progaming process not erase the memory as part of the normal load? I'm not familiar with the TLV functionality, but have just read up a bit on it - it does seem important to keep, but I haven't found anything that explains how to reload it after erasing - do you have a link to relevant instructions?

    Thanks again.

    Oliver.

  • Hi Oliver,

    I'm glad that you've been able to program it, albeit with some inconsistencies.

    • For this device the JTAG slow would be the slowest setting you can implement. 
    • The programming would erase the main memory, but by default it doesn't touch the information or IP sections.
      • The TLV data is essentially calibration factors for the specific device as well as other device specific characteristics. To back-up the data you would need to connect to the device and export the memory from the device. The TLV data is in Segment A of the information section. If you download Uniflash it is very easy to connect and export the relevant data (just go to the memory section and there is an export button, you can then choose which sections of memory to export). I then recommend re-flashing the device with this data so you don't need to flash it every time in your normal program.

    Keep me updated if any of the other options provides a more permanent solution.

    Regards,

    Luke

**Attention** This is a public forum