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] - для короткого!!!

[Д_М]

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

[kolobok0]

...действительно ли наслоение одного процесса передачи на другой могло вызвать такой эффект? Если да, то какова его природа?..

если у вас к одному и тому-же ресурсу имеется асинхронный программный доступ из разных потоков - то результатом может быть всё,
что угодно (если нет синхронизации доступа).

можно охранять ресурс объектом синхронизации. можно строить саму логику так, что-бы исключить асинхронность
(например выделение в единственный поток, который и будет обслуживать порт. тут на самом деле есть синхронизация но на уровне уже
потока. который в свою очередь не прерывается пока не закончит логический квант работы).