So, I bought an lpc2148 header board from SFE, as well as a UART-USB breakout board. I can load hex files just fine using lpc21isp, so I modified a simple LED blinker program to make it blink the green LED on p1.24, and instead of getting 3.3v pulses, I’m getting pulses of somewhere around 200mv every second. While this makes me happy, I -would- like to see the LED actually lighting. Does this mean I blew my GPIO pin somehow? I assume the program works fine, because I do get pulses across p1.24.
So my question is this: Did I screw up somehow and blow something? I ordered a new board just to be safe, but it would be cool if I’m just missing something.
Make sure you have the jumper across the L_E pins to enable the LED.
Make sure that you are keeping the state of the pin high and low for the same amount of time. If you’re just seeing it at one voltage level for almost all of the time, you may have a way off-kilter duty cycle. If you’re modifying Jim Lynch’s code, you should only have to change a bit mask to make the program work properly.
Also remember that the LED is active low. In other words P1.24 must be an output and then have a value of 0 for the LED to be on. With that said, if you’re having problems take out the blink code and just clear the P1.24 bit after you’ve set it to an output, the go into a perpetual while loop (i.e., while(1);).
int main (void) {
long j;
Initialize();
SCS = 0x2;
IO1DIR |= 0x01000000; // p1.24
IO1SET = 0x01000000;
while (1) {
for (j = 0; j < 5000000; j++ );
IO1SET = 0x10000000;
for (j = 0; j < 5000000; j++ );
IO1CLR = 0x10000000;
}
}
I’m using a couple custom macros to make it a little easier for me to read:
#define IO1DIR (*((volatile unsigned long *) 0xE0028018))
#define IO1SET (*((volatile unsigned long *) 0xE0028014))
#define IO1CLR (*((volatile unsigned long *) 0xE002801C))
Changed the code from FIO to GPIO, and I’m -pretty- sure that setting SCS to 0x2 puts the pin in the right mode… Not really positive though. Any suggestions?
Your life would probably be a lot easier if you got the code for Jim Lynch’s tutorials. It has a makefile, linker script, a header file, and a blink program for the LPC2148 prototyping board. All you’d need to do is change the bitmasks in this file and it would work just fine for you. You can download it here - http://www.olimex.com/dev/soft/arm/LPC/sourcecode.zip.
In the file demo2148_blink_flash/main.c, you would just need to change every reference of “FIO0” to “FIO1” and change every reference to “0x00000400” to “0x01000000”. I think that should be enough for you to get it going. I actually did this exact same thing when I got my first LPC2148 header board a long time ago.
I tried that just now, and that’s the same source I’m basing mine off of. I did exactly like you said though, loaded up the hex, unjumped BSL and I get no lights and just pulsating “LOW V” from my multimeter… I have a feeling something must be wrong…
If you re-flashed the chip with a hex file, you overwrote the original firmware that would make those lights show. Perhaps the code you’re running is just not working correctly?
imphasing:
If you re-flashed the chip with a hex file, you overwrote the original firmware that would make those lights show. Perhaps the code you’re running is just not working correctly?
I think it's more than that. I can not seem to flash the board anymore. I've tried though JTAG, without success. I don't have a serial port setup for the header board, so I can't try the LPC2000 flash utility.
Pick up an FT232R breakout from sparkfun, and just use your USB port on your computer. Jumper p0.14 to get into ISP, then use either the philips flash utility, or lpc21isp to flash it. Works great for me, except I can’t get anything to happen with my IO pins.
What should I do after it’s done flashing? Just disconnect everything and reset?
Here’s my suggestion - take out all of the blink code and just do the while loop like I was saying. If you don’t at least get a solid voltage on the pin, then you are having some sort of programming issue is my guess. Are you getting any programming errors or warnings? Are you loading the hex files successfully with no errors (and if so, how are you doing it and with what program)?
linuxguy-
In the other post you said you were using OpenOCD. Nothing against the program, but I had a lot of issues with it when I was first starting to use the LPC2148 header board. Therefore, I just got a perfboard from RadioShack and built my own peripherals on it, including a serial port translator (MAX3232 circuit). In the long run, you’re better of time-wise by getting the prototyping board. However, I learned a lot more about the circuits building them myself, and I’m glad that I did it that way. In the end, the header board is intended for this purpose anyway - to plug it into another board (that you make) and run that way.
Oddly enough, I’m getting 2.1v when I meter p1.24 and gnd, yet no LED turns on. I have the jumper on, so unless I don’t have the right pin set for that LED or it somehow got blown out, I should be seeing -something-…
Also,
while (1) {
FIO1SET = 0x01000000;
}
and,
while (1) {
FIO1CLR = 0x01000000;
}
show the same voltages when I meter them… I would think with FIO1SET I wouldn’t show a voltage?
I’m thoroughly confused now… this seems simple enough in theory, but putting it in practice is killing my brain off
void main(void)
{
...
Initialize();
// set io pins for led P0.10
SCS = 0x03; // select the "fast" version of the I/O ports
FIO1DIR |= 0x01000000; // pin P0.10 is an output, everything else is input after reset
FIO1CLR = 0x01000000; // led on
while(1);
}
Compile and load that code. If the LED doesn’t come on, measure P1.24’s continuity to ground with your multimeter. If it’s more than a few ohms, you’re high impedance on the pin (in other words, it’s still set as an input or else the processor is not powering up properly).
If you really want to go crazy, set the entire port to outputs and set or clear all of the pin bits in that register (i.e., FIO1DIR = 0xFFFFFFFF; FIO1SET = 0xFFFFFFFF; in order to set all of the pins on FIO1). If you can’t find any pins that have the right voltage level, then something’s getting messed up somewhere.[/code]
Setting the entire row to output gives me around 2.1v on all the pins, yet the LED still doesn’t light up. I have a feeling something is wrong with my board. I guess we’ll find out in a couple days when I get my new board.
I also ran that sample code you gave me, with the same results. 2.1v across p1.24, yet no lighting LED. How very confusing…
Also, I’m not even registering an ohm amount on my meter when I meter p1.24 and ground.
If you’re using the LPC2000 Flash Utility, are you having any problems flashing the hex file? Also, are you sure that you have the correct file selected to flash to the device?
I’m using lpc21usb through OS X, and everything seems to be working fine. It syncs and transfers over, then drops me into a shell. I hit escape, it takes me out of the shell. I then unplug everything, takes the UART pins out, then turn the chip back on. Everything seems to be good, but I do get a warning that the hex file isn’t 32 bit aligned. Shouldn’t make much difference, however… Anyone got a text hex file I can use? Maybe my compiler is acting up… (arm-elf-gcc)
I can’t find anything on the internet about lpc21usb (a google search returns 0 results), so I can’t help you at all with that cuz I don’t know what it is. If you have access to a Windows box, you could try to program that hex file through the LPC2000 Flash Utility and see if that works. Otherwise, I can’t really offer much help for a Mac.
One thing to keep in mind is that you have to do some sort of checksum value in your hex file (I don’t remember exactly what it is). Jim Lynch describes it in his tutorial. The LPC2000 Flash Utility does this for you before you flash the chip. If whatever program you’re using to burn the chip doesn’t do this, then the LPC2148 may be locking up due to a bad checksum. Just an idea.
I tried the same hex file with a brand new board, and it did the same thing. Not sure what the problem could be.
EDIT: It lives! After hours of debugging and hacking away, I finally got it to work just fine. the culprit? One single typo in the crt.S file. Not sure why it compiled before, but it now works and I have one of the most beautiful sights in the world before me: A blinking, green LED. Thanks for all the help, guys.
Actually, I was using all his source code. I think he wrote that all on a windows machine, so my *nix system was having issues. If you run a *nix type machine, make sure to look over the source for things a case sensitive machine might choke on. In my case, it was the difference between 0X00000004 and 0x00000004. Also, you need to change the #include line to point to the right file. LPC and lpc aren’t the same fo *nix systems.
