caxapa.ru :: Ошибка HARD_FAULT в RTOS от КЕЙЛ 5.14

shan (25.06.2015 13:50, просмотров: 19232)

Ошибка HARD_FAULT в RTOS от КЕЙЛ 5.14 Запущено несколько процессов с периодом 10 мс, 1с, и 2 процесса без жёсткого периода. Один из 2-х процессов пишет (дозипись по append) файл журнала работы в диск S0: (на SPI флеш AT45DB321D). Иногда после сброса, первая группа команд {finit(),fopen(), fwrite("а") fclose() funinit()} выполняется без ошибок, а во второй группе fwrine() вылетает на вечный цикл по адресу HARD_FAUL_HANDLER (в startup_stm32f2xx.s)и приложение виснет. После этой ошибки,всегда сразу после ресета первый fwrine() вылетает на HARD_FAUL_HANDLER. Если записываемый файл удалить из S0:, то приложение работает нормально сколь-угодно долго (файл пишется). При очередном программном ресете может выскочить описанная бяка с 5-10% вероятностью. Программный ресет выполняется естественно до finit() или после funinit(). Нигде не нашёл в каких случаях происходит переход на HARD_FAUL_HANDLER. Что посоветуете? Где почитать про HARD_FAUL_HANDLER?

Ответить

- При отладке по JTAG или SWD самый простой метод поиска точки вылета - переключить поток выполнения на команду возврата. vmp(260 знак., 25.06.2015 22:26)
  - Буду проверять, но пытался сделать. чтобы обращение к SPI FLASH было только из одного потока. - shan(29.06.2015 20:24)
    - Ловится элементарно vmp(351 знак., 29.06.2015 22:34)
      - Как я понял пример, чтобы проверить на отсутствие свойства "static" у локальной переменной. shan(530 знак., 30.06.2015 16:03)
        
        Неправильно поняли. Приведенный мной текст - ловушка для вложенных вызовов функции. Статик переменная - счетчик вызовов. Если она больше 1, то это означает, что выполнение функции было прервано, поток переключился и из другого потока была снова vmp(21 знак., 30.06.2015 18:08)
        
        Добавил эту ловушку. shan(166 знак., 30.06.2015 21:17)
        
        Можно ловушку и на адрес буфера поставить. vmp(268 знак., 30.06.2015 21:25 - 21:57)
        
        Поставил на адрес буфера+длина: shan(377 знак., 30.06.2015 22:19 - 22:26)
        
        Ставить семафоры без причины - это танцы с бубном. У вас есть бубен? Если нет, то ничего не получится. - SciFi(30.06.2015 22:28)
        
        Мониторинг показал, что ОС иногда добавляет к передаваемым данным из ОЗУ в SPI 2 байта. shan(1430 знак., 10.07.2015 16:27 - 16:32)
        
        Если программа работает, то количество ошибок четное:) - Vit(10.07.2015 16:37)
        
        Поставил мьютики на все запросы к файловой системе во всех потоках. НЕ ПОМОГЛО - shan(10.07.2015 16:03)
        
        Отладчик может показать последовательность вызовов функций. А если не получается - ставьте ловушки выше (или ниже, всё относительно) по дереву вызовов. На самом деле всё просто. Вот если бы ошибка происходила раз в месяц, тогда было бы тяжко. - SciFi(30.06.2015 22:23 - 22:26)
        
        Неправильно поняли. Я с ртосами не возился, но даже мне понятно. Вы в курсе, для чего существуют мьютексы, семафоры и прочее? SciFi(38 знак., 30.06.2015 16:18)
        
        Конечно. В проекте уже есть с десяток семафоров. Но к функциям SPI драйвера и SPI флеш памяти я напрямую не обращаюсь а только через файловые функции ОС. shan(807 знак., 30.06.2015 16:44 - 16:53)
      - Пардон за сарказм, но строить системы на RTOS и не знать, что такое static, - это атас. - SciFi(29.06.2015 22:42)
        
        Знаю теоретически, а как на практике это делает компилятор КЕЙЛа, и есть ли подводные камни- опыта маловато. - shan(30.06.2015 15:48)
        
        можно строить, даже можно успешно строить. А вот без правильно расставленных семафоров низя. - Nikolay801_(30.06.2015 11:30)
- в разных потоках используется файловые функции, тут косяков нет? семафоры не нужно поставить? - Nikolay801_(25.06.2015 16:28)
  - Поток вылетает из драйвера SPI, функция SendBuf(файл STM32F2xx.c) shan(3119 знак., 29.06.2015 20:19 - 20:27)
    - именно обращение к несуществующей памяти и вызывает басфаулт. Может проблема не в самой функции SendBuf, а в том коде который ее вызывает? - Nikolay801_(30.06.2015 10:39)
      - SendBuf вызывается из функции SPI_Write() драйвера флеш памяти FS_SPI_FlashPrg.c? а её вызывают файловые функции ОС. shan(308 знак., 30.06.2015 16:23)
  - Проверил значения SCB-MMFSR=0; UFSR=0; а SCB-BFSR=0x82 !! shan(266 знак., 25.06.2015 20:48 - 21:38)
  - В разных потоках файловые функции есть (в другие файлы). Как я понимаю, функции имеют локальные переменные, выделяемые из стека, а значит их можно вызывать из разных потоков. Или это не так? shan(579 знак., 25.06.2015 17:53)
- плюс смотри стек вызова, откуда он в HARD_FAUL вывалился. - Nikolay801_(25.06.2015 15:45)
  - откуда-то из библиотечных функций RTX_CM3.lib shan(254 знак., 25.06.2015 15:57)
    - можно брек на данные поставить, узнаешь где они портятся. - Nikolay801_(25.06.2015 16:25)
- там еще есть такая полезная штука, для поиска источника проблемы Nikolay801_(627 знак., 25.06.2015 14:35)
  - У меня в RTX_config есть такое shan(211 знак., 25.06.2015 16:39)
  - Мопед не мой, с "Миландровского форума". И кстати, отладочную печать можно и через SWD/SWO вывести. Chum_A(1818 знак., 25.06.2015 15:44 - 15:47)
    - Мопед интересный. Я тоже модифицировал обработчик HARD_FAULT_HANDLER shan(471 знак., 25.06.2015 16:10)
    - а зачем? Вроде есть внутрисхемная отладка, можно брекпоинт поставить и все эти регистры посмотреть. - Nikolay801_(25.06.2015 15:51)
      - Иногда "в статике" не получается то, что получается "в динамике" :). А так, согласен, можно. - Chum_A(25.06.2015 16:00)
- грабли, типовые. 90% стека мало. - Nikolay801_(25.06.2015 14:08)
  - Про стек думал: было 512байт на задачу. увеличил до 596-- бяка осталась. shan(180 знак., 25.06.2015 14:21 - 16:14)
  - На стек не похоже, т.к. ошибка фиксируется в файловой системе и вместе с файлом удаляется. shan(412 знак., 25.06.2015 15:48)
  - Увеличение стека ТСР с 800 до 2048 байт и стеков остальных задач до с 596 до 800 байт не помогло. - shan(25.06.2015 15:22)
  - Увеличил стек с 596 до 800 байт на задачу: не помогло shan(60 знак., 25.06.2015 14:32)
    - Вообще-то есть методы измерения расхода стека. - SciFi(25.06.2015 14:33)
- Вообще-то про Hard Fault можно почитать в техническом руководстве на процессор Cortex-M*. Но конкретно эта тема разжёвана "для чайников" во множестве мест, просто погуглите. - SciFi(25.06.2015 13:53)

ARM, RISC-V контроллеры