Работаю на отладочной плате OLIMEX Header boards. Проц - LPC2138. Кому интересно можно поглядеть тут http://www.mt-system.ru/p125.mt . Среда Keil. Компилятор RealView.
Есть функция сравнивающая 2 больших массива, где в первых двух байтах длина массивов. По окончании сравнения если равно возвращается 0, если больше 1, если меньше -1. Так вот при возврате "-1" в определенный момент, когда определенное число принимает определенное значение (сравнение производится в цикле), следующий код портит R14.



До команды CMP r0,r1 содержимое R14 верное, после нее становится неверным.
Содержимое R0 и R1 таково, что переход идет в метку L1.500 и соответственно возвращается функция не туда откуда вызывалась.

Такой глюк возникает только в определенный момент, то не всегда. Гдето 95% глюка, в остальное время этот момент проходит, но скорее всего при следующей итерации в цикле глюк повторяется.

На что грешить и не знаю даже. В функции нет вообще ни одной команды, как либо работающей с R14.

Бьюсь головой в стену уже второй день

А что с прерываниями? Может, они портят?
Для контроля попробуйте запретить прерывания перед вызовом функции.
И какие адреса передаются в качестве параметров - попадают ли они в ОЗУ (ПЗУ).

Вполне может быть вызвано прерывание от таймера (Используется операционка RTX). Но дело в том, что регист R14 банкируется, то есть что в FIQ что в IRQ свой собственный R14, который хоть об изменяйся 100 раз, никак не повлияет на R14 вне прерывания.
В функцию передаются указатели на массивы. Сами массивы лежат в RAM.
Были подозрения, что что-то портится в стеке, но я стек увеличивал аж на 1.5к. Не помогло...

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

Сообщение отредактировал SanyaKID - Jul 27 2007, 11:09

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

Попробовал отключать прерывания от таймера - таже фигня

Где-то тут Data Abort-ом пахнет

Попробуйте запретить прерывания вообще.

А где собсно возврат результата "-1" ?

Насколько помнится RTX переключает контекст в прерывании на SVSR.
Так что вполне может портить LR.

А какая у вас ревизия чипа ? Случаем не C или D?
А в пошаговом режиме вам удавалось добиваться такого поведения?
А вот темку почитайте, на всякий случай:
http://electronix.ru/forum/index.php?showtopic=33479

Я был в отпуске... Тока что вернулся. Проблема оказалась действительно в MAM. Его отключение помогло.

То на что я до отпуска безрезультатно потратил 4 дня, сейчас решилось за 1 день. Удачно отдохнул

Сообщение отредактировал SanyaKID - Aug 20 2007, 13:38

Помогло полное отключение или перевод в режим MAMCR=1 ?
Какая ревизия чипа?

Ревизия чипа - С. Я отключил МАМ вообще. С частичным МАМом играться не пробовал, так как, посовещавшись, мы решили не тратить на это время.

при отключенном МАМ скорость выполнения программы замедляется раз в 5.
Не всегда это приемлемо. Не могли бы вы попробовать поработать с МАМCR=1
и просто пронаблюдать, если подобные глюки появятся, то сообщить.
У меня к сожалению нет сейчас ревизии чипа C или D, а партия спаянных устройств придет
только в середине сентября. Какая ревизия там будет пока не знаю, но могу предположить
с большой долей вероятностью что именно из этих. Хотелось бы заранее подстелить соломку,
хотя с отключенным МАМ мы попробовали, не хватает производительности однозначно

После опубликования бага имею в разработке пять экземпляров девайсов 2138 и 2148 с "нехорошими" ревизиями. С MAM=3 не уходил. Подготовил в конфигурационном EEPROM параметр для торможения, но пишу/отлаживаю на полном ускорителе. Как ни странно нималейших проблем. Крутится система, два сильно загруженных SPI, все внешние прерывания задействованы, внутри на прерываниях I2C, SPI, SPI на FIQ, RTC, один/два UART на полных 115200, всего остального тоже хватает. Кода в этих девайсах пока от 50 до 100K. Несколько работают уже круглосуточно под нагрузкой в реальной системе. Проблем нет.