I want to interface MCB2140 with a pressure sensor which will give input for every 1 second.. I connected UART0 to pressure sensor output, UART1 to serial port of PC. The pressure sensor gives the integer value as output.The UART0 will receive data from sensor and should display in hyper terminal for every 1 minute..I wrote the following code..The code gets hanged in startup file at BX R0...Please let me know any other changes required #include <LPC21xx.H> void init_serial (void); int main(void) { init_serial();
while(1) { int getc_serial0; int putc_serial1; } } void init_serial (void) {
PINSEL0 = 0x00050005;
U0LCR = 0x00000083;
U0DLL = 98;
U0LCR = 0x00000003;
U1LCR = 0x00000083;
U1DLL = 98;
U1LCR = 0x00000003;
}
int getc_serial0(void)
{
while (!(U0LSR & 0x01));
return U0RBR;
} int putc_serial1(void)
while (!(U1LSR & 0x20));
U1THR=U0RBR;
return (U1THR);
I did not called receive() in main loop
No, but you seem to have switched to a completely different strange idea about how to read/write:
void transmit() { if(!(U1LSR & 0x20) && U1THR != '#' ) /* Checking whether U1LSR 5th bit contains valid data and data is between 0 to 9*/ U1THR=receive(); /* copying the receive() to U1THR*/ printf("%d",U1THR); /*print U1THR */ }
What is that first read of U1THR? That is not a correct replacement for the previous receive().
What a mess. You are experiencing program failure - probably not related to your inability to use a UART correctly. Solve the crash first!
"Solve the crash first!"
Yes. First off it's important to figure out if it's a problem with the source code or with the project settings or with the selected startup file.
A good way to do that is to have main() only enter an infinite loop, while toggling a processor pin. That should make sure that main() doesn't contain any invalid code that generates an exception.
The startup code must match the used processor, and the project dialog boxes specifying start address and size of each memory region, so that the startup code doesn't try to initialize memory that doesn't exist or try to use non-existant memory as stack space.
Given the huge problems of just understanding the difference between read-only and write-only SFR and the failure of trying to read out the same character multiple times from the UART, I would recommend starting with one of the sample programs.
First try to download an existing sample and check that it runs as expected.
Then rebuild and download and check that it still runs as expected.
Then add own code, rebuild, download and test.
But it really helps to learn how to use the debugger and the simulator. Just with the note that the simulator will mainly be useful for finding algorithmic errors while only the real hardware can be used to verify that the project really is correctly configured for the used hardware.
It's important to notice that the debugger is way more than just a way to single-step through code. All debugger commands are there for a reason, and all commands should be learned. How they are used, and why they are there i.e. what they are good for. Single-stepping a large program that doesn't fail for the first 10 minutes would be very, very boring since the processor runs so much faster than what single-stepping does.
One thing that is good to learn is how to have breakpoints in exception handlers and understand where the processor came from when it decided to enter the exception handler. An alternative is to learn how to modify code to bracket code regions and figure out which code stretch the execution had to have been in when it jumped to an exception handler. This may be done by having the main loop update a global variable between each call it does - that global variable would then tell which function call that failed, and the user may then drill down that call chain and perform further subdivision of the problem. A problem is of course that the line that results in an exception need not be the broken source line - it may just suffer from an earlier error but would at least indicate what pointers/indices/... that may have been corrupted.