Предлагаю обратиться к первоисточнику - сайту Arm, а конкретно к документации на ARMv7E-M. Многоядерность в данном случае не влияет на инициализацию каждого отдельного ядра.
На подобный вопрос я предлагаю обратиться к классике - например, Таненбаум. Или почитать первоисточники по Arm - на сайте у них отлично описано назначение мейлбоксов и их использование.
Смотреть отладчиком, что именно происходит, смотреть состояние в HF. Отлаживать, как любой другой HF на Cortex M7.
Когда тестировали 7300 и пробовали собирать свою софт под него, никаких аппаратных проблем замечено не было, в том числе с многоядерностью и мейлбоксами. Может быть, отличаются версии чипов, рекомендую посмотреть в errata.
По второму вопросу сказать ничего не могу - необходимости такого сценария не возникало. Рекомендую посмотреть состояние core1 при зависании и регистры. Если указанный функционал является критичным, то обратиться к производителю.
Предлагаю посмотреть в сторону функций SCM и его регистров, а именно SCM_INT_ROUTERn
Про качество поставляемого софта и реализации конкретных функций могу предложить обратиться к флагчипу. Впрочем, опыт подсказывает, что качество софта и уровень поддержки китайский вендоров часто оставляет желать лучшего.
Конфигурируется VTOR, который определяет адрес таблицы прерываний, в которой первые 2 вектора - адрес стека и адрес исполнения. Поэтому программы для каждого ядра собираются в единое адресное пространство по разным адресам, что при сборке gcc определяется линкер-скриптом, например, так
Да почти как всегда на много ядерных системах - обратить внимание на синхронизацию между ядрами и разделение доступа к ресурсами. В принципе, можно посмотреть реализацию демонстрационного кода Example/Mailbox в примерах от производителя.
Также есть некоторые нюансы запуска, пример независимого исполняемого кода на всех 3х ядрах показан в Example/MultiCore.
Сразу скажу, что в проекте использовали 4150. Для прошивки - кастомная сборку openocd. Типового cfg для CortexM4 с правильно прописанными ядрами и айдишниками уже достаточно для дебага.
Но флагчип использует свой алгоритм прошивки во флеш - основанный на вызове функций из ROM чипа, плюс есть ошибки в документации. По этой причине пришлось добавить в openocd алгоритм flagchip_flash для поддержки.
К сожалению, по причине NDA могу предложить только через обращение в компанию Flagchip. Ещё в комментариях были люди, имеющие доступ к документации, может кто-то из них получал её без NDA.
Картинка приведена исключительно для примера. По 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.
ASIL Ranking из ISO26262
Разберём случай, когда аудиосистема превращается в LRAD.
Пусть Severity (серьёзность) = S3 (Максимальная, так как выше было указано, что все контужены, предположим, что высока вероятность аварии).
Probability of Exposure (вероятность наблюдения) = E1 (минимальная, так как про такие случаи в настоящий момент неизвестно, но может быть пересмотрено в будущем, если окажется, что это не так).
Controlability by driver (способность водителя справится) = С2 (средняя, предположим, что 90% водителей смогут нажать на тормоз). В таком случае требования к блокам ASIL-QM.
Если же мы заложим Controlability = C3, то требования - ASIL-A.
Вообще, предполагался цикл статей по ISO 26262, который когда-нибудь будет опубликован (никогда).
Конкретной информации нет, судя по доступными комбинациями, чипы FC4150SF и не выпускались. В документации достаточно большое количество неточностей и очепяток, например, банально нет 2М чипа, из даташита на который табличка и скопирована. Я бы предположил, что в данном случае производитель задумывался над вариантом выпуска микроконтроллеров с SiP Flash, подключенной, например, к OSPI интерфейсу. Хотя обычно используется аббревиатура SiP, TI, например, вполне использует SIP в документации.
Прошу прощения за долгий ответ. По результатам запуска Coremark на Flagchip. На FC4150 выполняется успешно с любым уровнем оптимизации, тестировали несколько суток. Для работы FPU надо включить руками.
На FC7300 также выполняется успешно, но -mfloat-abi=hard -mfpu=fpv5-sp-d16 . И вызвать FPU_Enable(), пример можно посмотреть в Fpu_Dsp_Example.
/**
* @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.
У нас по плану использование MCAL драйверов с AUTOSAR шедулером и сборкой Greenhill. SDK + gcc - ранний оценочный этап разработки.
Если у вас такая же Demo Board, то, скорее всего, там тоже FC7300F8MDT2A320T1A. Насколько мне известно, там только одна ревизия борды на FC7300 с одним MCU.
Там именно Hard Fault? И ещё один очевидный вопрос - как была запитана плата? Питание MCU 3.3в или 5в?
Можете написать версию gcc, версию sdk и флаги сборки? В понедельник проверю на 7300 с разными вариантами оптимизациями. Но наш код слабо нагружает ядро, много обмена с внешними устройствами с использованием DMA. При отсутствии проблем, попробую собрать Coremark и проверить на нём. Если есть проблема со стабильностью MCU, хотелось бы выяснить подробности до запуска в производство. При наличии проблемы с MCU, можно переадресовать вопрос флагчипу, но надо конкретизировать проблему.
Вот, например, в документации ARM есть интересные разделы Exception entry behavior, Exception return behavior
Почему бы не предположить, что у каждого ядра свой экземпляр SysTick по одним адресам? Это можно легко проверить.
Читать Exception entry behavior и The ARM core registers
Предлагаю обратиться к первоисточнику - сайту Arm, а конкретно к документации на ARMv7E-M. Многоядерность в данном случае не влияет на инициализацию каждого отдельного ядра.
На подобный вопрос я предлагаю обратиться к классике - например, Таненбаум. Или почитать первоисточники по Arm - на сайте у них отлично описано назначение мейлбоксов и их использование.
Смотреть отладчиком, что именно происходит, смотреть состояние в HF. Отлаживать, как любой другой HF на Cortex M7.
Когда тестировали 7300 и пробовали собирать свою софт под него, никаких аппаратных проблем замечено не было, в том числе с многоядерностью и мейлбоксами. Может быть, отличаются версии чипов, рекомендую посмотреть в errata.
По второму вопросу сказать ничего не могу - необходимости такого сценария не возникало. Рекомендую посмотреть состояние core1 при зависании и регистры. Если указанный функционал является критичным, то обратиться к производителю.
Предлагаю посмотреть в сторону функций SCM и его регистров, а именно SCM_INT_ROUTERn
Про качество поставляемого софта и реализации конкретных функций могу предложить обратиться к флагчипу. Впрочем, опыт подсказывает, что качество софта и уровень поддержки китайский вендоров часто оставляет желать лучшего.
Такой тоже знаем, использовали позже. В 22 году он не попался на глаза.
Тем не менее, спасибо за его упоминание - очень может кому-то из читателей будет интересно.
У меня нет пинаута на 7300. Насколько я знаю, там нет механизма через пин выбора адреса загрузки, но там есть механизм OTA, поддерживающий 2 региона.
Конфигурируется VTOR, который определяет адрес таблицы прерываний, в которой первые 2 вектора - адрес стека и адрес исполнения. Поэтому программы для каждого ядра собираются в единое адресное пространство по разным адресам, что при сборке gcc определяется линкер-скриптом, например, так
Собственно, как на SPC58 Bernina
Да почти как всегда на много ядерных системах - обратить внимание на синхронизацию между ядрами и разделение доступа к ресурсами. В принципе, можно посмотреть реализацию демонстрационного кода Example/Mailbox в примерах от производителя.
Также есть некоторые нюансы запуска, пример независимого исполняемого кода на всех 3х ядрах показан в Example/MultiCore.
В моей версии SDK такого нет, судя по всему, какие-то сторонние компоненты, если судить по тому, что рядом лежат FreeRTOS и lwIP.
Сразу скажу, что в проекте использовали 4150. Для прошивки - кастомная сборку openocd. Типового cfg для CortexM4 с правильно прописанными ядрами и айдишниками уже достаточно для дебага.
Но флагчип использует свой алгоритм прошивки во флеш - основанный на вызове функций из ROM чипа, плюс есть ошибки в документации. По этой причине пришлось добавить в openocd алгоритм flagchip_flash для поддержки.
К сожалению, по причине NDA могу предложить только через обращение в компанию Flagchip. Ещё в комментариях были люди, имеющие доступ к документации, может кто-то из них получал её без NDA.
Может и так.
Картинка приведена исключительно для примера. По 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, который когда-нибудь будет опубликован (
никогда).Конкретной информации нет, судя по доступными комбинациями, чипы FC4150SF и не выпускались. В документации достаточно большое количество неточностей и очепяток, например, банально нет 2М чипа, из даташита на который табличка и скопирована. Я бы предположил, что в данном случае производитель задумывался над вариантом выпуска микроконтроллеров с SiP Flash, подключенной, например, к OSPI интерфейсу. Хотя обычно используется аббревиатура SiP, TI, например, вполне использует SIP в документации.
Прошу прощения за долгий ответ. По результатам запуска 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/
У нас по плану использование MCAL драйверов с AUTOSAR шедулером и сборкой Greenhill. SDK + gcc - ранний оценочный этап разработки.
Если у вас такая же Demo Board, то, скорее всего, там тоже FC7300F8MDT2A320T1A. Насколько мне известно, там только одна ревизия борды на FC7300 с одним MCU.
Там именно Hard Fault? И ещё один очевидный вопрос - как была запитана плата? Питание MCU 3.3в или 5в?
Можете написать версию gcc, версию sdk и флаги сборки? В понедельник проверю на 7300 с разными вариантами оптимизациями. Но наш код слабо нагружает ядро, много обмена с внешними устройствами с использованием DMA. При отсутствии проблем, попробую собрать Coremark и проверить на нём. Если есть проблема со стабильностью MCU, хотелось бы выяснить подробности до запуска в производство. При наличии проблемы с MCU, можно переадресовать вопрос флагчипу, но надо конкретизировать проблему.