Compiler/SW-EK-TM4C1294XL: How to set system clock frequency to 120 MHZ and How calculation execution time of instructions In TM4C1294xl

Preformed a test:
1. Changed Tivaware driver library variant TM4C1294NCPDT, project symbol (CLASS_IS_TM4C129) then cleaned compiled driver library.

The run time ASSERT of SysCtlClkGet() never raised a warning during compile as one might expect upon not finding runtime symbol (CLASS_IS_TM4C123). Nor did it ever raise a runtime debug message, with debug defined in the application.

Other NON Tivaware module ASSERTS remain functional and do print messages via UART0. Perhaps the way the Tivaware driver ASSERT was written is incorrectly formed?

At (now) 52 posts in - and "Straying SO FAR" from o.p.'s (limited) Subject: (i.e. Set System Clock & Calc. exe. time) - is it not wise to, "Slam the door here" - and launch a, "Properly Subject Labeled" thread - focusing on these newer (and far more interesting) topics - unlikely to, "Ever again be noted" - once this thread, "rotates into forum oblivion?"

If "vendor note/comment" IS sought - a fresh thread - named properly - appears best...

BP101 said:

Preformed a test:
1. Changed Tivaware driver library variant TM4C1294NCPDT, project symbol (CLASS_IS_TM4C129) then cleaned compiled driver library.

The run time ASSERT of SysCtlClkGet() never raised a warning during compile as one might expect upon not finding runtime symbol (CLASS_IS_TM4C123). Nor did it ever raise a runtime debug message, with debug defined in the application.

Other NON Tivaware module ASSERTS remain functional and do print messages via UART0. Perhaps the way the Tivaware driver ASSERT was written is incorrectly formed?

It will not raise a compile-time warning or error. These ASSERTs can only produce some result at runtime. To show why, let's look at the definition of CLASS_IS_TM4C123 and CLASS_IS_TM4C129. This comes from C:\ti\TivaWare_C_Series-2.1.4.178\inc\hw_types.h if TivaWare is installed to the default location:

//*****************************************************************************
//
// Helper Macros for determining silicon revisions, etc.
//
// These macros will be used by Driverlib at "run-time" to create necessary
// conditional code blocks that will allow a single version of the Driverlib
// "binary" code to support multiple(all) Tiva silicon revisions.
//
// It is expected that these macros will be used inside of a standard 'C'
// conditional block of code, e.g.
//
//     if(CLASS_IS_TM4C123)
//     {
//         do some TM4C123-class specific code here.
//     }
//
// By default, these macros will be defined as run-time checks of the
// appropriate register(s) to allow creation of run-time conditional code
// blocks for a common DriverLib across the entire Tiva family.
//
// However, if code-space optimization is required, these macros can be "hard-
// coded" for a specific version of Tiva silicon.  Many compilers will then
// detect the "hard-coded" conditionals, and appropriately optimize the code
// blocks, eliminating any "unreachable" code.  This would result in a smaller
// Driverlib, thus producing a smaller final application size, but at the cost
// of limiting the Driverlib binary to a specific Tiva silicon revision.
//
//*****************************************************************************
#ifndef CLASS_IS_TM4C123
#define CLASS_IS_TM4C123                                                     \
        ((HWREG(SYSCTL_DID0) & (SYSCTL_DID0_VER_M | SYSCTL_DID0_CLASS_M)) == \
         (SYSCTL_DID0_VER_1 | SYSCTL_DID0_CLASS_TM4C123))
#endif

#ifndef CLASS_IS_TM4C129
#define CLASS_IS_TM4C129                                                     \
        ((HWREG(SYSCTL_DID0) & (SYSCTL_DID0_VER_M | SYSCTL_DID0_CLASS_M)) == \
         (SYSCTL_DID0_VER_1 | SYSCTL_DID0_CLASS_TM4C129))
#endif

#ifndef REVISION_IS_A0
#define REVISION_IS_A0                                                     \
        ((HWREG(SYSCTL_DID0) & (SYSCTL_DID0_MAJ_M | SYSCTL_DID0_MIN_M)) == \
         (SYSCTL_DID0_MAJ_REVA | SYSCTL_DID0_MIN_0))
#endif

#ifndef REVISION_IS_A1
#define REVISION_IS_A1                                                     \
        ((HWREG(SYSCTL_DID0) & (SYSCTL_DID0_MAJ_M | SYSCTL_DID0_MIN_M)) == \
         (SYSCTL_DID0_MAJ_REVA | SYSCTL_DID0_MIN_0))
#endif

#ifndef REVISION_IS_A2
#define REVISION_IS_A2                                                     \
        ((HWREG(SYSCTL_DID0) & (SYSCTL_DID0_MAJ_M | SYSCTL_DID0_MIN_M)) == \
         (SYSCTL_DID0_MAJ_REVA | SYSCTL_DID0_MIN_2))
#endif

#ifndef REVISION_IS_B0
#define REVISION_IS_B0                                                     \
        ((HWREG(SYSCTL_DID0) & (SYSCTL_DID0_MAJ_M | SYSCTL_DID0_MIN_M)) == \
         (SYSCTL_DID0_MAJ_REVB | SYSCTL_DID0_MIN_0))
#endif

#ifndef REVISION_IS_B1
#define REVISION_IS_B1                                                     \
        ((HWREG(SYSCTL_DID0) & (SYSCTL_DID0_MAJ_M | SYSCTL_DID0_MIN_M)) == \
         (SYSCTL_DID0_MAJ_REVB | SYSCTL_DID0_MIN_1))
#endif

Note that HWREG is a macro which reads a specific address. It is defined directly above in the same file:

//*****************************************************************************
//
// Macros for hardware access, both direct and via the bit-band region.
//
//*****************************************************************************
#define HWREG(x)                                                              \
        (*((volatile uint32_t *)(x)))

So this is something that MUST occur at runtime. The comment above CLASS_IS_TM4C123 and CLASS_IS_TM4C129 explains that these are to be used at runtime in if() statements.

Note that if your application code includes things like this:

#ifdef CLASS_IS_TM4C129
... do stuff that can only be done on TM4C129 ...
#endif

then that is a programming ERROR!!! That is because CLASS_IS_TM4C123 and CLASS_IS_TM4C129 are BOTH defined, regardless of which TM4C variant you're compiling for!

I repeat that the compiler cannot warn about this at compile-time. At least not the compiler as it exists today. As far as I know, both the TI ARM compiler and the GCC ARM compiler supplied by vendor for TM4C are basically just ARM compilers without any specific knowledge or special features for the TM4C family. If you want a compiler to provide compile-time checks such as this, then you would need the compiler to contain special knowledge of the TM4C family. You would need to pass a command line argument to the compiler to tell it which exact variant you're compiling for at the moment. In that compiler, HWREG and similar things would need to be compiler intrinsics, not ordinary defines in code. A compiler with this type of knowledge about the target chip and with HWREG being an intrinsic that could be resolved at compile time would make it possible to issue a compile-time warning that an ASSERT will fail -- and this comes with a caveat too. If your code passes arguments to a TivaWare function which cannot be resolved at compile time (because they depend on values not known until runtime) then it is possible that the compiler will not warn about an assertion that will fail.

The bottom line is that as long as the compiler does not know the details of the target chip, such as what values will be found in certain registers like SYSCTL_DID0, you will not get your desired compile-time warning.

twelve12pm said:

As far as I know, both the TI ARM compiler and the GCC ARM compiler supplied by vendor for TM4C are basically just ARM compilers without any specific knowledge or special features for the TM4C family. If you want a compiler to provide compile-time checks such as this, then you would need the compiler to contain special knowledge of the TM4C family.

That was sort of my point that the CCS code analyzer will complain about every other Symbol that is not explicitly defined or in the index but let ASSERT 123gClass fly by without any warning. Notice that SysCtrlClockSet() has an (If 129Class ASSERT return) but the runtime ASSERT in SysCtrlClkGet() was left for post mortem. Tivaware was supposed to free the programmer from wasting time in tracking down library issues that cause MCU faults. It has done a very good job but failed miserably in some earlier driver libraries to ensure these MCU specific class calls are made visible to the CSS code analyzer. 

CCS code analyzer warns (pre/post compile) watches for defined Macros (#Ifdef ASSERTS) being incorrectly enabled. CCS compilers will not fully build projects with incorrect ASSERT defines being enabled and throws errors if they are. So the compiler checks library ASSERTS before runtime despite all efforts to prove otherwise.  LWIP 1.4.1 has many of these (#ifdef ASSERT) checks to ensure the project is not being built with the wrong protocols enabled.

Question is has the ASSERT 123Class in SysCtlClkGet() been fixed in later versions of the Tivaware library?

BP101 said:

So the compiler checks library ASSERTS before runtime despite all efforts to prove otherwise.  LWIP 1.4.1 has many of these (#ifdef ASSERT) checks to ensure the project is not being built with the wrong protocols enabled.

Can you show me a specific example of such an ASSERT that is caught at compile-time? It doesn't matter if it's a TivaWare or lwIP assert. I'd like to figure out how that works. Thanks.