This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Code not working on LPC2148 board

I bought an ARM LPC2148 Development board and started uploading code in it.  I wrote the code to blink the on-board 4 LEDs.  It gets uploaded successfully in the board but the LEDs never blink (leave alone the blinking according to the code).  I have rechecked the code again and again.  I am getting 0 V on the pins(P1.16, P1.17, P1.18, P1.19) to which the LEDs are connected.  I cannot figure out why this is happening.  Help!!

The code is:-

#include  <lpc214x.h> //Includes LPC2148 register definitions
#define LED1_ON() IO1SET=(1<<16) //Macro Functions to turn ON LED

#define LED2_ON() IO1SET=(1<<17)

#define LED3_ON() IO1SET=(1<<18)

#define LED4_ON() IO1SET=(1<<19)

#define LED1_OFF() IO1CLR=(1<<16) //Macro Functions to turn OFF LED

#define LED2_OFF() IO1CLR=(1<<17)

#define LED3_OFF() IO1CLR=(1<<18)

#define LED4_OFF() IO1CLR=(1<<19)

void  Delay(unsigned char j)    //This Function is used to cause delay between LED ON and OFF events

{

unsigned int  i;

for(;j>0;j--)

{

  for(i=0; i<60000; i++);

}

}

int  main(void)

{

PINSEL0 = 0x00000000; // Enable GPIO on all pins

PINSEL1 = 0x00000000;

PINSEL2 = 0x00000000;

IO1DIR = (1<<19) | (1<<18) | (1<<17) | (1<<16); // Set P1.16, P1.17, P1.18, P1.19 as Output
while(1)

{

  LED1_ON();

  Delay(25);

  LED1_OFF();

  LED2_ON();

  Delay(25);

  LED2_OFF();

  LED3_ON();

  Delay(25);

  LED3_OFF();

  LED4_ON();

  Delay(25);

  LED4_OFF();

}

return(0);

}

Parents
  • Just adding an increment of an integer isn't enough to stop an optimizing compiler removing  the loop (the value of k is never used, so will be dropped, and what is left is still an empty loop).

    Generally you either need (1) something which writes back to a volatile memory location, or (2) something which is passed outside of the translation unit.

    Just disabling optimization is probably a good starting point for debugging, but if in doubt it's always sensible to disassemble the binary if you are not sure =)

    Pete

Reply
  • Just adding an increment of an integer isn't enough to stop an optimizing compiler removing  the loop (the value of k is never used, so will be dropped, and what is left is still an empty loop).

    Generally you either need (1) something which writes back to a volatile memory location, or (2) something which is passed outside of the translation unit.

    Just disabling optimization is probably a good starting point for debugging, but if in doubt it's always sensible to disassemble the binary if you are not sure =)

    Pete

Children
  • Just disabling optimization is probably a good starting point for debugging, but if in doubt it's always sensible to disassemble the binary if you are not sure =)

    I agree.

    Just adding an increment of an integer isn't enough to stop an optimizing compiler removing  the loop (the value of k is never used, so will be dropped, and what is left is still an empty loop).

    That's a reason why I stated skepticism on that approach in my previous reply. I included that kind of workaround because I encountered it in some articles and tutorials, I wonder how their program seem to work (as they claim) >:\

    Iterating a NOP is common in creating delay in assembly language. Although NOP is not guaranteed to acquire processing time in newer high-performance processors, it may be possible to use it to avoid an empty loop in C/C++. Below, the Delay function is modified by placing a __nop() in the inner loop (not necessarily to consume clock cycle/s although in the case of Delay expending time is beneficial).

    void  Delay(unsigned char j)   //This Function is used to cause delay between LED ON and OFF events

    {

    unsigned int  i;

    for(;j>0;j--)

    {

      for(i=0; i<60000; i++) __nop();

    }

    }

    GCC's optimization results in no code generated for asm("mov r0,r0") and to prevent that, we turn to volatile again, asm volatile("mov r0, r0"). On the other hand, the above code may work without appealing to a volatile qualifier. The armcc User Guide states that the compiler does not optimize away the NOP instructions inserted by the __nop intrinsic.