Точно? С printf? С плавучкой (я про это не говорил, но это важно)?

Да, с vsnprintf(), без плавучки.

Считаешь, что именно плавучка вызывает сбой?

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

Да, плавучка ибо double, который как раз-таки размером 8 байт (а возможно и long long).

Я тоже наступил на эти шикарные грабли.
Недавно добавил в свой printf поддержку 64-битных целых (signed/unsigned long long которые). Проверил, отладил - все работает. И даже пару месяцев нормально поработало. А потом - хрясь, и все, мусор вместо 64-битных лезть начал. И не сразу докопался я, что va_arg(list, long long) неверно из стека 64-битные вынимает. Добавил выравнивание стека в порт RTOS (TNKernel, не SCM, но это неважно) при инициализации задачи - и все снова работает. Да, грабли просто шикарные, и бьют больно.

Принимаю эстафету в беге по граблям.

Не могу найти причину hardfault'а в ScmRTOS после вызова sprintf. В hardfault падает из ContextRestore, на инструкции bx lr c 0xfffffffd в lr.

ScmRTOS 3.10, arm-kgp-eabi-x86_32-20111129 (с yagarto аналогично).

Оч. расчитываю на вашу помощь.

По симптомам очень похоже на порчу сохраненного на стеке контекста процесса. Хватает ли стека тому процессу, который вызывает sprintf? Хватает ли буфера, в который пишет sprintf?

Сергей, спасибо. Проблема действительно была заключена в недостаточном объёме памяти, выделенной под стек.

РРРР!) Прошу прощения за поднятие старой темы... Может быть какой-нить дефайн добавим в OS_Kernel.h? Чтобы при компиляции оси под армы (под ARM7TDMI точно) стек задач выравнивался на 8. А то я уж чуть не поседел, когда несколько дней думал, почему vsprintf не печатает плавучку... Выравнивание на 8 рулит!!!

З.Ы. У меня 4-я версия, там еще ничего не выравнивается(

Как это не выравнивается? Может быть, вы имели в виду 3-ю версию? Так и там исправлено (по крайней мере в 3.11/GCC - точно).
Вот же (tags/3.11/CortexM3/GCC/scmRTOS/CortexM3/OS_Target_cpp.cpp):
TBaseProcess::TBaseProcess(TStackItem* Stack, TPriority pr, void (*exec)())
: StackPointer((TStackItem*)((unsigned int)Stack & 0xFFFFFFF8))

Если у вас IAR, то поправьте по аналогии.

Я имел в виду под ARM7TDMI... Принтф у меня не работала, пока я не закомментировал то, что было, и не добавил то, что ниже комментария... Версия 4.00

А тема про CortexM3
Тут такое дело. Дефайн не поможет в общем случае. Потому что выравнивать нужно не начальную вершину стека, а его вершину после сохранения начального контекста. У ARM7 и у Cortex-M3 контекст 16 слов, поэтому можно выравнивать и так и так. А вот с Cortex-M4F такой фокус уже не прокатит, там 17 слов. Поэтому выравнивать надо не централизованно, а в порте. Лучше - так, как я сделал в порте для Cortex-M4F.

Не, так точно не надо. Надо как-то вот так (в OS_Target_cpp.cpp):

Попробуйте, и, если всё нормально, то я внесу правку в репозиторий.

Про кортекс не заметил, был увлечен ARM7

Поправки внес. Все запустилось и работает прекрасно. Надеюсь, что если пошло, то вылетов на этой почве уже не будет.

Спасибо!

Исправил в репозитории.

Попутно вскрылся интересный факт - я правил с старом репозитории, а в новом изменения пока не появились. Выходит, это два разных репозитория, и они синхронизируются. Надо тогда поаккуратнее быть...

Что-то не так... Сейчас снова одни нули вместо плавучки выводятся. Причем если вернуть определение стека так, как я первоначально сделал - то работает. Как Вы предложили - нет Неужели я в прошлый раз как-то компильнул проект не так Оперативы у меня 32 метра, дефицита не наблюдается. malloc() столь необходимая (иногда?) printf - работает.

Пока думаю, куда копать...

Для очистки совести сделал

для двух вариантов...

Вывод 1 (плохой)


Вывод 2 (хороший)


Сама функция работает (текст, hex, dec)

AHTOXA, а почему не стоит делать правку в кернел.h? Ведь это логично, там мы выравниваем стек именно процессов? Более того, Вы сами предложили этот вариант в первых постах) Нэ понимает моя)))

З.Ы. Блин, в map-файле от GCC без поллитра не разберешься...

Пошел мой разбор полетов:
1. По-сути при создании процесса мы попадаем в функцию , которая инициализиует стэк. И уже там "готовится" указатель, выровненный пока не понятным для меня ( к сожалению опыта мало) образом. Т.е. что там, что тут - вроде без разницы...