CC2652R7: Consecutive Builds without code change results in different .hex files

Hi Kenneth,

Let me check if others on my team have noticed this behavior, I'll get back to you within 3 business days.

Thanks,
Toby

Hi Kenneth,

My team has not noticed such a behavior, we just did a similar test with F3 SDK (CC2340), and the hex files are identical when building twice with the no code changes (expected).

Yes, I'd recommend reverting to a version which worked ok for you (CCS 12.6).

Note that according to the Release Notes ( dev.ti.com/.../node ), the recommended CCS is " CCS-12.5.0".

From my experience, usually a Release Notes "+1" version should work ok (e.g. CCS 12.6 == CCS 12.5 +1).

Thanks,
Toby

Hey Toby,

Sorry for taking so long to respond but I tried reverting it back to CCS v12.6. I thought I had already checked to see if consecutive builds produced different hex files however maybe we didn't do enough builds. So we have few more observations, 1) sometimes it can take up to 7 times for a different hex file to be produced, 2) changing the optimization level seemed to help but not fix the problem, 3) project_zero which our project is currently is built around doesn't seem to have this same issue, 4) something to note is that our entire project include our project_zero file is written in C++, 5) Also by consecutive builds I mean like rebuild projects, 6) Lastly our map, out and bin files also seem to be different as well.  

These are some photos for reference:

Thanks,
Kenneth

Hi Kenneth,

Kenneth Thomas said:

1) sometimes it can take up to 7 times for a different hex file to be produced, 2) changing the optimization level seemed to help but not fix the problem

This is an interesting observation. I don't think I've seen it before.

Kenneth Thomas said:

3) project_zero which our project is currently is built around doesn't seem to have this same issue

Thanks for confirming this. We also tested with an out-of-box SDK.

Kenneth Thomas said:

4) something to note is that our entire project include our project_zero file is written in C++

That might be a good clue... I wonder if there is something additional needed to enable C++. I'll look into adding C++ code to an example to see if I start noticing the same issues you've reported.

Kenneth Thomas said:

5) Also by consecutive builds I mean like rebuild projects

Understood.

Kenneth Thomas said:

6) Lastly our map, out and bin files also seem to be different as well

This is at least a good sign of consistency -- whatever's causing the hex file contents to be different is likely also causing differences in map/out/bin files.

I'll look into this and update you within 3 business days.

I got these observations from a team member who was also looking into this problem. 

1) "FYI, by unchecking "Enable parallel build" on the project properties (Build page), the file order in the build log is fixed. But that doesn't solve the issue. So maybe the linker is parallelizing something as well and that's not deterministic.

2)I built the project 21 times (which is 3x as much as previous max before observed build inconsistency) with optimization level 2 (instead of z), and there were no inconsistencies.  In addition, back to level z, but then checking "select link-time optimization" (which made the build take forever), also made the build consistent (ran 21 times)"

Hopefully this helps too

Hi Kenneth,

I tried reproducing this on my end, but unable to.

What I'm using:

• CCS 12.6
• F2 7.40 SDK (CC13xx/CC26xx)
• example: C:\ti\simplelink_cc13xx_cc26xx_sdk_7_40_00_77\examples\rtos\LP_CC2652R7\drivers\empty\freertos\ticlang
• number of re-builds: 22
• optimization level: z

For the C++ aspect, I renamed empty.c to empty.cpp, and added a simple class.

Code attached: 

/*
 * Copyright (c) 2015-2019, Texas Instruments Incorporated
 * All rights reserved.
 *
 * Redistribution and use in source and binary forms, with or without
 * modification, are permitted provided that the following conditions
 * are met:
 *
 * *  Redistributions of source code must retain the above copyright
 *    notice, this list of conditions and the following disclaimer.
 *
 * *  Redistributions in binary form must reproduce the above copyright
 *    notice, this list of conditions and the following disclaimer in the
 *    documentation and/or other materials provided with the distribution.
 *
 * *  Neither the name of Texas Instruments Incorporated nor the names of
 *    its contributors may be used to endorse or promote products derived
 *    from this software without specific prior written permission.
 *
 * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS"
 * AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO,
 * THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR
 * PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR
 * CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL,
 * EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO,
 * PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS;
 * OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY,
 * WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR
 * OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE,
 * EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
 */

/*
 *  ======== empty.c ========
 */

/* For usleep() */
#include <unistd.h>
#include <stdint.h>
#include <stddef.h>

/* Driver Header files */
#include <ti/drivers/GPIO.h>
// #include <ti/drivers/I2C.h>
// #include <ti/drivers/SPI.h>
// #include <ti/drivers/Watchdog.h>

/* Driver configuration */
#include "ti_drivers_config.h"

extern "C" void *mainThread(void *arg0);

class MyClass {       // The class
  public:             // Access specifier
    int myNum;        // Attribute (int variable)

  void doStuff();
};

void MyClass::doStuff()
{
    if (this->myNum != 42)
        while (1);
    else
        this->myNum += 1;
}

/*
 *  ======== mainThread ========
 */
void *mainThread(void *arg0)
{
    /* 1 second delay */
    uint32_t time = 1;

    /* Call driver init functions */
    GPIO_init();
    // I2C_init();
    // SPI_init();
    // Watchdog_init();

    MyClass myObj;  // Create an object of MyClass

    // Access attributes and set values
    myObj.myNum = 15;

    myObj.doStuff();

    /* Configure the LED pin */
    GPIO_setConfig(CONFIG_GPIO_LED_0, GPIO_CFG_OUT_STD | GPIO_CFG_OUT_LOW);

    /* Turn on user LED */
    GPIO_write(CONFIG_GPIO_LED_0, CONFIG_GPIO_LED_ON);


    while (1)
    {
        sleep(time);
        GPIO_toggle(CONFIG_GPIO_LED_0);
    }
}

Can you share with me a simple project which causes the issue you observe?

Thanks,
Toby