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.

MSP430, Flash is corrupt

Other Parts Discussed in Thread: MSP430F2350


i use a MSP430F2350 in a design. A customer returns the product because it don't work. The Problem is

the MSP430.

- We burn the fuse, so we have only access via BSL

- With the rigth Password i get Access to the CPU

- I read out the Memory, the Password in the Flash is correct, so the Flash was programmed with our software

- But the rest of the Flash is not our code, over the whole Flash i found the this sequenze "34 49 34 49 34 49"

- I tried to erase the Flash, but it don't work, the sequenze is still in the Flash

- I tried to Access the Flash with the wrong Password, but only the Password at the end of the Memory was erased

- We do not have any code which writes into the flash

Any ideas?

  • Holger,

    do you use a voltage supervisor in your application. If you are running the CPU on higher frequency, you need to make sure that the minimum voltage is supplied to the MSP430.

    Please refer here:

  • Hi,

    the F2350 has no integrated SVS and we have no external in our design. the MSP has a power voltage

    of about 3 Volt and is running on 12 MHz. In the datasheet i see that down to 2.7 Volt it is possible to

    have 12 MHz.

    So when there was a voltage drop in the field under 2.7 Volt the Flash can get corrupt? this might be

    terrible because every time a customer switch of our device the voltage goes under 2.7 Volt. 

    I have activated the brownout, but it will disable the CPU at about 1.8 Volt. So there is a problem

    between 2.7 and 1.8 Volt in our design?

  • Hi Holger,

    yes i would say this is one possibility. When switching off the device, you need to make sure that the CPU is not running anymore with 12 MHz. You can try to use an external SVS and see whether this would help:

  • Hi Leo,

    so i see our design is not really good. But there is one thing which will say that that is not the reason:

    We have sell over 200 000 of this products in the last 5 years. They are switched off an on often in

    the field and we have never a Problem.

    Now we have 5 devices which a corrupt Flash, all 5 devices are from the same shipment to one

    customer.  So we have no General Problem with the missing SVS. There must be another


  • Another thing about the Flash:

    - the Region 1000hex to 1100 hex is filled with FF expect the DCO calibration

    - the Region C000 to e000 is filled with the sequenze 34 49 34 49 34 49 ....

    - the Region E000 to FFFF is filled with FF expect the Interrupt vectors

    Does this fit to the theory with the insufficient power supply?

  • Hi Holger,

    as I said this is the most probable cause if you are saying that you have no code in the device which does flash programming. I have never tested it myself, but I have heard similar problem with other customers. The wiki "Flash Best Practice" was also made based on some other customer cases. What can happen is usually the PC jumps to the BSL area during the power down and execute flash programming routine which is part of the BSL.

    One thing you might want to check: do the device in which the issue appear have certain revision/lot code in comparison with others where you don't see the issue? I am not saying that the device revision/lot code has quality problem, but the fact that you are running the CPU at 12 MHz while the supply voltage drops down during switching off the device, this means that you are operating (at a very short time) the device outside the specification.  Maybe some revision can withstand this problem, and some not. But basically all device shall work properly if it is operated under the recommended operating conditions.

  • Hi Leo,

    thanks for your help. I will investigate the other 5 MSP430 which do not work. But this will happen next week.


  • Leo, are you sure that undervoltage at high CPU speed may corrupt the flash? That doesn’t sound logical and shouldn’t be.
    I know that (depending on flash technology and flash controller construction) an overvoltage may cause flash cells to be unintentionally ‘programmed’.
    And that writing to flash while VCC is too low or changing will cause an improper write. But reading flash at a too-high speed for the current VCC shouldn’t affect the flash contents. (well, it could on FRAM, where the cells are written again on every read).
    Also, the VCC/speed requirement is to ensure proper CPU core operation. Flash and RAM should be fast enough even on lower VCC.

     Of course it can be that if the CPU runs too fast for the current VCC, core malfunction will not immediately crash it but rather cause erratic code execution, including an improper call of a flash write code (if present). That’s why using the internal SVS or (where not present) and external voltage supervisor is a good idea.
    It is also imaginable that the processor accidentally jumps into the BSL code that does flash access, but shouldn't the BSL area be protected except for the jumptable at its start? And from there it won't go to flash write code. It would be very unikely that it first erroneously jumps to the BSL jumptable and then again erroneously into the BSL flash write function. Not impossible, but very unlikely.

  • Hi Leo, Hi Jens-Michael,

    so i investigate the 3rd of the MSP and it is the same.

    All 3 MSP430, communication over BSL:

    - from address C000 to DFFF i see the sequence 34 49 34 49 ...

    - from address E000 to FFDF the Flash is filled with FF

    - from address FFE0 to FFFF is see the original Interrupt Vektors

    - i can erase the Flash from E000 to FFFF, but i can not wright anything

    - I can not believe that this is a to low voltage/to high frequency Problem, because we have 5 MSP430

    which have this Problem and over 200000 MSP430 in the field which have no problem

    - All 5 MSP430 modules are from the same customer

    - The Flash is not only overwritten, it is damaged

    - The customer uses this MSP430 module in a ship application, maybe a surge impuls destroys this MSP430

    - I agree to Jens-Michael, your description is to unlikely that it will happen with 3 MSP40 (and all have the same

    Flash contant)

    Anymore i can do?

    Anymore ideas?

  • JMG, Holger,

    i must honestly say that my assumption above is based on some cases that i have been getting from the customer feedbacks. Personally i have never seen or tested it. Anyway, the theory is that due to the unsufficient supply voltage, the PC jumps to BSL area and execute the flash programming routine.

    Jens-Michael Gross said:

    It is also imaginable that the processor accidentally jumps into the BSL code that does flash access, but shouldn't the BSL area be protected except for the jumptable at its start? And from there it won't go to flash write code. It would be very unikely that it first erroneously jumps to the BSL jumptable and then again erroneously into the BSL flash write function. Not impossible, but very unlikely.

    This is true i think for 5xx/6xx devices, but not for older 1xx/2xx/4xx devices. Since Holger is using 2xx device family, so i think the BSL is not really protected in that way.


    have you tried to look for the specific revision/device lot code of the broken devices and compare it with the ones which are not affected?

  • Indeed, a surge is a possible explanation. I guess all devices have initially worked. And it happened only with devices from one customer but not with all form the same batch.
    It is imaginable that a surge has destroyed the flash cells or part of the write logic. It is also thinkable that it is the result of an attempt to retrieve the firmware (it isn’t a Chinese customer, is it? :) ).

    Since this is not the only known case, I wonder why there hasn’t been a microscope-level investigation from TI’s side. I remember that when I attended to the BeckIPC forum (an x86 based single-chip system in DIL32 case with network) in 2001, on any similar case, they asked to send the device in for closer inspection. Well, the devices were ~$100 each, but…

  • Hi,

    it is not a chinese customer, but it is in Asia. But i do not think that someone tried to read out the

    program code. Because i tried it also with a wrong Password and the Interrupt vector were filled with FF.

    I compare the device lot code:

    The MSP from the customer: TI G27K C027 G4

    Two MSP from the stock without this Problem: TI G33K  D8D6 G4 & TI G33K  D8VE G4

    So the same chip Revision "G" but a different year/month code and LOT Code

    I can not believe that jump in BSL and writing to Flash is my Problem, because the Flash

    is not only overwritten, it is damaged!!

    If Ti want i can send the MSP to you.

  • Holger,

    It looks like only the lower 8KB of main Flash are damaged. Can you write some test code that only uses the upper 8KB and see if the rest of the chip still works?

    -- OCY

  • Hi Holger,

    i will contact you and let's discuss this offline first, and post the result here later on.

  • It’s to be expected that flash is 0xFF after a wrong password. Nobody who tries to steal the software would simply try a (most certainly wrong) password.

    But some time ago, OCY and I discussed a way to hack the device without getting the firmware erased. By monitoring power consumption. When the password was sent and the BSL tries to do a mass erase, power consumption rises and a monitor will shut-off power instantly. This method could very well cause flash damage after some time.
    But I think, the 2x family doesn’t have an ‘erase by wrong password’ function in the BSL anyway.