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.

Office Hours - MSP430 FRAM Microcontrollers

Do you have questions about the new MSP430FR59x/FR69x microcontrollers?  During the following times, responses to this thread will be opened up for live communication with the MSP430 team:

  • Tuesday August 12th
    • 11:00 AM - 13:00 PM (CDT)
  • Wednesday August 13th
    • 17:00 - 19:00 PM (CDT)
  • Thursday August 14th
    • 9:00 - 10:00 AM (CDT)

We are looking forward to hearing from you!

  • Looking forward to this next week!

    -Katie

  • Q: Are FRAM speeds >8MHz in the near-future roadmap for the TI MSP430 series?

  • Hi Eric,

    There is not a plan for this in the near future, but we are always looking into the value of new technologies for our MCUs.

    Keep in mind that the effective access times are typically much closer to 16 MHz. For more information please refer to the FRAM Quality and Reliability guide.

  • 1) Right now the MSP430FRxxxx MCUs are only qualified up to 85C. Are there any plans to get them qualified up to 105+C? If so, is there a time frame?

    2) I know that the FRAM itself is "impervious" to external electrical, magnetic, and radiation fields, but how about the control circuitry to read/write the FRAM? Are there any possibilties that external signals might flip a bit here and there?

  • Why would I want to use a FRAM part when there are lower cost flash parts?

  • Zack Sheffield said:
    1) Right now the MSP430FRxxxx MCUs are only qualified up to 85C. Are there any plans to get them qualified up to 105+C? If so, is there a time frame?

    We recognize that 105C is a feature that can benefit customers in several application spaces and are looking at possibilities to expand our offering. There is no near-term plan for this particular family at the moment, but if 105C is the differentiating factor you need, please check out this page: www.ti.com/extendedtemp

    Zack Sheffield said:
    2) I know that the FRAM itself is "impervious" to external electrical, magnetic, and radiation fields, but how about the control circuitry to read/write the FRAM? Are there any possibilties that external signals might flip a bit here and there?

    The FRAM does give you some advantages in this area and gives you the opportunity to frequently backup state information, but the devices as a whole are not qualified as Hi-Rel parts so therefore parts of the device could be affected in some way by these types of radiation. www.ti.com/hirel

    Regards,

    Katie

  • @Derek9531

    There are a number of applications where FRAM can provide tremendous benefits over similar flash-based devices. In applications where more RAM is needed than Flash, you could leverage the unified memory on FRAM microcontrollers to minimize the total memory footprint. Additionally, the write speed and low energy consumption of FRAM can extend product battery. On top of that the high write endurance can enable data logging in your application. These FRAM based microcontrollers also offer integrated peripherals such as LCD and AES that could add value to an application by minimizing BOM or CPU cycle required for a given task.

  • Can I use FRAM in the same manner I might use normal static RAM? Would that be considered a reasonable use of the msp430fr59xx technology? Would it adversely affect the chip life?

    -rick

  • On another thread, posted a question about Comparator_D in the MSP430FR57x devices.

    http://e2e.ti.com/support/microcontrollers/msp430/f/166/t/361649.aspx

    The Question:

    I am confused by the documentation on Comparator_D as it appears in SLAU272C and the include files that support the Code Composer versions of the "C" compiler (say for example tools version 1.9).  In Figure 17-4, we see a block diagram that shows 5 bits that controls the "switches" on the reference generator resistor tree.  It also shows 5 resistors.  Given the way this picture "looks", one would assume that there are only 5 taps and "probably" one bit controls each tap (and probably one should NOT  turn on more than one tap switch at a time). 

    However, the compiler include files (msp430fr5739.h for example), seem to imply that the 5 bits decode up to 32 individual taps selections (which suggests an entirely different block diagram/circuit topology from what is shown in Fig. 17-4 where switching "on" more than one switch at a time could not possibly work "right"). 

    So which is correct?  Are there really effectively 32 tap positions (and equally spaced in voltage)?  I also have not seen any specification on the accuracy of the tap selections from the "ideal" value.

    Our Answer:

    There are in fact 32 settings available. We will take a look at the User's Guide to see how we can make it more clear. Thank you for bringing this to our attention! 

  • @Rick Kimball

    The answer is yes! The beauty of the FRAM technology is that it offers write endurance of 1015 in addition to being non-volatile. The unified nature of the memory means that you can dynamically set the memory boundaries as make sense for your application. You should keep in mind that we do have some SRAM on our devices as well, since it can offer slightly faster speeds and lower power when required.

  • Aside from using FRAM, the Wolverines have lots of good features (for example, the IP Encapsulation) that other MSP430s do not have yet. Do you think these new features are going to be added to other MSP430s in the near future?

  • Hi old_cow_yellow,

    We are definitely looking to reuse some of the features from the FR59xx/69xx family on future devices as they are developed, and we are also always looking to develop and improve on our IP as we expand our portfolio.

    Are there particular features that you are particularly hoping for or really like on FR59xx/69xx that you'd like to see on other parts? This would be good feedback for our teams developing new parts.

    Regards,

    Katie

  • @Katie,

    The “IP Encapsulation” feature is on top of my list. Others are, password protected JTAG, and factory trimmed DCO frequencies. UART TX shift-register empty interrupt is very desirable too.

    --OCY

  • old_cow_yellow said:

    The “IP Encapsulation” feature is on top of my list. Others are, password protected JTAG, and factory trimmed DCO frequencies. UART TX shift-register empty interrupt is very desirable too.

    Thanks for the feedback - I will definitely pass this along.

    -Katie

  • A problem I've seen a few times both here and @ 43oh is folks accidentally bricking their FR5969 by setting the JTAG password inadvertently.  You can of course recover with the BSL but at least 1 user I noticed didn't have the knowledge yet to set that up...  Would it be possible to move the JTAG fuse bits to a protected FRAM segment, such as the one used by the device calibration settings?  Seems to me that could be a safer place and if you need to set the password you should know what to do.  Or a different/new protected segment if the proximity to the calibration data seems too risky...

  • Hi Eric,

    This is good feedback and something that we should probably address better. In your experience, is this usually an issue where:

    1. the user locks the 430 by simply programming in their application code (meaning their binary code image included that area where the fuse bits are),
    2. or is it usually caused by someone whose code does in-application writes and writes to this area accidentally?

    I am curious because, while I don't think we can move these bits on this device, there are strategies you can do to help prevent each of these mistakes that maybe we could just make clearer or more prominent in the documentation or examples.

    For cause #1, the latest version of the linker command file includes definitions for the passwords so that they are by default filled with 0xFFFF and won't have any code placed there by the linker unless you explicitly tell it to place something there (linker should catch it) - I don't know if early versions of the linker files had this. From Linker File:

    JTAGSIGNATURE : origin = 0xFF80, length = 0x0004, fill = 0xFFFF

    BSLSIGNATURE : origin = 0xFF84, length = 0x0004, fill = 0xFFFF

    IPESIGNATURE : origin = 0xFF88, length = 0x0008, fill = 0xFFFF

    For cause #2, this can be prevented by setting aside an array in FRAM for where you want to later write data in application using the DATA_SECTION type pragmas. This way it will work with the linker to make sure that area is free for you to write to when you go to build/link your code, to help catch the problem. It is best not to simply write to a hard-coded address to help prevent this type of mistake (or writing over your application code). The MPU should also be used to protect any areas that include your code or other constant data, to protect them from inadvertent writes - CCS now includes an assistant to help you configure your MPU settings.

    Do you think that providing more examples or some more documentation with this type of advice for FRAM usage would be helpful to keep people from running into this problem?

    Regards,

    Katie

**Attention** This is a public forum