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.

TM4C123G LaunchPad Workshop Lab9 build/linker errors

Other Parts Discussed in Thread: TM4C1294NCPDT

There appears to be an omission in the code for Lab9 in the TIVA™ C Series TM4C123G LaunchPad workshop.

After importing the project into CCS, adding the code from the workbook (and main.txt), the code failed to build. The ROM_* calls weren't defined, even though driverlib/rom.h was included.

It turns out TARGET_IS_BLIZZARD_RB1 wasn't defined anywhere. After adding the #define before the rom.h #include, the lab built without errors.

Lab 15 mentions adding TARGET_IS_BLIZZARD_RB1 as a predefined symbol in the project build properties, but that's not defined in the imported lab9 files.

Hopefully it can be fixed in the sample code, but if not, maybe this can save others a bit of frustration.

  • Brad,

    Thanks for this information!  This issue could have been created due to a new change in TivaWare.  If you look at the TivaWare for C Series Release Notes, item 1.3.12 states that the MCU class names have been replaced by part numbers.  TARGET_IS_BLIZZARD_Rxx has been replaced with TARGET_IS_TM4C123_Rxx.  This may have been the cause of the code failing to build.  We've made note of this and have plans to fix it.  Thanks again!

    -Rebecca

  • Thanks for the reply, Rebecca.

    The new class names make more sense and will be easier to choose from a list than an unknown internal code name.

    One of the previous labs, 5 I believe, uses the TARGET_IS_BLIZZARD define, so when you make the changes, be sure to change that one, too.

    Brad

  • Rebecca,

    the StellarisWare to TivaWare migration guide SPMA050A doesn't explain how (or even that) I should change the following Predefined symbols in the Project's advanced options.  What do I do ?

    I am migrating from Stellaris (LM4F*) to Tiva (TMC129X) and the following pre-defined NAMES in my old (CCSv5.2 project) have imported into CCS v5.4:

    PART_LM4F232H5QD
    TARGET_IS_BLIZZARD_RA1

    Must I change them (as I wasn't advised to), if so, what to ?

  • Hello Peter,

    Yes these pre-defines will change for TM4C129

    PART_LM4F232HQD ==> PART_TM4C129??? (where ??? depends on which TM4C129 part you are using

    TARGET_IS_BLIZZARD_RA1 ==> TARGET_IS_TM4C129_RA? (where ? will depend on which revision of the part. If the Part nomenclature has I1 in end then ?=0, I2 then ?=1 and so on)

    Regards

    Amit

  • Thanks for a speedy reply Amit.

    I will use PART_TM4C1294NCPDT but I'm unsure of its revision to determine the TARGET suffix.  how can I tell that ?

    I am hoping it will eliminate some compilation errors I am getting of the type.  

    identifier "GPIO_PF0_SSI1RX" is undefined

    I think that due to this post.

  • Hello Peter,

    I believe that when you mentioned TM4C1294NCPDT then it is the EK-TM4C129 Connected launchpad. For this device the TARGET_IS_TM4C129_RA1

    To double check, you can refer to the top of the device as shown in the image below

    For the error, please refer to the signal description section in QSSI chapter for the device. SSI-1 is not mapped on PF0.

    Regards

    Amit

  • thanks again Amit !

    The MCU I am using is XM4C129 ENCPDTI1 because the full release production silicon wasn't available at the time I built the boards.  Additionally I am also using the DK-TM4C129X Connected Development Kit which also has the I1 suffix.  Therefore for now I will use TARGET_IS_TM4C129_RA0 according to your formula above (not RA1).

    Thanks for pointing out SSI1 is not mapped to PF0.   Even after changing the part number and class as above this and other GPIO errors still remain (see below).   Was this mentioned in the StellarisWare to TivaWare migration guide SPMA050A ?  in section 3.4 of the guide I expected this to be automatically taken care of as the pin mappings changes between parts. 

    Here are the other GPIO errors :

    error #20: identifier "GPIO_PF0_SSI1RX" is undefined
    error #20: identifier "GPIO_PF1_SSI1TX" is undefined
    error #20: identifier "GPIO_PF2_SSI1CLK" is undefined
    error #20: identifier "GPIO_PF3_SSI1FSS" is undefined
    error #20: identifier "GPIO_PA0_U0RX" is undefined
    error #20: identifier "GPIO_PA1_U0TX" is undefined
    error #20:  identifier "GPIO_PD0_SSI3CLK" is undefined
    error #20: identifier "GPIO_PD1_SSI3FSS" is undefined
    error #20: identifier "GPIO_PD2_SSI3RX" is undefined
    error #20: identifier "GPIO_PD3_SSI3TX" is undefined

     

  • Hello Peter,

    This would not be in the migration guide. It is something that you need to check for TM4C129 as mentioned earlier. TM4C129 is a new platform device, so a lot of pin changes have been done.

    Regards

    Amit

  • OK, thanks Amit,  the change in pin mapping makes sense.  I temporarily forgot that the TM4C129 part I chose was not a direct replacement for the LM4F part I used to use.  The LM4F I used was replaced by a TM4C123 which I am not using.

    I have other migration questions which I'll post as new entries.

  • Amit Ashara said:
    I believe that when you mentioned TM4C1294NCPDT then it is the EK-TM4C129 Connected launchpad. For this device the TARGET_IS_TM4C129_RA1

    Amit, I have discovered from here that "It's TARGET_IS_TM4C129_RA1 for the new TivaWare 2.1, or the later releases of TivaWare 2.0 it's TARGET_IS_SNOWFLAKE_RA0".

    I'm posting this so others don't get mislead.  It appears  the TARGET_IS definition is only used for ROM functions.

    I am using TivaWare 2.0 so I need to use TARGET_IS_SNOWFLAKE_RA0

    Actually this means the formula you gave above doesn't take into account the version of TivaWare one has installed on your HDD.   It would be great if you could update your formula taking into account both the device suffix and the TivaWare version.

  • Hello Peter.

    Yes the define TARGET_IS is used for ROM functions. Till version 2.0 of TivaWare it was called Snowflake and at that time on RA0 devices were available. When 2.1 version of the TivaWare was released RA1 devices were available as well and we had changed the nomenclature as well.

    It is advised that users migrate to the latest version of the SW.

    Regards

    Amit

  • Thanks Amit.  It will easily take another 1-2 days of my time to upgrade and migrate again from CCS 5.4 to CCS 6.0 with TivaWare v2.1.   I cite recent example of this here .   Of course if I knew what to do it would only take a few hours.

    Additionally upgrading to the latest of anything comes with a new set of problems that take time to be sorted out.