Jump to content

    
Allregia

Распределение памяти, H7, Keil.

Recommended Posts

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

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

Share this post


Link to post
Share on other sites
1 minute ago, haker_fox said:

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

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

Share this post


Link to post
Share on other sites
40 minutes ago, LAS9891 said:

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

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

Share this post


Link to post
Share on other sites
8 часов назад, LAS9891 сказал:

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

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

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

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites
1 hour ago, Arlleex said:

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

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

Share this post


Link to post
Share on other sites
1 минуту назад, khach сказал:

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

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

Share this post


Link to post
Share on other sites
9 minutes ago, Darth Vader said:

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

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

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

Share this post


Link to post
Share on other sites
50 minutes ago, khach said:

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

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

Share this post


Link to post
Share on other sites
16 часов назад, Arlleex сказал:

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

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

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

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

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

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

Share this post


Link to post
Share on other sites
1 час назад, jcxz сказал:

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

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

Цитата

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

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

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.