STM32F101C8. Free RTOS, Hard Fault Exception Опции

[Aleksandr Barano...]

Здравствуйте.
У меня есть плата с STM32F101C8, на которой я успешно потренировался мигать светодиодами. То есть, очевидные аппаратные ошибки маловероятны. Я откомпилировал FreeRtos с двумя простыми задачами:

Код

static void vLCDTask( void *pvParameters )
{
  (void)(*pvParameters);
    for(;;)
    {
          GPIOB->ODR &= 0x03FF; // LED ON
                 vTaskDelay(10);
    }
}


static void vLSDTask( void *pvParameters )
{
  (void)(*pvParameters);

    for(;;)
    {
      GPIOB->ODR |= 0xFC00;//LED OFF
       vTaskDelay(10);
    }
}

Система работает несколько секунд, а потом улетает на Hard Fault Exception.
Кварц - 8МГц, множитель/ делитель PLL сконфигурирован как 6/2. Тактовая частота, по моим расчетам - 24МГц. На всякий случай Flash - с двумя wait states.
Нет ли каких-то идей, как помочь этой беде?

[Forger]

По опыту скажу: крайне опасно обращаться к аппаратному ресурсу - в данном случае к конкретному регистру железа - из разных мест (задач RTOS или обработчиков прерываний).
В кооперативном планировщике это допустимо, но, все равно, не желательно (нарушается логичность кода), а в вытесняющем, как у FreeRTOS - вообще нельзя!
Но, если уж очень хочеться так делать (бывает, что просто нет другого выбора), то нужно такие обращения делать атомарными, т.е. непрерывными - например, использовать критическую секцию, или мьютекс (предпочтительнее).
В данном случае это удобно оформить в виде сервиса RTOS - флага (типа команда, вкл/выкл светодиод) или сообщения (так сделано в Windows).
Если светодиодов много, то лучше - флаги: одно битовое поле - один светодиод.
Тогда управлять светодиодами можно безопасно из любой задачи, а одна задача просто постоянно ждет изменения любого из флагов (имеется ввиду использование сервиса ожидания события RTOS), а остальные задачи в любой момент посылают соотв. сообщение.
В этом случае доступ к железу исключительно атомарен, безопасность достигнута и, просто, красиво построен сам код - легче отлаживать и исправлять ошибки.

Если посмотреть код асемблера, то такая строчка

Код

  GPIOB->ODR &= 0x03FF; // LED ON

выйдет в ряд команд ассемблера.
Если бы эта же строчка занимала одну команду процессора, то проблем бы не было.