[Spider 0]

Всем привет!

Имеем STM32F405CC и запущенный на ней FreeRTOS от SysTick в качестве такта.
Чтобы сильно не напрягаться инициализирую I2C средствами HAL и далее пытаюсь с ним (I2C) таботать. И какое-то время всё работает, а потом HardFault_Handler(), буквально через 1-2 секунды. И всегда в одном месте - внутри xTaskGetTickCount() который по стеку вызван из HAL_GetTick() который вызван из I2C_WaitOnFlagUntilTimeout() в котором есть конструкция типа:

/* Check for the Timeout */
if (Timeout != HAL_MAX_DELAY)
{
  if (((HAL_GetTick() - Tickstart) > Timeout) || (Timeout == 0U))
  {
    bla bla bla
  }
}

И вот этот HAL_GetTick() и вызывает ошибку.

СТАНДАРТНЫЙ  HAL_GetTick() объявлен как:

__weak uint32_t HAL_GetTick(void)
{
  return uwTick;
}

и этот самый uwTick должен увеличиваться в прерывании SysTick, но у нас же freeRTOS, поэтому я объявил свою копию функции:

void HAL_Delay(uint32_t Delay)
{
    vTaskDelay(pdMS_TO_TICKS(Delay));
}

uint32_t HAL_GetTick(void)
{
  return xTaskGetTickCount();
}

HAL_StatusTypeDef HAL_InitTick(uint32_t TickPriority)
{
    return HAL_OK;
}

и как следствие вызовы идут из freeRTOS. Но вот беда, крашатся.

Почему!?

[rkit 1]

Крашится по другой причине, просто в этот момент. Например, из-за необработанного прерывания.

[Spider 0]

32 minutes ago, rkit said:

Крашится по другой причине, просто в этот момент. Например, из-за необработанного прерывания.

А как найти? :) Прерываний кроме систика ещё нет. i2c без прерываний. Если читать РЕЖЕ чем каждый круг цикла потока, то не падает.

[KARLSON 1]

оставшееся место памяти в стеке этого таска проверяли? Я держу, что бы было не менее 90 слов.

[Spider 0]

Там полно, заведомо больше выделено, включена проверка на переполнение 2.

[jcxz 184]

6 часов назад, Spider сказал:

А как найти? :) Прерываний кроме систика ещё нет. i2c без прерываний. Если читать РЕЖЕ чем каждый круг цикла потока, то не падает.

Как и всегда - посмотреть регистры состояния HardFault. Наверняка ведь даже не заглядывали в них.  

А ещё лучше - написать обработчик HF с расшифровкой причины по значениям регистров статуса HF.

3 часа назад, Spider сказал:

Там полно, заведомо больше выделено, включена проверка на переполнение 2.

Проверка переполнения средствами ОС (без MMU/MPU) - это не панацея. Может не срабатывать.

[AleksBak 0]

17 часов назад, jcxz сказал:

написать обработчик HF

недавно опять наткнулся на рекомендуемый код этого обработчика и уже смотрю стал там использоваться квалификатор (или как это точно называется) '__attribute__((naked))'

Оказывается и такое есть (чего там вообще только нет - лучше кто-нибудь спросил бы).