• State
  • Locked Locked
  • Replies 6 replies
  • Subscribers 82 subscribers
  • Views 1761 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

MSP430FR6972 FRAM issue

Oleksandr Kasianenko
Prodigy 30 points
Other Parts Discussed in Thread: MSP430FR6972, MSP430-FLASHER

Hello everyone,  I sent a question to AskTexas support and was advised to rise a topic here...

One of our designs is based on a MSP430FR6972 FRAM micro-controller as a CPU.
We ordered a couple of parts as samples at the end of 2015 and tested them in prototype boards.
Testing showed good results so we decided to put them into mass production and purchased 600 chips
from one of TI's official distributors.
After half of the PCB-s have been assembled we bumped into some peculiar problem with FRAM failing to be re-programmed.
All the processors were initially programmed OK, but some samples have one FRAM page failing to be reprogrammed.
Actually it fails to be erased, giving as a result array of 0xFF3F values instead of 0xFFFF for the erased state.

Now we already have 3 parts failing out of 3 taken for experiments with program code improvement. One of them ceased to reprogram
straight away after it was re-soldered in place of the very first one. Third one was not re-soldered and allowed for some cycles
of reprogramming, but eventually also stopped to be erased.
Bad FRAM page address is 0x5800..0x6000. Cell values and page address remain the same for all the failed parts.

We excluded this page from the code mapping via corresponding linker directives so it works OK for the time being.
But we have some doubts remained regarding the nature of the effect and virtual possibility of it propagation to other
pages of memory during operation of a device.

The assembly of PCB-s was made at a plant using certified reflow soldering process.
To program the processors we use branded tools only.
Photo of the board you can find in the attachment.

Could you, please, give us some suggestions to the questions:
- What's the specificity of working with the MSP chips having FRAM as memory array?
- Are there some tricks and traps in using this memory as ordinary RAM with multiple access?
- Does it has limited value of erase/write cycles?
- Is there some errata for such an issue released?
- What is data retention period for this memory?

Thanks a lot.

Oleksandr 

R&D engineer
Ukraine

  • 0
    Guru 318740 points

    FRAM does not have erase cycles; you just write or read it. There is no erased state; to get 0xFFFF, you write 0xFFFF.

    The value 0x3FFF is returned by the MCU when you try to access some address where no memory is mapped (see section 1.9 of the User's Guide).

    And how did you program the MPU? Did its configuration change on those bad MCUs?

  • 0 in reply to Clemens Ladisch
    Guru 58965 points
    Clements is correct of course.
    But we are in new-age of high-tech jargon where not only we can "Erase" the FRAM, we can even "Flash" the FRAM.

    Back to the topic. Olesandr, did you try other tools to "Erase" or "Flash" (babble babble) your FR6972?
    For example, "MSP430-Flasher" (see www.ti.com/.../msp430-flasher), using JTAG or BSL interface?
  • 0 in reply to Clemens Ladisch
    Prodigy 30 points
    Hi, Clemens!
    Thank you very much for the answer.
    Yes, I realize there is no special procedure to erase an FRAM. The programmer we use is MSP-FET430UIF. Though it does the seemingly similar procedure as it does for the flash programming - it erases, checks for cleanness and if OK, loads the code. It reports an issue within second stage, when checking for cleanness fails...
    For the second question - we did not intentionally change any config bits while reprogramming the device... Could some be changed accidentally?
    Thanks a lot!
  • 0 in reply to old_cow_yellow
    Prodigy 30 points
    Hello,
    thank you very much for the answer!
    Nope, we have not tried other tools... Yet we'll certainly do!!
  • 0 in reply to Oleksandr Kasianenko
    Guru 34773 points

    Don't see any reason for "erasing" FRAM. Check if your device has option for  erase user code or total erase by mailbox / boot code, for resetting device to factory state. This can be done by MSP-FET430UIF with MSP430-Flasher.

  • 0
    Guru 25245 points

    Since all of the parts program correctly the first time and all fail in the same location, I suspect this has something to do with your code.


    One thing that could cause the value 0x3fff to be read in the middle of memory that should be there is a MPU violation. Is that enabled in your code?

**Attention** This is a public forum