УКНЦ отсутствие микросхемы

[ZPilot]

А при снятии сигнала SACK все остальные сигналы также снимаются, в том числе и шина адреса-данных?

В общем, ситуация не много не такая, если войти в ДМА и выйти, то процентов на 90, что УКНЦ продолжит работать, в 10% ШДА и все сигналы остаются в высоком уровне при снятии SACK, связано с нерабочей 031 и проводами тестера.
Но вот после чтения или записи в ДМА - УКНЦ зависает всегда, даже если обмен, после выхода из ДМА, на шинах присутствует.

[Alex_K]

А как долго в режиме ДМА вы держите процессор?

[ZPilot]

А как долго в режиме ДМА вы держите процессор?

ну.. нажал кнопку на плате СТМ - вошел на УКНЦ в ДМА, нажал на клавиатуре циферку с выбором записи или чтения (уже на компе, общаемся через уарт), получил ответ, нажал кнопку выхода.. ну пусть будет секунд 20

[Alex_K]

ну.. нажал кнопку на плате СТМ - вошел на УКНЦ в ДМА, нажал на клавиатуре циферку с выбором записи или чтения (уже на компе, общаемся через уарт), получил ответ, нажал кнопку выхода.. ну пусть будет секунд 20

Возможно это долго. Уточнение по входу в режим ДМА из описания процессора 1801ВМ2. Для получения запроса устройство выставляет сигнал DMR. При получении сигнала DMGO устройство, запросившее прямой доступ, должно сначала выставить сигнал SACK и затем снять DMR. Рекомендуется снимать сигнал DMR по снятию сигнала DMGO.

[ZPilot]

выставить сигнал SACK и затем снять DMR

Я так и делаю.
А не могу я записью или чтением изменять какие-то регистры процессора, что он потом стартует не правильно?
Ведь если войти в ДМА, подождать немного ни чего не делая, а потом выйти, то УКНЦ продолжает работать нормально.

[Alex_K]

А не могу я записью или чтением изменять какие-то регистры процессора, что он потом стартует не правильно?

Нет, не можете. Из режима ДМА регистры процессора не доступны.
Про снятие DMR есть уточнение, что снимать его желательно по снятию сигнала DMGO.

- - - Добавлено - - -

Ведь если войти в ДМА, подождать немного ни чего не делая, а потом выйти, то УКНЦ продолжает работать нормально.

Когда что-то делаете, то все сигналы перед выходом из ДМА переводите в неактивный высокий уровень?

[Advertiser]

[ZPilot]

ро снятие DMR есть уточнение, что снимать его желательно по снятию сигнала DMGO.

Делаю вот так:

Скрытый текст

"mov r1,#(DMR<<16) \n"
"str r1,[%[portb],BSRR] \n"

"wait_l_dmg: \n"
"ldr r1,[%[portb],IDR] \n"
"and r1,#(DMG) \n"
"cmp r1,#(DMG) \n"
"beq wait_l_dmg \n"

"mov r1,#(SACK<<16) \n"
"str r1,[%[portb],BSRR] \n"
"mov r1,#(DMR) \n"
"str r1,[%[portb],BSRR] \n"

[свернуть]

- - - Добавлено - - -

ДМА переводите в неактивный высокий уровень

Да, и вроде бы ни про кого не забыл.
Выводы еще и open drain

[AFZ]

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

Странно это. Процессор обязан дождаться, когда абонент МПИ снимет RPLY и только после этого поднимать SYNC. Более того, это реальный способ завесить МПИ - если на ВВОД или ВЫВОД абонент не ответит RPLU, процессор, отсчитав тайм-аут, трапнется по 4-му вектору, а если абонент ответил, но не снял свой RPLY после того, как процессор снял свой ВВОД или ВЫВОД, он будет ждать, пока RPLY не снимется. Наблюдал не раз, ставя брекпоинт на какую-то из команд между выдачей и снятием RPLY. STM-ка вылетает в отладку, я что-то разглядываю в ее портах и регистрах, ЦП тихо ждет. При этом может испортиться содержимое динамической памяти; полсекунды оно как-то держится, а дальше - не факт.

[ZPilot]

Странно это. Процессор обязан дождаться, когда абонент МПИ снимет RPLY и только после этого поднимать SYNC

Наверное потому, что я слишком долго отвечаю на сигнал Ввод или Вывод? Дело в том, что мне надо проверить какой из 7 портов у хм1-031 вызван, а только потом подтянуть к земле RPLY, если вызвать сразу после определения, что обращаются к хм1-031, то для ПП у 031 появится еще 9 портов.

[Alex_K]

ZPilot, а подвисает у вас после ДМА, если производилось чтение или запись?