UART ATmega128 портится последний байт посылки, всегда (0xFF) Опции

[Д_М]

Здравствуйте!
При использовании хорошо отлаженного кода MODBUS, но несколько адаптированного для особых условий, контроллер входит в устойчивое состояние, кода на любой запрос он даёт вменяемый ответ, но последний байт всегда 0xFF. В моём случае с MODBUS - это CRC. Предпоследний байт соответствует правильному CRC. Не зависит от длины ответа - хоть длинный, хоть короткий. Проблема залечивается путём передёргивания питания. Передача производится массивом. Каждый новый байт передаётся из обработчика прерывания. После отправки последнего байта запрещается прерывание UDRIE и разрешается прерывание TXCIE.

CODE

#pragma vector=USART1_UDRE_vect
__interrupt void UDRE1_handler (void)
{
char data;

if (size_SIO1)// not complete
{
size_SIO1--;
data = *ptr_SIO1++;
UDR1 = data;
#ifdef SIO1_poly
UDRIE_1 = 0;
GI_enable
CRC(data, &CRC1, SIO1_poly);
UDRIE_1 = 1;
#endif
}
else /* Array sent */
{
#ifdef SIO1_poly
if (!CRC1Lo_sent)
{
UDR1 = (char)(CRC1);
CRC1Lo_sent = 1;
return;
}

if (!CRC1Hi_sent)
{
UDR1 = (char)(CRC1>>8);
CRC1Hi_sent = 1;
LED = 0;
return;
}
#endif
UDRIE_1 = 0;
TXCIE_1 = 1;
}
}

#pragma vector=USART1_TXC_vect
__interrupt void TXC1_handler (void)
{
TXCIE_1 = 0;
if (handler_SIO1)
{
GI_enable
(*handler_SIO1)(); // Activate handler execution
}
}

Одно важнейшее отличие от такого же кода, который никогда не выдавал таких проблем - добавлена функция широковещания. То есть слэйв выступает мастером, когда есть на то условия. Дважды передаёт одну и ту же посылку. При этом, приём у него отключен. Не выявил закономерностей, которые приводят контроллер в такое устойчивое состояние. Даже не занаю за что зацепиться. Как мне кажется. Что-то меняется в формате передачи данных. То есть не было передачи 0xFF, а был только один старт бит и всё, далее пассивная линия, которая и воспринемается приёмником, как 0xFF и стоп-бит. Но что могло бы привести к этому - даже нет зацепок. Благодарен за любые мысли, даже самые невероятные.
Спасибо!

Сообщение отредактировал IgorKossak - Nov 5 2014, 09:23

Причина редактирования: [codebox] для длинного кода, [code] - для короткого!!!

[kovigor]

То есть не было передачи 0xFF, а был только один старт бит и всё, далее пассивная линия, которая и воспринемается приёмником, как 0xFF и стоп-бит. Но что могло бы привести к этому - даже нет зацепок.Спасибо!

1. А почему вы решили, что передачи 0xFF не было ? На экране осциллографа этого не увидишь. Был старт-бит ? Был. А потом надолго - лог.1. Это может быть как 0xFF, так и банальное зависание или перезагрузка (сброс) МК.
2. Кстати, о зависаниях и перезагрузках. Вы уверены, что у вас, например, ничего не зависает, стек не переполняется, одни данные не наезжают на другие, и проч. Я - не уверен. Возможно, дело вообще не в UART. Попробуйте "отрезать" от вашего кода все второстепенное, оставить только необходимую, тестовую часть и проверить, что будет.

[Д_М]

1. А почему вы решили, что передачи 0xFF не было ? На экране осциллографа этого не увидишь. Был старт-бит ? Был. А потом надолго - лог.1. Это может быть как 0xFF, так и банальное зависание или перезагрузка (сброс) МК.
2. Кстати, о зависаниях и перезагрузках. Вы уверены, что у вас, например, ничего не зависает, стек не переполняется, одни данные не наезжают на другие, и проч. Я - не уверен. Возможно, дело вообще не в UART. Попробуйте "отрезать" от вашего кода все второстепенное, оставить только необходимую, тестовую часть и проверить, что будет.

Спасибо большое за отклик! Передачи 0xFF не было точно. Этот глюк выявляется тогда, когда на ведущем устройстве не обновляется информация от ведомых. Ведущее устройтво отбраковывает ответы с некорректным CRC. Специально проверил CRC. Действительно не 0xFF. Скорее всего, имеет место наезжание данных. Но ума не могу предположить - что можно такое затереть, чтобы портился именно последний байт. Это происходит очень редко. Прибор работает в составе очень хитро мудрой системы. Затыки происходят тогда, когда происходят технологические события. Что-то выкинуть не представляется возможным, так как тогда не будет работать, и как следствие, затыкаться. Передёргивание питания восстанавливает функциональность. Один плюс - дурное состояние устойчивое, значит нет частого перезагруза контроллера, что ещё хуже.

[kovigor]

Затыки происходят тогда, когда происходят технологические события.

Технологическое событие -> Прерывание -> Вызов обработчика прерывания -> Разрушение стека или "наезд" стека на данные (при вызове обработчика как минимум контекст помещается в стек). Попробуйте увеличить размер стека.
И еще - проверьте программу на наличие таких классических ошибок, как не соответствующие требованиям задачи типы данных (например, ы с помощью указателей пытаетесь записать 16-разрядную переменную в ячейку, выделенную для 8-разрядной). И на ошибки при работе с памятью проверьте. Например, вы выделили память, а потом освободили ее, затем забыли об этом и снова пишете что-то по тому же адресу, а там уже не ваши данные, а что-то другое ...