Hello,
We have an application for LPC2368, based on RL-ARM, that run UART communication. This is working very well.
For power consuming reasons, we need to slow the MCU clock down to 4 MHz (based on Internal Osc.). Now, the UART work well up to 57600 baud rate. But in 115200 bps, I cannot receive any data although sending data work well. The debugger isn't even reach the UART IRQ at all.
In the data sheet I found that "Standard baud rates such as 115200 can be achieved with any crystal frequency above 2 MHz."
What can be the problem? Is it possible that there is a conflict between UART and RL-ARM?
Have you verified your baudrate?
That you can send means that your baudrate is correct - or close enough - that the other side can accept the data. But is it close enough that your device will accept data from the other side?
The obvious thing to do is to use a oscilloscope to measure the exact baudrate of outgoing data.
Remember that as you reduce the input clock to the UART baudrate generator, you also get a smaller and smaller divisor. So each value one tick up or one tick down of the divisor results in a larger baudrate error. 4MHz does not result in an even divisor for your 115200 baud. 4000000/115200 is 34,7222. And the UART requires 16x the baudrate frequency so 4000000/16/115200 is 2,17. A divisor of 2 would then have an error of 8,5%.
Have you made use of the fractional baudrate correction?
use a oscilloscope to measure the exact baudrate of outgoing data I tested the signal bit width with oscilloscope and it close to 115200kHz (~8.7us), although the signal had raising and falling time (it isn't fixed square) so I don't know from where to measure.
Yes. According to lpc200.uart.baudrate.calculator.xls from NXP, I should to get relative error of 0.16% (UDL = 2, DivAddVal = 1, MulVal = 12).
"I tested the signal bit width with oscilloscope and it close to 115200kHz (~8.7us), although the signal had raising and falling time (it isn't fixed square) so I don't know from where to measure."
Just measure on the same position on the rising (or falling) flank of different bits. Preferably many bits away in same byte transfer to allow you to reduce the measurement error from how exactly you can place the markers.
The nominal bit length should be 8,68us. With the measurement precision you have given 8,68&8.7 would be an error of about 1% - it would hurt to remeasure over 5 or 8 bits just to get a bit extra precision.
Anyway - unless there is a calculation error somewhere, the use of the fractional compensation should have been enough. Is this the only time you are using the internal RC oscillator? There is a trim register in the chip, and the chip should be factory-trimmed for the 4MHz RC oscillator to be good enough for use with the UART. But it wouldn't hurt to verify how close you really are to a 4MHz oscillator frequency. Some of the LPC23xx batches have had production problems resulting in the internal boot loader failing to correctly autobaud at higher baudrates in which case you could suffer from the same problem.
Besides having a problem with the baudrate, I can't really see why your UART should work as transmitter but be unable to receive, just because you have changed the internal oscillator. Do you use interrupts for both receive and transmit, or just for receiving? Do you use any FIFO?
Alas, NXP have done a bad job of describing the requirements of the peripherial clock divisors for the different submodules. Soch as the requirements for the PCLK_PCB (Pin Control Block) or PCLK_SYSCON (System Control Block). This makes it hard to know if there is a problem with specific clock settings and the interrupt logic.
By the way - do you perform a full reinitialization of the UART when switching to the internal oscillator? Just so no part of the UART happens to get partially stuck because of the clock jitter caused by the switch of oscillator. When switching down to low-power modes (all the way down to sleeping with the 32.768Hz RTC oscillator), I haven't needed any UART to run - it have been enough to just have pin-change interrupts to let the processor know if it needs to jump back into active service again.
1. Some of the LPC23xx batches have had production problems resulting in the internal boot loader failing to correctly autobaud at higher baudrates in which case you could suffer from the same problem. Do you have a source for this issue? We met the problem some times when we access to the internal bootloader from FlashMagic and the only workaround was to program the MCUs in 9600 bps. But I cannot find any reference in Erratasheet.
2. I tested the baudrate issue with 12MHz external oscillator, and the 115200 mode work well, but when I divide the clock to 4MHz, this issue is back again. So, the problem is probably not with Oscillator accuracy.
3. I am using the IRQ for TX and RX. The debugger is stopping in IRQ on TX, but not in RX (Only in 115200). I enabled interrupt for line status change so I excepted to get at least an error but didn't got nothing.
I'll check the FIFO definition if it had to matter.
"But I cannot find any reference in Erratasheet."
I don't think NXP have officially posted any note. Just a "oops, sorry" and "your next batch shouldn't have this problem."
I think you might need to contact NXP - and then keep this thread updated with anything interesting the NXP application engineers might tell you.