Комментарии 80
Контроллер FC4150F2MBS1P144T1A
Кто говорит, что у STM нейминги ужасные, еще не видел этого.
Что значит акроним SIP Flash в прямоугольнике Memory Type?
Конкретной информации нет, судя по доступными комбинациями, чипы FC4150SF и не выпускались. В документации достаточно большое количество неточностей и очепяток, например, банально нет 2М чипа, из даташита на который табличка и скопирована. Я бы предположил, что в данном случае производитель задумывался над вариантом выпуска микроконтроллеров с SiP Flash, подключенной, например, к OSPI интерфейсу. Хотя обычно используется аббревиатура SiP, TI, например, вполне использует SIP в документации.
Нейминги ужасные, но я очень много наблюдаю в отечественном оборудовании 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.
При оптимизации O2, O3, Ofast нет.
Зачем Вам, Мария, эта оптимизация?
SoC и так мощный и памяти в нем много.
При оптимизации O0, O1, Os, Og код работал адекватно. При оптимизации O2, O3, Ofast нет. Выражалось это в уходе контроллера в hard fault.
"Преждевременная оптимизация — корень всех зол."
( Donald Knuth)
На платах на фото видны примерно по сотне дискретных (и не очень) элементов обвязки и прочие разъёмы. Как решается вопрос с отказами среди них ?
Ещё интересен вопрос насчёт радиационной стойкости. Значительное увеличение объёмов памяти, уменьшение технологических норм (тут, правда, может быть как минус так и плюс в зависимости от), многослойные чипы и прочая 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, так и на получение сэмплов. После этого заказали уже. Документацию тоже техподдержка предоставляет.
Поставщика им в России официального не хватает это точно. Но у них нет каких либо проблем работы с нами.
Типовое распределение требований к уровню ASIL для отдельных автомобильных систем
Красивая картинка. Однако там нет многих приборов.
Какой ASIL должен быть у телематики, блоков eCall или аудиосистемы?
Ведь при ошибке в программе телематика может через спикеры во время езды оглушительным звуком контузить всех пассажиров до потери сознания.
Картинка приведена исключительно для примера. По ISO 26262 требования ASIL обозначаются к конкретным функциям и на этапе TSC (Technical Safety Concept) транслируются на конкретные аппаратные требования. Грубо говоря, конкретный блок, выполняющий функции с уровнем ASIL-A/B/C/D должен соответствовать этим требованиям в необходимом объеме. Например, в блоке может использоваться SOC, включающий в себя как ядра, на которых исполняется Android/Linux/etc с функциями ASIL-QM, так и так называемый Safety Domain, обеспечивающий выполнение функций с уровнем ASIL-A/B/C/D.
Требования определяются в результате HARA анализа, при котором для каждого отказа определяется уровень ASIL.
Разберём случай, когда аудиосистема превращается в LRAD.
Пусть Severity (серьёзность) = S3 (Максимальная, так как выше было указано, что все контужены, предположим, что высока вероятность аварии).
Probability of Exposure (вероятность наблюдения) = E1 (минимальная, так как про такие случаи в настоящий момент неизвестно, но может быть пересмотрено в будущем, если окажется, что это не так).
Controlability by driver (способность водителя справится) = С2 (средняя, предположим, что 90% водителей смогут нажать на тормоз). В таком случае требования к блокам ASIL-QM.
Если же мы заложим Controlability = C3, то требования - ASIL-A.
Вообще, предполагался цикл статей по ISO 26262, который когда-нибудь будет опубликован (никогда).
Есть ли возможность, пожалуйста, написать подробнее про процесс заливки hex прошивки в Flash память микроконтроллера семейства FC7300X?
Есть ли .bat скрипт или утилита от вендора, что даешь hex, нажимаешь enter и MCU прошивается по JTAG?
Чтобы без IDE (Keil, IAR и т п)
Сразу скажу, что в проекте использовали 4150. Для прошивки - кастомная сборку openocd. Типового cfg для CortexM4 с правильно прописанными ядрами и айдишниками уже достаточно для дебага.
Но флагчип использует свой алгоритм прошивки во флеш - основанный на вызове функций из ROM чипа, плюс есть ошибки в документации. По этой причине пришлось добавить в openocd алгоритм flagchip_flash для поддержки.
Как получить полный Datasheet (Reference Manual) и SDK на семейство MCU FC7300F8MDT, если на официальном сайте их так просто не скачать
https://www.flagchip.com.cn/en/Pro/3/3.html
и регистрации на сайте тоже не предлагают?
Что такое Flagchip FC7300_SDK_Vx_x_x\Template\MiddleWare\FlexCore ?
На что надо обратить внимание если надо для каждого ядра внутри FC7300x написать отдельную прошивку?
Да почти как всегда на много ядерных системах - обратить внимание на синхронизацию между ядрами и разделение доступа к ресурсами. В принципе, можно посмотреть реализацию демонстрационного кода Example/Mailbox в примерах от производителя.
Также есть некоторые нюансы запуска, пример независимого исполняемого кода на всех 3х ядрах показан в Example/MultiCore.
До синхронизации ядер еще добраться надо.
У меня вопрос стоит, как сделать три отдельные прошивки, где каждое ядром мигает своим отдельным LED-ом.
Для каждого ядра надо собирать отдельный elf файл, как у nrf5340?
Смотрю на пример
third_party\FC7300_SDK_Vx_x_x\Example\FC7300_Others\MultiCore_AMP_Demo
Я правильно понимаю, что при подаче электропитания сначала включается нулевое ядро и только после этого оно программно осуществляет пуск ядер №1 и №2?
Конфигурируется VTOR, который определяет адрес таблицы прерываний, в которой первые 2 вектора - адрес стека и адрес исполнения. Поэтому программы для каждого ядра собираются в единое адресное пространство по разным адресам, что при сборке gcc определяется линкер-скриптом, например, так
del
Мне удалось включить ядра 1 и 2.
Однако при попытке отключить или приостановить одно из ядер (например 1) получается так, что отключаются прерывания на нулевом ядре. (
Я правильно понимаю, что в многоядерном ARMе, когда у ядра Core2 вызываются прерывание, то локальные переменные этого прерывания размещаются в стековой памяти ядра Core2?
Или же для прерываний есть какой-то свой отдельный стек в RAM памяти?
Предлагаю обратиться к первоисточнику - сайту Arm, а конкретно к документации на ARMv7E-M. Многоядерность в данном случае не влияет на инициализацию каждого отдельного ядра.
Просмотрел все 338 упоминаний слова interrupt в доке ARM®v7-M Architecture Reference Manual.
Там нигде явно не прописана взаимосвязь прерываний и стека.
Читать Exception entry behavior и The ARM core registers
Как проверить, что конкретные номера прерываний включенные на Core2, если функции CMSIS NVIC_GetActive не имеют аргумента с именем номер ядра?
Предлагаю посмотреть в сторону функций SCM и его регистров, а именно SCM_INT_ROUTERn
Про качество поставляемого софта и реализации конкретных функций могу предложить обратиться к флагчипу. Впрочем, опыт подсказывает, что качество софта и уровень поддержки китайский вендоров часто оставляет желать лучшего.
Я заметил что
1--после активации каждого ядра надо выдержать паузу (я отлаживался с паузой в 1s). Если не делать паузу, то прошивка сваливается в исключение HardFault_Handler.
2--Также надо отметить, что только нулевое ядро (core0) может включать ядра core1 и core2. Если core0 включит core1, а core1 попытается включить core2 то core1 зависнет.
так и должно быть?
Смотреть отладчиком, что именно происходит, смотреть состояние в HF. Отлаживать, как любой другой HF на Cortex M7.
Когда тестировали 7300 и пробовали собирать свою софт под него, никаких аппаратных проблем замечено не было, в том числе с многоядерностью и мейлбоксами. Может быть, отличаются версии чипов, рекомендую посмотреть в errata.
По второму вопросу сказать ничего не могу - необходимости такого сценария не возникало. Рекомендую посмотреть состояние core1 при зависании и регистры. Если указанный функционал является критичным, то обратиться к производителю.
Вот портирую пример
FC7300_SDK_V2_3_2\Example\FC7300\Mailbox\LongMessage\Sources\mb.c
bAutoRelease = true
Режим с прерываниями:
И что-то этот Mailbox работает с глюками.
Посылаю массив Core0 ->Core1
Прерывания происходят, а Call Back не вызывается.
–При отправке Core1->Core0 происходит бесконечный вызов прерывания.
–Посылаешь на второе ядро, а принимает первое ядро.
–Прерывание срабатывает A callback не срабатывает.
–MailBox Done CallBack вообще ни разу не вызывался при отправке, даже если прописывать указатель на его в структуру для инициализации
Режим Polling-а
–При отправке 0>1 ядро 1 зависает после третьего успешного приема
–Отправляешь от первого ядра второму, а получает опять первое ядро, а иногда и нулевое. Случайным образом. Это как?
В примере MailBox от вендора настораживает, что у них в примерах SDK только один экземпляр структуры g_tMbHandle на оба ядра. Так и должно быть?
А если между тремя ядрами надо массивы гонять, то как изменится пример кода тоже не ясно.
можно посмотреть реализацию демонстрационного кода Example/Mailbox в примерах от производителя.
Зачем нужны эти MailBox-ы?
Почему нельзя просто взять и передать между ядрами последовательность байт через обыкновенный глобальный массив ?
Собственно, как на SPC58 Bernina
Где у FC7300F8MDT boot пины?
Он что всегда загружается только с адреса 0x0100_0000?
К сожалению, в связи с текущей геополитической ситуацией, популярные микроконтроллеры, удовлетворяющие требованиям ISO26262, стали практически недоступны. При этом отечественная микроэлектронная промышленность только набирает обороты в производстве безопасных автомобильных микроконтроллеров.
Существует еще один автомобильный микроконтроллер из КНР.
Называется YTM32B1ME05G0MLQ(ARM Cortex-M33) от компании YUN TU (Suzhou YTM Semiconductor Co Ltd).
Вот инструкция про то, как его программировать
Настройка ToolChain-нa для Разработки на Микроконтроллерах YTM32x
https://habr.com/ru/articles/875274/
В этом микроконтроллере установлено 3 ядра: два D-Core LS M7 и один B-Core M7 по терминологии Flagchip. D-Core LS - это как раз безопасные Lockstep ядра. B-Core - обычное M7
"Ядра — Чистый Изумруд".
кристалл в самом деле изумрудного цвета
Просто сегодня день рождения у А.С. Пушкина. Знаю про Пушкина так как каждый день дважды пересаживаюсь на станции метро Пушкинская.
В этом микроконтроллере установлено 3 ядра: два D-Core LS M7 и один B-Core M7 по терминологии Flagchip. D-Core LS - это как раз безопасные Lockstep ядра. B-Core - обычное M7
Раз внутри микроконтроллера FC7300F8MDT заложено три процессорных ядра ARM Cortex-M7, то следовательно должно быть и три экземпляра SysTick таймеров.
При этом в доке FC7300 Reference Manual базовый адрес для SysTick вообще не фигурирует.
В доке ARM Cortex-M7 Processor Technical Reference Manual для SysTick фигурирует только один физический адрес. Вот он 0xE000E010.
А какие тогда физические адреса у остальных SysTick таймеров: (SysTick2 и SysTick3 )?
Что это получается? Все три SysTick таймера могут иметь только одинаковые настройки что-ли?
Обзор безопасных микроконтроллеров Flagchip для автомобильной электроники