Есть плата от МТ. Все работает, тикает и мигает.
Помогите разобраться с UART.

Подключаю PLL:

//Документ UM_LPC21XX_LPC22XX_2.pdf, стр.80
//Расчет PLL
//Частота кварца - Fosc = 11,059200 МГц
//Fcclk = 60 МГц
//M = Fcclk / Fosc = 5,42 (=5) В соответствии с табл. в рег-р записываем - 4
//Fcclk = 11,059200 * 5 = 55,296 МГц
//Fcco выбираем из интервала: 156МГц - 320МГц
//Fcco = 156 МГц
//P = 156 / (2*55,296)=1,41 (=2) В соответствии с табл. врег-р записываем 1.
//Fcco = 2*2*55.96=223.84МГц

PLLCFG_bit.MSEL=4;
PLLCFG_bit.PSEL=1;
feed();
PLLCON_bit.PLLE=1; // Enable the PLL
feed();
while(!(PLLSTAT & PLOCK)); // Wait for PLL to lock

//Init MAM & Flash memory fetch
MAMCR_bit.MODECTRL=2;
MAMTIM_bit.CYCLES=4;
VPBDIV_bit.VPBDIV=1;

Затем инициализирую UART:
unsigned int divisor = getperipheralClockFreq() / (16 * baud);
U0LCR_bit.DLAB=1; //Enable DLAB
U0LCR_bit.WLS=3; //8 bits
U0LCR_bit.SBS=1; //1 stop bit
U0DLL = (divisor&0xFF);//LSB(divisor);
U0DLM = ((divisor>>8)&0xFF);//MSB(divisor);
U0LCR_bit.DLAB=0; //Disable DLAB
PINSEL0 = PINSEL0 & ~0xF | 0x5;

Проблема в том, что когда работа без PLL - все работает, на компе с UART данные снимаю правильно. Как только пробую работать с PLL - UART выдает ошибки, вернее какую-то лобуду. Понимаю, что где-то в этих настройках (PLL или UART) я баг прописал. Но где не найду. Смотрел примеры и в даташите - так вроде все правильно. Да, то что регистры прописаны, как структуры - взял пример от IAR, там файл макросов есть - iolpc2129.h

А это не слишком ли большое округление ?
0.42 от 5.42 составит ~ 7.75 %.

Вот здесь очень внятно и понятно изложенно все про максимально допустимые ошибки при подсчете baud rate, это кусочек AVR datasheet, но именно это место общее для всех UART

Честно говоря, я не знаю точно, к каким именно последствиям приведет
указанное округление для ARM. Но для вообше UART-a
расчет выглядит так:

1. Очевидно, что если тактовая частота UART-a отличается
от стандартной, скорость UART-а будет отличаться от стандартной.
Как оценить допустимые пределы частоты ?
Очевидно, сначала нужно определиться с форматом передачи.
Допустим весьма распространенный случай: 8N2.
1 старт, 8 бит данных, 1 стоп = всего 10 бит.

2. если ошибка выбора в частоте составляет N процентов,
то ошибка в длительности во время пиема M бита составит: M*N.
Значит - 1% в частоте при приеме 10 бита составит 10% по длительности.

3. Существует еще постоянная, не накапливающаяся ошибка, вызванная
самим цифровым методом приема. Поскольку частота заполнения
бита выбирается обычно в 16 раз выше скорости - это значит
в худшем случае появится методическая погрешность 1/16 скорости.
Т.е. ~6%.

4. А какие наши резервы ?
Очевидно, чтобы правильно принять 10 бит, нельзя ошибиться >50%.
Поскольку биты принимаются "по серединкам".

5. Как будем делить эти 50 % ?
Во первых сразу:
50% - 6% = 44%.
Но эти 44 надо делить пополам.
Раз мы для себя делаем допуск, то очевидно и абонент
подключенный к нашему устройству имеет те же права.
44/2 = 22%. Это теоретически предельная ошибка в длительности
для правильного приема 10 бита.
Вот теперь и поделим на 10, чтобы узнать предельное отклонения
в частоте.
22/10 = 2.2 %.
Казалось бы, по даташиту еще более жестко.
Но на самом деле придется учитывать искажения драйверов/буферов.
Которые период импульсов конечно не изменят. А вот длительности - запросто.
Относительные длительности 0-й и 1-ц.
А если речь пойдет о гальванической развязке и оптронах, то .....
Так что 1 % - это еще многовато..
К этому 1 %, указанному в даташите, надо подходить творчески.

Как работает ваша функция getperipheralClockFreq() ?
Если не ошибаюсь, она дложна вернуть 55296000.

Да, так и возвращает.

Спасибо всем, кто обратил внимание на эту ветку, так же как и за помощь. Раньше ответить не мог, не было доступа к инету.
С UART, к счастью, разобрался. Шлет, то штонужно и без багов. Осталось поднять АЦП... Буду очень благодарен, если кто поможет рзобраться. В мануале только несколько строк по нему, примеров не нашел, к сожалению. Теперь хоть можно через UART контролировать выполнение процесса.