1882ВЕ53У

[paskal]

Вот, например, в МК 1530, 1532 и 1548 столкнулись с проблемой случайного пропуска прерываний от UART на приём,

Это вы оптимист. Обнаружено что не только прием, а любое прерывание может потеряться.

[Sanek]

Это вы оптимист. Обнаружено что не только прием, а любое прерывание может потеряться.

Пришлите пример программы с пропуском прерывания для контроллеров партии 1548 или более поздней партии на avas@niiet.ru

[Dreamer]

Вот, например, в МК 1530, 1532 и 1548 столкнулись с проблемой случайного пропуска прерываний от UART на приём,

Это вы оптимист. Обнаружено что не только прием, а любое прерывание может потеряться.

Если есть, какая-нибудь небольшая тестовая прога, на которой явно видна проблема с прерываниями, поделитесь с НИИЭТовцами и общественностью. Мы пока отлавливаем только пропуски прерываний на приём по UART, но т.к. они возникают бывает что и один-два раза за 15-20 мин, то пока не совсем понятно где подкрутить, чтобы получить больше пропусков и желательно на короткой программе. Если в процессе поиска выяснится, что действительно любое прерывание может случайно потеряться, то это опять будет дикий скандал с военной приёмкой и возврат нескольких сотен микроконтроллеров производителю.

[paskal]

Если есть, какая-нибудь небольшая тестовая прога, на которой явно видна проблема с прерываниями, поделитесь с НИИЭТовцами и общественностью.

Хорошо, завтра попробую что то восстановить.

[_sva_]

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

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

[paskal]

Dreamer, привожу код.

Код: Выделить всё

                cseg    at      0

                jmp             start

                org             0Bh
                mov             tl0,#low(-1000)
                mov             th0,#high(-1000)
                dec             r7
                reti


start:
                mov             tmod,#21h
                mov             tl0,#low(-1000)
                mov             th0,#high(-1000)
                setb    tr0
                setb    et0
                setb    ea
                clr             p1.0
                mov             r7,#100
loop:
                setb    c
                mov             tr0,c
                cjne    r7,#0,loop
                setb    p1.0
                jmp             $
                end

Проверялся на кварце 7.37 МГц. Таймер работает с частотой 7370000/12/1000=614 Гц. При 100 тиках таймера на p1.0 получается отрицательный импульс 163 миллисекунды. На импортных, и в симуляторе так и происходит. На кристалле 14 года тоже. А вот с 15 года происходит как будто пропуски таймера. Импульс удлиняется. Сейчас я проверял на микросхеме с датой 1536.
Надо сказать ведет себя непредсказуемо. Можно добавлять в текст незначительные команды, или даже NOPы и дефект исчезает. Из за чего исследовать его сложно. Или еще. Длина импульса меняется непропорционально длине счетчика. Например при r7=100 у меня 2.8 сек (вместо 163 мс), при r7=200 получается 9.8 сек.
На других кварцах дефект тоже проявляется, только время другое.
Прикрепляю еще проект на Кейле, можно в симуляторе посмотреть если включить logic analiser.
Интересно, устранено ли это на последних кристаллах, у меня самый новый 1536.

[Sanek]

Интересно, устранено ли это на последних кристаллах, у меня самый новый 1536.

В микросхемах 2016 г.в. это устранено.

[Dreamer]

Опять клещами информацию приходится вытаскивать из НИИЭТовцев. В чём суть глюка? Какие именно команды или обращение к каким регистрам и при каких обстоятельствах приводят к возникновению проблемы? То есть все МК с маркировкой 15ХХ имеют такую проблему? Значит вскоре придёт запрос на замену отгруженных МК на 16ХХ.

Интересно, устранено ли это на последних кристаллах, у меня самый новый 1536.

В микросхемах 2016 г.в. это устранено.

[Sanek]

На странице 21-25 этой темы проблема уже обсуждалось!
речь шла о выполнение команды mov tr0,c

[alpha]

Здравствуйте. В работе МК 1882ВЕ53У обнаружена следующая особенность: при программной записи информации (0x0000) в регистр T0, работающий в режиме счетчика внешних импульсов, иногда в регистрах оказывается не 0, а 0x0100. Во время записи (обнуления) флаг TR0 установлен.
Есть подозрение, что при определённом совпадении фазы АЛУ с фронтом внешнего сигнала (он асинхронен к тактовому генератору), происходит конфликт программного и аппаратного обращения на запись к регистрам счетчика.
Данное проявление зафиксировано и на AT89C52. Это особенность работы или баг? Если особенность, то где она описана?