Multi Source Translation Content

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

Multi Source Translation Content

Discussions

Sort by:
S32 Design Studio バージョン v.3.5 ライセンス こんにちは、NXPサポートチームの皆さん、 私のS32 Design Studio バージョン3.5のライセンスは2026年10月19日に期限切れとなりました。ライセンス延長を手伝ってもらえますか? 起動コード:30E0-0F7D-F883-9AFB サポートありがとうございます。 Eclipse IDEの使用と設定
View full article
HSE [Wait for Interrupt(WFI)] status understanding Currently, I am working on MCU clock initialization and waiting for the HSE to enter the WFI state (CLOCK_IP_WFI_EXECUTED == 0x80000000U) before proceeding with the clock configuration. The current implementation is shown below. However, my concern is that if the HSE never transitions to the WFI state, the ECU will remain stuck in the waiting loop indefinitely. Could you please suggest a suitable safeguard or timeout mechanism to handle this scenario safely? do { WfiStatus = (IP_MC_ME->PRTN0_CORE2_STAT & MC_ME_PRTN0_CORE2_STAT_WFI_MASK); } while (CLOCK_IP_WFI_EXECUTED != WfiStatus); Re: HSE [Wait for Interrupt(WFI)] status understanding Hi @ManuSharma1  The worst case is HSE firmware installation, update, or recovery, which can take approximately 1 second as mentioned in HSE-B firmware reference manual. Therefore, I would recommend a timeout of approximately 1.3 seconds to provide some margin and avoid an infinite wait if the expected WFI state is not reached. Regards, Lukas
View full article
Matter Stack 移植到 MIMXRT700-EVK (MIMXRT798S) — 持久存储初始化失败 您好, 我目前正在使用 MCUXpresso SDK 和 VS Code 将 NXP Matter 协议栈移植到 MIMXRT700-EVK (MIMXRT798S)板上。该板使用基于 IW612 芯片组的外部 Murata Type 2EL 无线模块。 开发设置和变更 我通过 VS Code 下载并设置了 Matter MCUXpresso SDK 工作区。该工作区位于matter_mcuxpresso/mcuxsdk 。 我针对RT700进行了以下方面的修改: Matter:修改了中间件/matter下的文件,用于 RT700 平台集成。 无线框架:增加了对外部 Murata Type 2EL (IW612) 无线模块的 RT700 特定平台支持和集成。 链接器脚本:使用 RT700 SDK 提供的MIMXRT798Sxxxx_cm33_core0_flash.ld作为参考,并根据 Matter 应用程序的内存布局和 NVS 存储配置对其进行了修改。 问题描述 Matter 应用程序构建成功,并且可以使用 LinkServer 进行编程。但是,运行时初始化失败,并在src/platform/nxp/common/NXPConfigNVS.cpp中的以下调用处出现CHIP_ERROR_PERSISTED_STORAGE_FAILED错误: flash_init(fa->fa_dev) CHIP_ERROR_PERSISTED_STORAGE_FAILED 链接器脚本附件 我将附上修改后的MIMXRT798Sxxxx_cm33_core0_flash.ld链接器脚本供您参考。该脚本基于 RT700 SDK 提供的链接器脚本,并针对 Matter 应用程序的内存布局和 NVS 存储配置进行了修改。 需要支持 请问您能否帮忙澄清一下: 如何在RT700-EVK上配置Matter持久存储的闪存设备和驱动程序? 是否还需要任何针对 RT700 的额外闪存驱动程序或 NVS 集成步骤? 修改后的链接器脚本或 NVS 内存布局是否会导致flash_init()失败? 我希望您能指导我如何解决这个问题。 谢谢! 评估板 Re: Matter Stack Porting to MIMXRT700-EVK (MIMXRT798S) — Persistent Storage Initialization Failure 嗨@Aparna1 , 谢谢你的提问! 我已审核提供的链接脚本。它目前引用了以下与 FlexSPI 相关的对象: *(EXCLUDE_FILE( ... *fsl_adapter_flexspi_nor_flash.c.o* *mflash_drv.c.o* *fsl_flexspi.c.o* ) .text*) 但是,MIMXRT700 使用的是 XSPI 控制器。请确认该应用程序已链接到正确的 RT700 XSPI 闪存后端,并且 fa->fa_dev 指的是该设备,而不是其他 i.MX RT 平台使用的 FlexSPI 后端。 另请检查映射文件中的 flash_init() 、闪存擦除/编程功能以及相关的 XSPI_* 功能。这些功能及其所需的配置数据应该位于 RAM 中,而不是 XIP 闪存区域中。 我们建议按以下顺序检查端口: 验证 SDK 中的官方 RT700 XSPI 或非 闪存示例; 确认 fa->fa_dev 使用正确的XSPI后端; 验证闪存操作代码是否确实从 RAM 中执行; 然后检查 NVS 地址、扇区对齐方式,以及驱动程序是否期望绝对地址或设备相对偏移量。 此致, 加文
View full article
Clock - power relationship : MIMXRT685 - EVK Hello,  For an application I'm shooting the core clock frequency to max possible, i.e., 297MHz from the default 250 MHz. I wanted to know what implications it causes from the power perspective. Although nothing breaks right now, from the static characteristics from the datasheet, I think I need to make some changes, to avoid future hardfaults. I would really appreciate some guidance here.  Thanks in advance! Shri Re: Clock - power relationship : MIMXRT685 - EVK Hi @shri00 , Thank you so much for your interest in our products and for using our community. For 297 MHz operation on the MIMXRT685-EVK, please check the VDDCORE voltage as well as the clock configuration. The fact that the board currently runs without faults does not necessarily mean that VDDCORE meets the operating requirements for your target frequency and temperature range.   When increasing the clock frequency, first set VDDCORE to the level required for the target frequency, and then switch to the higher frequency.   For the relationship between VDDCORE and clock frequency, please refer to Tables 20 and 21 of the RT600 data sheet. Dual-core microcontroller with 32-bit Cortex®-M33 and Xtensa HiFi4 Audio DSP CPUs Have a nice day. Best Regards May Liu
View full article
GenAVB_TSN-rtos-apps RT1180 tsn_app プロジェクトのビルド問題 私は https://github.com/NXP/GenAVB_TSN-rtos-apps のリポジトリを基にTSNデモをセットアップしています。そして、 https://community.nxp.com/t5/i-MX-RT-Crossover-MCUs-Knowledge/Step-by-Step-Guide-to-Running-the-GenAVB-TSN-Stack-FreeRTOS/ta-p/2390969のステップバイステップガイドに従いました。厳密に。 しかし、プロジェクトをインポートした後、プロジェクトオプションには ram_release ビルド構成のみが表示され、 release_no_enetc0はないため、フラッシュプログラムができません。インポート処理を何度もやり直しましたが、結果は変わりません。 私はNXP_GenAVB_TSN_MCUXpresso_User_s_Guide_8_0_rev0.pdfに従ってプロジェクトをインポートし、対応するセットアップスクリプトも実行しました。どなたか、この問題の原因を教えていただけませんか? Re: GenAVB_TSN-rtos-apps RT1180 tsn_app project build problem @ChandlerY様、 GitHubで8_0ブランチを選択してください。 https://github.com/NXP/GenAVB_TSN-rtos-apps/tree/8_0 このブランチのREADMEファイルには、サポートされていることが明記されています。 よろしくお願いします、 シェリー Re: GenAVB_TSN-rtos-apps RT1180 tsn_app project build problem こんにちは、シェリーさん。 ご返信ありがとうございます! 手順を全て繰り返しましたが、問題は依然として解決していません。私は最新バージョンのVS Codeと最新のMCUXpressoインストーラーを使用しています。 以下に、私の製作手順を記載します。必要な手順を見落としていないか、手伝ってもらえますか?ありがとう。 1. SDKをインポートする( 8_0_0 と 8_0の両方試しました) 2. パッチスクリプトを実行します(ファイル《NXP_GenAVB_TSN_MCUXpresso_User_s_Guide_8_0_rev0》が必要です)。 1)  cd E:\111\genavb_tsn_rtos_apps_800\GenAVB_TSN-rtos-apps\scripts 2) ブートストラップ.bat   そして、それは正常に実行されました。   3.プロジェクトをインポートする 4.プロジェクトで利用できるビルド構成はまだ2つしかありません。 さらに、コマンドラインでプロジェクトのコンパイルやデバイスのフラッシュができ、プログラミング後に通常のログ出力も確認できます。しかし、このワークフローは日常的な開発には十分便利とは言えません。IDE内でワンクリックでコンパイル&フラッシュできる機能と、ビルド構成を選択できる機能があればいいのですが。どうすればこの問題を解決できるか、ぜひ教えていただけますか? お早めにご回答いただけると幸いです。 Re: GenAVB_TSN-rtos-apps RT1180 tsn_app project build problem @ChandlerY様、 ご辛抱いただきありがとうございます。 リポジトリから最新のコードを取得し、私の環境でも同様の問題を再現することができました。現時点では、根本原因はまだ不明である。これは、VS Codeの表示設定とツール構成の間に何らかの不整合があることに関係している可能性があります。 一時的な回避策として、 west build コマンドを使用してプロジェクトを作成/ビルドしてください。例えば: west build -p always boards/src/demo_apps/avb_tsn/tsn_app --toolchain armgcc --config release_no_enetc0 -b evkmimxrt1180 -Dcore_id=cm33 私たちはこの問題について引き続き調査を進めていきます。   よろしくお願いいたします。 シェリー Re: GenAVB_TSN-rtos-apps RT1180 tsn_app project build problem @ChandlerY様、 問題の原因を特定しました。これは新しいバージョンのMCUXpresso for VS Codeに関連しているようです。 バージョン26.5.57にロールバックした後、利用可能なビルド構成はすべて正しく確認できます: 下記のスクリーンショットを参照し、バージョン26.5.57にロールバックしてください。拡張機能ビューから:   また、TSNアプリケーションは現在フリースタンディングアプリケーションをサポートしていません。代わりにリポジトリアプリケーションをご利用ください。 よろしくお願いします、 シェリー Re: GenAVB_TSN-rtos-apps RT1180 tsn_app project build problem 親愛なるシェリーへ、 ご返信ありがとうございます。さらに、もう一つ問題があります。プロジェクトをインポートする際、ビルドは「 リポジトリアプリケーション 」をアプリタイプとして選択した場合のみ成功します。スタンドアロンアプリケーションか独立アプリケーションのどちらかでビルドすると失敗します。この問題の解決も手伝っていただけませんか?ありがとう。 Re: GenAVB_TSN-rtos-apps RT1180 tsn_app project build problem @ChandlerY様、 回避策がうまくいったようで良かったです。 問題点とご要望の両方を社内チームに共有し、さらなる検討を依頼しました。 その間、TSNアプリケーションは主に機能テストと評価を目的としていることにご注意ください。実際の製品開発には、独自のスタンドアロンアプリケーションプロジェクトを作成し、必要なTSN機能を移植することをお勧めします。 よろしくお願いします、 シェリー Re: GenAVB_TSN-rtos-apps RT1180 tsn_app project build problem こんにちは、シェリーさん。 あなたの解決策を試してみました。うまくいきました!どうもありがとう。 VS Code 用の新しいバージョンの mcuxpresso でこの問題を修正する際には、その旨をお知らせください。 リポジトリアプリケーションタイプに限定されているため、プロジェクトの変更や移植には不便です。FUTUREのリリースでスタンドアロンアプリケーションタイプのサポートを導入する予定はありますか?
View full article
GenAVB_TSN-rtos-apps RT1180 tsn_app project build problem I am setting up a TSN demo based on the repository at https://github.com/NXP/GenAVB_TSN-rtos-apps, and I have followed the step-by-step guide at https://community.nxp.com/t5/i-MX-RT-Crossover-MCUs-Knowledge/Step-by-Step-Guide-to-Running-the-GenAVB-TSN-Stack-FreeRTOS/ta-p/2390969 strictly. However, after importing the project, only the ram_release build configuration is available in the project options,no release_no_enetc0,so it can not program to flash. I have retry the import process many times, but the outcome stays the same. I imported the project in accordance with NXP_GenAVB_TSN_MCUXpresso_User_s_Guide_8_0_rev0.pdf, and also executed the corresponding setup scripts. Could anyone please help figure out what is causing this issue? Re: GenAVB_TSN-rtos-apps RT1180 tsn_app project build problem Dear @ChandlerY , Please make sure to select the 8_0 branch on GitHub: https://github.com/NXP/GenAVB_TSN-rtos-apps/tree/8_0 The README file for this branch explicitly states that it is supported:  Best Regards, Shelly Re: GenAVB_TSN-rtos-apps RT1180 tsn_app project build problem Hi,shelly,    Thanks for your reply! I have repeated the whole process, but the issue still persists. I am using the latest version of VS Code and the latest MCUXpresso installer. My build steps are listed below. Could you please help check if I have missed any required steps? Thank you. 1. Import the SDK(I have tried both 8_0_0 & 8_0) 2.Execute the patch scripts(file《NXP_GenAVB_TSN_MCUXpresso_User_s_Guide_8_0_rev0》 required) 1)  cd E:\111\genavb_tsn_rtos_apps_800\GenAVB_TSN-rtos-apps\scripts 2) bootstrap.bat   and it excute successfully.   3.import the project 4.There are still only two build configurations available for the project Additionally, I am able to compile the project and flash the device via the command line, and normal log output can be observed after programing. However, this workflow is not convenient enough for daily development. I would prefer to have the one-click compile-and-flash functionality with selectable build configurations in the IDE. Could you please help how to resolve this? I would appreciate your early response. Re: GenAVB_TSN-rtos-apps RT1180 tsn_app project build problem Dear shelly,       thanks for your reply. In addition, I have another issue. When importing the project, the build can only succeed when Repository application is selected as the App type. Builds with either standalone application or freestanding application will fail. Could you please help resolve this problem as well? Thank you. Re: GenAVB_TSN-rtos-apps RT1180 tsn_app project build problem Dear @ChandlerY , Thank you for your patience. I pulled the latest code from the repository and was able to reproduce the issue on my side. At this moment, the root cause is still unclear. It may be related to some inconsistency between the VS Code display settings and the tool configuration. As a temporary workaround, please use the west build command to create/build the project. For example: west build -p always boards/src/demo_apps/avb_tsn/tsn_app --toolchain armgcc --config release_no_enetc0 -b evkmimxrt1180 -Dcore_id=cm33 We will continue to follow up on this issue.   Best Regards, Shelly Re: GenAVB_TSN-rtos-apps RT1180 tsn_app project build problem Dear @ChandlerY , We have identified the cause of the issue. It appears to be related to the newer version of MCUXpresso for VS Code. After rolling back to version 26.5.57, I can see all the available build configurations correctly: Please refer to the screenshot below and roll back to version 26.5.57 from the Extensions view:   Also, the TSN application currently does not support Freestanding Application. Please use Repository Application instead. Best regards, Shelly Re: GenAVB_TSN-rtos-apps RT1180 tsn_app project build problem Hi,shelly,     I have tried your solution,it works! Thanks a lot.     Please tell me when fixing this problem at the newer version of mcuxpresso for vscode.      Limited exclusively to the Repository Application type is inconvenient for project modification and porting. Are there any plans to introduce support for the Standalone Application type in future releases? Re: GenAVB_TSN-rtos-apps RT1180 tsn_app project build problem Dear @ChandlerY , Glad to hear that the workaround works for you. I have shared both the issue and your request with our internal team for further consideration. In the meantime, please note that the TSN application is primarily intended for feature testing and evaluation. For actual product development, we recommend creating your own standalone application project and porting the required TSN functionality to it. Best regards, Shelly
View full article
SW32K14-MCAL421-RTMC-1.0.1ダウンロードへのアクセス許可の要請 NXPサポートチームの皆さん、こんにちは。 SW32K14-MCAL421-RTMC-1.0.1のダウンロードアクセスをお願いしたいです。 現在、NXPソフトウェアライセンスページの「前回」タブが グレーアウト しており、このバージョンにアクセスできません。 私のアカウントのユーザー名はChefanqfです。 このバージョンは、 S32K14x MCAL 4.2をベースにした既存のプロジェクトとの互換性のために必要です。 このソフトウェアの権利を私のアカウントで有効にするのを手伝ってもらえますか? ご支援ありがとうございます! よろしくお願いいたします。 Re: Request to enable access for SW32K14-MCAL421-RTMC-1.0.1 download こんにちは@812311483 この問い合わせの内容は「SW32K14-MCAL421-RTMC-1.0.1ダウンロードへのアクセス許可を要請」と同一です。 このアカウントがソフトウェアを必要としているのか、それとも以前のアカウント「Chefanqf」が必要だったのか、明確にしていただけますか? よろしくお願いいたします ロビン Re: Request to enable access for SW32K14-MCAL421-RTMC-1.0.1 download はい、学習と使用のためにSW32K14-MCAL421-RTMC-1.0.1をダウンロードする必要があるのは私のアカウントです。このアカウントのダウンロード許可をいただけますか?ありがとう
View full article
Technical Inquiry Regarding Human and Pet Classification Using 77–81 GHz FMCW Radar Hello, My name is Eunjin Kwon, and I am a researcher in the Eco-Friendly Building Research Team at GS Engineering & Construction in South Korea. We are currently exploring the application of mmWave radar technology for non-contact fall detection and activity monitoring in residential environments. One of our key technical requirements is to distinguish humans from pets (such as dogs and cats) to prevent false alarms caused by pet movements while ensuring reliable fall detection for human occupants. We are particularly interested in NXP's 77–81 GHz FMCW radar solutions and would appreciate your technical guidance on the following questions: 1. Does NXP have any existing technologies, research results, or application examples related to human versus pet (Human / Non-human) classification using mmWave radar? 2. Is it technically feasible to distinguish humans from pets using radar data, such as point clouds and Doppler information, through AI-based classification algorithms? 3. Are there any relevant reference designs, technical documents, or development resources available for this application? We would also appreciate the opportunity to discuss this topic with an NXP radar technical specialist or Field Application Engineer (FAE) in South Korea. Thank you for your time and assistance. I look forward to your response. Best regards, Eunjin Re: Technical Inquiry Regarding Human and Pet Classification Using 77–81 GHz FMCW Radar Hello, Let me look closer if we have done something similar as our RADARs are automotive. Best regards, Peter
View full article
BCC MC33771C 测量时序 各位同事好,   我们正在使用 MC33771C 电池单元控制器 (BCC),并观察到使用不同的读取间隔时电压/温度测量读取时间存在差异。   测试观察结果:   配置:与 BCC 配置相同,有 4 个从节点。 读取间隔:10 毫秒:从所有 4 个从站读取温度数据大约需要 40 毫秒。 读取间隔:100 毫秒:从所有 4 个从站读取相同的温度数据大约需要 7.7 毫秒。 我们观察到,即使配置保持不变,当读取间隔设置为 10 毫秒时,总测量读取时间也会明显增加。   请问您能否帮我们理解以下问题?   为什么 10 毫秒和 100 毫秒读取间隔的测量读取时间会有显著差异? 读取间隔与ADC转换、测量更新或BCC通信时序之间是否存在任何依赖关系? 使用 4 个 BCC 从设备时,是否有推荐的配置或步骤来实现一致且优化的电压/温度读取时序? 从多个 MC33771C 设备读取测量数据时,我们是否需要考虑任何特定的时间限制或同步要求? 如需进一步分析,如需其他配置详情或测量日志,请与我们联系。 Re: BCC MC33771C measurement timing 你好,Nirmal, 感谢您确认ADC配置。这是一个重要的澄清:当 ADC_CFG[AVG] = 0 且分辨率为 16 位时,硬件 tEOC 仅为 ~520 µs。您在 10 毫秒间隔内观察到的 40 毫秒读取时间不可能是 ADC 转换本身造成的,几乎可以肯定是由固件测量序列造成的。 tEOC ≈ 520 µs,因此在两个时间间隔到期之前,数据就已经准备就绪。因此,观察到的读取时间差异源于固件触发信号 SOC 并读取结果相对于该时间间隔的方式和时间。导致这种特定症状的最常见原因是: 1. SYS_CFG1[CYCLIC_TIMER] 在 10 毫秒时激活 如果循环定时器设置为 10 毫秒,则设备每 10 毫秒自动触发信号一次循环转换。但是,循环转换不会更新 MEAS_xxxx 测量寄存器——它们只会更新 OV/UV/OT/UT 故障标志。如果 MCU 固件在发出在线点播 SOC 之前等待循环触发信号,则有效测量周期将与循环周期耦合,每次读取之前最多会增加 10 毫秒的延迟。在 100 毫秒的循环周期下,这种延迟消失了,因为 MCU 可以独立地在线点播发出 SOC。请验证 SYS_CFG1[CYCLIC_TIMER] 的值,如果已激活,请考虑禁用它或将 MCU 读取序列与其完全解耦。 2. 读取前插入固定时间间隔延迟(不等待 EOC) 如果固件发出 SOC 信号,然后等待完整的读取间隔(10 毫秒或 100 毫秒)后再进行读取,而不是轮询 EOC 标志,则其行为将是: 100 毫秒:SOC → 等待 100 毫秒 → 读取(通信时间 7.7 毫秒)→ 测量值 ≈ 7.7 毫秒 ✓ 10 毫秒:SOC → 等待 10 毫秒 → 读取(7.7 毫秒通信) → 但是如果循环重复且时间累积,则有效测量持续时间会增加。 3. SOC 是按从设备发放的,而不是广播发放的。 如果固件分别向每个从设备触发信号 SOC,并强制执行每次读取之间的间隔,则 4 个从设备的总和将是间隔的倍数。 4个奴隶的正确顺序是: - 同时向所有 4 个从设备发出单个广播 SOC。 - 轮询 EOC 标志(或在 16 位时等待至少 520 µs,AVG=0)— 不要使用等于读取间隔的固定延迟。 - 确认 EOC 后,依次读取所有 4 个从属设备。 BRs,托马斯 按您所需的时间间隔重复。 Re: BCC MC33771C measurement timing 你好@TomasVaverka 感谢您的详细解释。 在我们的配置中,我们使用以下设置: ADC_CFG[AVG] = 0 ADC分辨率 = 16位 BCC 从节点数量 = 4 我们对两个测试用例使用了相同的配置(读取间隔分别为 10 毫秒和 100 毫秒)。 但是,我们观察到以下时间差异: 10 毫秒读取间隔:从所有 4 个从站读取温度数据大约需要 40 毫秒。 100 毫秒读取间隔:从所有 4 个从站读取温度数据大约需要 7.7 毫秒。 由于两种情况下 ADC 平均值和分辨率设置相同,请问为什么转换和测量读出时间会有如此大的差异? 是否存在与 SOC 触发信号间隔、ADC 转换状态或 EOC 标志处理相关的依赖关系,可以解释这种行为? 您能否也建议一下,如何在 10 毫秒的测量间隔下实现一致的测量读数时间? Re: BCC MC33771C measurement timing 你好,Nirmal, 时间差异很可能是由您的 ADC_CFG[AVG] 平均设置引起的。 启用平均值后,tEOC(从 SOC 到数据准备就绪的时间)与样本计数成正比。例如,在 16 位分辨率且 AVG=64 的情况下,tEOC ≈ 32.5 毫秒 — 远远超过您的 10 毫秒读取间隔。这就解释了观察到的现象: 每隔 100 毫秒:当 MCU 读取时转换已经完成 → 仅测量通信时间(~7.7 毫秒)。 每隔 10 毫秒:MCU 必须等待转换完成 → 测量时间 = 剩余的 tEOC 等待时间 + 通信时间 ≈ 40 毫秒。 以下几点与您的问题相关: 1. 循环模式 (SYS_CFG1[CYCLIC_TIMER]) 不会更新 MEAS_xxxx 寄存器 — 它只会更新故障标志 (OV/UV/OT/UT)。要获得实际的电压/温度读数,需要在线点播 SOC 信息。循环模式下也不支持平均值计算。 2. 务必等待 EOC 标志出现后再读取结果。除非能保证延迟时间超过 tEOC,否则不要使用等于读取间隔的固定延迟时间。 3. 对于 4 个从设备:同时向所有从设备广播一个 SOC(所有设备并行转换,在 tEOC 完成),然后按顺序读取。在 16 位,AVG=0 时,最小总时间约为 0.52 毫秒 (tEOC) + 4 × 0.7 毫秒 (TPL 通信) ≈ 3.3 毫秒。 4. 有关完整的时序优化框架,请参阅 AN12637:基于 MC33771C 和 MC33772C 的系统时序优化(可在 nxp.com 上获取,需要登录)。 BRs,托马斯
View full article
ホールセンサーベースのモータ制御リファレンスウェアおよびトレーニング・マテリアルの要請 NXPチームの皆様へ 私たちは、24V、3.47Aモーターを用いた空冷システムを開発するお客様と協力しています。 センサーレスFOCベースのモータ制御を用いたデモンストレーションを成功裏に完了しました。顧客は現在、FRDM-MCXA156 EVK(制御カード)とFRDM-MC-LVPMSM(電源カード)を用いてローター位置検出用のホールセンサーを統合したいと考えています。 このハードウェアの組み合わせでホールセンサーベースのモーター制御を実装するための適切なリファレンスファームウェアやアプリケーション例を教えていただけますか? GitHubで公開されているLPC55S36用のホールセンサー搭載BLDCモーターのサンプルコードを確認しました。 しかし、この例に対応するFreeMASTER設定ファイル(.pmpx)を見つけることができませんでした。 以下の点についてご協力いただけますか? FRDM-MCXA156とFRDM-MC-LVPMSMのホールセンサー統合に関するリファレンスファームウェア。 利用可能な場合は、対応するFreeMASTERプロジェクト/設定ファイル(.pmpx)。 既存のセンサーレスFOCプロジェクトにホールセンサーフィードバックを統合するための関連するアプリケーションノート、トレーニング・マテリアル、または実装ガイド(FRDM-MCXA156 EVKに基づくもの。 技術的なご指導やご提案をいただければ大変ありがたく存じます。 よろしくお願いします ダルシャン・J・L WPGインド ボード設計 開発ボード FRDMトレーニング ハンズオン・トレーニング MCXA モータ制御 Re: Request for Hall Sensor-Based Motor Control Reference Firmware and Training Material こんにちは、 @Darshan_J_L さん。 投稿ありがとうございます。 MCUXpresso SDKには複数のモーター制御の例プロジェクトが含まれています。FRDM-MCXA156の詳細については、次のページでご覧いただけます。 MCUXpresso モータ制御用SDK |NXP Semiconductors。   FRDM-MCXA156 + FRDM-MC-LVPMSM の組み合わせのpmsm_enc例はSDK v25.06にあります。センサーレスおよびセンサー付きFOCをサポートし、pmsm_float_enc.pmpx FreeMASTERプロジェクトを含んでいます。ご参照くださいUG10247.pdf 詳細については、こちらをご覧ください。   デモ用の対応するFreeMASTER設定ファイル(.pmpx)については、こちらLPC55S36:an-lpc55s36_mc_bldc_whall/LPC5536_mc_bldc_wHall.pmpx at main · nxp-appcodehub/an-lpc55s36_mc_bldc_whall ·GitHub   お役に立てば幸いです。他に何かご質問がありましたら、お気軽にお知らせください。   BR セレステ    
View full article
MPC5777C Nexus trace while eTPU A/B clock halted Hi, It was found that if eTPU A/B clock is halted via SIU_HLT1.ETPUA bit, then MDO and MSEO Nexus outputs from Nexus Port Controller (NPC) are stuck to 0V (dead). Even if other Nexus client (e.g. e200) is generating Nexus trace data. If SIU_HLT1.ETPUA is later written with '0' (clock not halted anymore), Nexus trace stream from e200 Nexus client reaches NPC and outside world. After doing some testing it seems that no other clock halt request within HLT1 register seems to produce same behavior on MSEO/MDO pins. So the core problem is that it seems that eTPU A/B clock halt affects Nexus trace operation in general. This happens regardless of clock divider or port width in NPC. Workaround I found by trial and error is that if you firstly disable each (A and B) eTPU engine via respective ECR.MDIS bit and then disable whole module clock via HLT1.ETPUA, MSEO/MDO pins still behave normally if trace is initiated from other Nexus clients (e.g. e200 core).   This workaround however is not optimal as it requires change to the user application. I am interested if something can be done by debugger to mitigate this behavior?  
View full article
How many Quadrature encoder inputs can an S32K44 and an S32K388 support? I found https://community.nxp.com/t5/S32K/Quadrature-decoder-on-S32K344/m-p/1507580 as well as the application notes on https://www.nxp.com/design/design-center/development-boards-and-designs/MCSPTE1AK344 but I'm struggling to pin down how many quadrature encoders I could instantiate. I have an application where, ideally, I would be able to have 4 independent quadrature decoders. Would either the S32K344 or the S32K388 support that? Re: How many Quadrature encoder inputs can an S32K44 and an S32K388 support? Hello, The S32K3 family does not include a dedicated quadrature decoder peripheral. Instead, the quadrature decoder functionality is implemented using a combination of the LCU, TRGMUX, and eMIOS modules. This is the approach described in the S32K3 Reference Manual and the motor-control example referenced in the community thread. According to the Reference Manual, the incremental encoder example requires two Logic Cells (LC0 and LC1) for a single quadrature decoder implementation. The S32K344 and S32K388 devices provide two LCU instances. However, I have also asked motor control team to provide the feedback. I will update you ASAP. Best regards, Peter Re: How many Quadrature encoder inputs can an S32K44 and an S32K388 support? Hello, Update: Based on the implementation described in the NXP example, the practical limit is three independent quadrature decoders on both S32K344 and S32K388. This solution consumes: 6 TRGMUX input pins (3 × A/B encoder inputs), 6 eMIOS channels capable of MCB operation (for example eMIOS0 CH1-CH6), 3 Logic Cells (one LCU instance). Therefore, three encoder instances can be implemented directly using the demonstrated architecture. A fourth encoder is not directly supported by the same resource mapping. The main limitation is the availability of suitable eMIOS channels operating in MCB mode together with the required signal routing through TRGMUX and LCU. A possible workaround may exist by using the remaining G-type channel (e.g. CH7) together with an X-channel and routing the LCU output externally through a device pin back into the eMIOS X input. For example, on S32K344, PTB2 can be configured as both LCU1_OUT3 and eMIOS0_CH8_X, effectively creating an external loopback path. However, this approach consumes an additional package pin and is not part of the standard demonstrated solution. As a result, 3 quadrature decoders are straightforwardly achievable, while a 4th decoder would require an alternative routing scheme or custom workaround and should be evaluated against the overall pin and peripheral resource usage. Best regards, Peter Re: How many Quadrature encoder inputs can an S32K44 and an S32K388 support? For my application, I don't really need the eMIOS-based interpretation which counts using the timer - I really only need to have the encoder counts available. Is there any configuration which would support having 8 TRGMUX inputs and 4 LCU cells leading to something which just counts up and down?
View full article
IMX8mp gstreamer vpuenc_h264 プロファイルとレベルを設定 当社では、カスタムボード上にIMX8mpを搭載し、NXP Yocto Hardknottをベースプラットフォームとして使用しています。 ハードウェアH264エンコーダーであるvpuenc_h264プラグインを使用して、カメラストリームをH264/MP4に圧縮/エンコードしています。 基本的な例としては、次のようなものがあります。 gst-launch-1.0-v videotestsrc num-buffers=100 !video/x-raw、幅=720、高さ=576、フレームレート=25/1 !vpuenc_h264 !video/x-h264,profile=main !h264parse !mp4mux fragment-duration=10 !filesink location=/tmp/Video1.mp4 しかし、vpuenc_h264 は profile= および level= ストリームパラメータを無視するようです。imx-gst1.0-plugin を見てみるとコードには、H264プロファイルを設定する機能がないようです。 GStreamerのパラメータを使用してH264ハードウェアエンコーダのプロファイルを設定する機能はありますか? インターネットで、この設定をVPUのハードウェアレジスタにハードコーディングする必要があることを示唆する情報を見かけたのですが、実際はどうなのでしょうか? 代替案(コミュニティ?)があることに気付いた。gstreamer1.0-plugins-imxこのプラグインはプロファイルとレベルをサポートしているようです。これは、NXP fsl-nxp-bsp-hardknott Yoctoビルドのソフトウェアモジュール/カーネルでは使用できないということでしょうか? Re: IMX8mp gstreamer vpuenc_h264 set profile and level 裏付けとなるご意見をありがとうございます。 私も同様に、v4l2-ctl -d /dev/video1 --all がこれらのエンコーダーパラメータに関して誤解を招くような表示をしており、変更可能であるかのように誤って示唆し、「high」がデフォルトのプロファイルであるかのように見せかけているのを目にしました。 Re: IMX8mp gstreamer vpuenc_h264 set profile and level はい、ご指摘ありがとうございます。 NXPの公式ドキュメントは通常入手困難なため、インターネット検索やコードの確認を通して私が収集した情報を他のユーザー向けに以下にまとめました。 H264エンコーディングプロファイルは、vpu_wrapper内でBaselineにハードコーディングされています。例えばこれをMainlineに変更すると(vpu_wrapperを再構築する)、H264ストリームがMainlineとしてマークされます。実際の圧縮率が異なるかどうかは分かりません。 レベルは、ビデオの解像度に基づいてvpu_wrapperによって設定されます。このレベルをH264ストリームにタグ付けする以外に、何か影響があるかどうかは分かりません。どうやら、vpu_wrapperの古いバージョンには、このレベルを誤って設定するバグがあったようです。 ビットレートを指定しない場合、少なくともgstreamerのvpuenc_h264レベルでは、結果として得られるストリームのビットレートは非常に低くなり、したがって非常に低品質になります(少なくとも私たちのビデオストリーム(通常は静止画で、時折動きがある)の場合)。ビットレートを設定しない場合、H264エンコーダーは私が知らない何らかの可変ビットレートアルゴリズムを使用することになります。 NXPへのフィードバック: H264エンコーダーのプロファイル、レベル、ビットレートに関するドキュメントが必要であり、おそらく「i.MX Linuxリファレンスマニュアル」または他の場所に記載されているでしょう。 NXPのgstreamer vpuenc_h264コードは、gst-inspect-1.0でモジュールに関する情報を一覧表示する際に、この点について言及すべきです。なぜなら、多くのエンドユーザーがこのレベルで作業を行うからです。 Re: IMX8mp gstreamer vpuenc_h264 set profile and level こんにちは、 @TerryBarnaby1 さん。 お元気でお過ごしでしょうか。   関連情報については、下記のスレッドをご覧ください。 https://community.nxp.com/t5/ i-MX-プロセッサ/Encoding-H-264-amp-H-265-using-vpu-wrapper-h/mp/1347610   この情報がお役に立てば幸いです。   ありがとう、よろしく。 ドゥルヴィット・ヴァサヴァダ Re: IMX8mp gstreamer vpuenc_h264 set profile and level 同様に、デバイスはforce_key_frame ( V4L2_BUF_FLAG_KEYFRAME )が使用可能であると誤って宣伝しているようですが、実際には、私がそれを送信してもVPUによって完全に無視されているようです。 Re: IMX8mp gstreamer vpuenc_h264 set profile and level 関連して、NXPが私たちに嘘をついている別のCASEを見つけました:video_peak_bitrateは完全に無視されているのです!
View full article
多核项目设置额外的 MPU 区域 我一直在开发一个项目,该项目本质上是两个 SDK 示例的结合体。我一直在使用 RT1170-EVKB SDK,版本为 26.09.00。该项目的想法是采用多核示例和 LVGL 示例,让 M7 核心运行图形,然后与运行程序的 M4 核心进行通信。为此,我采用了 SDK 示例: 我的基础项目是 freertos_message_buffers(包括主缓冲区和辅助缓冲区)。然后我通过从 lvgl_guider_cm7 项目中复制和粘贴代码和驱动程序文件,慢慢地添加图形。 我保留了 lvgl_guider_cm7 mcux_config.h文件内容相同,以便它能够使用 PXP 和 VGLite。为了实现这一点,需要将帧缓冲区放置在非缓存位置。SDK 示例中使用的共享内存也需要放置在非缓存中。发生这种情况时,屏幕上会出现瑕疵(不应该出现在那里的物体上出现细线)。 我可以通过移除 __USE_SHMEM 预处理器来解决这个问题,但显然这会导致多核通信失败。我认为这是由于 BOARD_EarlyConfigMPU 函数引起的。函数内部有一个部分的内容如下: #elif defined(__MCUXPRESSO) #if defined(__USE_SHMEM) extern uint32_t __base_rpmsg_sh_mem; extern uint32_t __top_rpmsg_sh_mem; uint32_t nonCacheStart = (uint32_t)(&__base_rpmsg_sh_mem); uint32_t size = (uint32_t)(&__top_rpmsg_sh_mem) - nonCacheStart; #else extern uint32_t __base_NCACHE_REGION; extern uint32_t __top_NCACHE_REGION; uint32_t nonCacheStart = (uint32_t)(&__base_NCACHE_REGION); uint32_t size = (uint32_t)(&__top_NCACHE_REGION) - nonCacheStart; #endif 本节根据 __USE_SHMEM 预处理器定义了共享内存或常规非缓存的非缓存。函数后面部分对 MPU 区域进行了如下声明: volatile uint32_t i = 0; ... while ((size >> i) > 0x1U) { i++; } if (i != 0) { /* The MPU region size should be 2^N, 5<=N<=32, region base should be multiples of size. */ BOARD_EARLY_ASSERT(!(nonCacheStart % size)); BOARD_EARLY_ASSERT(size == (uint32_t)(1 << i)); BOARD_EARLY_ASSERT(i >= 5); /* Region 10 setting: Memory with Normal type, not shareable, non-cacheable */ MPU->RBAR = ARM_MPU_RBAR(BOARD_MPU_REGION_NONCACHE, nonCacheStart); MPU->RASR = ARM_MPU_RASR(0, ARM_MPU_AP_FULL, 1, 0, 0, 0, 0, i - 1); } 现在我希望能够在 MPU 中定义这两个区域,以便 LVGL 能够正常工作而不会出现瑕疵,并且 rpmsg 消息缓冲区能够进行通信。我的记忆区域如下: 我尝试修改上面的代码,使其能够同时定义两个 MPU 区域,如下所示: #elif defined(__MCUXPRESSO) extern uint32_t __base_NCACHE_REGION; extern uint32_t __top_NCACHE_REGION; uint32_t nonCacheStart = (uint32_t)(&__base_NCACHE_REGION); uint32_t nonCacheSize = (uint32_t)(&__top_NCACHE_REGION) - nonCacheStart; #if defined(__USE_SHMEM) extern uint32_t __base_rpmsg_sh_mem; extern uint32_t __top_rpmsg_sh_mem; uint32_t rpmsgShmemStart = (uint32_t)(&__base_rpmsg_sh_mem); uint32_t rpmsgShmemSize = (uint32_t)(&__top_rpmsg_sh_mem) - rpmsgShmemStart; #endif 这样一来,常规的非缓存区域始终会被定义,而共享内存区域仅在需要时才会被定义。我按如下方式修改了 MPU 区域定义: volatile uint32_t i = 0; ... while ((nonCacheSize >> i) > 0x1U) { i++; } if (i != 0) { /* The MPU region size should be 2^N, 5<=N<=32, region base should be multiples of size. */ BOARD_EARLY_ASSERT(!(nonCacheStart % nonCacheSize)); BOARD_EARLY_ASSERT(nonCacheSize == (uint32_t)(1 << i)); BOARD_EARLY_ASSERT(i >= 5); /* Region 10 setting: Memory with Normal type, not shareable, non-cacheable */ MPU->RBAR = ARM_MPU_RBAR(BOARD_MPU_REGION_NONCACHE, nonCacheStart); MPU->RASR = ARM_MPU_RASR(0, ARM_MPU_AP_FULL, 1, 0, 0, 0, 0, i - 1); } #if (__USE_SHMEM) i = 0; while ((rpmsgShmemSize >> i) > 0x1U) { i++; } if (i != 0) { /* The MPU region size should be 2^N, 5<=N<=32, region base should be multiples of size. */ BOARD_EARLY_ASSERT(!(rpmsgShmemStart % rpmsgShmemSize)); BOARD_EARLY_ASSERT(rpmsgShmemSize == (uint32_t)(1 << i)); BOARD_EARLY_ASSERT(i >= 5); /* Region 16 setting: Memory with Normal type, not shareable, non-cacheable */ MPU->RBAR = ARM_MPU_RBAR(BOARD_MPU_REGION_SHMEM, rpmsgShmemStart); MPU->RASR = ARM_MPU_RASR(0, ARM_MPU_AP_FULL, 1, 0, 0, 0, 0, i - 1); } #endif 为此,我在 board.h 中为额外的 MPU 区域创建了一个宏。就像这样: #define BOARD_MPU_REGION_SHMEM (16) /* rpmsg shared memory */ 进行这些修改后,LVGL 可以无瑕疵地绘制图形,但多核通信仍然失败。我在运行多核通信的 M4 线程中设置了一个断点。有时它会在启动时触发信号,通知它已收到消息,但消息数据不正确,因此不会执行与消息数据关联的代码。断点触发信号几次后,将不再触发。 我是否遗漏了什么才能让这个项目运行起来,例如 MPU 区域定义等等……? Re: Multicore Project setup of an additional MPU region 这些更改仅应用于主核心,因为主核心运行 BOARD_EarlyConfigMPU,而辅助核心运行 BOARD_ConfigMPU,辅助核心的函数已经具有我更改主核心的行为。以下是辅助核心在硬件初始化时运行的部分代码片段。 #elif __CORTEX_M == 4 void BOARD_ConfigMPU(void) { #if defined(__CC_ARM) || defined(__ARMCC_VERSION) ... #elif defined(__MCUXPRESSO) extern uint32_t __base_NCACHE_REGION; extern uint32_t __top_NCACHE_REGION; uint32_t nonCacheStart = (uint32_t)(&__base_NCACHE_REGION); uint32_t nonCacheSize = (uint32_t)(&__top_NCACHE_REGION) - nonCacheStart; #elif defined(__ICCARM__) || defined(__GNUC__) ... #endif #if defined(__USE_SHMEM) #if defined(__CC_ARM) || defined(__ARMCC_VERSION) ... #elif defined(__MCUXPRESSO) extern uint32_t __base_rpmsg_sh_mem; extern uint32_t __top_rpmsg_sh_mem; uint32_t rpmsgShmemStart = (uint32_t)(&__base_rpmsg_sh_mem); uint32_t rpmsgShmemSize = (uint32_t)(&__top_rpmsg_sh_mem) - rpmsgShmemStart; #elif defined(__ICCARM__) || defined(__GNUC__) ... #endif #endif 然后在函数的后面部分: uint32_t i = 0; /* Only config non-cacheable region on system bus */ assert(nonCacheStart >= 0x20000000); ... while ((nonCacheSize >> i) > 0x1U) { i++; } if (i != 0) { /* The MPU region size should be 2^N, 5<=N<=32, region base should be multiples of size. */ assert(!(nonCacheStart % nonCacheSize)); assert(nonCacheSize == (uint32_t)(1 << i)); assert(i >= 5); /* Region 0 setting: Memory with device type, not shareable, non-cacheable */ MPU->RBAR = ARM_MPU_RBAR(BOARD_MPU_REGION_NONCACHE, nonCacheStart); MPU->RASR = ARM_MPU_RASR(0, ARM_MPU_AP_FULL, 2, 0, 0, 0, 0, i - 1); } #if defined(__USE_SHMEM) i = 0; while ((rpmsgShmemSize >> i) > 0x1U) { i++; } if (i != 0) { /* The MPU region size should be 2^N, 5<=N<=32, region base should be multiples of size. */ assert(!(rpmsgShmemStart % rpmsgShmemSize)); assert(rpmsgShmemSize == (uint32_t)(1 << i)); assert(i >= 5); /* Region 1 setting: Memory with device type, not shareable, non-cacheable */ MPU->RBAR = ARM_MPU_RBAR(BOARD_MPU_REGION_RPMSG_SHMEM, rpmsgShmemStart); MPU->RASR = ARM_MPU_RASR(0, ARM_MPU_AP_FULL, 2, 0, 0, 0, 0, i - 1); } #endif 这两个项目的预处理器中都定义了 __USE_SHMEM。以下是辅助核心的内存配置: 我是否遗漏了什么,或者我的修改是否错误?我是否需要在主项目设置的“管理链接器脚本”部分添加一些额外的内容?有机会的话,我会上传一个包含 EVK-B 板上运行的项目的 .zip 文件,以便您可以查看/重现该问题。 Re: Multicore Project setup of an additional MPU region 嗨@CMoran , 你的理解很有道理,但是你提到的变化是否同时适用于 CM7 和 CM4 内核,这一点还不清楚。每个核心都有 board.h 的定义,它们使用各自的 MPU 配置在初始硬件初始化期间进行设置。如果您提到的更改仅针对主核心进行,则核心对内存区域的处理方式可能不一致,从而导致这些意外行为。 请验证更改是否已应用于两个核心,以确保 MPU 设置一致,并确保已为两个项目的预处理器定义设置 __USE_SHMEM。 Re: Multicore Project setup of an additional MPU region 这是 .zip 文件。其中包含 m7 和 m4 项目。我保留了修改前的样子,因为修改后也没起作用。在这个例子中,如果你打开一个终端并按下中间的按钮,m7 和 m4 内核都会打印一条消息。如前所述,屏幕上移动的设置图标包含许多瑕疵。 从 m7 项目中移除 __USE_SHMEM 预处理器将修复设置图标中的瑕疵,但多核通信将会失败。 添加我上面应用的修改后,设置图标也会修复,但多核通信将会失败。 本演示中使用的屏幕是 RK055HDMIPI4MA0。 Re: Multicore Project setup of an additional MPU region 遗憾的是,在创建新的内存区域定义之前: #define BOARD_MPU_REGION_SHMEM (16) /* rpmsg shared memory */ 我只是重复使用了预定义的非缓存内存区域: #define BOARD_MPU_REGION_NONCACHE (10) /* Noncacheable space in application */ 我的结果也一样。我已经将新的内存区域定义更改为10 ,以匹配非缓存区域。核心之间始终无法通信。 我用断点检查了两个核心上 rpmsg 共享内存的起始位置和大小,它们的起始位置 (0x20340000) 和大小 (0x10000) 都正确。我已将两个核心上的 ARM_MPU_RASR() 函数的第 4 个参数更改为1 ,以表明该区域是“可共享的”。还是没找到办法。当您或团队成员有空时,我会在另一个回复中发布我的项目代码。我已经想不出还能尝试什么了。 Re: Multicore Project setup of an additional MPU region 嗨@CMoran , 知道了。不过,回到你最初的回复: 您提到您创建了一个新的内存区域定义: #define BOARD_MPU_REGION_SHMEM (16) /* rpmsg shared memory */ 但是 ARM_MPU_RBAR() 的定义使用了 MPU_RBAR_REGION_Msk,其定义为 15: #define MPU_RBAR_REGION_Msk (0xFUL /*<< MPU_RBAR_REGION_Pos*/) CM7 将区域数量定义为 16 个,编号为 0-15。 因此,这样做实际上是将区域 0 设置到该区域。
View full article
Multicore Project setup of an additional MPU region I've been working on making a project that is essentially a combination of 2 SDK examples. I've been using the RT1170-EVKB SDK, version 26.09.00. The idea of the project is to take a multicore example and an LVGL example to have the M7 core run the graphics then communicate with the M4 core running the program. To do this I have taken the SDK examples: freertos_message_buffers (both primary and secondary) as my base project. I then slowly add in the graphics by copying and pasting the code and driver files from the lvgl_guider_cm7 project. I keep lvgl_guider_cm7 mcux_config.h file the same so that it does use PXP and VGLite. In order to do this, framebuffers need to placed in non-cache. The shared memory used in the SDK example also needs to be placed in non-cache. When this happens, I get artifacts on the display (little lines through objects that shouldn't be there). I can fix this by removing the __USE_SHMEM preprocessor, obviously this causes the multicore communication to fail. I believe it is because of the BOARD_EarlyConfigMPU function. Inside the function there is a section that goes like: #elif defined(__MCUXPRESSO) #if defined(__USE_SHMEM) extern uint32_t __base_rpmsg_sh_mem; extern uint32_t __top_rpmsg_sh_mem; uint32_t nonCacheStart = (uint32_t)(&__base_rpmsg_sh_mem); uint32_t size = (uint32_t)(&__top_rpmsg_sh_mem) - nonCacheStart; #else extern uint32_t __base_NCACHE_REGION; extern uint32_t __top_NCACHE_REGION; uint32_t nonCacheStart = (uint32_t)(&__base_NCACHE_REGION); uint32_t size = (uint32_t)(&__top_NCACHE_REGION) - nonCacheStart; #endif In this section it defines non-cache for either the shared memory or regular non-cache based on the __USE_SHMEM preprocessor. Further down in the function it declares the MPU region like so: volatile uint32_t i = 0; ... while ((size >> i) > 0x1U) { i++; } if (i != 0) { /* The MPU region size should be 2^N, 5<=N<=32, region base should be multiples of size. */ BOARD_EARLY_ASSERT(!(nonCacheStart % size)); BOARD_EARLY_ASSERT(size == (uint32_t)(1 << i)); BOARD_EARLY_ASSERT(i >= 5); /* Region 10 setting: Memory with Normal type, not shareable, non-cacheable */ MPU->RBAR = ARM_MPU_RBAR(BOARD_MPU_REGION_NONCACHE, nonCacheStart); MPU->RASR = ARM_MPU_RASR(0, ARM_MPU_AP_FULL, 1, 0, 0, 0, 0, i - 1); } Now I want to be able to define both regions in the MPU to have both LVGL working without artifacts and the rpmsg message buffers be able to communicate. My memory regions can be found below: What I tried to do was modify the code above to perform both MPU region definitions, like so: #elif defined(__MCUXPRESSO) extern uint32_t __base_NCACHE_REGION; extern uint32_t __top_NCACHE_REGION; uint32_t nonCacheStart = (uint32_t)(&__base_NCACHE_REGION); uint32_t nonCacheSize = (uint32_t)(&__top_NCACHE_REGION) - nonCacheStart; #if defined(__USE_SHMEM) extern uint32_t __base_rpmsg_sh_mem; extern uint32_t __top_rpmsg_sh_mem; uint32_t rpmsgShmemStart = (uint32_t)(&__base_rpmsg_sh_mem); uint32_t rpmsgShmemSize = (uint32_t)(&__top_rpmsg_sh_mem) - rpmsgShmemStart; #endif This way the regular non-cache region is always defined and the shared memory region is only defined if used. I modified the MPU region definition like so: volatile uint32_t i = 0; ... while ((nonCacheSize >> i) > 0x1U) { i++; } if (i != 0) { /* The MPU region size should be 2^N, 5<=N<=32, region base should be multiples of size. */ BOARD_EARLY_ASSERT(!(nonCacheStart % nonCacheSize)); BOARD_EARLY_ASSERT(nonCacheSize == (uint32_t)(1 << i)); BOARD_EARLY_ASSERT(i >= 5); /* Region 10 setting: Memory with Normal type, not shareable, non-cacheable */ MPU->RBAR = ARM_MPU_RBAR(BOARD_MPU_REGION_NONCACHE, nonCacheStart); MPU->RASR = ARM_MPU_RASR(0, ARM_MPU_AP_FULL, 1, 0, 0, 0, 0, i - 1); } #if (__USE_SHMEM) i = 0; while ((rpmsgShmemSize >> i) > 0x1U) { i++; } if (i != 0) { /* The MPU region size should be 2^N, 5<=N<=32, region base should be multiples of size. */ BOARD_EARLY_ASSERT(!(rpmsgShmemStart % rpmsgShmemSize)); BOARD_EARLY_ASSERT(rpmsgShmemSize == (uint32_t)(1 << i)); BOARD_EARLY_ASSERT(i >= 5); /* Region 16 setting: Memory with Normal type, not shareable, non-cacheable */ MPU->RBAR = ARM_MPU_RBAR(BOARD_MPU_REGION_SHMEM, rpmsgShmemStart); MPU->RASR = ARM_MPU_RASR(0, ARM_MPU_AP_FULL, 1, 0, 0, 0, 0, i - 1); } #endif In doing this I created a macro for the additional MPU region inside board.h like so: #define BOARD_MPU_REGION_SHMEM (16) /* rpmsg shared memory */ Performing the modifications allowed LVGL to draw without artifacts but the multicore communication still fails. I put a breakpoint in the M4 thread running the multicore communication. Sometimes it'll trigger at the start, notifying that it received a message, but the message data is incorrect so it will not execute the code associated with the message's data. After a couple triggers of the breakpoint it will never trigger again. Is there anything I'm missing to be able to get this project running, the MPU region defines, etc...? Re: Multicore Project setup of an additional MPU region The changes were only applied to the primary core, as the primary core runs BOARD_EarlyConfigMPU and the secondary core runs BOARD_ConfigMPU, in the secondary core's function it already has the behaviour that I changed the primary core to have. Below are snippets from the what the secondary core runs on hardware init. #elif __CORTEX_M == 4 void BOARD_ConfigMPU(void) { #if defined(__CC_ARM) || defined(__ARMCC_VERSION) ... #elif defined(__MCUXPRESSO) extern uint32_t __base_NCACHE_REGION; extern uint32_t __top_NCACHE_REGION; uint32_t nonCacheStart = (uint32_t)(&__base_NCACHE_REGION); uint32_t nonCacheSize = (uint32_t)(&__top_NCACHE_REGION) - nonCacheStart; #elif defined(__ICCARM__) || defined(__GNUC__) ... #endif #if defined(__USE_SHMEM) #if defined(__CC_ARM) || defined(__ARMCC_VERSION) ... #elif defined(__MCUXPRESSO) extern uint32_t __base_rpmsg_sh_mem; extern uint32_t __top_rpmsg_sh_mem; uint32_t rpmsgShmemStart = (uint32_t)(&__base_rpmsg_sh_mem); uint32_t rpmsgShmemSize = (uint32_t)(&__top_rpmsg_sh_mem) - rpmsgShmemStart; #elif defined(__ICCARM__) || defined(__GNUC__) ... #endif #endif And then later in the function: uint32_t i = 0; /* Only config non-cacheable region on system bus */ assert(nonCacheStart >= 0x20000000); ... while ((nonCacheSize >> i) > 0x1U) { i++; } if (i != 0) { /* The MPU region size should be 2^N, 5<=N<=32, region base should be multiples of size. */ assert(!(nonCacheStart % nonCacheSize)); assert(nonCacheSize == (uint32_t)(1 << i)); assert(i >= 5); /* Region 0 setting: Memory with device type, not shareable, non-cacheable */ MPU->RBAR = ARM_MPU_RBAR(BOARD_MPU_REGION_NONCACHE, nonCacheStart); MPU->RASR = ARM_MPU_RASR(0, ARM_MPU_AP_FULL, 2, 0, 0, 0, 0, i - 1); } #if defined(__USE_SHMEM) i = 0; while ((rpmsgShmemSize >> i) > 0x1U) { i++; } if (i != 0) { /* The MPU region size should be 2^N, 5<=N<=32, region base should be multiples of size. */ assert(!(rpmsgShmemStart % rpmsgShmemSize)); assert(rpmsgShmemSize == (uint32_t)(1 << i)); assert(i >= 5); /* Region 1 setting: Memory with device type, not shareable, non-cacheable */ MPU->RBAR = ARM_MPU_RBAR(BOARD_MPU_REGION_RPMSG_SHMEM, rpmsgShmemStart); MPU->RASR = ARM_MPU_RASR(0, ARM_MPU_AP_FULL, 2, 0, 0, 0, 0, i - 1); } #endif Both projects have __USE_SHMEM defined in the preprocessor. Below is the memory config for the secondary core: Am I missing something else, or perhaps are my modifications wrong? Do I need to add something extra to the "Manage Linker Script" section of the primary project's settings? When I get the chance I'll upload a .zip of the projects that run on the EVK-B board so that you may see/replicate the issue. Re: Multicore Project setup of an additional MPU region Hi @CMoran, Your understanding makes sense, but it wasn't clear if that changed you mention were applied to both CM7 and CM4 cores. Each core has a definition of board.h, where they use their respective configuration of the MPU to setup during the initial hardware initialization. If the changes you mention were only made for the primary core, it's likely that the cores don't treat the memory regions equally, resulting in these unexpected behaviors. Please verify that the changes are applied to both cores to ensure they coincide on MPU setup, as well as ensuring that __USE_SHMEM was setup for both project's preprocessor definitions. Re: Multicore Project setup of an additional MPU region Here's the .zip with the m7 and m4 projects within. I've left it to be before my modifications, as the modifications didn't work anyway. In this example if you open a terminal and push the button in the center, both the m7 and m4 cores will print a message. The settings icon moving around the screen has a bunch of artifacts in it as described. Removing the __USE_SHMEM preprocessor from the m7 project will fix the artifacts in the settings icon, but the multicore communication will fail. Adding the modifications I've applied above will also fix the settings icon, but the multicore communication will fail. Screen used in this demo is the RK055HDMIPI4MA0. Re: Multicore Project setup of an additional MPU region Hi @CMoran, Got it. Going back on your first reply though: You mentioned that you created a new definition for a memory region: #define BOARD_MPU_REGION_SHMEM (16) /* rpmsg shared memory */ But the definition of ARM_MPU_RBAR() uses MPU_RBAR_REGION_Msk, which is defined as 15: #define MPU_RBAR_REGION_Msk (0xFUL /*<< MPU_RBAR_REGION_Pos*/)  The CM7 defines the number of regions as 16, numbered 0-15. Therefore, you are actually setting region 0 by doing so. Re: Multicore Project setup of an additional MPU region Unfortunately before creating the new memory region definition: #define BOARD_MPU_REGION_SHMEM (16) /* rpmsg shared memory */ I was just reusing the predefined memory region for non-cache: #define BOARD_MPU_REGION_NONCACHE (10) /* Noncacheable space in application */ And I had the same result. I've changed my new memory region definition to be 10 now to match the non-cache. With no luck on the cores being able to communicate. I've checked the start location and the size of the rpmsg shared memory on both cores with breakpoints, both have the correct start (0x20340000) and size (0x10000). I've changed the 4th parameter of the ARM_MPU_RASR() function on both cores to 1 to indicate that the region is "shareable". No luck there still. When you or a member of the team gets a chance, I posted my project's code in another reply. I'm running out of ideas of what to try.
View full article
需要MBD职业建议 5年前我开始从事汽车软件的基于模型的设计工作,现在我觉得这份工作非常单调,而且在工具方面也没有太多学习机会,你是如何应对这种情况的? 我每月可能参与的工作量可能是:10% 用于 Simulink 建模,50% 用于测试这些模型和报告,其余时间用于手动编写合规性文档。
View full article
故障したimxrt1024ボードを復旧する 1枚の基板が故障してしまい、以下の手順で復旧を試みました。 1. ブートモードをシリアルダウンローダーモードに変更します。 2. UART経由でチップを消去し、その後、正常なブート可能なイメージ(led_blinky)をフラッシュします。 3. ブートモードを再度変更しますが、デバイスは復旧しません。 j-link commanderを使っていますが、この問題が発生しています 「ロードビン」:MCUの暗黙のリセットおよび停止を実行すること。 ResetTarget() 開始 フラッシュ画像の検証でコアは停止しませんでした。フラッシュ設定の誤りを想定します。 ターゲットを手動で停止します。 ResetTarget() 終了 - 329ms かかりました デバイス固有のリセットが実行されました。 AfterResetTarget() 開始 MPUは有効化されていましたが、現在は無効化されています。 AfterResetTarget() 終了 - 2.92ms かかりました ファイル [C:\M7Binaties Prep\Secure Boot extebeded implementation\M7SafetBoot+Combined_SignedPackage.bin] をダウンロードしています... フラッシュメモリのプログラミング中にエラーが発生しました: プログラミングに失敗しました。 さらに、もう一つ気づいた点があります。 1. デバイスをシリアルダウンローダーモードに設定します。 2. LED点滅画像を点滅させる。 3. 画像をシリアルモードのみで読み返す 4. バイナリが正常にフラッシュされているのが確認できます その後、内部起動モードに切り替えました 5. J_Flashで読み返すと、フラッシュ全体の領域が0になります 今どうすればいいのか、なぜ回復できないのか Re: Recover bricked imxrt1024 board こんにちは、 @Abhay2080 さん。 より良くサポートするために、以下の詳細を教えていただけますか? 現在、カスタムボードをお使いですか、それとも弊社のEVKをお使いですか? LED点滅のサンプルは、点滅させる前に変更されましたか? この機器で以前にヒューズが焼損したことはありますか? J-Linkのログを見ると、署名付きイメージをフラッシュしようとしているようです。このマザーボードで以前にセキュアブートが有効になっていたことはありますか? 現在、セキュアプロビジョニングツールを使用してイメージの書き込みと一括消去を実行していますか? 「 ターゲットプロセッサとの接続 」機能を使ってデバッガ接続をテストして、結果を教えていただけますか? BR ハビブ Re: Recover bricked imxrt1024 board 1. カスタムボード。 2. LED点滅は変更されていません。私の作業中のプロジェクトでも試してみました。 3. はい、デバイスでHABが有効になっています。SEC_CONFIGとSRK_HASHは融合されています 4. はい、HABは有効になっています。 5. はい、SPTは使用されています。 6. はい、ターゲットに接続できます Re: Recover bricked imxrt1024 board こんにちは、 @Abhay2080。 HABが有効であるため、イメージは秘密鍵で署名され、対応する公開鍵をプログラムイメージ内に含めなければなりません。これはリファレンス・マニュアルの第9.2章「概要」に記載されています。参照ハッシュ値とフラッシュでソフトウェアから計算された現在のハッシュ値との比較が一致しない場合、または画像に署名されていない場合、認証が失敗し、RMの第7.3.1章「HABプロセスフロー」に記載されているようにデバイスが起動しません。 LEDの点滅サインを正しいキーで点滅させているか確認していただけますか?また、この画像に署名した手順とHABを有効にした方法を教えていただけますか? また、HABを有効にした直後にエラーが発生したのかも教えてもらえますか? BR ハビブ Re: Recover bricked imxrt1024 board こんにちは@Habib_MS  HABが有効になっているので署名済みイメージのみが起動できることは理解していますが、問題は画像をフラッシュできないことです。 また、SPT を使用してフラッシュを消去しているときに、フラッシュ領域全体 4MB を選択しているにもかかわらず、ログに「検出された消去可能なブロック サイズ: 0x1000」と表示されるという観察結果があります。スクリーンショットを添付しましたのでご確認ください。 さらに、署名付きLED点滅イメージも試しましたが、それでもボードは復旧しませんでした。 Re: Recover bricked imxrt1024 board こんにちは、 @Abhay2080 さん。 この消去可能ブロックサイズは、最小の消去可能ブロックサイズを定義します。この値は、FCBが利用可能な場合はFCBから、FCBを使用しないメモリの場合はブートメモリ構成から読み取られます。Flash Programmerのセクションで説明したとおりです。SPTはメモリ全域のすべてのセクターを消去するため、4MBのフラッシュ全体が消去されます。 問題がJ-Flashプログラミングアルゴリズムに関連しているかどうか判断するために、認証済み (HAB)イメージの起動 手順を事前に構築された.s19を使用してご確認いただけますか「mimxrt1024evk_iled_blinky_flash.s19」というファイルが正しいキーで署名されているか確認して、結果を教えてください。 BR ハビブ Re: Recover bricked imxrt1024 board こんにちは、 @Habib_MS さん。おっしゃる通り、iled_blink.s19 署名付きイメージを試して、イメージを書き込んでみました。以下は私が実行した手順です イメージを書き込んだのですが、J-flashを使ってバイナリをフラッシュすることができません。
View full article
Number of supported endpoints on the iMX8 The iMX8 uses the DWC3 for USB, which is an xHCI controller. When I read out the register from iMX8 i can figure out, that it may support up to 64 devices. But when I attach a few devices I much earlier on run in xHCI resource error. It seems there is some kind of a limitation on the number of endpoints, and it also seems that it depends on the type of transfer type (Bulk, Control, ...). On the type of devices I use (includsing the hubs) it seem I run after 80 endpoints into the problem. Could you please provide some exact numbers/formula how many endpoints are supported.
View full article
Correct snvs_cfg values for TAMPER_OUT0/TAMPER_IN4 active tamper loop on i.MX8DXL EVK (J20) Hi, I'm validating the external active-tamper loop on the i.MX8DXL EVK (MCIMX8DXL-WEVK) via U-Boot. From the board schematic, I've confirmed J20 (TAMPER header, 1x3) is wired as: - Pin 1 = TAMPER_IN4 (net SNVS.TAMPER_IN4, ball AJ13) - Pin 2 = GND - Pin 3 = TAMPER_OUT0 (net SNVS.TAMPER_OUT0, ball AP22) These are dedicated SNVS pins, not shared with SAI2/SAI3 like TAMPER_OUT1-4/IN0-3. Available U-Boot commands: tamper_pin_cfg, snvs_cfg (with sub-registers hp.lock, hp.secvio_intcfg, hp.secvio_ctl, lp.lock, lp.secvio_ctl, lp.tamper_filt_cfg, lp.tamper_det_cfg, lp.tamper_det_cfg2, lp.tamper_filt1_cfg, lp.tamper_filt2_cfg, lp.act_tamper1_cfg through lp.act_tamper5_cfg, lp.act_tamper_ctl, lp.act_tamper_clk_ctl, lp.act_tamper_routing_ctl1, lp.act_tamper_routing_ctl2), snvs_sec_status, snvs_clear_status. Since TAMPER_OUT0/TAMPER_IN4 form an active tamper pair, my questions: 1. Which lp.act_tamperN_cfg channel (1-5) corresponds to TAMPER_OUT0? 2. What values for lp.act_tamper_routing_ctl1/routing_ctl2 route TAMPER_OUT0's pattern to be checked against TAMPER_IN4? 3. What value for lp.act_tamper_clk_ctl enables the pattern clock for this channel? 4. What value for lp.act_tamper_ctl globally enables active tamper detection for this channel? Goal: closing a jumper across J20 pins 1-3 should read as secure in snvs_sec_status, and opening it should trigger a violation. I've attempted several values on hardware (routing 4, 5, 10; various clock/detector settings) — all were either rejected by the SECO firmware (error res:9 / SC_ERR_PARM) or accepted with no observable change in snvs_sec_status's SNVS a4(1) (LPTDSR) register when physically toggling the loop. Is there a reference test procedure or app note for external active tamper validation on i.MX8DXL? Thanks! Re: Correct snvs_cfg values for TAMPER_OUT0/TAMPER_IN4 active tamper loop on i.MX8DXL EVK (J20) Hello, 1. lp.act_tamper1_cfg drives TAMPER_OUT0. 2. The i.MX8DXL SNVS has 5 Active Tamper (AT) output sources and up to 8 External Tamper (ET) input detectors. Please use this configuration: lp.act_tamper_routing_ctl1 = 0x00010000 # ET5 (TAMPER_IN4) to AT1 (TAMPER_OUT0) lp.act_tamper_routing_ctl2 = 0x00000000 # ET6-ET8 not used 3. That value changes the clock divider, use 0x00 for maximum frequency configuration. lp.act_tamper_clk_ctl = 0x00000000 4. Use lp.act_tamper_ctl = 0x00010001: Bit 0: AT1EN enable AT1 LFSR pattern generator Bit 16: AT1_OUT_EN drive TAMPER_OUT0 pad with AT1 pattern There is no application note available for this processor but you can use this from an i.MX7 that can be used as reference: /* Config ET5 (pin in et4) <-> (pin out et5) AT 1 * /* reset */ write32(0, &svregs->lp.act_tamper_clk_ctl); write32(0, &svregs->lp.act_tamper_ctl); write32(0, &svregs->lp.tamper_det_cfg); write32(0, &svregs->lp.tamper_det_cfg2) /* Deault value for LFSR */ write32(0x84000000 | 0x00001111, &svregs->lp.act_tamper1_cfg) /* Set the clock at max freq */ write32(0x00000000, &svregs->lp.act_tamper_clk_ctl); /* ET5 (pin et4) takes ref from AT1 (pin et5) */ write32(0x00010000, &svregs->lp.act_tamper_routing_ctl1); write32(0x0, &svregs->lp.act_tamper_routing_ctl2) /* activate out pad of AT1 and enable it, AT1 output on pin et5 */ write32(0x00010000 | 0x00000001, &svregs->lp.act_tamper_ctl) /* Configuring IRQs and secviols */ write32(0x8000003f, &svregs->hp.secvio_intcfg); write32(0x4000003f, &svregs->hp.secvio_ctl); write32(0x0000003f, &svregs->lp.secvio_ctl) /* Activating detector for ET5 */ write32(0x00000000, &svregs->lp.tamper_det_cfg); write32(0x00000004, &svregs->lp.tamper_det_cfg2); Best regards. Re: Correct snvs_cfg values for TAMPER_OUT0/TAMPER_IN4 active tamper loop on i.MX8DXL EVK (J20) Thank you for the configuration. I applied it exactly on a fresh power cycle: snvs_dgo_cfg 0 0 20000000 0 80000000 0 snvs_cfg 0 8000003f 4000003f 0 3f 0 0 4 0 0 84001111 0 0 0 0 10001 0 10000 0 Readback matches your values: SNVS e8(2) = 00010000 00000000, SNVS 48(2) = 00000000 00000004, SNVS e0 = 00010001, DGO 20 = 20000000, DGO 40 = 80000000. Result: LPTDSR (SNVS a4) = 00000004 (ET5D set). It reads 00000004 both with no jumper and with an insulated jumper connected between J20 pin 1 (TAMPER_IN4) and pin 3 (TAMPER_OUT0). It also stays 00000004 after snvs_clear_status 107ff ff. So detection asserts with the loop open, but I never get a clean 00000000 state with the loop closed. Questions: 1. Does the TAMPER_OUT0 / TAMPER_IN4 loop on this EVK need a pad or pull setting (for example DGO tamper_pull_ctl), or a different act_tamper_clk_ctl value, for a wired-jumper loop? 2. Is snvs_clear_status expected to clear LPTDSR while the tamper condition is still present? 3. Is any other setting needed for the loop to be seen as closed? Thanks again. Re: Correct snvs_cfg values for TAMPER_OUT0/TAMPER_IN4 active tamper loop on i.MX8DXL EVK (J20) Following up on our last update on this case (Project: Cryptographic Module). We have reviewed the setup with our team lead. We verified the hardware (J20 pin mapping from schematic SCH-54318, jumper loop between pin 1 and pin 3) and the SNVS configuration (register readback matches the values you gave). We also followed the sequence you shared, which is based on the i.MX7 reference. The result is unchanged: - Active configuration: LPTDSR (SNVS a4) = 0x00000004 (ET5D) and it does not clear, with or without the jumper. - Passive ET5 tests: a4 does not change with the pin level. We would appreciate your help with three points: 1. Could you please answer the questions in our previous update (passive ET5 enable and polarity settings, DGO settings, and how to confirm that AT1 is toggling)? 2. Could you please share the i.MX 8DXL Security Reference Manual (at least the SNVS tamper chapters), or tell us the process to get access, including any NDA requirement? 3. Do you have a sample U-Boot command sequence that has been verified on the i.MX8DXL EVK? Thank you for your support. Re: Correct snvs_cfg values for TAMPER_OUT0/TAMPER_IN4 active tamper loop on i.MX8DXL EVK (J20) Hello,  Please refer to the attached validated tamper test procedure on i.MX8DXL board and the corresponding active/passive tamper logs. You can also refer to the uboot source code for examples of how the SNVS registers are configured for active and passive tamper.  https://github.com/nxp-imx/uboot-imx/blob/lf_v2026.04/arch/arm/mach-imx/imx8/snvs_security_sc_conf_8dxl_evk.h Please note that the TAMPER_IN4 is mapped to ET7 rather than ET5. When using TAMPER_IN4  for passive/active tamper tests,  ET7 detections need to be enabled accordingly. I don't expect the SECO/SCFW version to have a big impact, please try the provided configuration and test steps and see if it works for you. Regarding how to get access to security reference manual, please request it on the next link. Best regards.
View full article
Mbd Career Advice needed I started my career on Model Based Design of Automotive software 5 years ago and now I feel that its very monotonous and not much learning on the tools side, how have you tackled this situation? The quantum of work that I might be involved in a monthly basis might be 10% on simulink modelling , 50% on testing these models and reporting and the rest on manual compliance docs.
View full article