MementoMori

Я видел 3d принтер, в котором шаговики и нагреватели питаются через подобный шлейф.

Да! Так получилось! Грузится без ошибок и отладка работает. Наконец-то. Добавил инициализационный файл - заработало. Но все равно гложет один момент...Я так понял, что галка "load application at startup" равносильна команде "LOAD OBJECTS\your_application_filename.axf" а мы в нашу команду добавили "NOCODE" Неужели в KEIL нет галки, добавляющей этот параметр в команду?

LOAD OBJECTS\D:\CUBE\H743\H743\MDK-ARM\H743\H743.axf NOCODE LOAD OBJECTS\D:\CUBE\H743\H743\MDK-ARM\H743\H743.axf NOCODE _____^ *** error 56: cannot open file А файл точно там, я проверял.

А как это сделать?

Ознакомился вот с этим https://www.keil.com/support/man/docs/uv4/uv4_db_scripting.htm Скажите, я правильно понял, что из этого скрипта можно вызвать функцию, находящуюся в самом проекте??

QSPI блок в контроллере при прошивек QSPI инициализируется, а при ресете почему-то не сбрасывается..

Задайтесь вопросом - "loading object code" - это уже debug или ещё не debug?

Давайте определимся, что для вас загрузка - "flash Download" или "loading object code"? Я тут поэкспериментировал. Переделал алгоритм прошивки qspi, убрал оттуда стирание и запись. Оставил инициализации memory mapped Mode. Как я и предполагал, при ресете после прошивки qspi почему то видится в адресом пространстве. И, о чудо, отладчик коннектится и проблема вроде бы решена. Но.... Процесс фиктивной перепрошивки тоже слишком долгий, я думал, если сделать функцию записи пустой, то процесс пойдёт быстрее, но перебор адресов тоже долог. Я решил сделать финт ушами - обманул IDE, написал, что ёмкость qspi всего 64 КБ. Не помогло, раньше вылетала ошибка доступа на адресе 0х90000000, теперь на адресе 0х90010000. Возвращаюсь к вопросу, который не раз уже задавал и ответа не нашёл. Что такое loading object code, что и откуда он читает? Object code - это что? Вся программа целиком? Или некое рабочее ядро? Почему в него попадают данные по адресу 0х90000000? Почему keil их куда то грузит? Почему этот процесс отличается в зависимости от камня?

Скажите, что мне сделать, чтобы вы поняли, что QSPI мне прошивать не нужно?

То есть проверить адреса для алгоритма qspi? Простите, вам, как вновь прибывшему, хочу сказать то, что уже говорил раньше. Я отключаю алгоритм прошивки qspi, убираю его из этого списка, у меня все выглядит как на вашей картинке, что для примера. Как я в этом случае могу редактировать адреса и зачем? Может я как то неправильно понимаю логику разработки проекта с qspi, но я делаю так - создаю проект, состоящий из кода и картинок. Добавляю алгоритм прошивки qspi. Прошиваю - контроллер 30 секунд, qspi 1 час. Далее картинки не трогаю, а правлю код. И дабы не перепрошивать qspi в течение часа, я убираю этот алгоритм. Но в файле SCT секцию с адресом 0x90000000 оставляю. В результате линкуется проект правильно, при прошивке получаю предупреждение, что алгоритм для диапазона 0х9000000... Не найден, пропускаем. После чего прошивается контроллер, происходит загадочный "loading object code", контроллер стартуееэт, отладчик запускается и читает информацию по всем доступным адресам. Но это с F746 камнем. С H743 камнем loading object code завершается ошибкой сразу после того, как достигнет того процента выполнения, который составляет объем кода для внутренней флеши по отношению к объёму внутренней флеши+qspi.

Вы про внутреннюю флеш? Или картинка для примера, а вы имеете в виду qspi?

Ну когда я создавал в кубе проект под 746 камень, я так же работал с sct файлом. Всё остальное создавал куб и touchgfx designer. Попробую

Вы про вкладку "flash Download"? А она как то отвечает за чтение? А по моему за запись и только. Не не туда, а во внутреннюю флеш и все было бы хорошо, если бы флеш не была столь мала. Как вам сказать... Когда настраивал режимы qspi, то была необходимость. Через окно memory очень легко понять, правильно ли читаются данные. Я писал уже раньше, что перелазию с F746 на Н743, так вот что-то не работает у меня dualflash, не могу понять почему. Окошко мемори пригодилось бы. Он по совершенно непонятным причинам лезет туда до запуска кода, на стадии загрузки (не путать с прошиванием) Ещё более непонятно, почему этой проблемы не было на F746 камне Не понимаю. Смотрите, если я прописываю в sct файле ExtFlashSection, то линковка происходит правильно. Всё массивы, содержащие картинки кидаются в секцию, из которой шьётcя qspi. Но при этом проблема при загрузке. Если же убрать ExtFlashSection - то линковщик пытается засунуть все во внутреннюю флеш. У меня мысль появилась интересная - сделать некий костыль. Написать алгоритм прошивания qspi, в котором включается. Memory mapped Mode, но самой прошивки и затраты времени на неё, не происходит. И посмотреть, что будет. По идее контроллер все равно должен ресетнуться, но чем черт не шутит

Да как бы, знаете ли, хотелось бы читать. На самом деле нужно настроить сборку проекта так, чтобы загружаемый во время "loading object code" код не содержал в себе секции, которые привязаны к адресу 0x90000000 и выше. Чтобы во время стадии "loading object code" не происходило обращения по указанному адресу.

И галку и адрес. Не работает.

Как выяснилось, у меня старая версия, не подднрживающая h7 серию. Новвй китайский клон я заказал конечно. Но может найдётся на форуме человек, у которого и jlink и плата на н7 и keil..... Галки не принимаются во внимание, если стоит другая галка, та что предписывпет использовать sct файл

Ну допустим. Но эти строки во первых, необходимы, чтобы линковщик назначил картинки не во внутреннюю флеш контроллера, а в QSPI, иначе, если объем их велик, проект не соберется. Во-вторых - для F746 камня это проблемой не являлось. Господа, вы, на мой взгляд, не учли одну вещь - ошибка происходит не при выполнении кода, а при его загрузке. Я ж писал - "loading object code". ПРичем происходит это на определенном проценте загрузки. И если флеш контроллера 1 МБ, а в ExtFlashSection данных на 4 МБ - то ошибка возникает на 20%, если в ExtFlashSection тоже 1Мб - то на 50% - улавливаете о чем я?

вы об этом? Initialistion File? Или может быть это Как видите, пусто. Проверил, нигде. Но строка QSPI_BASE (0x90000000) обнаруживается в куче объектных файлов MAP-файл - там тоже вроде все ровно, но все же выложу его, может кто опытным глазом глянет H743.map

Я не силен в ассемблере. Вообще, увидев такую картину - куда копать? Я кстати, убрал галку "run to main" - та же петрушка.

Вот оно что))) Случайно увидел - после генерации ошибки на очень короткое мгновение появляется окошко "command" в котором указано на ошибку. Затем это окошко исчезает, поймал только через скриншот. Я пересмотрел внимательно MAP файл -по адресу 0x90000000 и выше - только данные, никакого кода. ОБратите внимание на окно дизассемблера - я не пойму ошибка обращения генерируется при отдаче первой же команды? Я не силен в ассемблере.

Каждый, к кому обращаюсь на этом форуме и не только, обязательно проходит эту стадию непонимания вопроса. Мне не надо прошивать QSPI, она прошита. Я прошил и убрал алгоритм. Прошиальщик спокойно пропускает QSPI, прошивает флеш контроллера и пытается запустить плату. Проблема в том, что в SCT файле секция с адресом 0x90000000 должна быть определена, иначе все 10 мегабайт линкер пытается запихнуть во внутреннюю флеш. Поэтому эту запись удалять нельзя.

Господа, есть у кого-нибудь плата на H743 камне? Я бы проект скинул, кому не трудно посмотреть... Проверяю. Только не DLL - а исходники. А они че-то так завязаны друг с другом, что только блоком... Вот нерабочий проект https://cloud.mail.ru/public/fyST/PYnhuPQkp Отключить из проекта все папки TouchGFX - проблема исчезает. Откликнитесь, владельцы плат с H743....

В F746 камне я ничего не инициализировал ДО. Но и обращения к этому ДО загрузки не было. Как уже написал выше - мне удалось создать проект, причем не минимальный (голый), а вполне полноценный, в котором при указанном мной содержимом SCT файла данная ошибка не возникает. Проблемный код отличается от этого проекта наличием подключенной библиотеки TOuchGFX. Причем сама библиотека, ее код тут ни при чем - если в самом начале функции main() поставить тормоз (while(1)), Keil понимает, что дальше этого тормоза программа не пойдет (ниже по тексту не ставятся брейкпоинты), но тем не менее, loading object code все так же выдает ошибку..... То есть само наличие библиотеки touchgfx каким-то образом меняет поведение отлачдика.

Там есть галка если ее убрать, то указанные вам настройки игнорируются, а информация берется из scatter файла, его содержимое в первом посте. БОлее того, это содержимое правильное. А пока я выяснил кое что- видать дело не в настройках кейла. Если я создаю голый проект в кубе, настраиваю всю периферию - проблемы нет. Я даже добавляю в проект массив с данными для картинки - проблем нет, он шьется в QSPI, а потом, когда я убираю алгоритм прошивки QSPI из списка, этот код не мешает работе. Стоит только добавить в проект TOuchGFX, пересоздать проект - проблема появляется.

Короче, все указывает на то, что после прошивки, при старте, при "loading object code" отладчик пытается обратиться по адресу 0х90000000, которого к этому моменту ещё не существует (qspi не инициализирована). Об этом свидетельствует тот факт, что если убрать галку load application at startup, то ошибки не возникает. Не возникает её ещё и если вместо 0х90000000 указать другой, читабельный адрес. Скажите мне, как мне настроить scatter файл или настройки keil, чтобы во время "loading object code" отладчик не пытался читать адрес, прописаный в секции LR_EROM, там ведь только данные. Можно же это как то отключить?