Перейти к содержанию
    

SimpleSoft

Участник
  • Постов

    316
  • Зарегистрирован

  • Посещение

  • Победитель дней

    2

Сообщения, опубликованные SimpleSoft


  1. Да, действительно ловушка не была включена. Однако при её включении ситуация не поменялась.

    Попробовал configCHECK_FOR_STACK_OVERFLOW с опциями 1 и 2.

    FaultAnalyzer все еще ссылается на list.c файл - в тоже место.

    Stack вызовов выглядит так:

    image.png.8d1f9b4405ea19c15fc9d50e1491d405.png

    Ветку в принципе можно закрывать.

    Единственное что меня смущает - так это код 1-в-1 кроме FreeRTOS portable исходников, и такое поведение. Я списываю пока это на разные компиляторы ARM IAR vs GCC ARM.

  2. Спасибо за советы. 

    1 hour ago, esaulenka said:

    Блин. Ну что сложного-то?

    Ничего сложного. 

    Я не хочу возиться с чужим кодом и всего.

    Если кто-то сталкивался с подобной пробемой и может поделится решением - я буду благодарен.

    Иначе будем с разработчиками искать. 

    Пс: я смотрю не особо народ в восторге от Куба ;) 

  3. 9 hours ago, esaulenka said:

    Осталось дело за малым: выяснить, какое значение pxItemToRemove и откуда оно там взялось.

    Я предполагал что возможно кто-то уже сталкивался.  Не хотелось бы копаться в "свежем" коде который сгенерирован CubeMX.

    Если я генерирую в IAR ARM -> код работает нормально.

    Разница только в 2х файлах:

    Middlewares\Third_Party\FreeRTOS\Source\portable\GCC\ARM_CM4F\port.c и portmacro.h

    • Upvote 1
  4. Добрый день.

    Свежий проект, cгенерированныйв CubeMX и собранный с помощью STM32CubeIDE падает в HardFault:

    image.png.2329db47755f7c9d4d584c7c0ab2ea91.png

    размер стека в 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.2

    FreeRTOS таймер - TIM6.

  5.  

    Программа вылетает с исключением STATUS_STACK_BUFFER_OVERRUN .

    Место вылета точно не определил (не хочу копать глубоко), но однозначно в IdeFramework.dll

    Прилагать дизассемблированный код нельзя - запрещено пользовательским соглашением.

  6. Спасибо за ответы.

    Версия IAR ARM 8.40.1 свежая, без патчей. 

     

    Дамп

    Quote
    EventData
          2154759513
          421261876
          BEX
          Нет данных
          0
          IarIdePm.exe
          8.3.2.5988
          5ce48f11
          IdeFramework.dll
          8.3.2.5988
          5ce48d60
          000b5dc2
          c0000409
          00000000

     

  7. Добрый день.

    Всегда пользовались версией 7.х но из-за STM32H7xx семейства пришлось переехать на IAR ARM 8.х.

    При запуске IAR ARM 8.x (любого) - "падает" при запуске (Вылетает с диалоговым окном "Прекращена работа программы IAR Embedded Workbench IDE").

    ОС Windows 7 Ultra, SP1 x64.

    Подскажите, может кто-то решал такую проблему?

    Может где-то есть Log запуска (чтобы посмотреть что случилось)?

  8. У Microchip и подобного нет. 2 года назад использовали ATSAMV70Q20 (Automotive). После STM32 это был неприятный опыт - мы потратили около полугода на вылизывание BSP и валидацию минимального набора драйверов (правда с использованием V-model процесса).

    Наверное самый лучший и качественный BSP для NXP S32K микроконтроллеров, где драйвера уже написаны по MISRA C правилам.

    Параллельно делали проект на STM32F7 - Там было гораздо меньше косяков и почти сразу стали давать релизы заказчику для полевых испытаний.

  9. On 7/4/2019 at 2:47 PM, ilya.solomkin said:

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

    Спасибо большое за информацию. Это все что нужно знать о SW для Rockchip.

  10. 13 hours ago, new123 said:

    Вот еще вариант, если погуглить, внизу раздел Kernel configuration

    https://xilinx-wiki.atlassian.net/wiki/spaces/A/pages/18842339/SATA

    Я думаю это правильный вариант. Там есть Devicetree пример

  11. День добрый.

    Может кто-то имел опыт программирования на языке Halide для DSP (Qualcomm Hexagon). Я посмотрел примеры на языке Halide - но этого явно мало. Нашим разработчикам нужно написать алгоритмы (свертка, фильтрация) и интересно знать с чего лучше начинать.

    Если кто-то имел опыт работы с DSP - поделитесь, пожалуйста, идеями.

    Спасибо!

  12. Время идёт и доработали нашу систему тестирования, моделями QEMU - особенно хорошо для Xilinx Zynq7000 & ZynqMP.

    Также симуляторы иногда выручают - например Cadence Vision P6 DSP имеет неплохой симулятор.

    Также ARM Fast models могут быть альтернативой.

  13. Спасибо!

    Про голову, это конечно замечательно:)

    Но я хочу спросить за конкретику. Может кто-то знает хорошие техники из опыта?

    Я понимаю, что нужно соблюдать баланс между стоимостью решения для тестирования/отладки без железа и производства реальных образцов. Однако время простоя тоже денег стоит.

  14. Этом не просто хороший, это отличный вопрос, в нём содержится 100% ответа.

     

    Я скорее имел ввиду - возможно кто-то знает техники, как это сделать малой кровью.

  15. С Новым, уже 2018 годом. Всех благ!

    Добавлю еще от себя.

     

    Мы попробовали двинуться дальше в области качества ПО.

    Приобрели LDRA пакет вместе с TBManager, TBrun, LDRAcover, LDRAunit.

    Данный пакет умеет увязывать требования написанные в Word или из JIRA/Polarion с кодом. А также запускать тесты прямо на железе используя JTAG.

    Более подробно - презентация.

     

    Возник попутно вопрос - а что вы используете для отладки кода, когда ещё железо не готово?

    Отладки спаянные воедино? Может есть софтовые эмуляторы? (как например QEMU) или что-то иное? (Особенно если 60% кода копируется из проекта-в-проект, меняется только приложение)

    К примеру: есть проект на FreeRTOS который конвертирует аналоговые входы используя алгоритмы в цифру и гонит по Ethernet по спец протоколам. Нужно сделать ещё пару приложений, которые основу имеют туже, но кол-во аналоговых входов другое, уровни другие, выхлодной протокол другой - но железо не готово. Как разрабатывать софт параллельно максимально абстрагируя софт от железа пока оно не готово?

    Какие при этом риски?

×
×
  • Создать...