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.

TM4C1294NCPDT: lifetime guarantee compared to MSP432 equivalent

Part Number: TM4C1294NCPDT
Other Parts Discussed in Thread: MSP432E401Y, CC2642R

I'm considering to redesign a current circuit based on LM3S9B90 using the part as mentioned. However, I believe that MSP432E401Y may be expected to be still available in - let's say - 12 years (both devices offer Ethernet MAC+PHY and USB).

According to datasheet comparison, there is not apparently little difference in peripheral units. As such, it seems that TIVA C merely provides a shorter software migration path due to its associated tivaware.

Any information regarding expected lifespan & technical recommendation regarding the best choice?

Note: launchpad eval kits for foth MCUs are present for test sessions related to the redesign.

  • Hi Rob,

      If you want to have easier migration then TM4C129 will be your choice as TivaWare is very similar to the Stellarisware. The MSP432E is based on the SimpleLink SDK platform if you want to build your application around that ecosystem. I can't comment on the longevity of MSP432E but I believe the TM4C129 will still have a long life to go. 12 years is a long time. I don't think neither MSP432E or TM4C129 can guarantee you on paper for 12 years of production. I will suggest you contact the local TI sales office regarding the service life. 

  • Regarding Lifetime: That's okay, when MCU's even may have a lifetime clearly below twelve years. Because technology is advancing & improving. But that's a matter of policy. E.g. Does a vendor present successor devices that are even pin compatible or not. It is this where TI performs far below e.g. NXP-policy, where ARM7-MCU's have got pin compatible Cortex successors.

    It would be nice if TI could submit a generic statement related to EOL of MCU's and its policy related to successor devices. The LM3S-experience is quite a matter of lost confidence in EOL-policies.

  • Hi Rob,

      Please understand we don't discuss roadmap on the public forum. It will be best if you could contact the local TI sales office regarding this matter. This forum is mostly used for technical discussion. Thank you!

  • Yes, I understand that. Therefore let me give a reason to discuss it here. It is the website structure that minimizes the trust that I have regarding Tiva lifetime.

    First of all, Tiva is categorized under "other microcontrollers". Where it is put together with CC430-families and other CC-11xx-families.

    When I enter http://ti.com/tiva-c-launchpad

    (link noted in the eval kit "let's get started" leaflet), a redirection to a generic web page (hardware kits) takes place. Towards the bottom, 7 MCU-families are listed. Tiva is not among this.

    Such experiences cause a huge drag in confidence regarding the future of Tiva.

    As a sidenote: it can be seen, that good old MSP430 is still shining brightly (for good reasons, though).

     

  • Hello Rob,

    Thank you for raising these concerns with us.

    The topic of concern regarding our long term commitment with Tiva devices is understandable to bring up given the issues in the past with LM3S devices. That said, we also learned a lot as a company due to what happened with Stellaris.

    On the topic of the re-direct, I will have to look into that more. Our web structure changed a while back, and I think that the link you referenced got impacted by this. No one else had reported that link redirecting like it does, so I need to find out what is going on there. I definitely dislike how that is looking right now myself.

    And I am not sure if this helps any, but we are actively working on a new TivaWare release that, unless we hit a severe snag, will be out before end of the year.

    Lastly, I appreciate the feedback you gave on the concerns with the overall structure and how it gives a lack of trust/confidence. That was a concern when trying to make the navigation simpler and less daunting for new customers to navigate and also highlight the newest device families (which, reality is, TM4C is far from new by now). So thank you for being candid with us on how the impression you get from the current setup. I will share this with the team to discuss.

  • Ralph,

    I appreciate your answer. Meanwhile, the question of service life has been forwarded to the appropriate distributor.

    Regarding the device in the Subject line as well as the only MSP432 device having MAC+PHY: The reason for including the latter in the inquiry is the following. Some investigation seems to confirm that (today too) no other ARM/Cortex chip vendor provides MAC+PHY on chip. However, I treat having also a PHY on chip as crucial. As such, I'd consider it even more important to evaluate the perspectives of both devices.

    In the case of MSP432 having a longer service life, I'd seriously consider this device for the migration task.

    FYI: I have to correct a sentence from the initial posting in this thread: According to datasheet comparison, there is not apparently little difference in peripheral units (MSP432E401Y vs. TM4C1294NCPDT). Sorry for the mistake. If it is true that peripherals of MSP432 compared to Tiva-C are quite comparable, this would make migration a bit simpler. Of course even more, if Tivaware could be applied to MSP432E401Y (with appropriate device header file etc.).

    Regards,

    Rob

  • Rob Maris said:
    no other ARM/Cortex chip vendor provides MAC+PHY on chip. However, I treat having also a PHY on chip as crucial.

    May it be noted that my small tech firm - as well as several (larger/far more notable) - recognize that (same) crucial 'PHY' factor?    Except - in the EXACTLY REVERSE SENSE!     

    The fact that (almost) 'all others' require the addition of an external PHY likely causes/provides:

    • 'Strength in Numbers' - can 'one vendor' - some way/how - make such a unique development - beyond 'all others?'    Really?
    • Avoids 'Culling oneself' - so desperately/deliberately - from the herd.    A HUGE 'Learning Curve' will be imposed - should the 'on-chip' MCU become 'uncertain.'
    • Superior PHY performance - especially due to the passage of (much) time - focused experience - and 'vast client feedback.' 

    Might we consider the 'How & Why' of 'On-Chip' PHY?     Are not two elements especially critical?'

    • One vendor alone - due to (some) fortuitous circumstance(s) - was 'able to uniquely succeed w/such implementation.'
    • Others (vast majority) suspected and/or concluded that 'On-Chip PHY imposed 'negatives' - deemed substantial enough - to remove it from consideration.     And - external PHY were 'readily available' from a variety of known/trusted sources...

    A third element - 'Comparison of External PHY vs. that 'On-Chip' - deserves analysis - does it not?    Thus - the simple/unique 'appearance of a capability' - good as it may seem - may or may not prove conclusive!

    ARM Cortex MCUs have and continue to 'leapfrog' each other on a regular basis.    Clock Speeds for M4s (and now M7s) have well exceeded those here - and other (especially external memory provisions & display ports) have emerged - enjoying huge advantages.

    It would prove interesting to learn your view - contrasted to the above.    'On-Chip' when 'done well' - and (near) equal to the 'flexibility, performance, accommodation & robustness of  'Multiple Sourced, external devices' (may) have its place.    The 'justification for on-chip' remains silent - the alternative has been (reasonably) described...

  • Hi cb1_mobile - thanks for your contribution...

    Let me explain my reasoning:

    With built-in PHY all of the RM (or RMII-wiring) is not applicable at all. This not only saves pins (and space), but also makes EMC less of a potential problem (which is - good layout assumed, a minor problem). Further it helps in simple two layer routing. Which makes a little cost difference.

    Such considerations makes sense in the given application, which is automation related and where all stuff outside of the MCU is not EMC-critical (emission). There are a couple of digital 24V inputs & outputs, analog ins, USB, Ethernet, ...

    Most of the PCB consists of quite "conventional" parts. And much of the GPIOs is assigned for "optimum" routing to the destination of the signal.

    If I'd had quite many parts with higher pin count, I woudn't bother about internal or external PHY. E.g. when external flash and/or RAM would be needed (which also requires extra EMC attention).

    As a general statement: I'd even say this: If an MCU would offer a USB port with external PHY (analogously to RS232&CAN transceivers), I'd prefer this for simple reasons: If any electromagnetic pulse event destroys the PHY, the MCU might still operate. This means more system reliability if USB communication is not crucial for system operation (let's say not permanent) and it means better repairability. Such considerations of course don't apply to Ethernet because of the galvanic separation. In one word: I generally don't feel very well with any MCU pins that are fed directly to any outside interface - regardless common-mode chokes and blocking diodes.

  • Greetings,

    While the staff has long departed (it IS Sunday) I shared your writing - both they & I are impressed - yet (not) convinced.

    May we review your response - systematically - point by point?    Yours in 'Pacific Blue' - where my boat awaits its 'mad captain.'

    • "...all of the RM (or RMII-wiring) is not applicable at all. This not only saves pins (and space), but also makes EMC less of a potential problem."

    Agreed.   R.M. +1

    • " it helps in simple two layer routing."

    Agreed.  R.M. +2

    • "much of the GPIOs is assigned for "optimum" routing to the destination of the signal."

    Same    R.M. +2

    • "many parts - higher pin count - wouldn't bother about internal/external PHY. E.g.  external flash and/or RAM deployed"

    Same   R.M. +2

    • "If any electromagnetic pulse event destroys the (External) PHY, the MCU might still operate."

    EXT!    R.M. +1  In such case - the (External PHY) plays that (same) sacrificial role - cb1 'dances' (at last) in the end zone!

    • "Such considerations of course don't apply to Ethernet because of the galvanic separation."

    Same  R.M. +1   IIRC several of our firm's clients employ similar - or (other) isolation methods.

    This has exhausted your significant points - my group believes.

    Comes now my listing of 'External PHY's Advantages:    (Women/Children advised to 'Stand-Back' - avoid the 'Prop-Wash')

    • Multiple PHY Devices available from many sources
    • Far Newer PHY Devices 'out-perform' that (other) MCU's (rather old) PHY
    • One client employs 'Redundant External PHY Chips' - beyond 'On-Chip' capability
    • Far Newer ARM Cortex MCUs have (long) been introduced.   Multiple System Benefits accrue from such 'Upgrades.'
    • Any/All 'Negatively Impacting Issues' - arriving w/'On-Board' PHY - are completely prevented!

    While you've 'fought the good fight' - have you not 'skipped over' - each/every one - of these (Crucial Points) above?     Alas - such IS understandable - as they 'Tilt the Scale' FAR in favor of the External PHY - which likely explains why (almost) ALL Others (i.e. those 'naming their MCUs') have committed to the External PHY.

    As you know - much of Engineering involves (even demands) 'Trade-Offs' - and the price paid for (just one) benefit - cannot justify the (pardon) 'Turtle' sitting in the Left Lane of the Autobahn!    

  • Hi Rob,

    Rob Maris said:
    Of course even more, if Tivaware could be applied to MSP432E401Y (with appropriate device header file etc.).

    I've never heard of TivaWare being used with another MCU family. Even if you managed to make it work though I would say that would strictly fall into an area where neither our team nor MSP432 would offer any support. TivaWare is for TM4C devices and SimpleLink SDK is what is used for MSP432.

    By the way, depending on your future application needs, if you foresee a need for wireless communication technologies like what TI offers, that could be another reason to migrate as the latest support for Wi-Fi, BLE, etc. will be on MSP432.

  • Hi Ralph,

    migration to the latest support for e.g. BLE is an interesting point, since the customer wants some wireless extension in order to allow clients to exchange data with next revision industrial automation controller product. I have been checking it out, and found this page www.ti.com/.../msp432e4.html where I also can see that TI is advocating (actively) the concept of a built-in PHY.

    But... the devices with built-in PHY do not offer wireless capability... So I'd still need external devices in order to provide wireless functionality. As long as this applies, the only reason for selecting MSP432 or TM4C is migration effort, while considering service life of these families.

    BTW: the web page mentioned here suggests - at least at first glance - that these MAC+PHY devices natively provides wireless connection capability...

  • Hello Rob,

    I am not knowledgeable enough about those devices to comment, but I am trying to get someone who is able to elaborate looped in here, I will see if they can get back to you on Monday.

  • Hi Rob,

    My best recommendation is to proceed with an MSP432E + CC2642R solution.  Both of these devices are a part of the SimpleLink platform and could take advantage of the common development environment.  Additionally, there are already examples available using the CC2642R in NWP mode next to the MSP432E.  We do not have a single chip with BLE connectivity and a built-in Ethernet PHY. http://dev.ti.com/tirex/explore/node?node=AFx.GPKrcYKYb2o0x0jWHg__kmPly-e__LATEST

  • Well, meanwhile Arrow Germany answered. The only information was: Both parts are not known to be subject to EOL.

    That sort of information can anyone read on any product site, whether it is Last Time Buy, active, NRND etc. Weeks have gone now (also because Arrow forgot the inquiry) for nothing.