Tivaware Defines

I understand the confusion on this.  Inside of that define you have two things: the product platform/silicon class, and the silicon revision.  The class used to be defined in the DID0 register in the datasheet, but it appears that we have recently gone away from using that name in favor of the Tiva platform naming (a good thing).  So, with that said, all current Tiva C series devices are Blizzard class.  We'll need to clarify this going forward.  

The second piece of that macro can also be obtained from DID0.  It's the major/minor revision of silicon.

I *think* that this macro is only necessary when using ROM, so if you're not using ROM, you should be able to ignore it.

Clarification on the class would be useful.

 The second part is rather worrisome and seems to beg the original question and raise another.

First how am I to know the contents of the DID0 register?  The data sheet appears to describe the format but not the value.

Second this would appear from your description to be value that should be checked at run time not compile time.  At the very least there must be a Tivaware function to verify compatibility between the device and the revision of the silicon the software was compiled for?  This would be less worrisome if you could specify the revision in the part number but since you cannot you are left with the possibility of getting non-matching silicon.

Robert

The software team is already aware of the class naming issue and will resolve the problem in future releases.

You obtain the contents of the DID0 register by reading the contents either via some basic program that spits out data over something like a UART or via a debugger memory window.  Once you know the revision of your specific part, you set the value in your project.  There is the possibility that the silicon revision on something like a development board may be different than parts you order for mass production, but once in production, silicon revision won't change unless there is a PCN.  In that case you would get advanced notice of the change and have time to adjust your software.

Again, the TARGET_IS macro is only used to determine which ROM functions are available.  So, if you don't use the ROM, this is all a moot point.  Within a specific product class, you will very rarely lose or break functionality by a silicon revision.  The actual functions in ROM may change due to a device erratum (just an example), but the API pointed to by the preprocessor will not.  

You can, I hope, understand why I consider reading the DID0 register to find out what the DID0 register should be an incomplete solution.

I would like to see TI officially commit to not changing the contents of DID0 w/o a PCN.    That's a partial solution but PCNs like this in my experience often do not make it to those who could make a judgement call (and get some testing done) until units start failing.  And often the person who could recognise a firmware change as a possible source of the problem is working on other responsibilities or has forgotten the details.

At least there is is a version register so I can/will check against revision changes (The very fact that one exists suggests that changes are likely)

"Within a specific product class, you will very rarely lose or break functionality by a silicon revision"

I and I know others have as well been hit by that very problem.  In the worst case the revisions are such that you cannot design code to work on both revisions of the silicon and you cannot distinguish between them in SW.  I ran into that once and since the bondout in the ICE was at a third incompatible revision the Heisenbugs were very difficult to track down.

It is good news that I can tell the revisions apart.  That is a capability I've wished for in desparate times.

Robert