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

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

[zltigo]

Ну так по минимуму,хотя-бы LR и NVIC_HARDFAULT посмотреть при вылетах. А вообще и порт может быть совсем не рабочий - я "для начала" решил как-то из комплекта поставки FreeRTOS залить проект для Stelaris, так не живой он был абсолютно. Потом уже тихонечко с чистого листа в меру понимания порт сделал - живет, естественно.

По опыту скажу

Не морочьте сейчас этим человеку голову.

[Forger]

Не морочьте сейчас этим человеку голову.

Отчего ж морочу? Увидел явный ляп в коде, ткнул пальцем в слабое место.
В голове отложится. Может, когда-нить пригодится

[Aleksandr Barano...]

Отчего ж морочу? Увидел явный ляп в коде, ткнул пальцем в слабое место.
В голове отложится. Может, когда-нить пригодится

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

[zltigo]

Отчего ж морочу? Увидел явный ляп в коде

Нет там явного ляпа:
1. любая сколь угодно хаотичная работа с GPIO не есть причина вылета;
2. без известных приоритетов задач говорить проблемах доступа к ресурсам бессмысленно;
3. при двух микроскопических задачах из считанных команд, если системный таймер не разогнан до невменяемых
времен, эти задачи не будут прерывать друг друга.

[Aleksandr Barano...]

Когда я в FreeRtosConfig.h установил configUSE_TICK_HOOK = 0 эффект вылетания исчез, но - почему-то - теперь светодиод гораздо дольше OFF, чем ON. Может, я что-то с SysTick напутал...

[zltigo]

но - почему-то - теперь светодиод гораздо дольше OFF, чем ON.

Потому, что это у Вас так написано - от фонаря мигать и должно.

[Aleksandr Barano...]

Потому, что это у Вас так написано - от фонаря мигать и должно.

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