• State TI Thinks Resolved
  • Locked Locked
  • Replies 3 replies
  • Answers 2 answers
  • Subscribers 80 subscribers
  • Views 464 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.

MSP430FR2033: SYS23 errata

Calex36
Intellectual 2285 points


Regarding the errata, implmenting a remapping of the RAM to avoid the two bytes that are not preserved after BOR (Brownout) takes up 256 bytes as a workaround as avoid whole area of 256 bytes to avoid the two bytes, this is undesireable. 

So if re-initialising RAM Variables when there is a Brown-Out

Do we need to worry about RAM content at addresses 0x20FE and 0x20FF relating to the SYS23 errata

If cannot guarentee that entire ram is initialised do you percieve any danger?  As cannot gurantee what the variables may be in the location with each code change?

Many Thanks

  • 0
    TI__Expert 6635 points
    Hi Calum,

    If the RAM variables are being re-initialized when there is a brown-out, you should be ok.

    If you cannot guarantee that the entire RAM is re-initialized when there is a brown-out, then you may be effected by the SYS23 errata. Instead of remapping the RAM, one option is to explicitly define where in RAM you want to place your variable(s). Here is a link to an E2E thread that explains how to do this:

    e2e.ti.com/.../179005

    If you can re-initialize your RAM variables after a BOR, you should be fine. I wanted to mention this workaround in case you wanted to take extra precaution.

    Please let me know if there are any questions

    Thanks,

    Mitch
  • 0 in reply to Mitch Ridgeway
    TI__Intellectual 2285 points
    Relating to this errata further could you please provide some advice on the following areas;

    CS11

    Is workaround a one time thing?.

    Initial though is yes because of FRAMs ability of CPTL
    Is there any scenario where this workaround will fail? And would require calibration again?

    Also Would clock stay at ACLK Frequency?

    CS13

    Lock up state transition am to lpm3/4 when dco >2MHZ

    Relating to PMM32

    The device can recover from this lockup
    Condition by a PUC/BOR/Power cycle (e.g. enable Watchdog to trigger PUC).

    Can the watchdog act as workaround for CS13 too?
  • 0 in reply to Calex36
    TI__Expert 6635 points

    Hi Calum,

    Yes, the workaround for CS11 should be a one time thing. Once you get the calibrated room temp DCOFTRIM value and load it into the register on every boot up (as described in the document), you shouldn't have any problems. The only instance I can think of where this workaround would fail is if you  erase the calibrated room temp DCOFTRIM value in FRAM or somehow clear your calibration flag in FRAM. As long as this data does not get corrupted, you should be ok.

    As far as the ACLK question - are you asking about the reference clock? The FLL reference can either be XT1CLK or REFOCLK. XT1CLK should be a 32kHz crystal and REFOCLK is an on-chip 32kHz clock. Both of these will stay at their 32kHz frequencies for the FLL reference.

    No, the watchdog cannot act as a workaround for CS13. The only way to recover from CS13 is with a BOR/Power Cycle:

    Thanks,

    Mitch

**Attention** This is a public forum