Отправлено Oleg_0515 04 января 2004 г. 19:01

Сталкнулись вот с чем:
Железка с ADSP2189, микроконтроллером и FLASH.
МК занимается файловыми операциями с FLASH и через свой порт выдает данные в BDMA DSP. Синхронизация с помощью BR, BG, как в классическом примере (из hardware example). В принципе, такая парочка успешно работает во многих девайсах. Но... "под эмулятором" (EZ-ICE) ранее BDMA не гоняли. А сейчас - грабли! Долго бились об них лбом и все-таки древко осталось целым. Решили обойти (удалось), но ходить вокруг них стремно. Вот что имеется ввиду:
Софт в DSP загружается через JTAG с помощью EZ-ICE и стартуется. Программа - проще не бывает:
ar=address(buf_1); dm(0x3fe1)=ar;
ar=любой адрес; dm(0x3fe2)=ar;
ar=0x3; dm(0x3fe3)=ar;
ar=length(buf_1); dm(0x3fe4)=ar;
__LBL_1: ar=dm(0x3fe4); none=pass ar; if NE jump __LBL_1;
__LBL_2: jump __LBL_2;
Программа МК гонит в BDMA счетчик (0x01, 0x02..., 0xFF, 0x00, 0x01).

Оказалось, что после того, как EZ-ICE "отпускает" DSP в работу его BDMA потроха нагребают в buf_1 всекого дерьма: сначала блок нулей, потом блоков одинаковых байт, потом блок других одинаковых байт и т.д., и только спустя некоторое время все начинает работать как надо.
Размеры мусорных блоков переменные, четкой закономерности обнаружено не было.
Такое впечатление, что в течении этого интервала аномальности механиз сигналов BR, BG вообще не работает.
Проблема была отодвинута в сторону (точнее - осталась лежать где лежала, а стороной прошли мы) с помощью вставки программной задержки перед юзанием BDMA:
cntr=NNN; do __LBL_0 until CE; __LBL_0: nop;
На величину NNN влияет BMWAITE.
Если с помощью EZ-ICE (VisualDSP++2.0) тормознуть DSP, а затем "отпустить" или рестартовать, то хохма повторяется в подобном виде. Т.е. опять нужно, чтобы DSP поработал, прежде чем BDMA проснется. Может там нечто подобное выходу из режима PWDOWN происходит (после снятия сигналов JTAG)?

Хотелось бы знать, что за собака здесь порылась?