tgruzd

Нет, не об этом. Если бы в вашем случае вам удалось поместить десигнатор снизу пина, тогда да.

Мой armcc 5.06 тоже ведет себя по-разному

Раз уж открытые коллекторы уже есть, то как бы монтажное ИЛИ само напрашивается

Что вы планируете с ним делать?

https://www.keil.com/support/man/docs/uv4/uv4_cm_load.htm У меня, например, файл находится в папке OBJECTS .

1) Снимаете галку Load application at startup 2) Ctrl+F5 3) в окне команд вводите "LOAD OBJECTS\your_application_filename.axf NOCODE". Hу или через *.ini

А способ, который предложил HardEgor не привел к желаемому результату? Я сейчас попробовал ради любопытства и у меня получилось таким образом запустить отладку, причём часть данных была слинкована в физически отсутствующее место. То есть, даже при неправильно настроенной qspi можно отлаживать, если я правильно понимаю.

Извините. То есть, какая-то связь имеется. Хм, интересно ...

Советую ознакомиться с примером Keil_v5\ARM\Flash\_Template\ - не пожалеете. Это проект в результате компиляции которого, как раз и получается кастомный *.FLM Теоретически, таким подходом можно не только любую память подключённую к МК шить прямо из кейла, но и в процессе прошивки вытворять всё, на что способен ваш МК.

Картинка для примера. Я про qspi. Это к вопросу о том, почему раньше всё работало. Эти диапазоны адресов означают, что конкретный алгоритм только этими адресами и оперирует.

Нет, я про другое. смотрите столбец address range. ваша память входит в этот диапазон(диапазоны)? полностью? Вот здесь корень ошибки. и просто поменять start и size - не поможет.

предположительно, проверяет доступна ли вообще эта память Наверное не в камне дело. Вы ведь память добавили. В *.sct секцию-то прописали, а как же *.FLM об этом узнает? Тут надо понять, что линковка здесь не причём. Попробуйте ещё раз внимательно прочитать написанное, потом попробуйте сделать это, а там вдруг и жизнь наладится.

Смотрите, как всё происходит: В файле *.FLM содержится исполняемый код (Program algorithm), который размещается в RAM МК: он занимается тем, что пишет и читает данные поступающие от отладчика по jtag или sw. Т.к. память везде разная - внутренняя, внешняя, да любая - то собственно в этом файле и содержится информация о том, каким образом осуществлять доступ к тому или иному диапазону адресов. происходит следующее: отладчик передает микроконтроллеру информацию, что сейчас нужно записать такую-то страницу или хотя бы просто сообщает о факте её существования. Но так как вы сознательно подменили "програм алгоритм", то функции доступа (инициализации) возвращают ошибки для соответствующего диапазона адресов, которые вы и наблюдаете. 3. Улавливаем. А теперь ваша очередь оставить попытки править *.sct (зачем? пускай физически у вас всё лежит по правильным адресам), а вместо этого пресечь попытки линка обращаться к адресам, которыми он не может оперировать (не важно почему не может, в общем случае). Вы также можете не следовать моему первоначальному совету (честно сказать, я так не пробовал делать), а просто написать и скомпилировать свой собственный *.FLM (так пробовал), где-то в недрах кейла даже соответствующий пример есть.

А теперь я прочитал тему и ещё больше не понял. Получается, вы сознательно убрали алгоритм чтения памяти по адресу 0x9..... . Отладчик туда лезет по каким-то причинам, что закономерно вызывает ошибку. Вы пытаетесь решить вопрос правкой sct файла, что закономерно приводит к расположению данных не туда. Но почему-то не хотите явно запретить отладчику лазить туда, куда он не умеет. Это действительно необходимо - читать картинки и шрифты через отладчик?