Bubble в UART LPC2148 Опции

[3m-soft]

Работаю с LPC2148, но никак не могу решить проблему с UART. Осциллятор у меня на 12Мгц из-за USB модуля, второй осциллятор часовой. Понятное дело что битрейт на UART с нулевой ошибкой выставить невозможно. На UART0 реализован обычный текстовый терминал. На UART1 рабочее устройство с которым ведется обмен данными. Так вот в зависимости от степени расхождения в битрейте с устройством на длинных пакетах может произойти какой-то срыв в мозгах у LPC и он начинает "базарить" (bubble) на оба UART как наружу так и вовнутрь, т.е. в течение нескольких секунд я наблюдаю на экране терминала как быстро быстро прет всякая х...ня, тоже самое происходит и вовнутрь, т.е. в течение этого же времени оба модуля активно принимают "левые" данные в основном просто нули. Подчеркиваю, что базарит он на оба модуля одновременно, и так посрет посрет данными и успокаивается и продолжает работать. Раньше bubble вызывал вообще зависание, да такое что внешний ресет не помогал, а помогало только выключение питание или сторожевой таймер, но я поиграл с таймингами MAM и теперь он не всегда зависает. Плюс к этому я выяснил что если во время работы с PLL, устройство что-нибудь ответит в UART, то это bubble с последующим гарантированным зависанием. Раньше эта прога работала на LPC2194 с осциллятором 11059200 и таких проблем не было. Кстати терминал параллельно продублирован на логический канал USB и когда UART0 гадит мусором с свою терминальную программу, то в специальной терминальной программе подключенной через USB в это время все в порядке, так что это точно модуль UART0 сам что-то гонит, а не моя прога что-то сдуру посылает.

[3m-soft]

Вероятно порблема в том, что передача или прием данных происходит в момент перенастройки PLL.
По USB изменение частоты (читай искажения сигнала на шине) при перестройке PLL просто отсеется на уровне HOST контроллера аппаратно.
В UART синхронизация идет поБИТно. Именно потому что по старт БИТу определяется начало байта. Именно к этому старт БИТу привязывается защелкивание остальных битов.
И если стоп бит придет не вовремя, то и будет описанная ситуация.
Особенно сказывается при ошибке в скорости и именно таким образом.
Проверяйте в UART биты ошибок приема. И при изменениях PLL вообще отключайте UART.

Я конечно понимаю, что рассказываю фантастические вещи, но во время перенастройки PLL (а это не часто бывает) я конечно отключаю UART вплоть до того, что питание от UART отрубаю, но когда включаю потом обратно то и возникает зависание вот в этом куске кода:

__irq void uart1_irq(void)
{
......
// Узнать статус
unsigned char status=U1LSR;
while ((status & (1<<0))!=0) // Есть входные данные
{
// Получить байт и узнать статус
unsigned char ch=U1RBR; status=U1LSR;
....
}
.....
}

Вы скажете что этого не может быть, я тоже так думаю, но это так и из этого кстати выручает сторожевой таймер.

Хотя меня больше волнует проблема того что он двунаправленно спамит по двум модулям UART одновременно.

P.S. Кстати почему никто не думает что это может быть проблема компилятора или компиляции.