Здравствуйте, имею проект на ASMe для C8051F321, раньше писал его в IDE от Silabs, но из-за ограничения кода перешел на Keil. Пока не было кейла написал 2 куска программы и отладил их отдельно, все работало. Вчера собрал все в одну кучу, с трудом скампилировал,

Program Size: data=179.0 xdata=0 const=0 code=2729
"DAC" - 0 Error(s), 0 Warning(s).

но результат разочаровал. а именно: в проекте имеется LCD 20*2, рабочая подпрограмма работы с ним многократно проверенная (автор Конышев Ю.А.). В ней имеются массивы данных, обращение к ним через DPTR:

LCD_StringLeft:
push ACC
mov A,#lcdAddrLeftStr

lcall LCD_AddrDDRAM

push 00h
mov R0,#lcdLimitStr

clr A
movc A,@A+DPTR
cjne A,#eos,$+5
SJMP $+7

lcall LCD_WriteCData
inc DPTR
djnz R0,$-10

pop 00h
pop ACC
ret

Подпрограмма выводит строку:

lcd_str4: db 'ERROR!!! делаю сброс'

Команда

movc A,@A+DPTR

первый раз получает правильный байт из массива, все последующие байты берутся из области вне массива и имеют значение FF.

Кто знает подскажите как это забороть, сам я не знаю даже в каком направлении копать.

Меня вот это смущает SJMP $+7

LCD_WriteCData эта подпрограмма меняет DPTR ?
может она его не восстанавливает перед выходом?

А меня ещё и вот это: cjne A,#eos,$+5
Вопрос: как программа попадет на lcall LCD_WriteCData ? Ответ: никак...
По существу вопроса о неправильных данных возвращаемых командой movc A,@A+DPTR
Очевидно, что возможны три причины:
1. разрушение содержимого DPTR - вероятнее всего
2. ненулевое значение аккумулятора
3. разрушение области хранения строки вывода (массива) - крайне маловероятно.
Keil имеет симулятор. Что Вам стоит посмотреть какая из этих причин приводит к такому результату?

Спасибо всем за ответы.

Вечером дома проверю куда перепрыгивает, но раньше все работало без проблем.


Эта подпрограмма перекодирует коды ASCII в коды LCD. Просто из массива берет по определенному адресу значение и отправляет в LCD, DPTR смотрел, просто инкрементируется и перед командой movc A,@A+DPTR там нужное значение, в памяти смотрел данный массив, там то что надо.


Повторюсь, раньше все работало, и я никаких изменений относительно переходов не делал, и на команду lcall LCD_WriteCData попадает, и данные выводятся на LCD.


Вечером проверю куда ведет djnz R0,$-10

Сообщение отредактировал serenya - Nov 2 2009, 06:29

Любопытно было бы посмотреть откуда (с какой команды) МК попадает на lcall LCD_WriteCData ...
Совет: замените все относительные переходы (типа "$ + 7"), на "нормальные": в нужных местах поставьте метки и переходы на эти метки.

Посмотрю вечером и отпишусь, по поводу не нулевого значения в аккумуляторе Вы были правы, сейчас еще раз сравнил подпрограмму с оригиналом и нашел разницу, за что и извиняюсь, все же я вносил изменения относящиеся к переходам. А именно раньше команды были acall , и при компиляции давали ошибки, я их заменил на lcall и команда djnz R0,$-10 теперь возвращает не на очистку ACC а сразу на получение очередного символа movc A,@A+DPTR. Надеюсь по этому поводу вопросов больше не будет.
Спасибо за помощь

Уже и сам увидел: с cjne A,#eos,$+5 МК и попадает на lcall. Относительные переходы меня запутали. Использование относительных переходов - дурной стиль программирования и источник трудно находимых ошибок.
P.S. Поскольку sjmp $ + 7 тоже перепрыгивает через изменённую Вами часть программы, то и тут - ошибка. Настоятельно рекомендую убрать все относительные переходы!

исправлено
написал , когда заметил что автор уже разобрался

Сообщение отредактировал тау - Nov 2 2009, 08:57

- я так понял что это переход на процедуру перекодировки символов.
А для переход на процедуру нужно использовать lcall или acall.
Или вставте процедуру перекодировки сразу с тело подпрограммы "LCD_StringLeft:" чтобы увеличить скорость.

Это переход на восстановление регистров из стека и выход из подпрограммы.


Исправил lcall на acall и все заработало.

Подскажите пожалуйста еще, что означает данное сообщение:
NOTE: USB address and data registers will not be valid until USB clock is running.
Я так понял что это просто предупреждение о том, что обновление значений регистров не произойдет пока не будет запущена программа.
И что значит это сообщение:
Unable to remove breakpoint: invalid target response.
Процессор перестает вести себя адекватно? Это сообщение появляется всегда в разных частях программы при попытках использования breakpoint и run to cursor. Причем чем дольше процессор подключен и на него подается питание тем быстрее начинаются такие баги, а если процессор "отдохнет" не подключенный то программа выполняется без ошибок некоторое время. Правда отлаживал на другой плате с таким же МК.