Столкнулся с такой проблемой.
Перестает работать printf (а также sprintf, vprintf и т.д.), если запущена ОСь. Проявляется это в том, что функция неправильно вынимает из стека, переданные ей параметры и, соответственно, неправильно их выводит.
Эффект наблюдается только на CortexM3 с компилятором IAR (конкретно 5.41.2). На ARM7, BlackFin, AVR, MSP430 - не наблюдается.
В чем может быть причина этого и как с это исправить?

Факты к размышлению.
1. У Cortexa есть два стека (в отличии от других упомянутых процев). Причем тот, который привычный CSTACK используется для прерываний. Для нужд приложения используется второй стек.
2. В связке CortexM3 + GCC printf сначала не работал, но после выравнивания стека задач TStackItem Stack[] на границу 8 байт, функция заработала. Выравнивание при использовании IAR не помогло.

Вот что я нарыл по этому поводу: 8 byte stack alignment is a requirement of the ARM Architecture Procedure Call Standard [AAPCS].

Да, проблема именно в выравнивании стека задачи.
Сейчас на свежую голову выполнил выравнивание и все заработало.
В прошлый раз по запарке не тем средством для выравнивания воспользовался.

Вопрос снят.

А как это выглядит в IAR-е? (Как задаётся выравнивание?)

Хм, у меня тоже проект в ИАРе.
Никакого выравнивания не делал, всё работает.
Правда, printf() не пользуюсь, только vsnprintf().

А сама операционка разве не делает выравнивание стеков задач?

Там как повезёт. Добавил переменную - работает, убавил - не работает

Пока не делает, починяем
В качестве временной меры надо в OS_Kernel.h сделать так:

(не знаю как в IAR задаётся выравнивание)

Сейчас временно сделал так.
При определении объекта задачи:

Но это не совсем правильно. В scmRTOS, как мне думается, выравнивание надо делать как-то вроде этого (не помню как это называется):

Ну, тогда, наверное, мне сильно везёт, так как вывода через vsnprintf() много и самого разного.

Кстати, мне вот не особо понятно, как применительно к стеку может относится выравнивание в 8 байт?
Ведь минимальная величина изменения указателя стека - 4 байта, не 8?
Тогда получается выравнивать надо по границе слова, а не двух слов?

Дело не в количестве вывода через printf. Вам везет, что стек выровнен как надо. Кстати какой проц. Не факт, что вам требуется выравнивание именно на 8 байт.



Требование конторы ARM, ссылка уже была. И у IARa в Development Guide для ARM Cores четко прописано 8 байтное выравнивание стека.

То есть, выравнивание стека задать таким образом нельзя, только выравнивание всего объекта? Это конечно не дело.


Или IAR у вас старый, и ещё не научился пользоваться новыми фишками


Мне тоже не очень понятно. Но - стандарт, что поделать. Тем более, что имеем явный пример глюков, которые можно получить, не соблюдая этот стандарт.

У меня LPC1768.
В теме, по моему, ясно написано Cortex-M3.
Неужели двум чипам на одном и том же ядре требуется разное выравнивание?

У себя использую три процесса с такими стеками:

Посмотрел в map файле линкера их расположение:

Как видно, стек третьего процесса не выровнен по границе 8 байт.
Однако же именно этот низкоприоритетный поток постоянно юзает печать через vsnprintf().

Вот и не верится мне что-то, что ваша проблема на 100% связана с выравниванием.

EWARM v5.50.5.
Поновее, чем у автора.
Может, наоборот, старенький ИАР подглючивает?

Возможно, проблема не гарантировано появляется, а лишь с какой-то вероятностью. Или стек расположен не в начале объекта TBaseProcess, и как раз наоборот, получается выровненным. Не знаю. Попробуйте ещё добавлять/убавлять переменные, чтобы выравнивание изменилось и возможно поймаете этот глюк.

Если ничего не меняя, только выравнивание, удаётся решить проблему, то вероятнее всего, что проблема именно в выравнивании, не правда ли?

Дело в том, что и на GCC та же проблема (см. первое сообщение топика, п. 2) (это как раз я проверял, с GCC).

ЗЫ. Дополню картину. В проекте вызываю тестовую функцию дважды - один раз до вызова OS:Run(), второй - после, уже из процесса.
В первом случае результат корректный, во втором - нет. Запрет прерываний во втором случае не спасает. Зато выравнивание стека процесса - устраняет глюк. Какие тут можно придумать варианты, кроме стека?

Да, резервируется место, на 12 байт большее отведённого места под стек.
Для чего, интересно?

Было бы неплохо для наглядности продебажить на самом низком уровне и увидеть, в каком именно месте затык.

Ведь даже если вершина стека является выровненной до 8 байт, разве не может на момент вызова любой функции текущий адрес стека быть равен его вершине-4, -12 и т.д. с кратностью 4?

Как это для чего? Вот же:

Вот они, наши 12 байт. Итого, 0x10002414 + 12 = 0x10002420 (!) Вот потому и работает printf


Нет. Компилятор обеспечивает дискретность выделения стека, равную восьми байтам. Таким образом получается, что при условии изначального выравнивания стека на границу 8 байт, оно соблюдается (сохраняется) при любом уровне вложенности вызовов.
(ИМХО конечно)

А, точно, вот они где

Э, нет, Антоха, так просто не получится - посмотри на другие два процесса - они тоже печатью занимаются
Там выравнивание тогда будет нарушаться.

Ну если компилер поддерживает выравнивание - тогда всё в порядке.