• State Resolved
  • Locked Locked
  • Replies 14 replies
  • Subscribers 32 subscribers
  • Views 2112 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

Same source code, different results

Joshua Lowry
Intellectual 370 points
Other Parts Discussed in Thread: TM4C123GH6PM

Hello everyone, me again with another noob question.

So I am revisiting a TIVA project I finished a few months ago and I am confused about what happens when I run it now. Long story short, I have a new laptop with no access to my old laptop with the old TIVA project saved on it, created in CCS. I still have access to the source code however, so I just created a new CCS project and copy-pasted the source code into it. The purpose of the project itself is basically to generate space vector-based PWM signals for a DC-AC power inverter and it does this using ISRs triggered by GP timer timeout events that read pre-determined pulse width time values from an array and then loads them into a timer, finishing the ISR. The program then waits in an empty while loop for the next timeout event. It was set to generate this PWM scheme with a fundamental frequency of 50Hz and a switching frequency of 2kHz.

The only change I made to the source code was changing the ROM_SysCtlClockSet function to a SysCtlClockSet with the same input arguments and ROM_FPUEnaable to FPUEnable. This was because I couldn't get the compiler to recognise the ROM functions, even though I included what I thought to be the correct header files (I had not changed them from the previous working project). So I changed them because I thought they should do pretty much exactly the same thing. Those are literally the only changes I've made to the code. I am now using a newer version of CCS (I think) and I am using a TIVA C Series Launchpad as before.

However, since I tried running the new project with the slightly changed source code, the interrupt service routines takes much so longer for it to run such that the fundamental frequency is no longer the same and is in fact a lot higher. Using an oscilloscope to determine, I remember the ISR used to take 1.2us to run and now it takes 10us. I tried playing with the optimisation settings but they didn't restore it to its previous speed and I tried changing the ISR a little bit by removing half of the output pin value setting commands to try and speed it up, but I saw no change (not even a decrease in ISR execute time like what happened before on my old laptop) and I also confirmed that the clock is running at the same frequency it was before (80MHz). Is there anything external to the source code, such as in the project settings that be causing such a slowdown?

  • 0
    TI__Guru**** 244400 points
    Hello Joshua

    Is there a change in the hardware that you are running the project?

    Regards
    Amit
  • 0 in reply to Amit Ashara
    Guru 11940 points

    Is there a change in the hardware that you are running the project?

    And don't forget the toolchain. You can expect identical results only for the same compiler and the same project settings (build options).

    As a well-known example, turning up the optimization level totally breaks a lot of examples/applications ...

  • 0
    Expert 2355 points

    Hi Joshua,

    That profound a change is unlikely to be compiler/optimization related.  Are you really sure it is still running at 80MHz?  A few others have run into errata with the Clock API's and were running at an unintended clock rate...  Good luck!

    Regards,

    Dave

  • 0
    Guru 117855 points

    Joshua Lowry said:
    I also confirmed that the clock is running at the same frequency it was before (80MHz).

    And HOW did you realize such "confirmation?"   In my book - outputting a divided replica of system clock - via a Timer forced to PWM mode - proves the "best" means of such confirmation.

    Let this stand as post 2 (agreeing w/Source_2) that your SysClock should be (really) confirmed.   (sooner rather than later)

    Note too that your, "long story - short" fails to list your MCU.   There are harsh differences between 123 and 129 versions...   (such short stories may prove ok - but must cover the basics...)

  • 0 in reply to SourceTwo
    Guru 27665 points
    Mostly agreed. It can happen but it usually means there is something wrong with the source to begin with. The more complex the source and the less disciplined the development the more likely optimization may have had quite dramatic results. Heisenbugs are often affected by optimization level (it's part of what makes them so hard to track down).

    Having said that compilers changes and optimization levels do have a way of surfacing race conditions.

    There is also the possibility of an optimization bug but that's an increasingly uncommon occurrence. Thankfully.

    Robert
  • 0 in reply to cb1_mobile
    Intellectual 370 points
    I confirmed it by modifying the source code such that each pulse was of the same minimum time width (10us), then adding exactly 1us onto each by increasing the timer load values by 80 counts. An 80MHz clock tick period is 12.5ns, multiplied by 80 is 1us. I used a digital oscilloscope with the cursors to determine that exactly 1us had indeed been added onto each pulse. My MCU is a TIVA TM4C123GH6PM, both before when it was working as expected and now.
  • 0 in reply to Amit Ashara
    Intellectual 370 points
    I am very sure. I am using the same microcontroller, a TM4C123GH6PM attached to a C Series launchpad now as I did before.
  • 0 in reply to Joshua Lowry
    TI__Guru**** 244400 points
    Hello Joshua

    And if you revert the changes then does it restore the responsiveness of the device?

    Regards
    Amit
  • 0 in reply to Amit Ashara
    Intellectual 370 points

    Nothing really seemed to be changing it.

    Since then though I have uninstalled CCS v6 and installed v5.4 as this was the version I think I previously used. I am trying to restore all compiler and IDE settings back to what they were. The original project was actually the "lab4" project of the "Getting Started with the TIVA™ C Series TM4C123G LaunchPad" with the source code changed to fulfill my desired application. I even removed my up to date TIVAWARE files and brought back the old v1.1 as this is what I think I had used before (don't know how much that would have helped).

    I have downloaded lab 4, which uses GP interrupt timers to time the flashing of an RGB LED and it works fine. However, when I copy-paste my own source code into it, it now doesn't work at all. The interrupt handler's name in my source code has been kept the same. It appears to run in debug mode but I don't observe any outputs with my oscilloscope and often when I press pause (but not every time) I get a message in red font saying 'Can't find a source file at "/tmp/TI_MKLIBBMPOk8/SRC/fd_mul_t2.asm" Locate the file or edit the source lookup path to include its location.' I feel I am (hopefully) very close and that this is the final hurdle. Do you have any idea what could be causing this? I should note that the source code has been verified to work.

    Or is this a job where I have to add little bits of my source code to the original working lab4 to systematically determine the exact source of the error? :(

  • 0 in reply to Joshua Lowry
    TI__Guru**** 244400 points
    Hello Joshua

    I am afraid so. It needs to be reverse engineered to the failing point.

    Regards
    Amit
  • 0 in reply to Amit Ashara
    Intellectual 370 points
    Ah ok. I hoped it wouldn't have to come to that as it's quite big. But thank you and everyone else who took the time to reply and help me out. I always appreciate it.
  • 0 in reply to Amit Ashara
    Intellectual 370 points

    Hello Amit and everyone.

    Just an update. I got it working again and I found out why it is so much slower. The reason is that, before I 'finished' the project a few months ago, I wanted to parameterise my code and in doing so, I introduced a floating point operation into the ISR which took up a lot of processor resources to carry out and I must have not properly checked if the performance had been impacted by my changes before shelving the project for the following several months. So it was nothing to do with the build settings. It was all the result of my own mistake.

  • 0 in reply to Joshua Lowry
    TI__Guru**** 244400 points
    Hello Joshua

    And you did not switch on the Floating Point Unit?

    Regards
    Amit
  • 0 in reply to Amit Ashara
    Intellectual 370 points
    I did switch on the FPU. But that particular floating point calculation was basically just totally unnecessary could have been done just using integer data-types, which is how it was done before I attempted to parameterise the code. Don't ask me why I did it haha. >_>