Start up code for lpc2378

I am using keil uvision3. But the simulator shows the value of U0FCR after stepping through this line as 0XC1 instead of 0x07.

And are you sure that's not exactly what you should get from reading that register? Did you check back with the data sheet?

I am using keil uvision3. But the simulator shows the value of U0FCR after stepping through this line as 0XC1 instead of 0x07.

And are you sure that's not exactly what you should get from reading that register? Did you check back with the data sheet?

It is not uncommon that the bits returned when reading a register are different from the bits affected by writing that register.

It is also not uncommon that writing a certain bit may affect the values read-back from other bits.

The only way to know, as previously mentioned, is by careful study of the datasheet...

I checked the datasheet , when I was not able to get anything I posted it here.
I actually read the user manual lpc23xx_um. where the bits 0,1,2 U0FCR are FIFO enable,RX and TX FIFO RESET respectively. I have to do this in UARTInit() ie during UART initialization. so I am writing 0x07 to U0FCR. But instead value coming on U0FCR is 0xC1. But I am not able to figure out the reason.

These informations are available on usermanual pages 411 and 412.
Thank You for the response.

I also had same problem when i use USB Examples in LPC2378. I use UART and Terminal to trace USB operation. when i send char, terminal show uncorrect character.

My solution is use startup code of Blinky example. However, i think some other problems will invoke which i can predict. At moment, i don't get any error in my firmware.

so I am writing 0x07 to U0FCR. But instead value coming on U0FCR is 0xC1.

We understood that the first 4 times you wrote it...

But I am not able to figure out the reason.

So you're telling us you haven't found anything in the data sheet about what the read value of bits 1 and 2 is supposed to be? Please note these are not just ordinary memory cells. Just because you wrote something into them doesn't mean you're entitled to reading the same thing back.

I have this doubt ie if I am writing a value to a register ( I am debugging in simulator mode ) , in the watch window won't the register show the value that I have written to it , because I have not worked with ARM based microcontrollers much but I have worked with PIC but in there if I write something to a register atleast it will show on the watch window( the value that is written).

It's quite reasonable that the two reset bits clears themselves. After all, the datasheet says that the bits are self-clearing, so you do not need to write a second time to this register, to clear the bits.

It's a bit interesting that it switches from 1-ch rx FIFO to 14-ch FIFO.

On the other hand, the datasheet does say
"Table 344. UARTn FIFO Control Register (U0FCR - address 0xE000 C008,
U2FCR - 0xE007 8008, U3FCR - 0xE007 C008, Write Only) bit description"

Since it is a write-only register, the datasheet doesn't really tell what the Keil debugger should return if you read from this address - any read results should after all be seen as undefinied.

What do you expect Keil to do?
- always return zero, even if it isn't documented that the real processor does that?
- return the current state of the UART, even if it isn't documented that the real processor does that?
- generate an exception of you read from the byte, even if the real processor doesn't do that?
- reverse-engineer the behaviour of a real chip, and try to duplicate it, even if a different stepping of the processor may do something else?
- something else?

I am really sorry with this foolish doubt. I will be more careful from now on and will post my doubt only after reading the datasheet/usermanual 5 times atleast. Any way thank you for pointing me in the right direction.

I have one more foolish doubt. U0DLL and U0RBR shares the same memory location with U0THR. The other two are R/W and RO. So will I be able to read the value written to U0THR from these other two registers.