[LPC1769] Problem with Code

lpcware · ‎06-15-2016

Content originally posted in LPCWare by nykelaz on Sat May 18 01:36:17 MST 2013
Hi all,

I have some issues with my chip and I hope you can give me some advice.

Basically I have written a simple program using the GPIO interface to light up an LED. The input is a pair of open end wires (active low) and will send a low signal when the wires are in contact to the LPC which will then light up an LED. The program worked fine until yesterday when it suddenly stopped working even when no modification is done to both the hardware or software. The GPIO output from the LPC is giving a constant 0.6-0.8 volts regardless of the input. After researching online, I'm inclined to believe that my chip may have been 'burnt' due to short circuit and would like to test to see if that's true. My questions are as follow:

1) Is the LPC able to accept 5V as input under GPIO interface? I understand the standard is 3.3V but the output from my hardware is 5V. Is there any issue for me to connect the hardware straight to the LPC in that manner?

2) Is there any way we can tell if the chip is 'burnt'? What are the indications if such were to happen? Is there any way we can test it?

Hope you will be able to give me some pointers here. Thank you for your assistance in advance.

P.S. I have attached my codes below for reference.

#include "stdio.h"
#include "lpc17xx_pinsel.h"
#include "lpc17xx_gpio.h"
#include "LPC17xx.h"
#include "lpc17xx_clkpwr.h"

int main (void)
{
uint8_t x=1;
PINSEL_CFG_Type PinCfg;

// Initialize Detector (Input)
PinCfg.Funcnum = 0;
PinCfg.OpenDrain = 0;
PinCfg.Pinmode = 3;
PinCfg.Portnum = 1;
PinCfg.Pinnum = 30;
PINSEL_ConfigPin(&PinCfg);

// Initialize LED (Output)
PinCfg.Funcnum = 0;
PinCfg.OpenDrain = 0;
PinCfg.Pinmode = 3;
PinCfg.Portnum = 1;
PinCfg.Pinnum = 31;
PINSEL_ConfigPin(&PinCfg);

GPIO_SetDir(1, 1<<30, 0); //Set Detector as input
GPIO_SetDir(1, 1<<31, 1); //Set LED as output

GPIO_ClearValue(1, 1<<30); //Clear pins
GPIO_ClearValue(1, 1<<31);

    while (1)
    {
    x=(GPIO_ReadValue(1)>>30) & 0x01;
    if(x==0) GPIO_SetValue(1, 1<<31);
    GPIO_ClearValue(1, 1<<31);
}

}

lpcware · ‎06-15-2016

Content originally posted in LPCWare by nykelaz on Sat May 18 09:10:38 MST 2013

Quote: R2D2
No, you can destroy a single output and the rest of the chip is working quite normal.

I would strongly recommend to spend a few hours with learning how to handle the debugger.

That's a very useful tool. Stepping through your program and using 'Peripherals View' to read and write registers will help you to understand what is happening :)

Cool. That's something new that I've learnt. I've always thought the entire chip will be damaged if one pin is faulty. You've been very helpful. Thanks! :)

lpcware · ‎06-15-2016

Content originally posted in LPCWare by R2D2 on Sat May 18 09:01:04 MST 2013

Quote: nykelaz
Sweet :cool: So other than this, the program seems fine? Will try to run the debugger as advised. Am I right to say the program will not be able to debug if the chip is faulty?

No, you can destroy a single output and the rest of the chip is working quite normal.

I would strongly recommend to spend a few hours with learning how to handle the debugger.

That's a very useful tool. Stepping through your program and using 'Peripherals View' to read and write registers will help you to understand what is happening :)

lpcware · ‎06-15-2016

Content originally posted in LPCWare by nykelaz on Sat May 18 08:52:02 MST 2013

Quote: ToBeFrank
If you look at it on a scope, you should see it when it's "on", it's actually switching on and off very rapidly, with more time spent off than on. I agree with R2D2, your code doesn't look right.

I see. So I guess I'll just remove that statement then :)

lpcware · ‎06-15-2016

Content originally posted in LPCWare by ToBeFrank on Sat May 18 08:46:11 MST 2013
If you look at it on a scope, you should see it when it's "on", it's actually switching on and off very rapidly, with more time spent off than on. I agree with R2D2, your code doesn't look right.

lpcware · ‎06-15-2016

Content originally posted in LPCWare by nykelaz on Sat May 18 08:46:01 MST 2013

Quote: R2D2
Not for me. But probably you are younger and faster and can see this LED being switched on a few cycles.

Anyway, you have a debugger, so use 'Peripherals view'. Check your GPIO settings there and switch on / off this pin there. If that's working, it's not a hardware problem :)

Sweet :cool: So other than this, the program seems fine? Will try to run the debugger as advised. Am I right to say the program will not be able to debug if the chip is faulty?

Sorry if my question sounds amateur. Pretty new to microprocessors :/

lpcware · ‎06-15-2016

Content originally posted in LPCWare by R2D2 on Sat May 18 08:36:09 MST 2013

Quote: nykelaz
Oh, the clear value wasn't intended to be conditional. This way the LED will be switched off if it has been turned on. It will remain off is it is not switched on. Does that make sense? :confused:

Not for me. But probably you are younger and faster and can see this LED being switched on a few cycles.

Anyway, you have a debugger, so use 'Peripherals view'. Check your GPIO settings there and switch on / off this pin there. If that's working, it's not a hardware problem :)

lpcware · ‎06-15-2016

Content originally posted in LPCWare by nykelaz on Sat May 18 08:04:45 MST 2013

Quote: R2D2
Shouldn't there appear an 'else' somewhere?

Oh, the clear value wasn't intended to be conditional. This way the LED will be switched off if it has been turned on. It will remain off is it is not switched on. Does that make sense? :confused:

lpcware · ‎06-15-2016

Content originally posted in LPCWare by R2D2 on Sat May 18 03:18:42 MST 2013

Quote: nykelaz

    while (1)
    {
        x=(GPIO_ReadValue(1)>>30) & 0x01;
        if(x==0) GPIO_SetValue(1, 1<<31);
        [COLOR=Red]??????????[/COLOR] GPIO_ClearValue(1, 1<<31);
    }
}

Shouldn't there appear an 'else' somewhere?