Start up code for lpc2378

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?

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.