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:-
#define LED2_ON() IO1SET=(1<<17)
#define LED3_ON() IO1SET=(1<<18)
#define LED4_ON() IO1SET=(1<<19)
#define LED2_OFF() IO1CLR=(1<<17)
#define LED3_OFF() IO1CLR=(1<<18)
#define LED4_OFF() IO1CLR=(1<<19)
{
unsigned int i;
for(;j>0;j--)
for(i=0; i<60000; i++);
}
int main(void)
PINSEL1 = 0x00000000;
PINSEL2 = 0x00000000;
LED1_ON();
Delay(25);
LED1_OFF();
LED2_ON();
LED2_OFF();
LED3_ON();
LED3_OFF();
LED4_ON();
LED4_OFF();
return(0);
Hi mayankv2,
It's puzzling when you get 0 V on P1.16 to P1.19, either the drivers are stuck to logic low or the ports cannot be properly configured (we note that they have internal pull-up). Try to verify your measurements first, double check the pin numbers, better yet use a logic probe or an oscilloscope if you have that instrument. If you confirm your previous results, try running your code with:
When trying to restart the LPC2148, press the reset button of your board instead of using a command from the IDE. If there is no change in the behavior of your board, try to disable the line that modifies PINSEL2
to
//PINSEL2 = 0x00000000;
Revisions of the LPC214x User manual have changes relating to PINSEL2 and you may want to avoid writing to the PINSEL2 register if possible.
If you will provide update to your progress, indicate the state of the LEDs in more detail. Do they appear to be all off, on simultaneously, or on simultaneously but faint?
Regards,
Goodwin
Thanks for replying back goodwin.
I double-checked all the connections. I run the above code in Debugging mode in Keil and it's working fine. I also checked in Simulation in Proteus and it shows expected results. Also, I connected 4 LEDs on a separate breadboard and connected them with the pins of the LPC board using jumper wires. They were all off for the whole time. Not a single LED blinked or turned on for a moment. Also, I noted a strange behavior. The pin P1.23 and P1.22 are always high in my board. I wrote a simply code to output LOW on P1.23 and P1.22 but again they gave high voltage. I don't know what is happening here.
Have you tried doing your exercises on PORT0?
In this LED sequencer, you may want to replace IO1SET, IO1CLR, and IO1DIR with IO0SET, IO0CLR, and IO0DIR respectively in your code (save the modification in a different project) and connect the separate LEDs to P0.16, P0.17, P0.18, P0.19. Try if the code will work, this will tell whether the problem is confined only to PORT1 or will also manifest on PORT0.
I suspect your delay loop is getting optimized away, as it doesn't actually do anything functional (from the point of view of a compiler). Try this one:
void Delay(volatile unsigned char j) { volatile unsigned int i; for(; j>0; j--) { for(i=0; i<60000; i++); } }
HTH, Pete
Hi Peter,
I'm glad you're here to help.
Delay is a usual problem in LED blinking program like this. However, I deferred to focus on that since if we analyze the code, regardless of the delay, P1.16 to P1.19 (and, supposedly, the LEDs) are always switched at 25% duty cycle. Here, the delay only affects the frequency of switching. If the delay is too short the LEDs will be sequenced at very high speed. mayankv2 would not notice them blink in succession. Instead, the LEDs will appear to be simultaneously lit albeit faint. Some factors can prevent the LEDs from working that way but at least there will be small voltages measured at P1.16 to P1.19, this was not observed by mayankv2.
I am getting 0 V on the pins(P1.16, P1.17, P1.18, P1.19) to which the LEDs are connected.
That's why I asked that the measurement be verified. Another reason why I deferred to point to delay is that in mayankv2's reply
Also, I noted a strange behavior. The pin P1.23 and P1.22 are always high in my board. I wrote a simply code to output LOW on P1.23 and P1.22 but again they gave high voltage.
If the objective of the code is to output a static low to P1.23 and P1.22, delay is not involved anymore but this problem surfaced.
Nevertheless, your suggested remedy to your suspected cause of the trouble is a brilliant idea and I suggest that mayankv2 should try any of these:
void Delay(unsigned char j) //This Function is used to cause delay between LED ON and OFF events
unsigned int i,k;
k=0;
for(i=0; i<60000; i++)
// Dummy operation(s) here so that the compiler will not optimize the loop as if it does not exist at all
k++;
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
I agree.
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).
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.
hey, I have a fix for you. I was stuck at same place for about a week. its not a problem with delay element or your IC. its about your compiler settings. Steps to fix it: 1: open keil. 2: open flash from top menu. 3: click on configure flash tools. 4: go on to linker. 5: check the first three boxes. Now your code should work just fine. hope this helps!
could you tell me how you solve this problem