scmRTOS + CortexM3 + printf, некорректная работа printf Опции

[shreck]

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

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

[haker_fox]

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

CODE

        class process : public TBaseProcess
        {
        public:
            INLINE_PROCESS_CTOR process();

            OS_PROCESS static void exec();
            
        #if scmRTOS_PROCESS_RESTART_ENABLE == 1
            INLINE void terminate();
        #endif
            

        private:
            //stack_item_t Stack[stack_size/sizeof(stack_item_t)];
            __attribute__ ((aligned (8))) stack_item_t Stack[stack_size/sizeof(stack_item_t)];

[AHTOXA]

Я имел в виду под ARM7TDMI...

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

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

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

Код

void TBaseProcess::init_stack_frame( stack_item_t * Stack
                                   , void (*exec)()
                                #if scmRTOS_DEBUG_ENABLE == 1
                                   , stack_item_t * StackBegin
                                #endif
                                   )
{
    StackPointer = (stack_item_t*)((uintptr_t)Stack & 0xFFFFFFF8);
    *(--StackPointer) = (stack_item_t)exec;    // return from interrupt address
    StackPointer -= 14;                        // emulate "push R0-R12", "push LR"
    if((uintptr_t)exec & (1 << 0))      // if exec is THUMB-mode code
        *(--StackPointer) =   0x003F;          // SR value: system mode, FIQ & IRQ enabled, THUMB mode
    else
        *(--StackPointer) =   0x001F;          // SR value: system mode, FIQ & IRQ enabled, ARM mode

#if scmRTOS_DEBUG_ENABLE == 1
...

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

[haker_fox]

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

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

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

Спасибо!

[AHTOXA]

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

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

[haker_fox]

Исправил

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

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

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

CODE

make clean && make all

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

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

CODE

#ai6di2
ADC0: 0x81 129 0.00
ADC1: 0x80 128 0.00
ADC2: 0x80 128 0.00
ADC3: 0x80 128 0.00
ADC4: 0x7f 127 0.00
ADC5: 0x7b 123 0.00

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

CODE

#ai6di2
ADC0: 0x81 129 2.52
ADC1: 0x80 128 2.50
ADC2: 0x80 128 2.50
ADC3: 0x80 128 2.50
ADC4: 0x7f 127 2.48
ADC5: 0x7b 123 2.40

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

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

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

Пошел мой разбор полетов:
1. По-сути при создании процесса мы попадаем в функцию

CODE

init_stack_frame

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

[AHTOXA]

Что-то не так... Сейчас снова одни нули вместо плавучки выводятся. Причем если вернуть определение стека так, как я первоначально сделал - то работает. Как Вы предложили - нет

Очень странно. Вообще-то эти варианты эквивалентны.
Только что увидел, что не до конца исправил:
Исправьте в конце TBaseProcess::init_stack_frame():

Код

#if scmRTOS_DEBUG_ENABLE == 1
    for (stack_item_t* pDst = StackBegin; pDst < StackPointer; pDst++)
        *pDst = STACK_DEFAULT_PATTERN;
#endif // scmRTOS_DEBUG_ENABLE

AHTOXA, а почему не стоит делать правку в кернел.h?

Потому что kernel.h - один на все порты. Чтобы внести правку в него, нужно вносить изменения во все порты (какие-то макросы придумывать, дефайны, или что-то типа того). Ну и вообще, не дело решать проблемы одного порта правками в коде оси, если есть иное решение.
А если вы ведёте речь о локальной правке, у себя, то такую правку делать можно (Только если вдруг, через полгода-год, давным-давно забыв об этой истории, обновите ось, и что-то перестанет работать, то не говорите, что я вас не предупреждал )