| |
 Выловить глюк с помощью JTAG ICE MKii, проконсультируйте варианты нахождения глюков в программе |
|
|
2 страниц 
1 2 >
|
 |
Ответов
(1 - 16)
|
|
 Jun 17 2008, 13:52
|
кекс
Группа: Свой
Сообщений: 3 825
Регистрация: 17-12-05
Из: Киев
Пользователь №: 12 326
|
Цитата(mdmitry @ Jun 17 2008, 13:17)  А зачем всегда прерывание по передаче стоит? А зачем его дергать? TXC вызывается только когда символ полностью отправлен и по факту вызова прерывания сбрасывается. Цитата так и сделано что в момент передачи приемник вообще отключается
а в момент приема - передатчик выкл Зачем это сделано? Уберите вкл/откл приемника передатчика, держите их всегда включенными. Пролеты с включением/отключением добавляют повода для глюкавости. Управляйте только направлением драйвера и все должно быть Ок. Цитата насчет конфликта по прерыванию
не исключено... Как уже посоветовали - сделайте обработчики максимально возможно быстрыми. Не анализируйте пакет в обработчике, зерно обработчика UART'a - байты. Rx должен вытянуть байт и куда-то его положить, просигналить что есть новые данные. Больше Rx обработчик ничего делать не должен. Аналогично TXC обработчик должен взять байт и положить его в UART. Сменить направление драйвера на прием если брать больше нечего. (не разрешайте прерываний в обработчиках прерываний).
|
|
|
|
|
|
|
|
Jun 17 2008, 16:05
|
кекс
Группа: Свой
Сообщений: 3 825
Регистрация: 17-12-05
Из: Киев
Пользователь №: 12 326
|
Цитата(Склихасовский @ Jun 17 2008, 18:03) далее присваиваю ему значение скажем $DD сразу после оканчания передачи фрема в сеть.
и стою на бреак поинте... Брекпоинт можно поставить непосредственно в обработчике RX. Цитата после вываливания в тайм аут вижу как был $DD так и остался $dd
регистры UCSRb - без изменений...
ещё раз повторюсь осцилограф стоит на ногах (RX) - (TX) - (bus_rx-tx)... Приемник не выключали? Не пишется ли в регистр управления этого UART'a из другого обработчика? (проверьте не ошиблись ли банально с вектором прерывания, или с именами регистров). Может дело в тайм-ауте - сильно короткий? Проблема постоянная или возникает иногда? Если проблема возникает иногда - попробуйте выделить событие-причину: после какого события это происходит, напр. прием пакета другим каналом, n-й тик таймера, n-й пакет, n-й длины пакет и т.п.
|
|
|
|
|
|
|
|
Jun 18 2008, 07:21
|
Частый гость
Группа: Участник
Сообщений: 77
Регистрация: 29-11-06
Пользователь №: 22 912
|
Цитата(defunct @ Jun 17 2008, 20:05) Брекпоинт можно поставить непосредственно в обработчике RX.
Приемник не выключали?
Не пишется ли в регистр управления этого UART'a из другого обработчика?
(проверьте не ошиблись ли банально с вектором прерывания, или с именами регистров).
Может дело в тайм-ауте - сильно короткий?
Проблема постоянная или возникает иногда?
Если проблема возникает иногда - попробуйте выделить событие-причину:
после какого события это происходит, напр. прием пакета другим каналом, n-й тик таймера, n-й пакет, n-й длины пакет и т.п. Приемник постоянно включен. брекпоинт на обработчик - бессмыслено во первых нарушу динамику процесса, а во вторых постоянно будет вываливаться при "нормальном" приеме фрейма.. проблема постоянная хотя вылезает в достаточно короткое время(2 сек до 2 минут) и всегда!! анализ события пока ни чего не дал.. очень хаотично возникает глюк физика подключения все ок (на случай помехи то се - этого ничего нет) даю картинки сего... на левой показал что на RX идет фрейм без ошибок на правой тайм аут беды ... принято без ошибок более 400 фремов что касается времени самих прерываний... RX int - меньше 60 тактов TX - меньше 51 такта (16 mHz clock) распределение векторов: Код .cseg
; Initialize interrupt vectors
.org 0x00
jmp START
.org OC2addr ;= 0x0012
RJMP timer2_process
.org OC1Aaddr ;= 0x0018; Timer/Counter1 Compare Match A
rjmp Modbus_idle
.org OC0addr ;= 0x001e; Timer/Counter0 Compare Match
rjmp lcd_trans
;---
.org URXC0addr ;= 0x0024; USART0, Rx Complete
rjmp uartrx
.org UDRE0addr ; 0x0026; USART0 Data Register Empty
reti
.org UTXC0addr ;= 0x0028; USART0, Tx Complete
rjmp uarttx
;---
.org URXC1addr ;= 0x003c; USART1, Rx Complete
rjmp RX_MODBUS
.org UDRE1addr ;= 0x004e; USART1, Tx Complete
rjmp TX_MODBUS
.org UTXC1addr ;= 0x0040; USART1, Tx Complete
rjmp END_FRAME_MODBUS
.org TWIaddr ;= 0x0042; 2-wire Serial Interface
RJMP TWI_COMPLETE да малостьввел в заблуждение.. скорость wake не 19200 а 50000 скорость модбас 19200
Сообщение отредактировал Склихасовский - Jun 18 2008, 07:24
Эскизы прикрепленных изображений
|
|
|
|
|
|
|
|
Jun 18 2008, 10:51
|
Частый гость
Группа: Участник
Сообщений: 77
Регистрация: 29-11-06
Пользователь №: 22 912
|
Цитата(SasaVitebsk @ Jun 18 2008, 14:37) На вид (точно сказать не могу) очень малое время м/у Tx и Rx. Сделайте задержку в датчиках. Может банально не успевает переключаться и режется кусок Rx посылки. Да я согласен на то что пусть даже режеться..... но в момем случае ни одного байта не принимается при этом ни одной ошибки не выскакивает типа FE, DOR, CRCerr - Просто тупо игнорирует весь фрейм... --- но тут есть новости: отключение модуля TWI решает эту проблему... покрайне мере устаешь ждать когда вылезет в таймаут... буду копать пока в этом наравлении.. хотя выбрана невысокая скорость I2C = 47 кгц. требования передавать данные для LCD 20Х4..
Сообщение отредактировал Склихасовский - Jun 18 2008, 10:53
|
|
|
|
|
|
|
|
Jun 19 2008, 19:30
|
Участник
Группа: Участник
Сообщений: 54
Регистрация: 19-07-06
Пользователь №: 18 920
|
Цитата .org UDRE1addr ;= 0x004e; USART1, Tx Complete
rjmp TX_MODBUS
.org UTXC1addr ;= 0x0040; USART1, Tx Complete
rjmp END_FRAME_MODBUS
.org TWIaddr ;= 0x0042; 2-wire Serial Interface
RJMP TWI_COMPLETE Если после .org TWIaddr ;= 0x0042 RJMP TWI_COMPLETE идет код программы - то он затрет .org UDRE1addr ;= 0x004e rjmp TX_MODBUS
|
|
|
|
|
|
|
|
Jun 20 2008, 06:44
|
Частый гость
Группа: Участник
Сообщений: 77
Регистрация: 29-11-06
Пользователь №: 22 912
|
да не вектора правильно расположены.. это просто в коментарии опечатка... Цитата(SasaVitebsk @ Jun 19 2008, 22:45) Боже а TWI здесь каким боком?  Если по прерыванию обрабатываете, то внимательно просмотрите. Ребят, я отказываюсь понимать почему но глюк был из за некоректной команды STOP в TWI.. я сам незнаю почему... на некоторый момент линия SDA была после посылки в 0 единственая мысль это сверх частая генерация прерывания по TWI: было Код ldi temp,(1<<TWINT)|(0<<TWEN)|(1<<TWSTO); transmit stop
STS TWCR,temp
flag_lcdDATA_off ; все данные перекачены - сброс флага стало: Код stsi TWCR,(1<<TWINT)|(1<<TWEN)|(1<<TWSTO)
flag_lcdDATA_off ; все данные перекачены - сброс флага
rjmp exit_TWI После чего проблему не наблюдаю уже 2й день... Как это повлияло - загадка...
Сообщение отредактировал Склихасовский - Jun 20 2008, 06:46
|
|
|
|
|
|
|
|
Jun 20 2008, 09:35
|
Гуру
Группа: Свой
Сообщений: 2 712
Регистрация: 28-11-05
Из: Беларусь, Витебск, Строителей 18-4-220
Пользователь №: 11 521
|
Цитата(Склихасовский @ Jun 20 2008, 09:44) Ребят, я отказываюсь понимать почему
но глюк был из за некоректной команды STOP в TWI..
я сам незнаю почему... А.... Ну тогда я понимаю. Здесь это уже обсуждалось на форуме. Вроде бы при неправильной обработке TWI - наблюдаются зависалово. Сам я с таким не сталкивался. Поищи по форуму насчёт TWI.
|
|
|
|
|
|
1 чел. читают эту тему (гостей: 1, скрытых пользователей: 0)
Пользователей: 0
|
|
|
