[_sda 0]

Коллеги, обнаружил в новом изделии неустойчивый старт ниос, инициализация периферии по включению питания иногда выполняется, иногда нет. При старте в отладчике почему то происходит остановка в файле crt0.S хотя у меня брейкпоинтов нет. Какова причина остановки?После продолжения программа работает нормально. В моей практике впервые обнаружился такой дефект. Подскажите,плз, в каком направлении копать.

[Kuzmi4 0]

а какой конфиг ниоса и раскладки памяти с которой он собственно запускается ?

[_sda 0]

Спасибо Игорь, я уже во всём разобрался ещё в понедельник, на плате был косяк. Меня ставила в ступор его остановка на 169 строке...

[_sda 0]

Коллеги, ещё одна засада, уже по кругу начал ходить. Не изменяется .sof при изменении исходников программы. Мои действия:

1). Компилирую изменённые исходники в Эклипсе.

2). Выполняю make targets,формируется новый файл .hex

3). Сравниваю новый файл .hex со старым - отличия есть

4). Запускаю quartus_cdb, update memory

5). Запускаю quartus_asm, ассемблер формирует новый .sof

6). Сравниваю новый файл .sof со старым - отличий нет

Перепроверил все мыслимые пути - криминала не нашёл. В QSYS файл .hex указан.

Помогите,плз, кто может.

[StewartLittle 41]

2 часа назад, _sda сказал:

6). Сравниваю новый файл .sof со старым - отличий нет

Может Вы новый файл не там ищете (а старый файл сам с собой сравниваете)?

[_sda 0]

1 час назад, StewartLittle сказал:

Может Вы новый файл не там ищете (а старый файл сам с собой сравниваете)?

Нет, я обычно делаю так - к имени старого файла добавляю постфикс и оставляю в той же папке. Ассемблер генерит новый файл *.sof со старым именем.

Оба файла находятся в одной папке, остаётся только сравнить их содержимое.

Во влип... Если даже у Вас нет других версий то рушатся последние надежды.

Завтра ещё попробую снести полностью весь проект и начать с нуля. Иных мыслей уже нет.

[Kuzmi4 0]

2 _sda:

а если заменить пустой начальный HEX на новый и пересобрать через qpf файл, какие результаты ?

[_sda 0]

15 минут назад, Kuzmi4 сказал:

2 _sda:

а если заменить пустой начальный HEX на новый и пересобрать через qpf файл, какие результаты ?

Что-то вечером уже туго соображаю - пересобрать через qpf файл это как?

 

[Kuzmi4 0]

самый простой вариант этого действа - через гуй открыть файл проекта (qpf) и пересобрать.

[_sda 0]

А-а-а-а, так это я уже раз пять делал - результат никакой.

[StewartLittle 41]

1 час назад, _sda сказал:

Нет, я обычно делаю так - к имени старого файла добавляю постфикс и оставляю в той же папке. Ассемблер генерит новый файл *.sof со старым именем.

Тогда проверьте, откуда квартус берет hex-файл - из папки эклипсовского проекта (meminit) или из корневой папки квартусовского проекта. Попробуйте вручную заменить hex-файл в папке квартусовского проекта на вновь созданный из meminit, и затем повторите cdb и asm.

[_sda 0]

Спасибо! Ваш совет помог мне узнать откуда берётся хекс файл для meminit - из старого места(я старый проект скопировал в новое место). Вывод - нужно чаще заглядывать в репорты-))))

Теперь непонятно как выйти из ситуации. Т.к.meminit игнорирует путь к хекс-файлу, указанный мной в кусис, я удалил инициализацию памяти из кусиса, перегенерил кусис и проект - meminit всё равно берёт хекс по старому пути. Вернул в кусисе инициализацию памяти, всё перегенерил - всё равно остался старый путь для хекса. Добавил сам хекс в проект(хотя раньше хватало добавления *.qip) - ничего не изменилось. Посмотрел в самом вериложном файле описания памяти - там прописан новый путь верно.

Эх, пенёк я старый - совсем забыл за существование баз. Почистил и всё стало на место.

Всем спасибо за желание помочь!