Раньше пользовался Keil для сборки проектов под STM32, и в нем вершина стека указывалась как _estack = 0x2001FFFF; т.е. конец SRAM

Ни так давно перешел на eclipse + ARM плагин, который позволяет создавать проект с готовым скриптом линкера, в котором вершина стека указана как __stack = ORIGIN(RAM) + LENGTH(RAM); = 0x20020000 а это за пределами SRAM

Обратился к разработчику плагина с этим вопросом, на что получил ответ



Но во всех примерах от ST вершина стека указывается именно как 0x2001FFFF, даже в примерах бутлоадера проверка наличия кода во флэш проверяется с помощью проверки адреса начала стека, записанного в этой области памяти


кто прав? как правильно выбрать адрес начала стека под STM32 ?

Чего-то я не то написал... Сверяюсь с документацией... Нет, все верно:
Вам правильно ответили - этот адрес не выровнен на границу слова, значит реально в указатель стека записывалось это число с какой-то коррекцией.
Тоже правильно, и тоже вам правильно написали - при сохранении на стек сначала уменьшается адрес в указателе, а затем происходит сохранение. И сохраняемое число попадает в последние ячейки ОЗУ. Что и требуется.

Аналогично, либо это явная ошибка (вероятность чего ничтожно мала), либо это число проходит какую-то коррекцию, прежде чем попасть в соответствующую ячейку таблицы векторов.
Значит такой кривой пример. Либо же авторы этих примеров настраивают стек так, что последнее слово ОЗУ просто не используется (что также говорит о качестве этих примеров).

Вообще я к чему эту тему завел, дело было так: сделал загрузчик и основное ПО в кейле. девайсы уже работают и проверяют наличие новой прошивки вышеприведенной проверкой. все ок (проверяют в ячейке флеш наличие записи значение которой = вершина стека т.к. с этой записи начинается образ прошивки).

затем в эклипсе пересобрал новую прошивку, а бутлоадер файлик то не принимает т.к в образе прошивки (после всех компиляций и преобразований) другое число...не ((*(__IO uint32_t*)USER_FLASH_FIRST_PAGE_ADDRESS) & 0x2FFE0000 ) == 0x20000000 а 20020000 т.к. в настройках линкера стек начинается с ORIGIN(RAM) + LENGTH(RAM); = 0x20020000

вопрос, что делать? будтлоадер то уже не изменить...

Смириться с потерей последнего слова ОЗУ и задать в настройках плагина адрес 0x20001ff8. Или размер ОЗУ уменьшите на 8 байт. Где задавать - не подскажу, так как не пользуюсь плагином. А в следующей разработке обложите образ вашего приложения нормальной контрольной суммой. Приложение может записаться не полностью и передавать на него управление без проверки целостности, мягко говоря, неразумно (это еще один камень в сторону примеров от ST).

Спасибо за разъяснения. Еще такой вопросик появился: если я вдруг захочу разместить стек не в области SRAM а в области CCM data RAM (0x10000000 - 0x1000FFFF 64Kb) и запишу как адрес стека не 0x1000FFFF, а 0x1000FFFF+1 (т.е. 0x10010000) это будет корректно?
+ Аналогичный вопрос касаемо области внешней SRAM Подключенной по FSMC

В регистрах указателя стека Cortex-M два младших бита всегда нули. Записывать можно что угодно, но нули останутся нулями.

Да. разумеется. Более того. записывая туда xxxxFFFF вы теряете последнее слово. Потому что при сохранении на стек сначала уменьшается указатель стека, а уже потом сохраняется значение. Еще можно добавить, что какой-то из стандартов ARM требует выравнивания стека на границу 8 байт, что с вашим числом xxxxFFFF, даже со сброшенными двумя младшими битами (xxxxFFFC) не выполняется.

да, это я уже понял, что лучше записывать не последний адрес области а +1 (т.е. начало следующей), тогда последнее слово не теряется.

в общем, кажется со всем разобрался, всем спасибо