Failure to write flash on G2452 with CCSv4

Maybe supply voltage is high enough for the device to work (and respond) but too low for writign the flash? Or the extra curent for the flash process brings down VCC?

Just wanted to throw my two cents in on this.  I am having the same problem and have seen a few other posts popping up on the web with regard to programming/debugging issues with the new G2452 on the launchpad.  Some folks can get them to program after a fair number of attempts...I haven't been so fortunate. :)  My copy of CCS is the most current version and the error thrown is:

MSP430: Trouble Writing Memory Block at 0xe000 on Page 0 of Length 0x50: This operation is not supported by this driver

Cannot write to target

If I swap the G2452 out and put in the orignal G2231, switching both the device include and target in CCS,  all is well.

I may be wrong but when comparing the flash voltage/current requirements in the datasheets between the G2231 (which again works fine) and the G2452...they appear identical.  Since the flash Vcc spec is 2.2 to 3.6V @ 7mA max. and the launchpad is powered from a desktop USB port, it just doesn't feel like a voltage drop issue.

I have also tried it with a launchpad with the microcrystal installed and on a lauchpad without the crystal... with the same results.  I am not sure what to try next. 

Humbly appealing for any help.....

Doug Bennett said:

ince the flash Vcc spec is 2.2 to 3.6V @ 7mA max. and the launchpad is powered from a desktop USB port, it just doesn't feel like a voltage drop issue.

But is is the only possible (or at least obvious) reason. Since programming the MSP does not need any 'special' mode, and the initial JTAG connection seems to work, the ONLY difference (besides, of course, a defective MSP) is the comparably huge current during flashing. The MSP can run with <1mA normally, but requires up to 7mA when flashing. Since the voltage is not diretly drawn from teh USB, it does nto matter that the whole part is powered by USB. The question is: does it arrive at the MSP after passing voltage regulation and such.

Is the VCC jumper on J3 set? If not, the MSP is powered over the programming lines, which is sufficient (while not intentional) for basic operation, including JTAG connetion, but definitely NOT for programming the flash. The clamp diodes on the port pins can route up to 2mA from the port pin to VCC (or from GND to the port pin). This is enough to power the MSP and the ripple capacitors on VCC, but as soon as a larger current is drawn, the voltage will drop up to the point where the diodes either melt to a shortcut or break and leave the pin unprotected. In case of the flash controller, the controller will abort the write as soon as the voltage drops. It is not necessary that it will drop below 2.2V then, the voltage (no matter where in the allowed range it is) may not CHANGE more than a certain amount during write or the controller will flag a write fault.

In any case, it won't hurt to use the extpwr input and power the MSP with 3.3V for testing.

Thank you for replying, Jens-Michael!

                 The voltage on Launch Pads is 3.3V which is near the absolute max. of 3.6V.  Also, USB can furnish at least 200ma to a device, even 500ma. I tought it was a

decoupling problem, so I soldered a 4.7uF mono directly between  pins 1 an 20 on solder side of the card without any improving.

Have a good day,

Gilles

Thank you for replying, Doug!

                 One of those I got from TI had an error for writing at 0xFFF0 and the other one at 0xE1c0;

                 The voltage on Launch Pads is 3.3V which is near the absolute max. of 3.6V.  Also, USB can furnish at least 200ma to a device, even 500ma. I tought it was a

decoupling problem, so I soldered a 4.7uF mono directly between  pins 1 an 20 on solder side of the card without any improving.

Have a good day,

Gilles

Hello, Jens-Michael!

             I checked the card and all jumpers on J3 are ON. I will try external 3.3V as you suggested.

Thank you,

Gilles

Gilles Bellemare said:

Also, USB can furnish at least 200ma to a device, even 500ma.

Also, 500mA is only after the device has identified itself to the host hub as high-current device. Else it is 100mA which are available always. (but some HUBs simply make it cheap and provide 500mA or even more without any limitation or checking. Which is prone to fatal failure when you cause shortcuts while plugging)

Decoupling i almost always a good idea. bad hting that it didn't help.

You could try to trace the route of VCC from the FET part to teh target MSP. Maybe there's a rupture on the wiring? Shouldn't happen but soemtime shappens, especially in mass production. And as I explained, it won't show up when simply doing a function test due to the 'port pin powering'.

But maybe I'm on the wrong track with this power supply thing. It's jsut that I don't see what else could be different from normal  FET access and data writing FET access. THe lines are the same, teh FET is the same, the target is the same. Only the power consumption is different. (provided that the MSP itself is okay)

I was having the same issue and I did an update on ccs.  it works now.  hope for you too..

unfortunately the luck was only temporary, sorry folks....

Flash Erase takes 1mA typical, 7mA max. Flash Write takes 1mA typical, 5mA max. These are the same for G2452 and G2231. It is not likely the problem.

CCS and those DLL etc. are more likely the source of the problem. With half a GB, they can do anything "automatically" and keep you in the dark.

I have had some limited success by starting fresh with a brand new project, using the <MSP430G2452.h> include. Program is a microcrystal test program and is 86 bytes. Approximately 50% of the time I can flash the 2452 successfully and about the same percentage of the time I can initiate the Run command from CCS successfully. However, rarely can I single step the program without an error. 

I have tried it with USB supplied power and a separate power supply for the MSP target device and it doesn't seem to affect the results one way or the other.  However, there is tangible comfort in that I now have a flashing LED.  :)

I wonder how much my successful device flashing percentage would drop if it was a much larger program....

I also wonder if there aren't slight timing differences between the 2231 and 2452...either due to the chip design itself or perhaps this is just a bad batch of 2452s.

old_cow_yellow said:

These are the same for G2452 and G2231.

After re-reading the whole thread, well it is also possible, that there is indeed a timing issue that allows a JTAG connection initially, but then fails - during the wait time for a flash process finishing, or when waiting for a breakpoint to be hit.

Then it is a problem in either the PC firmware, or in the Firmware of the 1612 (which is more likely since this processor is responsible for the low-level JTAG access to the target MSP).

Hi,

        I installed the latest release from IAR (5.20.1) and setted up a project with the same dummy code as with CCS:

#include "msp430g2452.h"
#include "float.h"
#include "math.h"
#define Pi 3.141592
void initClocks(void);
int main( void )
{
  unsigned int i,j,k=0;
  float x,y,z;
  WDTCTL = WDTPW + WDTHOLD;
  initClocks();
  P1DIR=0x01;
  P1OUT=0x01;
  do{
    P1OUT ^=0x01;
    for(i=0;i<655;i++)
    {
      x=32;
      y=2*Pi*x;
      z=Pi*x*x;
      j++;
      k=j;
    }
  }while(1);
}
void initClocks(void)
{
 BCSCTL1 = 0xFF;                   // Pour environ 16MHz faire DCOCTL = 0x60 et BCSCTL=0xFF
 DCOCTL = 0x60;                    //  Pour 21Mz faire DCOCTL = 0xE0
}                                  // Pour 8MHz BCSCTL=0xFD et DCOCTL= 0x60

IAR says it flashed all it O.K. but code is oversized (0xBC4) compared to the same flashed with G2211 (0x190). Also the stack is always almost full and the program doen't run. I changed for the other G2452 and IAR wrote the same code at 0x1E0 spacing (0xE000, 0XE1E0, 0XE3C0, 0xE5A0 etc) to the end of memory. Looks like internal address decoder problem. I think CCSv4 makes more verifications on memory placement than IAR explaining former reports errors and  stopping debug session.

          Everithing is O.K. with G2211.

Gilles

Gilles Bellemare said:

IAR says it flashed all it O.K. but code is oversized (0xBC4) compared to the same flashed with G2211 (0x190).

using floats is a no-no on small processors like the MSP. I guewss it has only been added to the compilers to allow people, who do even 1+1 with a double-precision float, having a hello world experience.

Even for high-power GPIO systems such as flash, teh rule is 'use the smallest possible type'. For MSP this should be altered by deleting the 'possible' from this rule or better rewrite it to 'make it possible to use the smallest type'.

For your program above, I suggest the following: Multiply Pi with something that fits nicely. e.g. 65536 (#define Pi 205887L) (effectively 3.141586304).
Then Y= 2*Pi*32 can optimized by the compiler to 0x3243F<<6, and Z=Pi*x*x is 0x3243F<<10. The result, of course, is the interger part in the high word of the long result, while the low word contains the fraction in 1/65536 steps.

I bet the code will execute about 100 times faster, is much smaller and gives the same result.

However, this is no explanation for why the G2452 behaves so differently to the G2211. A bug in the header files or the linker scripts I suspect.
An always full stack can also be caused by a wrong linker script, so the stack pointer is initialized to the wrong location.

Jens-Michael, Code for Floating-point multiplication is not that huge. It should fit in 0x190 bytes.

Besides, since x, y, and z are "useless", couldn't c-compiler just ignore them?

On the other hand, things like:

void initClocks(void)
{
  BCSCTL1 = 0xFF;
  DCOCTL = 0x60;
}

will not be ignored by the c-compiler and may kill the CPU.

Regards, OCY

Hi,

I just tortured my MSP430G2452 samples without problems! Did you ever use another USB cable (i.e. from an external HDD drive or a card reader) for connecting your launchpad to the PC? Sometimes the one supplied with launchpad makes some problems (it's not the best quality since it needs to be cheap).

Rgds
aBUGSworstnightmare 

this is a good hint, i have seen this suggestion somewhere in the forums.  It does not, however, explain why some are claiming to have no issues with the older 231 chip........

Hi there,

I have some new information about this problem! i think it's related to different revisions of the launchpad!!!

I have a Rev. 1.3 which works like a charm, and I've tested a new, fresh out-of the-box Rev 1.4 this morning which failed!

See this thread: http://e2e.ti.com/support/microcontrollers/msp43016-bit_ultra-low_power_mcus/f/166/p/93945/330304.aspx#330304

Rgds
aBUGSworstnightmare 

Hi,

          Bingo! I have many Lauch Pads on which I tried the G2452 and all are rev. 1.4

Gilles