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.

MSP430G2402: Programming FLASH memory as EEPROM

Part Number: MSP430G2402

Goog Morning TI community!

Today I have a question about programming FLASH memory's  MSP430 processors.

I use some segments of the Info Memory as EEPROM to store data, so I write on it several times during the execution of my code.

In your opinion is it possible that the writing operation on the Info Memory' segments goes to modify the protection bit of the FLASH program memory, so that the FLASH is no longer protect?

In this case I think the best way to take action is to introduce an external EEPROM so that I woldn't have any troubles with the FLASH memory.

What's your opinion? I really appreciate any answer and advice to this question.

My Best Regards,

Maria Angela

  • Hi Maria Angela,

    When saying "Flash is no longer protected" are you referring to the Flash memory no longer being locked?

    Please be aware of the following when writing to Info Memory segments:

    The Info A is protected and locked by the LOCKA bit in FCTL3 register; the LOCK bit cannot unlock Info A but the other way around LOCKA will unlock the whole Flash memory, both the Info segements and the main memory. So if you unlock InfoA and write to it your main memory will also be unlocked. Unlocking the Flash using LOCK will unlock all Flash memory except InfoA.

    For details see the MSP430x2xx Family User's Guide section 7 Flash Memory Controller.

    In case your program code fits into Info A you could that way further protect your program code from being accidentally accessed when writing to other parts of the Flash memory.

    Let me know if this answered your question.

    Best regards,

    Britta

  • In Info A segment of 2xx flash devices are stored factory calibrated data (DCO, ADC...), and because of this there is LOCKA.

  • Good morning everybody and thanks a lot for your answers!!

    In order to be much specific: I use the SEGMENT D of the Info Memory as an EEPROM and, to do that, I set and clear the LOCK bit as it is described in TI MSP430x2xyz familly's datasheet (section 7 as Britta mentioned in her post).

    After erasing D segment I write on it my data so that I can store them also when the machine is shut off. To do this I use the same procedure described in TI datasheet (chapter 7, paragraph 3)

    I think this is the correct procedure to erase and write on my D segment, isn't it?

    So, programming the FLASH in this way, is it possible that the Flash memory is no longer being lock?

    I really appreciate any answer to this particular question.

    Thanks a lot & Best Regards

    Maria Angela

  • Hi Maria Angela,

    as you said you are erasing and writing to Segment D according to the User's Guide it should be fine.

    As said before, while you erase and write to Segment D the whole Flash is unlocked (except for Info Memory A) until your erase/write operation is done and you lock the Flash again.

    If you say Flash memory, are you specifically talking about the main meory? When do you see protection bit unlocked without expecting it to be unlocked?

    Best regards,
    Britta

  • Hi Britta!

    Thank you very much for your answer. It really clarify me what is the root of the problem.

    Yes, when I say Flash Memory I'm talking about the Flash Main memory of the processsor.

    The issue I highlight is the same we were talking about Uwe in the last few weeks offline: the address stored in RESET vector location changes randomly.

    Luigi, my boss, thinks that if while the flash is unloked and any kind of electrostatic disturb would coming, it is this that causes the wrong re-programming of the reset vector.

    In this scenario which is the best way protect the Flash memory's part reserved to VECTORS from accidentally programming?

      Thanks a Lot & Best Regards

    Maria Angela 

  • Hi Maria Angela,

    please excuse the delay before answering, I checked with the team if the suspected root of the issue can be confirmed from our side. The experts do not agree that an electrostatic disturb would cause the described behaviour and that is why we think there has to be another issue in the application causing the Reset vector location change.

    Could you please pin down the instance in the apllication execution when you see the issue occur? What's the voltage and frequency setting at that point? Besides, can you tell me what code has been executed right before the Reset vector is set to a different location?

    If preferred we can go back to take this application related question offline, too.

    Best regards,
    Britta

**Attention** This is a public forum