Комментарии 35
Контроллер FC4150F2MBS1P144T1A
Кто говорит, что у STM нейминги ужасные, еще не видел этого.
Нейминги ужасные, но я очень много наблюдаю в отечественном оборудовании TMS320. Не знаю про нейминги, но знакомые разработчики говорят, что писать под него это просто адъ. А ведь вроде хороший контроллер для реалтайм задач типа управления частотниками и прочим.
Микросхемы, которые применяются в автомобилях, должны соответствовать квалификации AEC-Q100
Вообще то это не обязательное требование, а рекомендованное.
строго рекомендованное
http://www.aecouncil.com/
Тут пруфы.
Строго говоря, ещё нет на рынке всех микросхем таких, так что много сложных устройств не возможно создать с всеми микросхемами этой квалификации
Может и добровольное, вот только, если с климатикой найти компоненты можно из индустриального грейда, то с надёжностью могут возникнуть сложности. Обычно на не AEC компоненты никто не считает отказы, соответственно никакого Reliability Report. Остаётся только по справочникам считать.
В не Safety Related устройствах применение возможно. В Safety Related - с большой осторожностью и расчётами.
Ну тогда давайте на все компоненты смотреть. Как обеспечит безопасность контроллер, если у него в обвязке отказали другие компоненты?
спецификациях AEC-Q100 (для микросхем IC), AEC-Q101 (для дискретных компонентов), AEC-Q102(Дискретная оптоэлектроника), AEC-Q104(Мультичиповый модуль) и AEC-Q200 (для пассивных компонентов)
Безопасность обеспечивается не AEC
Выполняется FTA, по которому определяются критичные компоненты и оценивается надёжность Safety Related функций. Если в результате надёжность соответствует требованиям, то всё ОК.
Также используются различные Safety Mechanisms. Например, в микроконтроллере используется CCS, обеспечивающая переключение на внутренний генератор с формированием сообщения об ошибке при отсутствии/изменении параметров тактового сигнала. Плюс практически всегда используется Watchdog, переводящий исполнительные устройства в Safety State. Также работает Fault пин, который устанавливается при детектировании микроконтроллером ошибки в BIST или работе.
Каждый Safety Goal разбирается индивидуально.
Заключение: мы доверяем надежности контроллеров Flagchip на основе мигания диода?
Мы доверяем на основании заложенных Safety Mechanisms, соответствия ISO26262, сертификатов и здравого смысла.
Изучение сертификатов и Safety Manual было нами выполнено на этапе, предшествующем заказу отладочных плат. Другое дело SDK, который до получения платы был определённым "котом в мешке".
Мигание диодов - это простой пример, демонстрирующий сборку и запуск кода на этой платформе. Пока это первая статья, которая, если будет интерес, может превратиться в цикл: можем рассказать про использование модуля EIM (Error Injection Module), с помощью которого можно инжектировать ошибки, про софтовые Safety Mechanisms, решающие определённые задачи.
Я тоже почитал бы про более реальные сценарии. Как обрабатываются отказы безопасно? Пусть даже это будет описано псевдокодом или блок-схемами.
В SDK встречаются ошибки, связанные с регистром в именовании файлов, что намекает на использование авторами Windows.
После такого верить заключению "Flagchip производит безопасные микроконтроллеры" не получается.
да, мне заключение тоже понравилось
В данном случае речь идет про микроконтроллеры. Первое о чем спросит заказчик соответствует ли чип AEC-Q100 или нет.
Из моего опыта заказчику без разницы что стоит внутри, его интересует проходит ли сертификацию по автомобильным гостам или iso данное изделие.
Согласен частично, если это блок не отвечающий за безопасность, но в случае с уровнем выше хотя бы ASIL-A, очень сомнительно, что заказчику будет все равно
Заказчику может стать резко не "без разницы", если отказ устройств будет носить систематический характер и приводить к тяжёлым последствиям.
Можно вспомнить ситуацию с электроусилителем или электронной педалью газа. Или вот отзыв Боингов 737 Max.
И проблемы у боингов были явно не с контроллером ... В 99 случаях из 100 проблемы с софтом или связью с внешними устройствами ( разъёмы, пайка етс)
В том смысле,что то слово "безопасные" скорее вводит в заблуждение, они все "опасные" . :)
Проблема была в подходе к проектированию и игнорирование требований безопасности при разработке
https://habr.com/ru/companies/first/articles/754008/
https://en.wikipedia.org/wiki/Maneuvering_Characteristics_Augmentation_System
Добрый день! Немного работала с fc7300. Собирала проект в eclipse. У меня, правда, проект сложнее мигания светодиодом. Столкнулась с тем, что при оптимизации более O1 чип перестает адекватно работать. А как у вас? Вы пробовали оптимизировать и запускать код?
Добрый день! Elcipse - это FC_IDE и его генерируемые Makefile'ы? Тогда там под капотом там gcc. Интересно конкретику - какой именно чип, на каких ядрах запускаете код? Код в SRAM или Flash? В чём выражается неадекватность исполнения?
Немного занудства, не пробовали через gdb подключиться и поотлаживать?
7300 - очень интересный чип, но, по нашей информации, только находящийся в процессе сертификации.
Я собираю с оптимизацией -Os, сейчас запущен RTOS, под которым исполняется код, взаимодействующий с различной периферией. Пока всё работает как задумано. Но 4150 существенно отличается от 7300. Если не получится победить, могу свой проект запустить на 7300 на одном ядре.
Я проводила тестирование производительности ядра Coremark - это портируемый код, нагружающий ядро кучей вычислений и по времени выполнения выносящий суждение о быстродействии и отправляющий результат в uart.
Тестирование производилось именно на отладочной плате для FC7300 (если я правильно помню FC7300F8MD, остальные буковки-циферки смогу посмотреть в понедельник). Собирался проект из исходников Coremark+sdk Flagchip в eclipse общего назначения, так сказать (не FC IDE).
Запускала на core0 ( другие ядра или работали и просто мигали светодиодами или я их не включала), код во flash. При оптимизации O0, O1, Os, Og код работал адекватно. При оптимизации O2, O3, Ofast нет. Выражалось это в уходе контроллера в hard fault. Пыталась, конечно, отлаживать дебаггером пошагово, но там настолько замудренные вычисления, что найти причину не удалось. И сложилось впечатление, что пошагово если отлаживать, то вылетал контроллер в разное время. Плюс параллельно коллега портировал тоже на этот контроллер наш самописный шедьюлер и у него тоже с оптимизацией не работало. Поэтому решили приостановить выяснение причин.
Можно вас попросить проверить, ваш проект заработает на 7300 на любой из O2, O3, Ofast оптимизациях? Хотелось бы понять, это общая проблема или нам так не повезло то ли с платами, то ли с чипами, то ли с sdk.
У нас по плану использование MCAL драйверов с AUTOSAR шедулером и сборкой Greenhill. SDK + gcc - ранний оценочный этап разработки.
Если у вас такая же Demo Board, то, скорее всего, там тоже FC7300F8MDT2A320T1A. Насколько мне известно, там только одна ревизия борды на FC7300 с одним MCU.
Там именно Hard Fault? И ещё один очевидный вопрос - как была запитана плата? Питание MCU 3.3в или 5в?
Можете написать версию gcc, версию sdk и флаги сборки? В понедельник проверю на 7300 с разными вариантами оптимизациями. Но наш код слабо нагружает ядро, много обмена с внешними устройствами с использованием DMA. При отсутствии проблем, попробую собрать Coremark и проверить на нём. Если есть проблема со стабильностью MCU, хотелось бы выяснить подробности до запуска в производство. При наличии проблемы с MCU, можно переадресовать вопрос флагчипу, но надо конкретизировать проблему.
Посмотрела на плате, да, чип FC7300F8MDT2A320T1A
Я отлаживаюсь в ozone (таковы были рекомендации от коллег). Там нестабильность проявляется так. Запускаю код на выполнение ( без точек останова) и он типа выполняется (но до посылки результатов в uart явно не доходит), нажимаю паузу, выскакивает окошко сообщающее, что возник именно Hard Fault （но я ему не на 100% доверяю). Окошко это можно закрыть и увидеть, что код висит в DefaultISR, в которую (если я правильно понимаю дизассемблер) он попал из FTU2_IRQHandler. FTU2 у меня в коде не используется и не инициализируется.
Питание пробовала и 3.3 и 5В. Результат один.
sdk: 0.2.0
Сборка (на всякий случай все привожу):
xpack-arm-none-eabi-gcc-10.3.1-2.3
arm-none-eabi-gcc -mcpu=cortex-m7 -mthumb -mfloat-abi=hard -mfpu=fpv4-sp-d16 -O2 -fmessage-length=0 -fsigned-char -ffunction-sections -fdata-sections -g3 -I"C:\DATA\eclipse_projects\FC7300_CoreMark\project\dev" -
..."
-std=gnu11 -std=c99 -MMD -MP -MF"CoreMark/Src/core_main.d" -MT"CoreMark/Src/core_main.o" -c -o "CoreMark/Src/core_main.o" "../CoreMark/Src/core_main.c"
Invoking: GNU Arm Cross C Linker
arm-none-eabi-gcc -mcpu=cortex-m7 -mthumb -mfloat-abi=hard -mfpu=fpv4-sp-d16 -O2 -fmessage-length=0 -fsigned-char -ffunction-sections -fdata-sections -g3 -T "C:\DATA\eclipse_projects\FC7300_CoreMark\project\Startup\FC7300_flash.ld" -Xlinker --gc-sections -Wl,-Map,"FC7300_CoreMark.map" --specs=nano.specs --specs=nosys.specs -o "FC7300_CoreMark.elf"
Прошу прощения за долгий ответ. По результатам запуска Coremark на Flagchip. На FC4150 выполняется успешно с любым уровнем оптимизации, тестировали несколько суток. Для работы FPU надо включить руками.
На FC7300 также выполняется успешно, но -mfloat-abi=hard -mfpu=fpv5-sp-d16 . И вызвать FPU_Enable(), пример можно посмотреть в Fpu_Dsp_Example.
По поводу проблем с оптимизацией O2 и выше на хабре была статья https://habr.com/ru/companies/embox/articles/418295/
/**
* @brief Enable the FPU hardware.
*
* Usually, driver user only need use this API at the beginning of program. Nothing else about FPU need to be done.
* @details @verbatim
If only want use FPU,
1) configure FCIDE to enable FPU compiler support, "Properties" -> C/C++ Build -> Settings -> Tool Settings -> Target Processor -> Float ABI -> FP instructions(hard) -> FPU Type set to "fpv5-sp-d16"
2) configure FCIDE to enable FPU compiler support, "Properties" -> C/C++ Build -> Settings -> Tool Settings -> GNU Arm Cross C Compiler -> Preprocessor -> Defined symbols(-D) -> Add "__FPU_PRESENT=1" (without ")
3) and call FPU_Enable to enable FPU at the beginning of program.
На платах на фото видны примерно по сотне дискретных (и не очень) элементов обвязки и прочие разъёмы. Как решается вопрос с отказами среди них ?
Ещё интересен вопрос насчёт радиационной стойкости. Значительное увеличение объёмов памяти, уменьшение технологических норм (тут, правда, может быть как минус так и плюс в зависимости от), многослойные чипы и прочая 3D-упаковка, а также существенный рост просто количества электроники в одной единице техники должны заметно повышать вероятность всяких single event сотоварищи. На эту тему есть какие-то шевеления ?
На плате используются компоненты с автомобильным грейдом, больше никаких особенностей не видно. Производитель использует высоконадёжные дискретные элементы, прошедшие термотренировку и имеющие гарантированный FIT. Я не считал FIT для обвязки процессора, кмк, Demo Board не соответствует уровню ASIL-B (как минимум по покрытию обнаружения SPF/LPF). Но она будет использоваться только для разработки софта на столе до этапа готовности своего железа.
Информации о техпроцессах чипов у меня нет, рискну предполагаю, что там обычный техпроцесс без всяких КНИ. Но для исполнения могут использоваться ядра, работающие в режиме Lockstep. По сути, это 2 ядра, выполняющие одинаковые инструкции на одинаковых данных. При возникновении отличия в результате, процессор может быть переведён в Safety State. Также все критичные регистры "затроированны" (имеют 3 копии). Память и шина используют ECC SECDED (Single Error Correction Double Error Detection). Всё это увеличивает надёжность выполнения (как минимум вероятность обнаружить ошибку при её возникновении).
А где ж всё это можно купить? Ни самих контроллеров, ни отладочных не наблюдается. И даже даташит на официальном сайте нельзя скачать :-(
Честно говоря, когда сами узнали про эту компанию и чипы, тоже было непонятно где такое взять. Вышли напрямую на производителя, объяснили нашу задачу, объемы, для чего делаем, получили согласие на покупку как девкитов на двух мк разного уровня ASIL, так и на получение сэмплов. После этого заказали уже. Документацию тоже техподдержка предоставляет.
Поставщика им в России официального не хватает это точно. Но у них нет каких либо проблем работы с нами.
Обзор безопасных микроконтроллеров Flagchip для автомобильной электроники