[dxp 34]

Спасибо за листинг!

 

Глянул дизасмом:

 

Вариант без volatile (нерабочий):

08002206:   beq.n 0x8002220 <OS::TKernel::sched()+40>
84               SchedProcPriority = NextPrty;
>0800220a:   str r2, [r0, #12]
90                   DUMMY_INSTR();
>08002216:   nop 
93               while(CurProcPriority != SchedProcPriority); // until context switch done
>0800221a:   ldr r3, [r0, #0]
87               do
>0800221c:   cmp r3, r2
0800221e:   bne.n 0x8002214 <OS::TKernel::sched()+28>

Загрузка SchedProcPriority производится в регистр r2 до nop, но перед сравнением этого не делается, а делаться должно, потому что SchedProcPriority - volatile. Посмотрите, пожалуйста, объявлена ли эта переменная у вас волатильной? И какая версия оси используется?

[AHTOXA 14]

Вариант без volatile (нерабочий):

08002206:   beq.n 0x8002220 <OS::TKernel::sched()+40>
84               SchedProcPriority = NextPrty;
>0800220a:   str r2, [r0, #12]
90                   DUMMY_INSTR();
>08002216:   nop 
93               while(CurProcPriority != SchedProcPriority); // until context switch done
>0800221a:   ldr r3, [r0, #0]
87               do
>0800221c:   cmp r3, r2
0800221e:   bne.n 0x8002214 <OS::TKernel::sched()+28>

Хм.

[r0, #12] - это SchedProcPriority

[r0, #0] - это CurProcPriority

 

У вас здесь похоже, всё наоборот: CurProcPriority - volatile (перечитывается перед сравнением), а SchedProcPriority - нет.

Наверное, вы для проверки убирали volatile, и убрали немного не там:)

[skyspark 0]

Хм.

[r0, #12] - это SchedProcPriority

[r0, #0] - это CurProcPriority

 

У вас здесь похоже, всё наоборот: CurProcPriority - volatile (перечитывается перед сравнением), а SchedProcPriority - нет.

Наверное, вы для проверки убирали volatile, и убрали немного не там:)

 

Вот только добрался снова до этого кода. Да, по всей видимости ошибся (уж под утро дело было), но эффект был такой же как и ранее.

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

 

INLINE static volatile uint_fast8_t & cur_proc_priority()       { return Kernel.CurProcPriority;  }

 

Ну без этого "строгие" ++-ы валили ошибку.

[AHTOXA 14]

Эх, мы так не разберёмся. На вопросы о версии компилятора вы не отвечаете, ось используете со своими правками.

 

Давайте попробуем по порядку.

 

Попробуйте взять оригинальную версию оси, прямо из транка. Или вот временное зеркало версии для Cortex-Mx на гитхабе.

Если ошибка повторится - давайте сюда версию компилятора, ключи компиляции и листинг проблемного места.

Если нет - напишите тоже, мы все выдохнем и разойдёмся:)

 

PS. Чтобы узнать версию компилятора, наберите arm-none-eabi-gcc --version в командной строке.

 

[skyspark 0]

Если нет - напишите тоже, мы все выдохнем и разойдёмся:)

 

Выдыхаем, спасибо. Совладал.

 

Проблемы обнаружилось две:

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

2. если отлаживаться st-util'ом виснет как и раньше, но после аппаратного сброса (без разрыва debug-сессии) работает правильно. Разобрался с настройками родного opencdt и с ним все стало хорошо.

 

на всякий случай версия компилера (http://www.openstm32.org): arm-none-eabi-gcc.EXE (GNU Tools for ARM Embedded Processors) 4.9.3 20150529 (release) [ARM/embedded-4_9-branch revision 224288]

 

P.S. Извините за беспокойство :rolleyes: