SimpleSoft
-
Постов
316 -
Зарегистрирован
-
Посещение
-
Победитель дней
2
Сообщения, опубликованные SimpleSoft
-
-
30 minutes ago, haker_fox said:
Это нормально. Однако лучше держать её включенной.
Спасибо за информацию. Я так понимаю для Release лучше выключить?
-
Опубликовано · Изменено пользователем SimpleSoft · Пожаловаться
Да, действительно ловушка не была включена. Однако при её включении ситуация не поменялась.
Попробовал configCHECK_FOR_STACK_OVERFLOW с опциями 1 и 2.
FaultAnalyzer все еще ссылается на list.c файл - в тоже место.
Stack вызовов выглядит так:
Ветку в принципе можно закрывать.
Единственное что меня смущает - так это код 1-в-1 кроме FreeRTOS portable исходников, и такое поведение. Я списываю пока это на разные компиляторы ARM IAR vs GCC ARM.
-
Проблему решили.
const osThreadAttr_t defaultTask_attributes = { .name = "defaultTask", .priority = (osPriority_t) osPriorityNormal, .stack_size = 128 };
значение .stack_size увеличили в 2 раза - поток стал работать без сбоев
- 1
-
Опубликовано · Изменено пользователем SimpleSoft · Пожаловаться
Спасибо за советы.
1 hour ago, esaulenka said:Блин. Ну что сложного-то?
Ничего сложного.
Я не хочу возиться с чужим кодом и всего.
Если кто-то сталкивался с подобной пробемой и может поделится решением - я буду благодарен.
Иначе будем с разработчиками искать.
Пс: я смотрю не особо народ в восторге от Куба ;)
-
9 hours ago, esaulenka said:
Осталось дело за малым: выяснить, какое значение pxItemToRemove и откуда оно там взялось.
Я предполагал что возможно кто-то уже сталкивался. Не хотелось бы копаться в "свежем" коде который сгенерирован CubeMX.
Если я генерирую в IAR ARM -> код работает нормально.
Разница только в 2х файлах:
Middlewares\Third_Party\FreeRTOS\Source\portable\GCC\ARM_CM4F\port.c и portmacro.h
- 1
-
Опубликовано · Изменено пользователем SimpleSoft · Пожаловаться
Добрый день.
Свежий проект, cгенерированныйв CubeMX и собранный с помощью STM32CubeIDE падает в HardFault:
размер стека в Linker script:
_Min_Heap_Size = 0x2400 ; /* required amount of heap */ _Min_Stack_Size = 0x2800 ; /* required amount of stack */
место на котором срабатывает HardFault в list.c:
UBaseType_t uxListRemove( ListItem_t * const pxItemToRemove ) { /* The list item knows which list it is in. Obtain the list from the list item. */ List_t * const pxList = ( List_t * ) pxItemToRemove->pvContainer; /// <--- Hardfault pxItemToRemove->pxNext->pxPrevious = pxItemToRemove->pxPrevious; pxItemToRemove->pxPrevious->pxNext = pxItemToRemove->pxNext;
Может кто-то сталкивался с подобным?
MCU: STM32H743XIH
STM32CubeMX Ver 5.3.0
STM32CubeIDE Version: 1.0.2FreeRTOS таймер - TIM6.
-
SP1 стоит.
-
Заработал IAR ARM 8.40.1 только на Win 10 x64.
На Win7 x64 - не работает. И дело не в лицензии - наработает версия даже без патча.
-
Попробовал убить переменную PATH (и системную и пользовательскую) - не помогло.
-
На машине с Windows 10 запустился и работает без проблем.
@Xenia спасибо за информацию. Однако 8.40.1 пропатчил и запустил - пока работает. Как проявляется проблема?
-
Опубликовано · Изменено пользователем SimpleSoft · Пожаловаться
Программа вылетает с исключением STATUS_STACK_BUFFER_OVERRUN .
Место вылета точно не определил (не хочу копать глубоко), но однозначно в IdeFramework.dll
Прилагать дизассемблированный код нельзя - запрещено пользовательским соглашением.
-
-
Опубликовано · Изменено пользователем SimpleSoft · Пожаловаться
Спасибо за ответы.
Версия IAR ARM 8.40.1 свежая, без патчей.
Дамп
QuoteEventData 2154759513 421261876 BEX Нет данных 0 IarIdePm.exe 8.3.2.5988 5ce48f11 IdeFramework.dll 8.3.2.5988 5ce48d60 000b5dc2 c0000409 00000000 -
Добрый день.
Всегда пользовались версией 7.х но из-за STM32H7xx семейства пришлось переехать на IAR ARM 8.х.
При запуске IAR ARM 8.x (любого) - "падает" при запуске (Вылетает с диалоговым окном "Прекращена работа программы IAR Embedded Workbench IDE").
ОС Windows 7 Ultra, SP1 x64.
Подскажите, может кто-то решал такую проблему?
Может где-то есть Log запуска (чтобы посмотреть что случилось)?
-
У Microchip и подобного нет. 2 года назад использовали ATSAMV70Q20 (Automotive). После STM32 это был неприятный опыт - мы потратили около полугода на вылизывание BSP и валидацию минимального набора драйверов (правда с использованием V-model процесса).
Наверное самый лучший и качественный BSP для NXP S32K микроконтроллеров, где драйвера уже написаны по MISRA C правилам.
Параллельно делали проект на STM32F7 - Там было гораздо меньше косяков и почти сразу стали давать релизы заказчику для полевых испытаний.
-
On 7/4/2019 at 2:47 PM, ilya.solomkin said:
Смогли запустить плату только после того как вышли на одного из разработчиков прошивки, который подправил ее под работу с одним контроллером памяти, исходников так и не дали, только бинари.
Спасибо большое за информацию. Это все что нужно знать о SW для Rockchip.
-
Возможно банальный непропай. Переключите в режим GPIO (под JTAG) - попробуйте подёргать ногой и проверьте осциллографом.
-
13 hours ago, new123 said:
Вот еще вариант, если погуглить, внизу раздел Kernel configuration
https://xilinx-wiki.atlassian.net/wiki/spaces/A/pages/18842339/SATA
Я думаю это правильный вариант. Там есть Devicetree пример
-
День добрый.
Может кто-то имел опыт программирования на языке Halide для DSP (Qualcomm Hexagon). Я посмотрел примеры на языке Halide - но этого явно мало. Нашим разработчикам нужно написать алгоритмы (свертка, фильтрация) и интересно знать с чего лучше начинать.
Если кто-то имел опыт работы с DSP - поделитесь, пожалуйста, идеями.
Спасибо!
-
Опубликовано · Изменено пользователем SimpleSoft · Пожаловаться
Время идёт и доработали нашу систему тестирования, моделями QEMU - особенно хорошо для Xilinx Zynq7000 & ZynqMP.
Также симуляторы иногда выручают - например Cadence Vision P6 DSP имеет неплохой симулятор.
Также ARM Fast models могут быть альтернативой.
-
Вышел наконец 64-битный ARM у TI
-
Спасибо!
Про голову, это конечно замечательно:)
Но я хочу спросить за конкретику. Может кто-то знает хорошие техники из опыта?
Я понимаю, что нужно соблюдать баланс между стоимостью решения для тестирования/отладки без железа и производства реальных образцов. Однако время простоя тоже денег стоит.
-
Этом не просто хороший, это отличный вопрос, в нём содержится 100% ответа.
Я скорее имел ввиду - возможно кто-то знает техники, как это сделать малой кровью.
-
С Новым, уже 2018 годом. Всех благ!
Добавлю еще от себя.
Мы попробовали двинуться дальше в области качества ПО.
Приобрели LDRA пакет вместе с TBManager, TBrun, LDRAcover, LDRAunit.
Данный пакет умеет увязывать требования написанные в Word или из JIRA/Polarion с кодом. А также запускать тесты прямо на железе используя JTAG.
Более подробно - презентация.
Возник попутно вопрос - а что вы используете для отладки кода, когда ещё железо не готово?
Отладки спаянные воедино? Может есть софтовые эмуляторы? (как например QEMU) или что-то иное? (Особенно если 60% кода копируется из проекта-в-проект, меняется только приложение)
К примеру: есть проект на FreeRTOS который конвертирует аналоговые входы используя алгоритмы в цифру и гонит по Ethernet по спец протоколам. Нужно сделать ещё пару приложений, которые основу имеют туже, но кол-во аналоговых входов другое, уровни другие, выхлодной протокол другой - но железо не готово. Как разрабатывать софт параллельно максимально абстрагируя софт от железа пока оно не готово?
Какие при этом риски?
STM32CubeIDE: Сгенерированный FreeRTOS проект в Cube падает в HardFault
в STM
Опубликовано · Изменено пользователем SimpleSoft · Пожаловаться
Подскажите, как вы делаете подготовку к релизу? Есть ли unit test'ы? Код ревью? Функциональное тестирование? Тесты на стабильность?