• State Resolved
  • Locked Locked
  • Replies 7 replies
  • Subscribers 31 subscribers
  • Views 710 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.

CCS/EK-TM4C1294XL: for loop being ignored

Helder Sales
Expert 1220 points
Part Number: EK-TM4C1294XL

Tool/software: Code Composer Studio

Hi,

I'm having issues with for loops, the code compiles just fine, but it seems that the program ignores the for statement. If I change "for" to "while", the code run as expected. What may be causing this behavior? I'm missing some setting to enable for loops?

  • 0
    Guru 92251 points

    What is the code within the loops?

    If the code has no side effects, e.g. is for an attempt to create a delay, the optimizer might be removing the loops.

  • 0 in reply to Chester Gillon
    Guru 11940 points

    It would be easier if you presented the code in question, and the build settings.

    And keep in mind, a C compiler (i.e. the C language) has an "all is flat memory" model, originating from the environment it came from (Unix). There is no I/O in C. If something is changing outside the scope of the compiler (i.e. peripheral registers, interrupt routines), you must use "volatile" to tell the compiler. Otherwise he will remove it at the first optimization level.

  • 0
    Guru 13040 points
    Helder,
    During programming learning, every once in a while one comes to a moment in which he "discovers a bug in the C language" :)
    Look again, because if your code is not doing what you expected it to do, it is probably doing what you wrote it to do!
    In case of desperation, turn off all optimizations and make everything volatile - only to make sure.
    Cheers
    Bruno
  • 0
    Expert 1220 points 
    if(ROM_SysCtlResetCauseGet() & SYSCTL_CAUSE_WDOG0)
    {
        uint32_t pui32Data[1];
        volatile uint16_t i;
        uint16_t j = 0;

        EEPROM_Init();

        //wears EEPROM uniformly (at least try)
        for(i = 0; i <= 6136; i += 4)
        {
            ROM_EEPROMRead(pui32Data, 0x00 | i, sizeof(pui32Data));

            if(pui32Data[0] == 0xFFFFFFFF)
                break;

            if(i == 6136)
            {
                ROM_EEPROMRead(pui32Data, 0x17FC, sizeof(pui32Data));

                if(pui32Data[0] == 0xFFFFFFFF)
                {
                    pui32Data[0] = 0;
                    ROM_EEPROMProgram(pui32Data, 0x17FC, sizeof(pui32Data));
                }

                j += (i/4);
                pui32Data[0] += j;
                i = 0;
                j = 0;

                EEPROMMassErase();

                ROM_EEPROMProgram(pui32Data, 0x17FC, sizeof(pui32Data));

                break;
            }
        }

        pui32Data[0] = 0;

        ROM_EEPROMProgram(pui32Data, 0x00 | i, sizeof(pui32Data));
        ROM_EEPROMRead(pui32Data, 0x17FC, sizeof(pui32Data));

        if(pui32Data[0] != 0xFFFFFFFF)
        {
            if(i == 0)
                i = 4;

            else
                i += 4;

            i /= 4;
            j += (i + pui32Data[0]) - 1;
        }

        else
        {
            if(i == 0)
                i = 4;

            else
                i += 4;

            i /= 4;
            j += i;
        }

        UARTprintf("Watchdog Reset (WDOG_0).\n"
                "Resets: %u\n\n", j);

        ROM_SysCtlResetCauseClear(SYSCTL_CAUSE_WDOG0);

        ROM_SysCtlPeripheralDisable(SYSCTL_PERIPH_EEPROM0);
        ROM_SysCtlPeripheralReset(SYSCTL_PERIPH_EEPROM0);
    }

    Man, sometimes I feel dumb, like right now. With one word you can solve everything (if not this guy -> ";"). Never thought of optimization being the problem, and that the volatile could solve that. Thanks everyone! For those who are wondering, Optimization level was set to  --opt_level=2  --opt_for_speed=5, and the code was the one above.

    Initially I used goto, but they say goto is evil :p so I changed the code to use for loop instead. 

  • 0 in reply to Helder Sales
    Guru 11940 points

    Helder Sales said:
    Initially I used goto, but they say goto is evil :p ...

    De Omnibus Dubitandum.

    If no company coding guidelines (like MISRA) prohibit you from certain constructs, feel free to use it. A goto >>can<< make code shorter and improve readability.

  • 0 in reply to f. m.
    Expert 1220 points

    f. m. said:
    A goto >>can<< make code shorter and improve readability.

    Now that you mentioned, I realized that using goto in that case makes the code a bit smaller. Normally I use because it's easy to implement.

    Maybe they say it's evil because people tend to use gotos excessively, which can make the code difficult to understand, or just laziness to find a better way.

  • 0 in reply to Helder Sales
    Guru 11940 points

    Helder Sales said:
    Now that you mentioned, I realized that using goto in that case makes the code a bit smaller. Normally I use because it's easy to implement.

    Shorter source code does not necessarily mean shorter target code. Modern compilers are quite good, so one doesn't need to be tricky. A clear-structured, self documenting code is not the product of a Programming Guideline, but of a responsible coder.

    The 'goto' statement stems from the BASIC language, and originally allowed to 'jump' to everywhere. Perhaps you can dig out an example of old BASIC spaghetti code, to know why it's now frowned upon. But you can write convoluted and unmaintainable code in MISRA-C as well.