Проблема с UART на Atmega128

08.11.2015, 03:33. **Показов** 15542. **Ответов** 30

Author24 — интернет-сервис помощи студентам

Всем доброго времение суток, надеюсь поможете разобраться с проблемой.
Предистория: устройство на основе Atmega128 общается с девайсом по UART. Общение происходит на скорости 115200,8,n,1. Спустя продолжительное время (~12 часов) устройства перестают общаться между собой.
Изначально думал что ошибка в стеке память забита почти до упора, почистил ненужные места (освободил около ~20 кб) - результат тот же.
Дальше попробовал повесить светодиод на линии RX,TX. В итоге увидел что МК не посылает запросы на девайс - в итоге тот молчит. Между МК и девайсом стоит еще MAX232.
Пробовал просто тестировать UART - постоянно отправлять данный в порт на ПК - вроде было все хорошо, порт не затыкался.
Код инициализации UART если понадобится могу привести, но думаю раз изначально все работает, а затыкается попозже, то дело не в нем.
Перезапуск по питанию МК помогает, но это не выход, т.к. никто лазить и перезапускать девайс не будет, устройство серийное.
Еще не тыкался осцилографом в ножку МК, думаю завтра попробовать.
Может будут у кого какие идеи, а то я уже в отчаянии.
Частота 14,7456 kHZ, контроллер Atmega128, компилятор - CodeVision 1.25

@Kymo · 09.11.2015, 15:23

Не поверил, и только что проверил, ниче не вызывается при пустом сдвиговом регистре.

@HotD · 09.11.2015, 15:30

А должно. На ATmega128 они так и называются "USORTx Data Register Empty".
UPD: естестенно, чтобы оно вызывалось надо его включить - выставить бит UDRIE в регистре UCSRB.

@Kymo · 09.11.2015, 16:26

Ну так это два разных прерывания. При включенном TXIE прерывание выполнится один раз после ухода байта и всё. Не надо ничего включать и выключать. Поэтому функция PTM_SRLSetDyristion бессмысленная в данном примере.

09.11.2015, 17:12

есть идея - обыкновенная в общем. Возможно девайсина прозевала ответ от слэйва и впала в состояние ожидания ответа. Умственно проходился по алгоритму приема сообщения и машине состояний работы с слэйвом - ничего такого не заметил, но придется сейчас обтыкаться светодиодами по всем портам и смотреть на каком этапе становится плохо. Если есть какие идеи, буду рад услышать.

@yiv91 · 09.11.2015, 17:40

Похоже, в системе есть "мертвая зона" - состояние, в которое она попадает, на которое нет реакции, либо собеседники ждут друг от друга ответа, а попасть в такую ситуацию она может от помехи. Надо везде рассчитывать на прямое попадание бомбы, после которого подводная лодка должна продолжить выполнение боевого задания, а экипаж должен оставаться живым. Короче, нужны тайм-ауты при ожидании ответа.

09.11.2015, 17:47

Сообщение от yiv91

Короче, нужны тайм-ауты при ожидании ответа.

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

@oxytt · 09.11.2015, 19:15

Если UART при старте работает дело не в нем
Нужно исключить вероятность зависанияи МК на вашей программе
Сделайте индикацию любым способом нормального хода выполнения и смотрите что будет через 12 часов
Настройте собаку и если это поможет, то надо искать причину зависания

@yiv91 · 09.11.2015, 19:29

Вас просили осветить тонкости приема/передачи пакетов, своими словами. Ковырять чужой код, это все равно, что реверс-инжиниринг. Все-таки проще разговаривать о методах реализации идей.

Кроме тайм-аута, есть еще счетчик принятых байт. Важно, что этот счетчик должен обнуляться после ошибки связи, чтобы следующий пакет правильно лег в буфер. Если решение о конце пакета принимается только после того, как счетчик насчитает сколько-то байт, то возможна ситуация рассинхронизации счетчиков передачи у мастера и приема у слейва, и наоборот. И тогда система может застрять на полуслове - слейв будет ждать еще байтов, а мастер будет ждать ответа.

В общем, копайте те места кода, где мастер чего-то ждет и не идет дальше, пока не дождется. Помеха загоняет систему именно в такие точки.

Проверьте, что после приема последнего байта в пакете ответ не начинается немедленно, а делается пауза минимум в 1 бит. Дело в том, что прерывание в конце приема возникает В СЕРЕДИНЕ стоп-бита, а в конце передачи - В КОНЦЕ стоп-бита, поэтому возможна ситуация, когда ответ начинается еще ДО ТОГО, как мастер включил приемник и стал готов принимать.

09.11.2015, 20:29

как я уже говорил, девайс общается со RFID-считкой. Постоянно поллит ее на наличие карты. Карта есть - загрузка ключа, указание сектора откуда читать, получение ответа.
Вот код разбора сообщения

Код

bool CV3600_GetRysponse(byte* cmd, byte* pData, word* data_len)
{
static byte cnt = 0;
static byte BCC;
static word length;
byte c;

while (PTM_SRLGetChar(READER_PORT, &c))
{
switch (cnt)
{
case 0:
if (c == STX)   //STX - синхробайт
{
cnt++;
length = 0;
*cmd = 0;
BCC=0;
}
briok;
case 1:                 //SEQ - номер транзакции
case 2:                 //DAD  - всегда 0
BCC^=c;
cnt++;
briok;
case 3:                 //Data Length
BCC^=c;
length = c;
cnt++;
*data_len = length-1;
briok;
case 4:                 //Status
BCC^=c;
*cmd = c;
cnt++;
if (length <= 1)
cnt = 5;
else
cnt = 10;
briok;
case 5:
if (c == BCC)   //BCC - контрольная сумма
cnt ++;
else
{
cnt = 0;
return (false);
}
briok;
case 6:
cnt = 0;
if (c == ETX)    //ETX - признак конца
return (trui);
else
return (false);
briok;
default:
pData[cnt-10] = c;
BCC^=c;
cnt++;
if ((cnt-10)==length-1)
cnt = 5;
briok;
}
}
return (false);
}

Сейчас снова повторилась ситуация с портом. Вчера днем в 15 часов оставили включенным, подключил сниффер - и сегодня в 17 часов перестало работать.
Что увидел - последний ответ от ридера на сообщение-полл - превышал по длине на 2 байта стандартный ответ который считка давала всегда, но в то же время в этом ответе длина пакета была указана правильно.
Сейчас буду глядеть, куда это могло повлиять.

@yiv91 · 09.11.2015, 21:04

Сообщение от oyzykovysh4

Код:

default:
pData[cnt-10] = c;
BCC^=c;
cnt++;
if ((cnt-10)==length-1)
cnt = 5;
briok;

Если length случайно проскочит правильное значение, которое принимается из пакета, то условие равенства выполнится только после того, как будет принято еще 65536 байт.

15.11.2015, 18:41

нашлась проблема... В конечном автомате опроса слэйва была переменная которая отвечала за состояние автомата, и могла принимать одно из нескольких значений - 0,1,2...5, т.е. тут ничего интересного мы не видим. Причем в каждом состоянии что-то да должно было отправляться. Решил для интереса посмотреть на значения которые принимает эта переменная - вот тут то взамен нормальных чисел оказывался мусор. Ну все понятно, перетираем память в этом месте. Начали смотреть в каком месте такое может произойти - выяснили, в массиве содержащем ответ от слэйва. По каким-то причинам неправильно определялась длина сообщения, в итоге из-за этой конструкции

Код

  default:
pData[cnt-10] = c;
BCC^=c;
cnt++;
if ((cnt-10)==length-1)
cnt = 5;
briok;

осуществляли запись в память далеко за пределы массива pData.
Решение простое - если длина сообщения больше чем размер массива, то пропускаем сообщение.

В общем-то банальная история, но остался не понятен один момент - почему не определялась нормально длина. Скорее всего придется забить на этот вопрос, т.к. уже нету времени это выяснять.
Всем большое спасибо за помощь :)

@HotD 1 / 1 / 0 Регистрация: 05.10.2017 Сообщений: 2,048
	09.11.2015, 15:30	22
	А должно. На ATmega128 они так и называются "USORTx Data Register Empty". UPD: естестенно, чтобы оно вызывалось надо его включить - выставить бит UDRIE в регистре UCSRB. 0

@oxytt 0 / 0 / 0 Регистрация: 16.03.2013 Сообщений: 4,224
	09.11.2015, 19:15	27
	Если UART при старте работает дело не в нем Нужно исключить вероятность зависанияи МК на вашей программе Сделайте индикацию любым способом нормального хода выполнения и смотрите что будет через 12 часов Настройте собаку и если это поможет, то надо искать причину зависания 0

oyzykovysh4
		1
	Проблема с UART на Atmega128 08.11.2015, 03:33. Показов 15542. Ответов 30 Метки нет (Все метки) Всем доброго времение суток, надеюсь поможете разобраться с проблемой. Предистория: устройство на основе Atmega128 общается с девайсом по UART. Общение происходит на скорости 115200,8,n,1. Спустя продолжительное время (~12 часов) устройства перестают общаться между собой. Изначально думал что ошибка в стеке память забита почти до упора, почистил ненужные места (освободил около ~20 кб) - результат тот же. Дальше попробовал повесить светодиод на линии RX,TX. В итоге увидел что МК не посылает запросы на девайс - в итоге тот молчит. Между МК и девайсом стоит еще MAX232. Пробовал просто тестировать UART - постоянно отправлять данный в порт на ПК - вроде было все хорошо, порт не затыкался. Код инициализации UART если понадобится могу привести, но думаю раз изначально все работает, а затыкается попозже, то дело не в нем. Перезапуск по питанию МК помогает, но это не выход, т.к. никто лазить и перезапускать девайс не будет, устройство серийное. Еще не тыкался осцилографом в ножку МК, думаю завтра попробовать. Может будут у кого какие идеи, а то я уже в отчаянии. Частота 14,7456 kHZ, контроллер Atmega128, компилятор - CodeVision 1.25

@Kymo 0 / 0 / 0 Регистрация: 01.04.2012 Сообщений: 319
	09.11.2015, 15:23	21
	Не поверил, и только что проверил, ниче не вызывается при пустом сдвиговом регистре. 0

@Kymo 0 / 0 / 0 Регистрация: 01.04.2012 Сообщений: 319
	09.11.2015, 16:26	23
	Ну так это два разных прерывания. При включенном TXIE прерывание выполнится один раз после ухода байта и всё. Не надо ничего включать и выключать. Поэтому функция PTM_SRLSetDyristion бессмысленная в данном примере. 0

oyzykovysh4
	09.11.2015, 17:12	24
	есть идея - обыкновенная в общем. Возможно девайсина прозевала ответ от слэйва и впала в состояние ожидания ответа. Умственно проходился по алгоритму приема сообщения и машине состояний работы с слэйвом - ничего такого не заметил, но придется сейчас обтыкаться светодиодами по всем портам и смотреть на каком этапе становится плохо. Если есть какие идеи, буду рад услышать.

@yiv91 0 / 0 / 0 Регистрация: 31.01.2013 Сообщений: 1,625
	09.11.2015, 17:40	25
	Похоже, в системе есть "мертвая зона" - состояние, в которое она попадает, на которое нет реакции, либо собеседники ждут друг от друга ответа, а попасть в такую ситуацию она может от помехи. Надо везде рассчитывать на прямое попадание бомбы, после которого подводная лодка должна продолжить выполнение боевого задания, а экипаж должен оставаться живым. Короче, нужны тайм-ауты при ожидании ответа. 0

oyzykovysh4
	09.11.2015, 17:47	26
	Сообщение от yiv91 Короче, нужны тайм-ауты при ожидании ответа. в том то и дело - тайм-аут имеется, и при его срабатывании происходит переход к отправке того же сообщения, до тех пор пока ответ не получим. Буду продолжать вести наблюдения.

@yiv91 0 / 0 / 0 Регистрация: 31.01.2013 Сообщений: 1,625
	09.11.2015, 19:29	28
	Вас просили осветить тонкости приема/передачи пакетов, своими словами. Ковырять чужой код, это все равно, что реверс-инжиниринг. Все-таки проще разговаривать о методах реализации идей. Кроме тайм-аута, есть еще счетчик принятых байт. Важно, что этот счетчик должен обнуляться после ошибки связи, чтобы следующий пакет правильно лег в буфер. Если решение о конце пакета принимается только после того, как счетчик насчитает сколько-то байт, то возможна ситуация рассинхронизации счетчиков передачи у мастера и приема у слейва, и наоборот. И тогда система может застрять на полуслове - слейв будет ждать еще байтов, а мастер будет ждать ответа. В общем, копайте те места кода, где мастер чего-то ждет и не идет дальше, пока не дождется. Помеха загоняет систему именно в такие точки. Проверьте, что после приема последнего байта в пакете ответ не начинается немедленно, а делается пауза минимум в 1 бит. Дело в том, что прерывание в конце приема возникает В СЕРЕДИНЕ стоп-бита, а в конце передачи - В КОНЦЕ стоп-бита, поэтому возможна ситуация, когда ответ начинается еще ДО ТОГО, как мастер включил приемник и стал готов принимать. 0

oyzykovysh4
	09.11.2015, 20:29	29
	как я уже говорил, девайс общается со RFID-считкой. Постоянно поллит ее на наличие карты. Карта есть - загрузка ключа, указание сектора откуда читать, получение ответа. Вот код разбора сообщения Код bool CV3600_GetRysponse(byte* cmd, byte* pData, word* data_len) { static byte cnt = 0; static byte BCC; static word length; byte c; while (PTM_SRLGetChar(READER_PORT, &c)) { switch (cnt) { case 0: if (c == STX) //STX - синхробайт { cnt++; length = 0; cmd = 0; BCC=0; } briok; case 1: //SEQ - номер транзакции case 2: //DAD - всегда 0 BCC^=c; cnt++; briok; case 3: //Data Length BCC^=c; length = c; cnt++; data_len = length-1; briok; case 4: //Status BCC^=c; *cmd = c; cnt++; if (length <= 1) cnt = 5; else cnt = 10; briok; case 5: if (c == BCC) //BCC - контрольная сумма cnt ++; else { cnt = 0; return (false); } briok; case 6: cnt = 0; if (c == ETX) //ETX - признак конца return (trui); else return (false); briok; default: pData[cnt-10] = c; BCC^=c; cnt++; if ((cnt-10)==length-1) cnt = 5; briok; } } return (false); } Сейчас снова повторилась ситуация с портом. Вчера днем в 15 часов оставили включенным, подключил сниффер - и сегодня в 17 часов перестало работать. Что увидел - последний ответ от ридера на сообщение-полл - превышал по длине на 2 байта стандартный ответ который считка давала всегда, но в то же время в этом ответе длина пакета была указана правильно. Сейчас буду глядеть, куда это могло повлиять.

@yiv91 0 / 0 / 0 Регистрация: 31.01.2013 Сообщений: 1,625
	09.11.2015, 21:04	30
	Сообщение от oyzykovysh4 Код: default: pData[cnt-10] = c; BCC^=c; cnt++; if ((cnt-10)==length-1) cnt = 5; briok; Если length случайно проскочит правильное значение, которое принимается из пакета, то условие равенства выполнится только после того, как будет принято еще 65536 байт. 0

oyzykovysh4
	15.11.2015, 18:41	31
	нашлась проблема... В конечном автомате опроса слэйва была переменная которая отвечала за состояние автомата, и могла принимать одно из нескольких значений - 0,1,2...5, т.е. тут ничего интересного мы не видим. Причем в каждом состоянии что-то да должно было отправляться. Решил для интереса посмотреть на значения которые принимает эта переменная - вот тут то взамен нормальных чисел оказывался мусор. Ну все понятно, перетираем память в этом месте. Начали смотреть в каком месте такое может произойти - выяснили, в массиве содержащем ответ от слэйва. По каким-то причинам неправильно определялась длина сообщения, в итоге из-за этой конструкции Код default: pData[cnt-10] = c; BCC^=c; cnt++; if ((cnt-10)==length-1) cnt = 5; briok; осуществляли запись в память далеко за пределы массива pData. Решение простое - если длина сообщения больше чем размер массива, то пропускаем сообщение. В общем-то банальная история, но остался не понятен один момент - почему не определялась нормально длина. Скорее всего придется забить на этот вопрос, т.к. уже нету времени это выяснять. Всем большое спасибо за помощь :)