• State TI Thinks Resolved
  • Locked Locked
  • Replies 4 replies
  • Answers 1 answer
  • Subscribers 78 subscribers
  • Views 2386 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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.

MSP430FR5720: Part of FRAM cleared to 0x00

Koichiro Tashiro
Mastermind 21140 points
Part Number: MSP430FR5720

Hi,

My customer is using MSP430FR5720 and encountered an issue.
The system suddenly stops working after power cycle and customer found part of code memory is cleared to 0x00.

The issue was observed with 3pcs (in 60pcs total) and address 0xF000 to 0xF58C are cleared to 0x00 after the issue.
This is code area. These 3pcs were re-programmed again, then working fine after that.
Customer is trying to reproduce the issue, but so far no success. So issue probability seems very low.

One problem I found in customer board is that AVCC and DVCC are completely separated on board and power-up timing is like this:
DVCC power-up first, then AVCC power-up after mili-seconds/seconds order.
According to data sheet (SLASE35B), DVCC and AVCC should power-up with same timing.
There is a note at section 5.3.
"(1) TI recommends powering AVCC and DVCC from the same source. A maximum difference of 0.3 V between AVCC and DVCC can be

tolerated during power up and operation."

Questions:
1) What happens if DVCC and AVCC power-up separately ? Is it likely part of FRAM are cleared to 0x00 ?
2) What can be possible cause of FRAM data clear to 0x00 ?

Thanks and regards,
KoT

  • 0
    TI__Guru 68116 points

    Hi KoT,

    Thanks for posting.

    KoT said:
    Questions:
    1) What happens if DVCC and AVCC power-up separately ? Is it likely part of FRAM are cleared to 0x00 ?
    2) What can be possible cause of FRAM data clear to 0x00 ?

    For #1, results are unpredictable. If you violate the spec it is hard to predict exactly how a failure will occur because it is obviously outside of what the part is designed to do. I would say it could potentially cause the FRAM clearing in some way, if for example it causes erratic device execution.

    For #2:

    There are different scenarios that could cause FRAM data to be cleared. Since FRAM can be written to just like RAM, a likely one could be that code causes the FRAM to be written with 0's, or that erratic execution of the device causes erroneous writes to the FRAM. To understand better the root cause, we'll need to know more about the situation. First of all, does the customer enable the MPU to protect their code? This is considered to be a best practice and is important to help protect from erroneous writes. How does the customer enable the MPU (do they use the MPU tool in CCS/IAR, or do they do it manually in their code)? Do they perform any FRAM writes somewhere in their code normally?

    But no matter what, they should fix the issue of AVCC and DVCC coming up separately is violating the spec and therefore we can't rule that out as a root cause - even if it is not the root cause of this issue, it could cause other issues and so must be fixed.

    Regards,

    Katie

  • 0 in reply to Katie Pier
    TI__Mastermind 21140 points

    Hi Katie,

    Thanks for your quick reply and sorry for my late response.

    For#1, I understood the results are unpredictable.
    I got power-up waveform from customer. Please see attached.
    There are ~411msec timing gap between DVCC ON to AVCC ON.
    And during this period, AVCC is not powered externally, but ~2.4V voltage is seen at the pin.

    For#2, customer uses MPU manually in their code.
    In fact, they did not use MPU at first. And they saw system hang-up after power cycle a lot.
    After MPU was implemented, the issue occurred only 3 times with 3pcs.
    I asked customer to confirm the issue they saw without MPU is exactly the same issue as with MPU.

    Without MPU : Address 0xF630 was corrupted. Data corruption seems random.
    With MPU : Address 0xF0000 to 0xF58C are cleared to 0x00. (2pcs showed the same results. Another 1pcs was not checked)

    Thanks and regards,
    KoT

  • 0 in reply to Koichiro Tashiro
    TI__Guru 68116 points

    Hi KoT,

    Thanks for the additional information, and thanks for your patience during my delay in response - I have been travelling internationally.

    For #1: ~400ms is a long time to be in this out-of-spec state. I would be concerned if this is not fixed in the customer's design as they could potentially see other issues with other modules, not just this FRAM issue. I would strongly recommend that the customer needs to try to find a way to eliminate this long delay in the AVcc bring-up.

    For #2:

    You said that implementing MPU improved but did not totally resolve the issue. You also mentioned that they implemented the MPU manually. CAn they share their MPU init code, and at what point in the program it runs (e.g. is it called immediately at beginning of main(), or from __system_pre_init()?) Or do they use the manual selection within the MPU tool - if so can they share the settings they picked in the MPU tool?

    To confirm: when you listed the corrupted addresses with MPU, do you mean addresses 0xF000 to 0xF58C (not 0xF0000)?

    Regards,

    Katie

  • 0 in reply to Katie Pier
    TI__Guru 68116 points
    Hi KoT,

    Is this issue still open? Is there any update?

    Regards,
    Katie

**Attention** This is a public forum