• State Resolved
  • Locked Locked
  • Replies 6 replies
  • Subscribers 80 subscribers
  • Views 918 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.

MSP430F5437 Errata "JTAG27" Questions

Jared Sweet
Prodigy 40 points
Other Parts Discussed in Thread: MSP-GANG, MSP430F5437, MSP-FET

Hello, I am currently reviewing the MSP430F5437 Device Erratasheet, recently updated in June 2016 to add the Errata "JTAG27". This errata describes an issue where "The device can unintentionally start executing code from uninitialized RAM addresses 0x0006 or 0x0008 after being programming via the JTAG or SBW interface". We use the MSP-FET and MSP-GANG programming tools.

I am trying to understand the impact of this errata, so I have a few questions:

- Does the chance to execute code from these addresses occur only after the initial programming of the code? Or can this happen every time the microcontroller is reset?

- What exactly does the note "NOTE: This only affects debug mode" mean? That it only happens when attempting to debug through an IDE?

Any assistance is appreciated.

  • 0
    TI__Guru 68116 points
    Hi Jared,

    My understanding is that this can only occur after the very initial programming of the code, not every time the part resets if the part is running stand-alone (not in debug mode). The note means that there is only an issue when you have the part in debug mode, which means you have the part being connected to/accessed by a debugging tool like the FET tool or something - if you are accessing the part via JTAG or SBW essentially. If you are just powering up the device from cold, no debugger tool connected or anything, you aren't going to see this issue because you aren't in debug mode (basically going back to your first question).

    In any case, the workaround is pretty simple - just update to the latest version of your tools (CCS/IAR/MSP-GANG) and you shouldn't have to worry about this.

    Regards,
    Katie
  • 0 in reply to Katie Pier
    Prodigy 40 points
    Katie, thank you for your answer. Your help is very much appreciated!
  • 0 in reply to Katie Pier
    Prodigy 40 points
    Hi Katie, it's been a few days, but I have an additional question on this topic that I am hoping you can help with.

    One thing that I did not mention in my original post is that the tool that we are using for debugging is IAR Embedded Workbench version 5.20. The errata suggests upgrading to a version later than 6.30 to fix this issue. We are a little wary of upgrading our debugging tool a Major revision level, so we would like to verify if this issue affects our revision of IAR EW specifically. Was this an issue introduced in Major rev 6, and subsequently fixed in 6.30? Or does this truly impact all revisions of IAR EW prior to 6.30?

    Thanks again for your help.
  • 0 in reply to Jared Sweet
    TI__Guru 68116 points
    Hi Jared,

    I will see if I can find any more information - not sure what I'll turn up with. However, 5.20 is very old and likely has other bug fixes as well (e.g. bugs fixed in the compiler etc) so generally we would encourage an upgrade. Understood that is not always an option when you are trying to maintain or update an existing design though.

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

    I asked and they told me that no, this wasn't just introduced in the latest major version and then fixed in the minor version update, but rather ALL older versions are affected.

    The issue only happens during debug, and after a reset after you leave debug you shouldn't have to worry. The main concern is that when the issue occurs you don't know what instructions could be executed - this isn't probably as big of a concern on Flash parts like you are using as on FRAM parts (because FRAM could get written to easily so you worry more about potential FRAM corruption). But again, since it's just debug mode, hopefully this isn't a big risk for you.

    Regards,
    Katie
  • 0 in reply to Katie Pier
    Prodigy 40 points
    Katie, thanks for looking into this, it's been a big help. I agree, it does not seem like it is a big risk for us.

**Attention** This is a public forum