Нда..., Вы меня заинтриговали и я тоже глянул на код...
Переопределение main это фигня, если автор точно знает что делает,
декларация переменных в хедерах...., ну сам иногда пользуюсь, иногда это удобнее
и правильнее...(в соответствующем контексте конечно...)

Но примерно 30-50 вызовов функции EEPROM_write_byte, половина из которых
вызывается из прерываний...

Эта прога не заживет никогда, хотя автар будет еще долго утверждать что по частям
у него все работало... АМИНЬ...

Спасибо.

Надеюсь Вас тут убелили, что не стоит делать хитроумные проверки в виде счётчика переходов до основной точки входа и, тем более, хаять компилятор...

А вот и нет, не убедили. Я не понимаю почему не стоит делать проверки джампов до main(). Как раз там её и целесообразней сделать, чтобы ещё до начала фунциклирования кода выявить ошибку. Я не вижу в этом ничего криминального! В любых системах, перед её запуском производится тестирование оборудования.


А в чем собственно проблема? И причем тут вызов EEPROM_write_byte. Да хоть 100 раз я вызову - коренным образом это ничего не изменит. Во-первых, я их использую для отладки. Во-вторых, вызов функции записи в eeprom из прерываний для меня не критичен. В-третьих, на ход выполнения кода это тоже никак не влияет, иначе зачем тогда eeprom? Что Вы этим хотели сказать? Конкретизируйте пожалуйста.

Если для Вас не критично что из-за вызова функции записи в EEPROM,
прерывание может зависнуть в этом месте примерно на 3,5миллисекунды , и будут пропущены
другие прерывания, тогда не вопрос, тогда у Вас все в порядке...

Кстати, кто-нить смотрел checkjump.asm ? Особенно вот такое место впечатлило :
TESTJMP_SUCCESS_BRID:
INC R17
;//////////////////////////////////////////////////////////////////////////
;// Формируем адрес перехода исходя из результатов тестов
// SHL ecx, 1
// ADD R17, offset TESTJMP_FINISH;
;//////////////////////////////////////////////////////////////////////////
;// Переход в зависимости от результата
// JMP R17
;//////////////////////////////////////////////////////////////////////////
;// Програмные ловушки
TESTJMP_FINISH:
TESTJMP_FINISH_COMPLETE:
END
/*кгхм.... ну и куда дальше пошло исполнение ?
прим. мое, f. f. */

Автор, если серьёзно хотите что-то продолжить, у вас есть два выбора:
1. Внимать советам более опытных участников форума и не упираться рогами в духе
"а я вот хочу так и всё".
2. Продолжить самостоятельно заниматься этим сумеречным умопомрачением, но уже не задавать вопросы "почему у меня не заводится, наверно компилятор кривой ?"

[плохой вариант удалён]

Сообщение отредактировал IgorKossak - Feb 13 2008, 06:40

Потому что Си программа стартует с main(), а все что вы понаписали до функции main() это только определения функций, т.е. код , который может быть вызван, только из функции main() или из прерываний, которые инициализируются и разрешаются опять же из функции main().

Да этот тест ещё не дописан уважаемый!!! Не пугайтесь так. Приведенная Вами часть кода пока в разработке.



А здесь я с Вами в корне не согласен! Как тут уже упоминалось, можно прицепить файл cstartup.s90 и написать код в нем. Вызов main() функции производиться из этого файла строкой:

Здесь я и продумываю разместить свои тесты, т.е. до инициализации стека и массивов данных.

Сегодня я провел такой эксперимент с прошивкой которая не запускается в атмеге.
Вставил в этот файл свой код, который пару раз дергает один из выводов порта.
Подключил к ноге анализатор и зашил прошивку.
Код вставил сюда:

После запуска стало ясно, что выполнение программы даже до этого участка не доходит!!!
Изменений сигнала на выводе порта не происходит!

Выходит дело, что переход с нулевого адреса выполняется не по адресу PC+0x00F9:


Или в результате компиляции рождается битая прошивка.
А иначе как такое можно объяснить???!!!

Что на это скажете?!

Откуда у Вас такая неуёмная страсть к мазохизму? Вам уже десятка два людей прямо говорят, перестаньте страдать фигнёй. Годика 2-3 непрерывно попишите чего-нибудь попроще на чистом C, тогда, возможно, и самостоятельно разберётесь что к чему и без посторонней помощи, которую Вы не хотите слышать.

Прогнать в симуляторе АВР студии полученный код не пробовали ? Прямо по шагам по ассемблерным инструкциям, откуда стартует, куда доходит, куда не доходит. Не обломайтесь, прогоните, многое станет ясно. Еще вариант - сделать полный дизассемблерный листинг прошивки. 8к кода - это не очень много, что бы найти в нём ошибку за достаточно короткое время.

Прогонял я код и в AVR Studio и в IARовском отладчике. Правда в IAR я дебаггера так и не заставил шагать с 0x00 адреса. Всегда он начинает с main(). Ну да ладно...
В общем в студии всё чисто, без криминала. Всё работает.



Да и так уже почти год пишу на Си. Начинал с камешка AT90USB. Таких проблем там не было, а те что были разрулил. Это второй проект, причем на самом простом контроллере из AVR. И такая засада получилась...

Project->Options->Debugger->Setup снять галочку Run to main.

Тогда вернитесь к истокам. Создайте новый проект, напишите в нем моргалку светодиодом из четырех команд и вылизывая железо добейтесь ее устойчивой работы. Если даже такая простая программа работать не будет - надо менять или железо или профессию. Вы питание и землю на все ножки питания/земли процессора подали или только на одну пару?
Потом постепенно добавите кусочки из своего нынешнего проекта. Проверять команды перехода - полная фигня. Что вы будете делать, если тест покажет ошибку? Будете крутиться в замкнутом цикле? Но какой командой вы цикл организуете, ведь переходы-то не работают! Запрещать переходить в main тоже не нужно - если переходы не работают, вы туда просто не попадете по XCALL main, ведь переходы-то не работают.

Менять cstartup для выполнения кода перед main не нужно - почитайте про функцию __low_level_init() в IAR и секции .initX в avr-gcc.

А я часто сталкиваюсь с глюками ИАРа под МСП. В основном они однообразны и заключаются в непереходе по условию if, когда вроде бы всё очевидно.
Я точно не помню, но было что-то типа такого:

char i;
...
if (i) do something
else dо other

Так вот, условие никогда не выполнялось, хотя i было явно не ноль.
И так продолжалось до тех пор, пока я не переопределил условие типа i==0 или что-то типа этого, точно уже не помню.

И случай не единичный. Но ничего , привык. Правда, теперь вот на mspgcc надо переходить, а он вообще не хочет работать (в смысле код)

Хотя согласен, чаще всего ошибки в собственном коде.

Как правило причину уже озвучивали, - volatile. Компилятор просто видит, что вы не делали никаких операций и выбрасывает условие (оптимизирует)