How easy is it to migrate from Stellaris ARM Cortex-M3 to Cortex-M4? LM3S to LM4F

Anything which attempts to make the user's job easier - more efficient is welcomed - thanks for this.  May this humble outsider present some comments/observations - aiming to remain true to the "easier - more efficient" theme?  In addition - believe that I can make the case "against" pure transparency as a central goal.  Certainly no-one seeks to start anew - however multiple, compelling new features/capabilities await those willing to venture "just a bit beyond" full transparency...  TI's new M4 is miscast if its use is so restricted...

a) Top to Bottom makes great sense - I would differ from that proposed by starting with the TI Product Selector - insuring that the new MCU overlaps necessary functionality of the old -and/or its performance.

b) Absolutely insure that both your IDE and version of StellarisWare are the most current.  Changes are frequent - even slightly outdated versions may plague your effort with errors due to improper definitions - easily corrected with a current version. 

c) TI's "class" categorization has - and continues - to cause much pain to even we experienced ARM MCU developers/engineers.  The defining & clarifying documents are not especially easy to find - and once found a very special "horror" awaits.  BTW - I respect, admire & have been aided by one of the principal authors of the "Class" document yet this document early on offers up: "2 Determining the Product Class"

"To determine what class a particular microcontroller is in, see the CLASS field in the Device Identification 0 (DID0) register at offset 0x400F.E000. The CLASS designations in this register are as follows:• Sandstorm - 0x0 • Fury - 0x1 • DustDevil - 0x3 • Tempest - 0x4 • Firestorm - 0x6 • Blizzard - 0x5."

This advice - while certainly detailed & correct - requires that a functional MCU be mounted to a functional pcb and ready/waiting for test/verification.  How likely is this when the designer is considering candidate MCUs for such migration?  Not very - I (and multiple others) have said.  Nowhere in this document (spma035a.pdf) does a defining cross-list appear - matching specific MCUs to their designated "class."  Clearly this is a correctable oversight.  Vectoring every user - to yet another document search - (the current method) is ill-thought.  We have squawked here before - while spma035a is in itself good - this gaping hole deserves quick/complete rectification...

d) The use of "transparent & simple" are sharp daggers - beware.  Simple to whom - and to what degree?  My advice over many years and having taken a tech firm public is to expect neither - should you receive "any" count yourself lucky but never count on/rely upon "transparent or simple."  Specifically - the more complex M3s and M4s have much more sophisticated internal structures - in multiple instances new Stellaris commands have been developed just to accommodate these higher capability devices.  Such use will not be transparent - and rarely simple - nor should you hope for nor expect either.

e) More advanced devices demand multiple, serious reading of the manuals, code examples - suggest that adequate time/effort be reserved for familiarization, development & mastery...

f) Yes - version 2 will most likely go faster than version 1 (pre migration) but do NOT expect it to be transparent (requiring zero effort/consideration/planning)!

g) Transparent vs. Improvement!  New devices offer improved functionality & performance - yet another reason to "seek beyond" transparency.  Seems very sub-optimal to migrate to an improved device - and not to exploit the many additional features/functions/benefits now at your disposal.  More one thinks about "transparent" - the less appealing it becomes...

h) This forum is far & away best in class - served by multiple, skilled factory staff and a surpising number of experienced & dedicated outsiders...  One should prepare questions so that detail is adequate - and that scope is broad enough to attract favorable response.   Hope that this quick writing (serious user perspective) is of benefit...

Hi cb1,

Thanks for your comments.  I do want to point out that we have web pages that show all the devices in each class, for example, www.ti.com/blizzard.  We do not include the list in our documents because the list changes often as we add new parts and it would be very time consuming to update a great number of docs each time we add a product.  The way it happens now is that we update the product selector guide (PSG) and the web list is updated automatically from the PSG.  I'm sorry to send you to multiple places, but I'd rather send you knowing you will find the correct answer than to include a list that is sure to become outdated quickly.

Regards,

Sue

It would be nice if the data sheet for each device prominently declared which class the device belonged to.

If you know where you look, you can hunt it down, but it's far from obvious how to find it.

Sue Cozart said:

... we have web pages that show all the devices in each class, for example, www.ti.com/blizzard.

These web pages list which parts are in each Stellaris device class: Blizzard, Firestorm, Tempest, DustDevil, Fury, Sandstorm

www.ti.com/blizzard
www.ti.com/firestorm
www.ti.com/tempest
www.ti.com/dustdevil
www.ti.com/fury
www.ti.com/sandstorm

Application Report AN01285–November 2011 Differences Among Stellaris® Product Classes
(page 2 of 22)

Thanks for this - gives a motivated, potential TI MCU user "some chance" of resolving his MCU "class" issue.  (assuming he/she is even aware such exists - and is under no time nor effort crunch - and "stumbles" across this link...)

That said - an inexperienced user may well require 3-4 "clicks" to identify his MCU's class - an especially unlucky one may click six times...   Forgive me - this "class" issue is not new - as more MCU classes are introduced - the problem builds!   The elegance of "this solution" escapes one...  Sales are made by affording your clients, "Comfort & Convenience" (a la StellarisWare) - this class ID "trial & error search" falls surprisingly/painfully short.... 

So obvious that MCU "Class" likely belongs as a column entry w/in the Stellaris Product Selector - which is updated @ regular intervals... (just maybe a real "central fix" trumps a cascade of bandaids...disappointing - dare I say)  

These links take you to a generic page and a search on 'Blizzard' returns no results.  I am trying to indicate the correct Blizzard designation for the TM4C123GH6PGE MCU and cannot find out which Blizzard it is...  

I understand that you want to keep the information as up to date as possible, but setting the correct configuration bits in my IAR workbench is taking longer than implementing sophisticated control algorithms...

Hi Evelyn,

When we switched over to the Tiva nomenclature, we made it easier to identify classes.  All TM4C123x devices are Blizzard devices.

What configuration bits specifically are you having trouble with?

Regards,

Sue

Hi Sue,

Thank you for responding so quickly.

I understand that when you work with these MCU's every day and have access to all the pertinent information it is 'easy' to identify classes based on keywords like 'Blizzard' and 'Snowflake."

However.

As an end user, the documentation on whether the preprocessor defined symbol for a Tiva MCU should be set to TARGET_IS_BLIZZARD_RA1, TARGET_IS_BLIZZARD_RA3 or TARGET_IS_BLIZZARD_RB1 or even set at all is difficult if not impossible to find.  When I put this in as a search criteria on the TI website or in the forums, the search brings back no results.

Specifically, I am working with the TM4C123GH6PGE  on the IAR Workbench.  Which of these defined symbols should be used to correctly configure this MCU?  And where is this information kept so that if I change MCU's, I will know where to look without having to bother you guys personally?

Appreciate your attention to this matter,

Evelyn

Hi Evelyn,

I'm sorry for your confusion.  As I mentioned, all TM4C123x devices are Blizzard class.  You can find the particular revision of your device by reading the markings on your device or by reading the DID0 register.  See Appendix A in your data sheet for information on decoding the markings on  your device.  The DID0 register is documented in the System Control chapter.  We have been trying to make this easier by removing references to Blizzard in the data sheet and TivaWare, but sometimes it takes the 3rd party tool vendors longer to catch up.

Regards,

Sue

Hi Sue:  Sorry this is the wrong place for my posting, but I cannot get hold of you via email any more, so this is the only thing I could think of.  Please create an errata for the silicon bug I found.  See the attachment for details, and please let me know an email address which is not blocked.  Thanks, Garry.

0525.UART_Silicon_Bug.pdf

Ms. Cozart was a great aid to many here but has not appeared for awhile.

It may be that she's, "Left the building."

Vendor's Amit is more than capable of managing your request...

Thank you cb1, but who is "Vendor's Amit"?  Sorry, but I don't understand.  

Our local FAE has refused to process my request for Errata addition, so I tried all my previous email contacts at T.I., but they all reached dead ends.

Hello Garry,

I went through the report you mentioned. Is there a test that I can perhaps use (instead of creating another one which "may" not fail). As you mentioned LM3S is EOL, so what we need to do is to check it's applicability on the TM4C devices and then push for an errata.

Regards

Amit

Hi Amit:

Let's move to this thread, where this discussion belongs:

http://e2e.ti.com/support/microcontrollers/stellaris_arm/f/471/p/73536/1332513.aspx#1332513

Please meet me there, and I will give you the test case.

Thanks,

Garry.

Hello Garry

Sure.

Regards

Amit