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]

За счет Fractional baud rate у меня ошибка 0,0006%, так что большая ошибка не у меня, а у устройства, а оно куплено, а директор мне я..ца оторвет если деньги уплачены зря. Мне надо как-то подогнаться к нему по битрейту чтобы работать, я пробовал уже ставить битрейт который примерно у него, тем самым сократив ошибку между нами, но все равно косяки те же. Не пойму откуда появляются лишние байты, ведь в работе с ПК их нет. Приходит ровно 19 байт, а в LPC либо появляются лишние байты, либо bubble. И повторяю что с другими устройствами на LPC лишних байт нет, лишь совсем изредка bubble бывает.

[_basile]

За счет Fractional baud rate у меня ошибка 0,0006%, так что большая ошибка не у меня, а у устройства, а оно куплено, а директор мне я..ца оторвет если деньги уплачены зря. Мне надо как-то подогнаться к нему по битрейту чтобы работать, я пробовал уже ставить битрейт который примерно у него, тем самым сократив ошибку между нами, но все равно косяки те же. Не пойму откуда появляются лишние байты, ведь в работе с ПК их нет. Приходит ровно 19 байт, а в LPC либо появляются лишние байты, либо bubble. И повторяю что с другими устройствами на LPC лишних байт нет, лишь совсем изредка bubble бывает.

А значение 19-ти байт, которые приходят в LPC те же, что и отправленные "устройством" и принятые РС, только к ним добавляются лишние байты? Или первые 19 байт тоже не совпадают с отправленными "устройством"?
И еще. Как я понял, информация передается пакетами. Т.е. в пакете должны быть байты, определяющие начало и конец пакета (ну, и контрольная сумма пакета при нормальном протоколе). В таком случае, отделить пакет от мусора - не проблема.

Я конечно понимаю, что рассказываю фантастические вещи, но во время перенастройки 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. Кстати почему никто не думает что это может быть проблема компилятора или компиляции.

Посмотрел исходник, и вот чего скажу, хоть сами мы не местные.
Выкинь нафиг FIFO. Ты же разборку пакета все равно где-то в основном цикле программы делаешь,
выковыривая принятые байты через receive0(). Сделай для приема обычный массив со счетчиком принятых байт. А протокол реализуй прямо в обработчике прерывания.
А в основном цикле просто опрашивай состояние (пакет принят/не принят). Если пакет принят - делаешь его разборку, обнуляешь счетчик принятых байт, сбрасываешь статус.