[jcxz 184]

Уже сколько написано сообщений LAS9891, но до сих пор так и не определена причина HF. Хотя всё это прекрасно описано в доках. И это надо было сделать первым делом.

CPU кричит о причине проблемы, описывает её (через соотв.регистры), но LAS9891 продолжает упорно игнорировать это и предпочитает гадать на кофейной гуще.... 

[LAS9891 0]

4 minutes ago, jcxz said:

 но до сих пор так и не определена причина HF.

Научите.

[haker_fox 60]

2 minutes ago, LAS9891 said:

Научите.

Там всё подробно расписано. Можете взять официальные доки с arm.com вместо этой книги.

[LAS9891 0]

1 minute ago, haker_fox said:

Там всё подробно расписано. Можете взять официальные доки с arm.com вместо этой книги.

Спасибо. Прочитал - проблема решилась.

[jcxz 184]

7 минут назад, LAS9891 сказал:

Спасибо. Прочитал - проблема решилась.

Поразительно! Потребовалось всего 2 минуты!  

[haker_fox 60]

40 minutes ago, LAS9891 said:

Спасибо. Прочитал - проблема решилась.

Вот это да! Я про скорость разрешения проблемы. Или Вы смогли 30 страниц текста с картинками и графами так быстро окучить?

[Darth Vader 0]

8 часов назад, LAS9891 сказал:

В смысле не пишите не читаете? Я в Scatter-файле указываю область памяти SRAM1. При сборке проекта в этой области размещаются данные. Их не я сам принудительно размещаю.

Я имел ввиду, что до работы с этими переменными у вас дело не доходит. HF случается раньше, чем вы первый раз обращаетесь к ним из своей программы. Это так?

При отладке поставьте точку останова на входе в main() и посмотрите, доходит программа туда или нет. Поставьте другую точку в обработчике сброса перед переходом на __main. До туда доходит? Наверняка HF случается внутри __main().

[Arlleex 131]

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

[khach 33]

1 hour ago, Arlleex said:

Поэтому и говорю, что включать SRAM1 нужно до вызова SystemInit()

Тогда получается что вообще подпрограмм нельзя вызывать до инициализации SRAM1, т.к любой вызов пишет адрес возврата в стек и сразу вылетаем в HF. Можно ли с такой проблемой как то бороться, например назначив временный стек во внутренней памяти а после инициализации внешней скопировать его содержимое в SRAM1 и переназначить указатель стека. Есть ли готовый код для таких костылей чтобы не организовывать индивидуальный забег по граблям?

[Darth Vader 0]

1 минуту назад, khach сказал:

Можно ли с такой проблемой как то бороться

Почему бы не распределить стек в линкер-скрипте явно в тот регион памяти, тактирование которого включено по-умолчанию при старте.

[khach 33]

9 minutes ago, Darth Vader said:

Почему бы не распределить стек в линкер-скрипте явно в тот регион памяти, тактирование которого включено по-умолчанию при старте.

Потом этой памяти может не хватить при задачах которые требуют внешнюю SRAM. Тем более что там быстрые буфера для интерфейсов скорее всего  будут размещены, чтобы DMA не лез на внешнюю шину.

Кстати, а какой стек поинтер там используется в этот момент? Их же два MSP и PSP.

[aaarrr 63]

50 minutes ago, khach said:

любой вызов пишет адрес возврата в стек

Все же не любой. Но можно просто включить тактирование используемой памяти сразу после сброса.

[jcxz 184]

16 часов назад, Arlleex сказал:

на входе в этот SystemInit() возникнет исключение на первых же инструкциях пролога.

Если он (пролог) будет. Неизвестно, что там в SystemInit() и как он описан: вполне возможно что никаких сохранений регистров до включения тактирования может и не быть - тут как повезёт.

14 часов назад, khach сказал:

т.к любой вызов пишет адрес возврата в стек

Это не так. Сам вызов подпрограммы в стек ничего не пишет. Ознакомьтесь с системой команд ARM.

Да и PUSH/POP-ов внутри подпрограммы тоже может не быть.

[Arlleex 131]

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

Неизвестно, что там в SystemInit() и как он описан...

Я понимаю, что все зависит от описания SystemInit(), однако само название "SystemInit" говорит с 99.999% вероятностью о том, что был взят стандартный файл стартапа, стандартный файл system_stm32h7xx.c, в котором (насколько я помню) никогда никаких 'nacked'-подобных атрибутов у SysmteInit() отродясь не было, а значит она на входе какой-нибудь регистр в стеке да сохранит (при оптимизации -O0 это будет как минимум LR). Если же SystemInit() сама по себе простая и никаких локальных переменных на стеке не создает и других функций не вызывает, то на более высоких уровнях оптимизации доступа к стеку может не потребоваться, и баг не проявится.
 

Цитата

Да и PUSH/POP-ов внутри подпрограммы тоже может не быть.

Именно Поздно обратил на этот кусочек сообщения внимание, а стирать жалко.

[haker_fox 60]

18 hours ago, khach said:

Их же два MSP и PSP.

После сброса активен главный стэк MSP.