haker_fox 60 13 апреля, 2019 Опубликовано 13 апреля, 2019 · Жалоба 15 hours ago, amaora said: которые впрочем не затрагивали ничего важного, только удалял ненужное А что в ней есть ненужное? Многие сервисы ОС отключаются легально с помощь FreeRTOSConfig.h. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Arlleex 131 13 апреля, 2019 Опубликовано 13 апреля, 2019 · Жалоба Чего-то я не понимаю, почему здесь дискуссия в форме гадания на кофейной гуще: влетает в обработчик или не влетает определяем светодиодами 1. Другие задачи работают или устройство намертво зависает? 2. А можно отладчиком наконец подцепиться, запуститься и поймать эту ситуацию, если п. 1 подразумевает полное зависание всех задач и устройства в целом? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
x893 35 13 апреля, 2019 Опубликовано 13 апреля, 2019 · Жалоба Отсутствие отладчика не освобождает от ответственности за ошибки в коде. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Arlleex 131 13 апреля, 2019 Опубликовано 13 апреля, 2019 · Жалоба 46 минут назад, x893 сказал: Отсутствие отладчика не освобождает от ответственности за ошибки в коде. Это, разумеется, да, но с ним было бы быстрее эту ошибку локализовать. В конце концов окажется, что, например, редкое прерывание, будучи настроенным в недопустимый для сервисов RTOS приоритет, вызывает xSemaphoreGiveFromISR() и вешает все процессы. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
haker_fox 60 13 апреля, 2019 Опубликовано 13 апреля, 2019 · Жалоба Just now, Arlleex said: недопустимый для сервисов RTOS приоритет, вызывает xSemaphoreGiveFromISR() и вешает все процессы Нет, в этом случае будет вызван configASSERT в соответствующем файле. Там таже комментарий есть, почему система оказалась в этом месте. У меня такое много раз было. Вообще FreeRTOS довольно хорошо оснащена диагностическимы выводами. Их только включить нужно. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Arlleex 131 13 апреля, 2019 Опубликовано 13 апреля, 2019 · Жалоба 1 минуту назад, haker_fox сказал: Нет, в этом случае будет вызван configASSERT в соответствующем файле. Там таже комментарий есть, почему система оказалась в этом месте. У меня такое много раз было. Вообще FreeRTOS довольно хорошо оснащена диагностическимы выводами. Их только включить нужно. Ключевой момент "их только включить нужно" Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
haker_fox 60 13 апреля, 2019 Опубликовано 13 апреля, 2019 · Жалоба 3 minutes ago, Arlleex said: "их только включить нужно" Я написал "диагностические выводы". Имел в виду вывод в консоль. FreeRTOS же не может знать, как сделать вывод на конкретной системе. Через какой порт хотя бы. Может быть консоль на ethernet'е вообще висит))) Однако, если макрос configASSERT не определён, то работает макрос по-умолчанию, который просто стопорит систему. Тогда нужно остановиться отладчиком, и посмотреть, где зависло. Однако в руководстве по запуску системы (где-то на сайте) написано, что все эти фишечки включить нужно. У меня, например, они включены всегда. Даже в релизных проектах. И пишут всё на диск в случае ошибки. Зато потом, просмотрев служебный журнал ошибок, можно отметить где и что сбойнуло. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Arlleex 131 13 апреля, 2019 Опубликовано 13 апреля, 2019 · Жалоба 1 минуту назад, haker_fox сказал: Я написал "диагностические выводы". Имел в виду вывод в консоль. FreeRTOS же не может знать, как сделать вывод на конкретной системе. Через какой порт хотя бы. Может быть консоль на ethernet'е вообще висит))) Однако, если макрос configASSERT не определён, то работает макрос по-умолчанию, который просто стопорит систему. Тогда нужно остановиться отладчиком, и посмотреть, где зависло. Так я про то и говорю - отладчиком глянуть не мешало бы... Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
amaora 20 13 апреля, 2019 Опубликовано 13 апреля, 2019 (изменено) · Жалоба Да, согласен, посмотреть стек повисшей задачи интересно. Но пока с этим есть проблемы, отладчик отказывается работать с имеющимся экземпляром устройства. Есть еще трудности с тем чтобы безопасно остановить всю систему (просто так сделать break нельзя), но они преодолимы. Сейчас известно что: 1) Задача которая интенсивно вызывает putc() и переполняет очередь, иногда повисает на вызове xQueueSendToBack; 2) Прерывание USART с приоритетом ниже configMAX_SYSCALL_INTERRUPT_PRIORITY после этого не вызывается; 3) Прерывание ADC с приоритетом выше configMAX_SYSCALL_INTERRUPT_PRIORITY работает независимо от этого происшествия; 4) Работают ли другие задачи после этого не знаю, не проверял; 5) Проявляется только с -O3 -flto; 6) В коде FreeRTOS v9.0.0 есть правки, выше говорил какие; 7) Обновление на v10.2.0 приводит к исчезновению проблемы (при аналогичных правках); 8) configASSERT задан и выводит сообщение в тот же USART только более примитивным методом с ожиданием в цикле; 9) Обработчики исключений тоже заданы, когда я в них попадал это было видно; Кстати, мне не очень понятно, почему сборку с LTO не исправляют в новых версиях. Почему я сам это все правлю. Увидел вот там одно изменение в port.c, @@ -388,7 +381,10 @@ /* Should never get here as the tasks will now be executing! Call the task exit error function to prevent compiler warnings about a static function not being called in the case that the application writer overrides this - functionality by defining configTASK_RETURN_ADDRESS. */ + functionality by defining configTASK_RETURN_ADDRESS. Call + vTaskSwitchContext() so link time optimisation does not remove the + symbol. */ + vTaskSwitchContext(); prvTaskExitError(); Но это не помогает, и я вынужден добавлять __attribute__ (( used )). И другие проблемы есть, из-за которых я правлю асм-вставки. Изменено 13 апреля, 2019 пользователем amaora Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
x893 35 13 апреля, 2019 Опубликовано 13 апреля, 2019 · Жалоба А для вывода использовать RTT, который в 100500 раз быстрее USART Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
haker_fox 60 13 апреля, 2019 Опубликовано 13 апреля, 2019 · Жалоба 15 minutes ago, amaora said: Прерывание USART с приоритетом ниже configMAX_SYSCALL_INTERRUPT_PRIORITY после этого не вызывается; Все обработчики, использующие сервисы ОС должны иметь приоритет выше или равный configMAX_SYSCALL_INTERRUPT_PRIORITY. При обращении к сервисам они используют функции, оканчивающиеся на FromISR. Те обработчики, которые не используют сервисы ОС, могут иметь любые приоритеты. Я надеюсь у вас так?))) 18 minutes ago, amaora said: Обработчики исключений тоже заданы, когда я в них попадал это было видно; Ну тогда нужно только отладчик каким-то образом дружить с вашей системой. А стеки у вас достаточной глубины? Может быть увеличить принудительно раза в два... Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
amaora 20 13 апреля, 2019 Опубликовано 13 апреля, 2019 · Жалоба 3 hours ago, haker_fox said: А что в ней есть ненужное? Многие сервисы ОС отключаются легально с помощь FreeRTOSConfig.h. Если оно вынесено в отдельные файлы и не нужно, то удаляю весь файл (croutine, event_groups, deprecated_definitions, message_buffer, mpu_prototypes, stream_buffer, timers). Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
haker_fox 60 13 апреля, 2019 Опубликовано 13 апреля, 2019 · Жалоба Just now, amaora said: Если оно вынесено в отдельные файлы и не нужно, то удаляю весь файл Ну так-то можно, конечно. Я и сам не включаю в компиляции то, что не используется. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
amaora 20 13 апреля, 2019 Опубликовано 13 апреля, 2019 (изменено) · Жалоба 9 minutes ago, haker_fox said: Все обработчики, использующие сервисы ОС должны иметь приоритет выше или равный configMAX_SYSCALL_INTERRUPT_PRIORITY. При обращении к сервисам они используют функции, оканчивающиеся на FromISR. Те обработчики, которые не используют сервисы ОС, могут иметь любые приоритеты. Я надеюсь у вас так?))) Ну тогда нужно только отладчик каким-то образом дружить с вашей системой. А стеки у вас достаточной глубины? Может быть увеличить принудительно раза в два... Да так, только с выше-ниже путаница. Другие задачи сейчас обходятся одним vTakDelay() из всех сервисов ОС (ой нет забыл, есть мьютексы). В "быстрых" прерываниях которые более приоритетны чем вся ОС со всеми задачами, никаких функций ОС не вызывается, обмен только wait-free / lock-free методами. На стеке свободного места много, особенно у той задачи, используется ~100 байт из 512. Изменено 13 апреля, 2019 пользователем amaora Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Neo_Matrix 0 13 апреля, 2019 Опубликовано 13 апреля, 2019 (изменено) · Жалоба 5 часов назад, amaora сказал: Правки это например убрал include string.h и заменил на свои объявления mem* функций. Удалил файлы croutine, timers, и другие что не планирую использовать никогда. Добавил аттрибут used одной функции и одной переменной. Исправил инлайн асм вставки в port.c, заменив загрузку адреса через ldr на две movw/movt. Последнюю часть делал из необходимости а не по желанию, лучшего решения не нашел. В остальном стараюсь ничего не править. А не так, чтобы решил убрать вот здесь критическую сеецию для ускорения. И да, действительно есть опасения, что проблема скрылась и может проявиться когда-то снова. Ведь причину я не понял. Не вижу смысла удалять неиспользуемые функции, все что не используется нормально выпиливается встроенными макросами ОСи. Относительно атрибута used для LTO есть более правильное решение с точки зрения "красивости кода" оно описано в тикете под номером 90. А вот изменяя файлы порта есть большой шанс что то сломать. 5 часов назад, amaora сказал: Нет, в них не попадаем. Там есть обработчик, я бы узнал об этом. Если используется Кеил, у него многоие обработчики прерывания описаны в стартап файле, и если вы попадете в один из них отладчик не может показать где он сейчас находится(по крайней мере джетлинк). Допустим такой: BusFault_Handler\ PROC EXPORT BusFault_Handler [WEAK] B . ENDP ПС: Перед написанием комментария не обновил страницу.... Потому несколько устаревший Изменено 13 апреля, 2019 пользователем Neo_Matrix Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться