Schematics of MPC5775B BMS & VCU Reference Design Unit Hey, I wanted to look into which pins in the MPC5775B MCU is connected to the digital and analog outputs available via the BMS & VCU reference design. But could not find schematics on that. Can I get it or possibly the link to it ? I am trying to figure out which of the Inputs pins exposed through the reference unit can do interrupt handling. Re: Schematics of MPC5775B BMS & VCU Reference Design Unit Hello, Schematic is available at our web page: https://www.nxp.com/design/design-center/development-boards-and-designs/mpc5775b-bms-and-vcu-reference-design:RDVCU5775EVM?gad_source=1&gad_campaignid=24081577422&gclid=CjwKCAjwj7HTBhBiEiwA8s35OtHxPgln7wwf_p2BF5JDZ9GfWkdapC4yCnvxXk9Tp2NOHHSZHxyrSRoCk8IQAvD_BwE On page 12 are analog inputs and on page 14 digital inputs. Best regards, Peter

MPC5775B 电池管理系统 & 整车控制器VCU 参考设计单元原理图 嘿， 我想了解 MPC5775B MCU 中的哪些引脚连接到电池管理系统和整车控制器VCU参考设计中提供的数字和模拟输出。但找不到相关的原理图。我可以得到它或者它的链接吗？我正在尝试弄清楚参考单元暴露出的哪些输入引脚可以进行中断处理。 Re: Schematics of MPC5775B BMS & VCU Reference Design Unit 你好， 原理图可在我们的网页上找到： https://www.nxp.com/design/design-center/development-boards-and-designs/mpc5775b-bms-and-vcu-reference-design:RDVCU5775EVM?gad_source=1&gad_campaignid=24081577422&gclid=CjwKCAjwj7HTBhBiEiwA8s35OtHxPgln7wwf_p2BF5JDZ9GfWkdapC4yCnvxXk9Tp2NOHHSZHxyrSRoCk8IQAvD_BwE 第 12 页是模拟输入，第 14 页是数字输入。 顺祝商祺！ Peter

Zephyr 中对 i.MX95 FRDM EVK 的 HDMI 配置支持 您好，NXP团队： 我目前正在使用 Zephyr RTOS 在i.MX95 FRDM EVK板上进行开发。 Linux 系统方面，HDMI 输出已经得到支持，并且运行正常。但是，我想知道如何在 Zephyr 中启用和配置 HDMI。 请问您能否指导我完成以下事项？ Zephyr 是否支持 i.MX95 FRDM EVK 的 HDMI 输出？ 如果需要，需要哪些驱动程序和设备树配置？ Zephyr 上是否有 HDMI 的参考实现或示例应用程序？ 任何指导或文件都将不胜感激。 谢谢！ Re: HDMI Configuration Support in Zephyr for i.MX95 FRDM EVK 我已向AE团队确认过。 IMX95 Zephyr 目前不支持 HDMI。 Re: HDMI Configuration Support in Zephyr for i.MX95 FRDM EVK 您好，NXP团队： 我正在寻找IT6263参考手册或寄存器编程手册。 请问您能否分享 IT6263 HDMI 桥接器的详细寄存器描述（带有位级定义的寄存器映射），或者告诉我如何才能获得这些文档？ 注意：我需要的是芯片级寄存器文档，而不是 Linux 内核驱动程序源代码。 谢谢你， 卡尔蒂凯扬·M Re: HDMI Configuration Support in Zephyr for i.MX95 FRDM EVK IT6263 不是 NXP 的产品，因此 NXP 不提供该设备的参考手册。有关配置和初始化的详细信息，您可以参考 IT6263 Linux 驱动程序源代码。 Re: HDMI Configuration Support in Zephyr for i.MX95 FRDM EVK 感谢您的回复。 请问能否提供Arm技术支持的具体联系邮箱或支持门户网站？如果您有直接联系人或合适的电子邮件地址，那将非常有帮助。我会就此事与他们联系。 Re: HDMI Configuration Support in Zephyr for i.MX95 FRDM EVK 感谢您的回复以及提供的 Arm 支持链接。 我将联系 Arm 支持部门，以获取 Arm Mali-G310 技术参考手册和 CSF/固件接口文档。 Re: HDMI Configuration Support in Zephyr for i.MX95 FRDM EVK Arm 支持中心： https://support.arm.com/support-cases   支持咨询表单： https://www.arm.com/company/contact-us/support-inquiries Re: HDMI Configuration Support in Zephyr for i.MX95 FRDM EVK 我已经成功地将 HDMI 移植到 Zephyr 操作系统上，目前它正在 CPU 上运行。我的下一个目标是将其移植到GPU上运行。 为此，我需要Arm Mali-G310技术参考手册，特别是其中的CSF/固件接口部分。我应该向NXP技术支持索取这份文档，还是需要直接联系Arm技术支持？ 如果能查阅这份参考手册，对于在 Zephyr 上实现 GPU 移植将非常有帮助。 Re: HDMI Configuration Support in Zephyr for i.MX95 FRDM EVK 请直接联系Arm 支持团队。 Re: HDMI Configuration Support in Zephyr for i.MX95 FRDM EVK 感谢您提供的 Arm 门户网站和 i.MX 图形用户指南的链接。我们两种都看过，但它们都不能满足我们的需求。这些指南解释了如何在 Linux 下使用 GPU，而我们正在 i.MX95 上编写我们自己的底层 GPU 驱动程序（裸机，使用 Zephyr，而不是 Linux）。因此，我们需要比这些文件提供的更低层级、登记级别的信息。 我们在 ARM 门户网站上搜索了 TRM，但找不到。 简而言之，我们的情况是这样的：   我们已经让 Mali-G310 GPU 运行到一定程度。GPU 已正确检测、通电、RESET，并且我们已成功将 GPU 固件加载到内存中。到目前为止，一切运行正常，并且已经过验证。   我们卡在了其中一个步骤：启动 GPU 的固件微控制器（MCU）。启用后，它的状态始终为“已禁用”，并且永远不会开始运行。没有错误提示，也没有中断提示——就是无法启动。   Re: HDMI Configuration Support in Zephyr for i.MX95 FRDM EVK NXP团队您好， 我联系了 Arm 技术支持索取所需文档，他们回复如下： “如果您发现NXP芯片出现任何问题，请联系NXP技术支持。”再次强调，这些文件不应该提供给芯片供应商的客户。 根据他们的回复，我正在联系恩智浦半导体寻求帮助。 我已经成功在 Zephyr OS 上启用了 HDMI，它目前正在使用 CPU 运行。我的下一个目标是启用基于GPU的渲染。 要继续进行，我需要 Arm Mali-G310 技术参考手册，特别是 CSF/固件接口文档。 由于 Mali-G310 GPU 集成在 NXP i.MX95 平台中，请问我如何才能获得该文档？如果无法共享该文档，我希望得到任何其他指导或参考，引用，以帮助我继续在 Zephyr 上启动 GPU。 Re: HDMI Configuration Support in Zephyr for i.MX95 FRDM EVK 请查看以下信息是否对您有所帮助。如果没有，我需要联系AE团队。 Arm Mali-G310 技术参考手册可从 Arm 的文档门户获取：在 Arm Developer / Arm Documentation 中搜索“Mali-G310 技术参考手册”或“Mali-G310 TRM” 。根据访问级别，可能需要 Arm 帐户或接受 Arm 文档条款。 对于 NXP i.MX95 的工作，NXP 的公开文档通过i.MX 图形用户指南指向 Mali-G310 GPU，而 FRDM-i.MX95 入门页面链接提供了有关 GPU 使用详情的指南。FRDM-i.MX95 页面显示该板配备Mali-G310 GPU ，并提供了i.MX 图形用户指南的链接，以便了解更多详情： https://www.nxp.com/docs/en/user-guide/UG10159.pdf 从这里开始： Arm 文档门户： https://developer.arm.com/documentation NXP i.MX 图形处理器用户指南： https://www.nxp.com/docs/en/user-guide/UG10159.pdf Re: HDMI Configuration Support in Zephyr for i.MX95 FRDM EVK 您好，NXP团队， 我联系了 Arm 技术支持索取所需文档，他们回复如下： “如果您发现NXP芯片出现任何问题，请联系NXP支持部门。”再次强调，这些文件不应该提供给芯片供应商的客户。 根据他们的回复，我正在联系恩智浦半导体寻求帮助。 我已经成功在 Zephyr OS 上启用了 HDMI，它目前正在使用 CPU 运行。我的下一个目标是启用基于GPU的渲染。 要继续进行，我需要Arm Mali-G310 技术参考手册，特别是CSF/固件接口文档。 由于 Mali-G310 GPU 集成在 NXP i.MX95 平台中，请问我如何才能获得该文档？如果无法共享该文档，我希望得到任何其他指导或参考，引用，以帮助我继续在 Zephyr 上启动 GPU。 Re: HDMI Configuration Support in Zephyr for i.MX95 FRDM EVK 请参考AE团队的以下更新。 关于 Arm Mali-G310 TRM，本文档属于 Arm 机密知识产权。NXP 不允许将其转发给最终客户，因此基本上无法通过 NXP 渠道获得。正式请求必须直接通过 Arm 公司提出，这需要很长时间，而且不太可能获得批准。此外，i.MX95 GPU 仍处于预生产阶段，因此目前还没有官方验证的裸机/Zephyr 参考，引用。 关于启用后 MCU 保持“禁用”状态的问题，此步骤不需要 TRM。完整的启动流程可在以下两个公开来源中找到，这两个来源均可直接在 GitHub 上访问： Panthor — 主线驱动程序，主要关注的驱动程序（它实际上启动了 MCU 并支持 i.MX95）： https://github.com/torvalds/linux/tree/master/drivers/gpu/drm/panthor kbase — Arm 的官方驱动程序，用于交叉检查： https://github.com/JeffyCN/mirrors/blob/kernel/drivers/gpu/arm/bifrost/csf/mali_kbase_csf_firmware.c

BMSおよびVCUリファレンスデザインユニットMPC5775B回路図 こんにちは、 MPC5775B MCUのどのピンがBMSやVCUのリファレンス・デザインで利用可能なデジタルおよびアナログ出力にコネクテッドされているかを調べたかったのです。しかし、その設計図は見つかりませんでした。入手できますか?もしくはリンクも教えてもらえますか?参照ユニットを通して露出している入力ピンのうち、どのピンが割り込み処理に使えるのかを調べようとしています。 Re: Schematics of MPC5775B BMS & VCU Reference Design Unit こんにちは、 回路図は当社のウェブページでご覧いただけます。 https://www.nxp.com/design/design-center/development-boards-and-designs/mpc5775b-bms-and-vcu-reference-design:RDVCU5775EVM?gad_source=1&gad_campaignid=24081577422&gclid=CjwKCAjwj7HTBhBiEiwA8s35OtHxPgln7wwf_p2BF5JDZ9GfWkdapC4yCnvxXk9Tp2NOHHSZHxyrSRoCk8IQAvD_BwE 12ページにはアナログ入力、14ページにはデジタル入力があります。 よろしくお願いいたします。 ピーター

バーストレジスタを使用したSPI伝送 こんにちは、NXPさん。 ターゲットMCU:S32K388 私はeDMAを使用したSPI伝送に、バーストレジスタTCBRおよびTDBR0-127を使用しています。 現在のフレームサイズは32ビットで、すべて期待どおりに動作しています。 さて、32ビット未満のSPIフレームサイズの場合、DMA転送サイズを変更せずにバーストレジスタをどのように使えるでしょうか。 TCBRは16ビットまたは8ビット単位で書くことができますか? TDBRnは16ビットまたは8ビット単位で書けますか? もしなければ、16ビットと8ビットのフレームサイズのDMAチャネルの設定方法についてヒントを教えてもらえますか? 前もって感謝します Re: Spi transmission using burst registers はい、 TCBR と TDBRn の両方が16ビットおよび8ビットの書き込みをサポートしており、DMAの転送サイズ変更は必要ありません。 TDBRn（16ビットまたは8ビット書き込み）：書き込みデータをゼロ拡張し、直ちに送信FIFOにプッシュします。LPSPIは TCR[FRAMESZ] で定義されたビットのみをクロック出力します。 TCBR (16ビット書き込み[15:0]): 1つのコマンドエントリをFIFOにプッシュします。注: [7:0] への8ビット書き込みはデータをステージングするだけであり、プッシュをトリガーするには [15:8] への2回目の8ビット書き込みが必要です。 RM参照 — S32K3xxリファレンスマニュアル、Rev. 12、2025-11-11: セクション70.6.1.17— データ送信 (TDR)：   「このレジスタには32ビット、16ビット、8ビットの書き込みを使って書き込むことができます。8ビットおよび16ビットの送信データ書き込みはいずれも、書き込まれたデータをゼロ拡張し、送信FIFOにデータを送り込みます。8ビットおよび16ビットの書き込みをゼロ拡張（32ビットに拡張）するとは、8ビットおよび16ビットの書き込みの上位（最上位）の空き部分をゼロで埋めることを意味します。 セクション70.3.6.1 — DMAサポートレジスタ(TCBR / TDBR0–TDBR127): 8ビット、16ビット、または32ビットのDMA書き込みアクセスを増分するために設計されたバーストエイリアス領域を文書化します。   Re: Spi transmission using burst registers Reg TCBR、16ビットの[15:00]への書き込みや2回目の8ビット書き込みが[15:8]へのデータを送信すると、TCR全体をどうやって更新できるのでしょうか。下半分の単語では、フレームサイズの選択のみが可能です。CPOL、CPHA、PCSなどのその他の設定は、単語の上半分に含まれます。

S32K311 RTD 5.0 - Linker error: .non_cacheable_bss overflow and overlap with .int_results Hi NXP Team, I am working on an S32K311 project using the following environment: MCU: S32K311 IDE: S32 Design Studio 3.6.7 RTD: S32K3_RTD_5.0.0_D2408_ASR_REL_4_7_REV_0000_20241002 AUTOSAR: 4.7 Issue Initially, the project was building successfully. As the project progressed, I enabled and configured several RTD drivers, including ADC, eMIOS, LCU, ICU, PIT, PORT, LPUART, LPSPI, TRGMUX, MCL, and other required peripherals for my application. After integrating these drivers, the project now fails during the linking stage with the following errors: .non_cacheable_bss will not fit in region 'int_sram_no_cacheable' section .int_results overlaps section .non_cacheable_bss region 'int_sram_no_cacheable' overflowed by 440 bytes collect2.exe: error: ld returned 1 exit status Memory Layout The default linker script contains the following SRAM regions: int_sram : ORIGIN = 0x20400000, LENGTH = 0x00003F00 int_sram_fls_rsv : ORIGIN = 0x20403F00, LENGTH = 0x00000100 int_sram_no_cacheable : ORIGIN = 0x20404000, LENGTH = 0x00003B00 int_sram_results : ORIGIN = 0x20407B00, LENGTH = 0x00000100 int_sram_shareable : ORIGIN = 0x20407C00, LENGTH = 0x00000400 The linker reports that the .non_cacheable_bss section exceeds the allocated int_sram_no_cacheable region by approximately 440 bytes. Questions Is this memory usage expected when multiple RTD drivers are enabled on the S32K311? Is there a recommended method to reduce the size of .non_cacheable_bss? Is it recommended to modify the linker script and increase the int_sram_no_cacheable region? If so, what is the recommended memory layout for the S32K311? Are there any RTD configuration options that can reduce the memory allocated to non-cacheable sections? Has anyone encountered a similar issue when integrating multiple RTD peripherals? Any guidance or recommended solution would be greatly appreciated. Thank you. Re: S32K311 RTD 5.0 - Linker error: .non_cacheable_bss overflow and overlap with .int_results Hi @Esakki  You may find the following discussion threads helpful, as they discuss similar issues and provide some useful troubleshooting suggestions. int_sram_no_cacheable issue S32K312's SRAM is overflow Additionally, there is an S32K3 application note that explains the linker file and startup code in more detail, including how memory regions can be modified and customized. AN14893: S32K3xx Linker File and Startup Code This last thread includes some suggestions related to code optimization techniques. S32K3xx How to optimization APP code for get more high performance BR, VaneB

S32K344 RTD 3.0.0:空の.slewRateCtrlSelLPSPI4ピン用に生成されました - ビルドが失敗します こんにちは、 私は、NXP RD33772C14EVMリファレンス・デザインに従ってSPI配線をしたS32K344(172ピンMQFP)カスタムボード上のバッテリー・マネジメントアプリケーションを紹介しています。私はS32 Design Studio 3.5とRTD 3.0.0を使っています(プラットフォーム、ポート、SPIモジュールはすべてSWバージョン3.0.0を報告しています)および FS26 SBC CDD 2.0.0 (Sbc_fs26)。私の出発点は、S32K344 用の Sbc_fs26_example_HLD サンプルです。 私のシステムではLPSPI0はFUTUREの2チャネルデイジーチェーン用に予約されており、他のSPIインスタンスはすでに使用中なので、FS26のSBCはLPSPI4上で動作しなければなりません。RD33772C14EVM回路図に従い、4つのLPSPI4信号をリファレンス・デザインで使われている同じパッドにルーティングしました:lpspi4_pcs0はPTB8、lpspi4_soutはPTB9、lpspi4_sckはPTB10、lpspi4_sinはPTB11に。ペリフェラル側ではSPIの物理ユニットマッピングをLPSPI_4に設定し、SpiHwUnitをCSIB0に残し、MCUコンポーネントのLPSPI_4ペリフェラルクロックゲートを有効にしました。 「Update Code」を実行してビルドすると、生成されたファイルgenerate/src/Siul2_Port_Ip_VS_0_PBcfg.cでエラーが発生してコンパイラが停止します。ジェネレーターは右辺のない代入式を生成しました。 ../generate/src/Siul2_Port_Ip_VS_0_PBcfg.c:118:34: エラー: ',' トークンの前に式が必要です 118 | .slewRateCtrlSel= 、 同じ空の.slewRateCtrlSel= は、158行目、198行目、238行目に現れます。これは、4つのLPSPI4ピンそれぞれに対応しています。手動でその4行にPORT_SLEW_RATE_NOT_AVAILABLEを入力すると、ビルドは少し進みますが、.inputMuxRegで同じように失敗します。= { (空の初期化子、「ISO C では空の初期化子の括弧は禁止されています」)。つまり、これら4つのパッドのピン構成構造は、有効なCではない空のフィールドで生成されます。 PTB8–PTB11のピンツール「ルーティング詳細」を見ると、スリューレートコントロール列(および入力フィルター列)に該当なしが表示され、スリューレートセルを選択するとツールチップが表示されます:「選択したピンはこの機能の設定をサポートしていません。スルーレート制御を選択します。SO、これらのパッドにはスルーレート制御ハードウェアが搭載されていないのです。私の理解では、そのCASEジェネレーターは他のサポートされていないパッド機能に対して*_NOT_AVAILABLE値を使うのと同様に、PORT_SLEW_RATE_NOT_AVAILABLEを放出するはずです(その値はこのデバイスのSiul2_Port_Ip_PortSlewRateControl枚数に存在します)。しかし実際には何も発信せず、ビルドが壊れます。 これがピンの選択の誤りではなくツールやドライバの問題だと確信する理由は、NXP自身のLVBMS_RD_Bring_up_ExampleがFS26 SBC用にまったく同じ4つのLPSPI4パッド(PTB8/PTB9/PTB10/PTB11)を使っていて、きれいに組み立てられることです。その例と私のプロジェクトで唯一の違いはRTDバージョンです。LVBMSの例はRTD 2.0.0(プラットフォーム/Port/Spi SW 2.0.0)に基づいて構築されているのに対し、私のプロジェクトはRTD 3.0.0を使っています。基板のピン配置は同じで、ピンも4本とも同じ、ピンの電気的特性も同一です（方向のみが両者で設定されています）。SO、スルーレート対応しないパッドのSiul2_Port_Ipコード生成がRTD 2.0.0とRTD 3.0.0の間で逆行したように見えます。 私の質問： これはRTD 3.0.0の既知の問題ですか？修正版／パッチ適用済みのRTDリリースはありますか？ RTD 3.0.0環境下で、PTB8～PTB11（RD33772C14EVMピン配置）においてLPSPI4を正しく、かつサポートされている方法で構成するにはどうすればよいでしょうか？つまり、ピンツールが有効なコードを生成するようにするためです。つまり、slewRateCtrlSel = PORT_SLEW_RATE_NOT_AVAILABLEと有効なinputMuxRegを生成し、空欄ではなく? 設定レベルでの修正がない場合、生成された Siul2_Port_Ip_VS_0_PBcfg.c を手動で編集することが唯一の回避策でしょうか (「コードの更新」のたびに上書きされます)、それともプロジェクトを Port/RTD 2.0.0 に移行することが推奨される方法でしょうか？ もし役に立つなら、完全なビルドログ、ピンの「ルーティング詳細」スクリーンショット(ツールチップ付き)、そして2つのプロジェクトのモジュールバージョンを並べて添付CAN。 ありがとう、 ソン・ヒョンシク Re: S32K344 RTD 3.0.0: empty .slewRateCtrlSel generated for LPSPI4 pins — build fails こんにちは、VaneBさん。 どうもありがとうございました。まさにそれが問題だったのです。ピンツールはLPSPI4(PTB8–PTB11)に更新されていましたが、 ポート コンポーネントのポートピンエントリは元のLPSPI0パッドを指していたため、PortPin Pcr(Mscr)の値は古くなっていました。 ポート設定内の4つのPortPin Pcr値を、新しいピン割り当てに合わせて更新しました。 PCS0 → PTB8 (PCR 40) SOUT → PTB9 (PCR 41) SCK → PTB10 (PCR 42) SIN → PTB11 (PCR 43) Update Codeを実行して再構築した後、空の .slewRateCtrlSel/ .inputMuxRegSiul2_Port_Ip_VS_0_PBcfg.c のエラーは解消され、プロジェクトは正常にビルドされます。 迅速かつ的確なご回答、本当にありがとうございました。おかげで大変時間を節約できました。これを解決策としてマークします。 よろしくお願いします、 ヒョンシク Re: S32K344 RTD 3.0.0: empty .slewRateCtrlSel generated for LPSPI4 pins — build fails こんにちは、 @hyunsiksong この問題は、RTD自体にも、S32DS構成ツールによって生成されたコードにも関係ありません。むしろ、それは設定に関係している。 ペリフェラルツール内のポートドライバ構成では、PortPin Mscrパラメータに割り当てられた値は元のプロジェクト構成に対応しています。例えば、プロジェクトは以前、PTB1をLPSPI0_PCS0として使用するように構成されており、これはPortPin Mscr = 33に対応します。 ただし、更新された構成ではLPSPI4が使用され、PCS0はピン8に再割り当てされています。したがって、対応するPortPin Mscrの値は33ではなく40になります。 すべてのピンについてPortPin Mscrを確認し、現在のピン割り当てと一致していることを確認してください。これらの値を新しい構成に合わせて更新することで、問題は解決するはずです。 BR、VaneB

使用突发寄存器的SPI传输 您好，NXP， 目标微控制器：S32K388 我正在使用突发寄存器 TCBR 和 TDBR0-127 进行 eDMA SPI 传输。 当前帧大小为 32 位，一切运行正常 对于小于 32 位的 SPI 帧大小，如何在不改变 DMA 传输大小的情况下使用突发寄存器？ TCBR 可以用 16 位或 8 位单位写入吗？ TDBRn 可以用 16 位还是 8 位单位写入？ 如果不行，能否提供一些关于如何设置帧大小为 16 位和 8 位的 DMA 通道的提示？ 提前致谢 Re: Spi transmission using burst registers 是的， TCBR和TDBRn都支持 16 位和 8 位写入——无需更改 DMA 传输大小。 TDBRn（16 位或 8 位写入）：将写入的数据零扩展，并立即将其推入发送 FIFO。LPSPI 只会输出由 TCR[FRAMESZ] 定义的位。 TCBR（16 位写入 [15:0]）：将一条命令条目推入 FIFO。注意：向 [7:0] 写入 8 位数据只是暂存数据——需要向 [15:8] 写入第二个 8 位数据才能触发信号推送。 RM 参考，引用 — S32K3xx 参考手册，修订版 12，2025-11-11： 第 70.6.1.17 节— 传输数据（TDR）：   “您可以使用 32 位、16 位或 8 位写入操作向此寄存器写入数据。”8 位和 16 位发送数据的写入都会对写入的数据进行零扩展，并将数据推入发送 FIFO。将 8 位和 16 位写入数据零扩展（扩展至 32 位）意味着将 8 位和 16 位写入数据中最高有效位（即空位）的部分填充为零。 第 70.3.6.1 节 — DMA 支持寄存器（TCBR / TDBR0–TDBR127）：记录了为递增 8 位、16 位或 32 位 DMA 写入访问发送 FIFO 而设计的突发别名区域。   Re: Spi transmission using burst registers 寄存器 TCBR，如果对 [15:00] 的 16 位写入或对 [15:8] 的第二次 8 位写入将数据作为命令条目推入 FIFO，如何更新整个 TCR？下半部分文字仅提供边框尺寸选择。其他设置，如 CPOL、CPHA、PCS 等，都位于单词的上半部分。

S32K344 RTD 3.0.0: empty .slewRateCtrlSel generated for LPSPI4 pins — build fails Hello, I am bringing up a battery-management application on an S32K344 (172-pin MQFP) custom board whose SPI wiring follows the NXP RD33772C14EVM reference design. I am using S32 Design Studio 3.5 with RTD 3.0.0 (the Platform, Port and Spi modules all report SW version 3.0.0) and the FS26 SBC CDD 2.0.0 (Sbc_fs26). My starting point is the Sbc_fs26_example_HLD example for S32K344. In my system LPSPI0 is reserved for a future two-channel daisy-chain and the other SPI instances are already in use, so the FS26 SBC has to run on LPSPI4. Following the RD33772C14EVM schematic, I routed the four LPSPI4 signals to the same pads the reference design uses: lpspi4_pcs0 on PTB8, lpspi4_sout on PTB9, lpspi4_sck on PTB10 and lpspi4_sin on PTB11. On the peripheral side I set the SPI physical-unit mapping to LPSPI_4, left SpiHwUnit at CSIB0, and enabled the LPSPI_4 peripheral-clock gate in the Mcu component. After running "Update Code" and building, the compiler stops with errors in the generated file generate/src/Siul2_Port_Ip_VS_0_PBcfg.c. The generator has produced an assignment with no right-hand side: ../generate/src/Siul2_Port_Ip_VS_0_PBcfg.c:118:34: error: expected expression before ',' token 118 | .slewRateCtrlSel = , The same empty .slewRateCtrlSel = , appears at lines 158, 198 and 238 — one for each of the four LPSPI4 pins. If I manually fill those four lines with PORT_SLEW_RATE_NOT_AVAILABLE, the build gets a little further and then fails the same way on .inputMuxReg = { (empty initializer, "ISO C forbids empty initializer braces"). In other words, the pin-configuration structures for these four pads are generated with empty fields that are not valid C. When I look at the Pins tool "Routing Details" for PTB8–PTB11, the Slew Rate Control column (and the Input Filter column) shows n/a, and selecting the Slew Rate cell shows the tooltip: "The selected pin does not support the configuration of this feature. Selects the slew rate control." So these particular pads simply have no slew-rate-control hardware. My understanding is that in that case the generator should emit PORT_SLEW_RATE_NOT_AVAILABLE (that value does exist in the Siul2_Port_Ip_PortSlewRateControl enum on this device), the same way it uses *_NOT_AVAILABLE values for other unsupported pad features — but instead it emits nothing, which breaks the build. What convinces me this is a tool/driver problem rather than a wrong pin choice is that NXP's own LVBMS_RD_Bring_up_Example uses the exact same four LPSPI4 pads (PTB8/PTB9/PTB10/PTB11) for the FS26 SBC and builds cleanly. The only difference I can find between that example and my project is the RTD version: the LVBMS example is built on RTD 2.0.0 (Platform/Port/Spi SW 2.0.0), while my project uses RTD 3.0.0. Same board pinout, same four pins, and the pin electrical features are identical (only direction is set in both). So it really looks like the Siul2_Port_Ip code generation for slew-rate-unsupported pads regressed between RTD 2.0.0 and RTD 3.0.0. My questions: Is this a known issue in RTD 3.0.0, and is there a fixed / patched RTD release? What is the correct, supported way to configure LPSPI4 on PTB8–PTB11 (the RD33772C14EVM pinout) under RTD 3.0.0 so that the Pins tool generates valid code — i.e. slewRateCtrlSel = PORT_SLEW_RATE_NOT_AVAILABLE and a valid inputMuxReg, instead of empty fields? If there is no configuration-level fix, is editing the generated Siul2_Port_Ip_VS_0_PBcfg.c by hand the only workaround (it is overwritten on every "Update Code"), or is moving the project to Port/RTD 2.0.0 the recommended path? I can attach the full build log, the Pins "Routing Details" screenshot with the tooltip, and a side-by-side of the two projects' module versions if that helps. Thank you, Hyunsik Song Re: S32K344 RTD 3.0.0: empty .slewRateCtrlSel generated for LPSPI4 pins — build fails Hi VaneB, Thank you very much — that was exactly the problem. The Pins tool had been updated to LPSPI4 (PTB8–PTB11), but the Port component's PortPin entries were still pointing at the original LPSPI0 pads, so the PortPin Pcr (Mscr) values were stale. I updated the four PortPin Pcr values in the Port configuration to match the new pin assignment: PCS0 → PTB8 (Pcr 40) SOUT → PTB9 (Pcr 41) SCK → PTB10 (Pcr 42) SIN → PTB11 (Pcr 43) After running Update Code and rebuilding, the empty .slewRateCtrlSel / .inputMuxReg errors in Siul2_Port_Ip_VS_0_PBcfg.c are gone and the project builds cleanly. I really appreciate the quick and precise answer — it saved me a lot of time. Marking this as the solution. Best regards, Hyunsik Re: S32K344 RTD 3.0.0: empty .slewRateCtrlSel generated for LPSPI4 pins — build fails Hi @hyunsiksong  This issue is not related to the RTD itself, nor with the code generated by the S32DS Configuration Tools. Instead, it is related to the configurations. In the Port driver configuration within the Peripheral Tool, the values assigned to the PortPin Mscr parameters still correspond to the original project configuration. For example, the project was previously configured to use PTB1 as LPSPI0_PCS0, corresponds to PortPin Mscr = 33. In the updated configuration, however, LPSPI4 is being used and PCS0 has been reassigned to pin 8. Therefore, the corresponding PortPin Mscr value should be 40 instead of 33. Review the PortPin Mscr for all the pins and ensure they match the current pin assignments Updating these values to reflect the new configuration should resolve the issue. BR, VaneB

S32K311 RTD 5.0 - リンカーエラー: .non_cacheable_bss.int_resultsとのオーバーフローおよび重複 こんにちは、NXP チームの皆様、 私は以下の環境を使用してS32K311プロジェクトに取り組んでいます。 MCU: S32K311 IDE: S32 Design Studio 3.6.7 RTD: S32K3_RTD_5.0.0_D2408_ASR_REL_4_7_REV_0000_20241002 AUTOSAR: 4.7 問題 当初、プロジェクトは順調にビルディングされていました。 プロジェクトが進むにつれて、ADC、eMIOS、LCU、ICU、PIT、PORT、LPUART、LPSPI、TRGMUX、MCLなど、いくつかのRTDドライバを有効化・設定し、アプリケーションに必要なその他のペリフェラルを活用しました。 これらのドライバを統合した後、プロジェクトはリンク段階で以下のエラーで失敗します。 .non_cacheable_bss will not fit in region 'int_sram_no_cacheable' section .int_results overlaps section .non_cacheable_bss region 'int_sram_no_cacheable' overflowed by 440 bytes collect2.exe: error: ld returned 1 exit status メモリレイアウト デフォルトのリンカスクリプトには、以下のSRAM領域が含まれています。 int_sram : ORIGIN = 0x20400000, LENGTH = 0x00003F00 int_sram_fls_rsv : ORIGIN = 0x20403F00, LENGTH = 0x00000100 int_sram_no_cacheable : ORIGIN = 0x20404000, LENGTH = 0x00003B00 int_sram_results : ORIGIN = 0x20407B00, LENGTH = 0x00000100 int_sram_shareable : ORIGIN = 0x20407C00, LENGTH = 0x00000400 リンカーは、 .non_cacheable_bssがこのセクションは、割り当てられた int_sram_no_cacheable 領域を約440 バイト超過しています。 質問 複数のRTDドライバがS32K311で有効になっている場合、このメモリ使用は予想されますか? .non_cacheable_bssのサイズを減らすための推奨方法はありますか? リンカースクリプトを修正してint_sram_no_cacheable領域を増やすことは推奨されますか？もしそうなら、S32K311の推奨メモリ配置はどうなっていますか? キャッシュできないセクションに割り当てられるメモリを減らすRTDの設定オプションはありますか? 複数のRTDペリフェラルを統合する際に同じような問題に遭遇した方はいらっしゃいますか? 何かご助言や解決策をご提案いただければ大変ありがたいです。 よろしくお願いします。 Re: S32K311 RTD 5.0 - Linker error: .non_cacheable_bss overflow and overlap with .int_results こんにちは、 @Esakkiさん 以下のディスカッションThreadは、似たような問題を扱い、有用なトラブルシューティングの提案を提供してくれるので役立つかもしれません。 int_sram_no_cacheable の問題 S32K312のSRAMがオーバーフローする さらに、S32K3のアプリケーションノートには、リンカーファイルやスタートアップコードについてより詳しく説明されており、メモリ領域の変更やカスタマイズ方法も含まれています。 AN14893 : S32K3xx リンカーファイルとスタートアップコード この最後のThreadでは、コード最適化技術に関するいくつかの提案が含まれています。 S32K3xxでAPPのコードを最適化してパフォーマンスを向上させる方法 BR、VaneB

Spi transmission using burst registers Hello NXP, Target uC : S32K388 I am using the burst registers TCBR and TDBR0-127 for SPI transmissions using eDMA. Current frame size is 32 bits and everything works as expected Now for an SPI frame size which is less than 32 bits, how can the burst registers be used without changing the dma transfer size, in between. Can TCBR be written in 16 or 8 bit units. Can TDBRn be written in 16 or 8 bit units If not, could you give hints as to how to setup the dma channel for frame sizes 16 and 8 bits. Thanks in advance  Re: Spi transmission using burst registers Yes, both TCBR and TDBRn support 16-bit and 8-bit writes — no DMA transfer size change is needed. TDBRn (16-bit or 8-bit write): Both zero-extend the written data and immediately push it into the transmit FIFO. LPSPI will clock out only the bits defined by TCR[FRAMESZ] . TCBR (16-bit write to [15:0]): Pushes one command entry into the FIFO. Note: an 8-bit write to [7:0] only stages the data — a second 8-bit write to [15:8] is required to trigger the push. RM reference — S32K3xx Reference Manual, Rev. 12, 2025-11-11: Section 70.6.1.17 — Transmit Data (TDR):   "You can write to this register using 32-, 16-, or 8-bit writes. Both 8-bit and 16-bit writes of transmit data zero-extend the data written and push the data into the transmit FIFO. To zero-extend 8-bit and 16-bit writes (to 32 bits) means that the higher order (most significant) empty parts of the 8-bit and 16-bit writes are filled with zeroes." Section 70.3.6.1 — DMA support registers (TCBR / TDBR0–TDBR127): Documents the burst alias region designed for incrementing 8-bit, 16-bit, or 32-bit DMA write accesses to the transmit FIFO.   Re: Spi transmission using burst registers Reg TCBR, if the 16 bit write to [15:00] or the second 8-bit write to [15:8] pushes the data into the FIFO as a command entry, how can the entire TCR be updated. Only the frame size selection is available on the lower half word. The other settings like CPOL,CPHA,PCS etc comes in the upper half word.

HDMI Configuration Support in Zephyr for i.MX95 FRDM EVK Hi NXP Team, I am currently working on the i.MX95 FRDM EVK board using Zephyr RTOS. On the Linux side, HDMI output is already supported and working correctly. However, I would like to know how to enable and configure HDMI in Zephyr. Could you please guide me on the following? Does Zephyr support HDMI output on the i.MX95 FRDM EVK? If yes, what drivers and Device Tree configurations are required? Is there any reference implementation or sample application available for HDMI on Zephyr? Any guidance or documentation would be greatly appreciated. Thank you. Re: HDMI Configuration Support in Zephyr for i.MX95 FRDM EVK I confirmed with the AE team. HDMI is not supported in IMX95 Zephyr currently.  Re: HDMI Configuration Support in Zephyr for i.MX95 FRDM EVK Hi NXP Team, I am looking for the IT6263 Reference Manual or Register Programming Manual. Could you please share the detailed register descriptions (register map with bit-level definitions) for the IT6263 HDMI bridge, or let me know how I can obtain this documentation? Note: I am specifically looking for the chip-level register documentation itself, not the Linux kernel driver source. Thank you, Karthikeyan M Re: HDMI Configuration Support in Zephyr for i.MX95 FRDM EVK IT6263 is not an NXP product, so NXP does not provide a Reference Manual for this device. For configuration and initialization details, you can refer to the IT6263 Linux driver source code. Re: HDMI Configuration Support in Zephyr for i.MX95 FRDM EVK Thank you for your response and for providing the Arm Support links. I will contact Arm Support regarding the Arm Mali-G310 Technical Reference Manual and the CSF/Firmware Interface documentation. Re: HDMI Configuration Support in Zephyr for i.MX95 FRDM EVK I have successfully ported HDMI on Zephyr OS, and it is currently running on the CPU. My next goal is to port it to run on the GPU. For this, I need the Arm Mali-G310 Technical Reference Manual, specifically the CSF/Firmware Interface section. Should I request this document from NXP Support, or do I need to contact Arm Support directly? Having access to this reference manual would be very helpful for implementing the GPU port on Zephyr Re: HDMI Configuration Support in Zephyr for i.MX95 FRDM EVK Please contact Arm Support directly. Re: HDMI Configuration Support in Zephyr for i.MX95 FRDM EVK Thank you for your response. Could you please share the specific contact email or support portal for Arm Support? If you have a direct contact or the appropriate email address, it would be very helpful. I will contact them regarding this issue. Re: HDMI Configuration Support in Zephyr for i.MX95 FRDM EVK Arm Support Hub: https://support.arm.com/support-cases   Support Inquiries Form: https://www.arm.com/company/contact-us/support-inquiries Re: HDMI Configuration Support in Zephyr for i.MX95 FRDM EVK Thank you for the links to the Arm portal and the i.MX Graphics User's Guide. We looked at both, but they don't cover what we need. Those guides explain how to use the GPU under Linux, and we are writing our own low-level GPU driver on i.MX95 (bare-metal, using Zephyr, not Linux). So we need lower-level, register-level information than those documents provide. In the ARM portal, we have searched for the TRM, but it is unavailable. Here is our situation in short:   We have got the Mali-G310 GPU working up to a certain point. The GPU is detected correctly, powered on, reset, and we have loaded the GPU firmware into memory successfully. Everything up to this stage works and is verified.   We are stuck at one step: starting the GPU's firmware microcontroller (the MCU). After we enable it, its status stays "disabled" and it never starts running. There is no error and no interrupt - it simply does not boot.   Re: HDMI Configuration Support in Zephyr for i.MX95 FRDM EVK Hi   NXP Team, I contacted Arm support to request the required documentation, and they replied with the following: "Please reach NXP support if you see obstacles developing on their silicon. Again, these documents are NOT supposed to be available for silicon vendor's customers." Based on their response, I am reaching out to NXP for assistance. I have successfully enabled HDMI on Zephyr OS, and it is currently running using the CPU. My next objective is to enable GPU-based rendering. To proceed, I require the Arm Mali-G310 Technical Reference Manual, particularly the CSF/Firmware Interface documentation. As the Mali-G310 GPU is integrated into the NXP i.MX95 platform, could you please advise how I can obtain access to this documentation? If the document cannot be shared, I would appreciate any alternative guidance or references that would help me continue the GPU bring-up on Zephyr. Re: HDMI Configuration Support in Zephyr for i.MX95 FRDM EVK Please check whether the following information would be helpful. If no, I need to contact the AE team. The Arm Mali-G310 Technical Reference Manual is available from Arm’s documentation portal: search Arm Developer / Arm Documentation for “Mali-G310 Technical Reference Manual” or “Mali-G310 TRM” . It may require an Arm account or acceptance of Arm documentation terms, depending on access level. For NXP i.MX95 work, NXP’s public documentation points to the Mali-G310 GPU through the i.MX Graphics User’s Guide , and the FRDM-i.MX95 getting-started page links that guide for GPU usage details. The FRDM-i.MX95 page states that the board has a Mali-G310 GPU and links the i.MX Graphics User’s Guide for more details: https://www.nxp.com/docs/en/user-guide/UG10159.pdf  Start here: Arm documentation portal:https://developer.arm.com/documentation NXP i.MX Graphics User’s Guide:https://www.nxp.com/docs/en/user-guide/UG10159.pdf Re: HDMI Configuration Support in Zephyr for i.MX95 FRDM EVK Hi   NXP Team, I contacted Arm support to request the required documentation, and they replied with the following: "Please reach NXP support if you see obstacles developing on their silicon. Again, these documents are NOT supposed to be available for silicon vendor's customers." Based on their response, I am reaching out to NXP for assistance. I have successfully enabled HDMI on Zephyr OS, and it is currently running using the CPU. My next objective is to enable GPU-based rendering. To proceed, I require the Arm Mali-G310 Technical Reference Manual, particularly the CSF/Firmware Interface documentation. As the Mali-G310 GPU is integrated into the NXP i.MX95 platform, could you please advise how I can obtain access to this documentation? If the document cannot be shared, I would appreciate any alternative guidance or references that would help me continue the GPU bring-up on Zephyr. Re: HDMI Configuration Support in Zephyr for i.MX95 FRDM EVK Please refer to the following update from the AE team. Regarding the Arm Mali-G310 TRM, this document is Arm confidential IP. NXP is not permitted to forward it to end customers, so it is essentially unavailable through NXP channels. A formal request would have to go through Arm directly, which takes a long time and is unlikely to be granted. In addition, the i.MX95 GPU is still in the pre-production stage, so there is no officially validated bare-metal/Zephyr reference at this time. Regarding the MCU staying "disabled" after enable, this step does not require the TRM. The complete boot flow is available in the following two public sources, both accessible directly on GitHub: Panthor — mainline driver, the main one to look at (it actually boots the MCU and supports i.MX95): https://github.com/torvalds/linux/tree/master/drivers/gpu/drm/panthor kbase — Arm's official driver, for cross-checking: https://github.com/JeffyCN/mirrors/blob/kernel/drivers/gpu/arm/bifrost/csf/mali_kbase_csf_firmware.c

S32K344 RTD 3.0.0：空 .slewRateCtrlSel为 LPSPI4 引脚生成 — 版本失败 你好， 我正在 S32K344（172 引脚 MQFP）定制板上开发一个电池管理应用程序，该板的 SPI 布线遵循 NXP RD33772C14EVM 参考设计。我正在使用 S32 Design Studio 3.5 和 RTD 3.0.0。（平台、端口和 Spi 模块均报告软件版本为 3.0.0）以及 FS26 SBC CDD 2.0.0 (Sbc_fs26)。我的出发点是 S32K344 的 Sbc_fs26_example_HLD 示例。 在我的系统中，LPSPI0 已预留给未来的双通道菊花链，而其他 SPI 实例已被使用，因此 FS26 SBC 必须在 LPSPI4 上运行。按照 RD33772C14EVM 原理图，我将四个 LPSPI4 信号连接到参考设计使用的相同焊盘：lpspi4_pcs0 连接到 PTB8，lpspi4_sout 连接到 PTB9，lpspi4_sck 连接到 PTB10，lpspi4_sin 连接到 PTB11。在外围设备方面，我将 SPI 物理单元映射设置为 LPSPI_4，将 SpiHwUnit 设置为 CSIB0，并在 Mcu 元器件中启用了 LPSPI_4 外围时钟门。 运行“更新代码”并构建后，编译器停止运行，生成的文件 generate/src/Siul2_Port_Ip_VS_0_PBcfg.c 出现错误。生成器生成的赋值语句没有右侧等式： ../generate/src/Siul2_Port_Ip_VS_0_PBcfg.c:118:34: 错误：应在逗号 (,) 前插入表达式 118 | .slewRateCtrlSel=， 同样的空 .slewRateCtrlSel等号出现在第 158、198 和 238 行——分别对应四个 LPSPI4 引脚。如果我手动将这四行填充为 PORT_SLEW_RATE_NOT_AVAILABLE，版本会继续进行下去，然后在 .inputMuxReg 处以相同的方式失败。= {（空初始化器，“ISO C 禁止空初始化器大括号”）。换句话说，这四个焊盘的引脚配置结构生成的字段为空，这不是有效的 C。 当我查看 PTB8–PTB11 的“引脚”工具“布线详情”时，“转换速率控制”列（以及“输入滤波器”列）显示为“n/a”，选择“转换速率”单元格时，工具提示显示：“所选引脚不支持此功能的配置。”选择转换速率控制。所以这些特殊的垫子根本没有转换速率控制硬件。我的理解是，在这种情况下，生成器应该发出 PORT_SLEW_RATE_NOT_AVAILABLE（该值确实存在于此设备的 Siul2_Port_Ip_PortSlewRateControl 枚举中），就像它对其他不支持的 pad 功能使用 *_NOT_AVAILABLE 值一样——但它却什么也没发出，这导致版本失败。 让我确信这是工具/驱动程序问题而不是引脚选择错误的原因在于，NXP 自己的 LVBMS_RD_Bring_up_Example 使用了完全相同的四个 LPSPI4 焊盘（PTB8/PTB9/PTB10/PTB11）来构建 FS26 SBC，并且版本构建顺利。我发现该示例与我的项目之间唯一的区别是 RTD 版本：LVBMS 示例基于 RTD 2.0.0（平台/端口/Spi 软件 2.0.0），而我的项目使用 RTD 3.0.0。电路板引脚排列相同，四个引脚相同，引脚的电气特性也相同（两者仅方向设置不同）。所以看起来，RTD 2.0.0 和 RTD 3.0.0 之间，Siul2_Port_Ip 代码生成对于不支持压摆率的 pad 确实出现了倒退。 我的问题： 这是RTD 3.0.0中的已知问题吗？是否有已修复/已打补丁的RTD版本？ 在 RTD 3.0.0 版本下，配置 PTB8–PTB11（RD33772C14EVM 引脚排列）上的 LPSPI4 的正确且受支持的方法是什么？这样，引脚工具就能生成有效的代码——例如，slewRateCtrlSel = PORT_SLEW_RATE_NOT_AVAILABLE 和一个有效的 inputMuxReg，而不是空字段？ 如果没有配置级别的修复，手动编辑生成的 Siul2_Port_Ip_VS_0_PBcfg.c 是唯一的解决方法吗（每次“更新代码”都会覆盖它），还是将项目迁移到 Port/RTD 2.0.0 是推荐的方案？ 如果需要，我可以附上完整的构建日志、带有工具提示的引脚“布线详情”屏幕截图，以及两个项目模块版本的并排对比图。 谢谢你， 宋炫植 Re: S32K344 RTD 3.0.0: empty .slewRateCtrlSel generated for LPSPI4 pins — build fails 嗨 VaneB， 非常感谢——问题果然出在这里。Pins 工具已更新为 LPSPI4 (PTB8–PTB11)，但Port元器件的 PortPin 条目仍然指向原始的 LPSPI0 焊盘，因此 PortPin Pcr (Mscr) 值已过时。 我已将端口配置中的四个 PortPin Pcr 值更新为与新的引脚分配相匹配： PCS0 → PTB8 (Pcr 40) SOUT → PTB9 (Pcr 41) SCK → PTB10（Pcr 42） SIN → PTB11 (Pcr 43) 运行更新代码并重新构建后，.slewRateCtrlSel 文件为空。/ .inputMuxRegSiul2_Port_Ip_VS_0_PBcfg.c 中的错误已消失，项目可以顺利构建。 我非常感谢您快速而准确的答复——这为我节省了很多时间。标记为解决方案。 此致， 炫植 Re: S32K344 RTD 3.0.0: empty .slewRateCtrlSel generated for LPSPI4 pins — build fails 你好@hyunsiksong 这个问题与 RTD 本身无关，也与 S32DS 配置工具生成的代码无关。相反，它与配置有关。 在外设工具的端口驱动程序配置中，分配给 PortPin Mscr 参数的值仍然与原始项目配置相对应。例如，该项目之前配置为使用 PTB1 作为 LPSPI0_PCS0，对应于 PortPin Mscr = 33。 然而，在更新后的配置中，使用的是 LPSPI4，并且 PCS0 已重新分配给引脚 8。因此，相应的 PortPin Mscr 值应为 40 而不是 33。 检查所有引脚的 PortPin Mscr，确保它们与当前的引脚分配匹配。更新这些值以反映新的配置应该可以解决问题。 BR，VaneB

MCUXpresso Secure Provisioning ToolからFCBデータを構築する方法 こんにちは、 現在、RT1010 EVKボードでOTFADの設定をテストしています。 MCUXpresso Secure Provisioning Tool 26.03を使用してOTFADを設定し、バイナリファイルを生成するプロジェクトをビルドしたいと考えています。 ビルド結果は以下のとおりです。 MIMXRT1011_プロジェクト.bin MIMXRT1011_Project_hab.bin otfad_keyblobs.bin unsigned_MIMXRT1010_flashloader.bin これらが4つのファイルです。 MCUXpresso Secure Provisioning Tool 26.03 を使用して書き込み操作を実行し、フラッシュメモリを読み取ると、プログラムは 0x0400 領域に FCB と思われるデータを含めます。 しかし、ビルドされたファイルの中にFCBに対応するファイルが見当たらないようです。 ビルドプロセス中にFCB情報を含むファイルを生成することは可能ですか？ i.MXRT 101x Re: how i can build FCB data from MCUXpresso Secure Provisioning Tool ご返信よろしくお願いします。 あなたが提供してくれたリンクを参考に、FCBを作成しました。 もう一つ質問があります。 OTFAD設定のリージョン0情報のキーデータに関する説明はどのドキュメントで見られますか? 私が気になっているのは、ユーザーキーデータとカウンターデータセクションです。 説明してもらえますか? よろしくお願いします。 Re: how i can build FCB data from MCUXpresso Secure Provisioning Tool こんにちは、 @TnseoRnr さん。 SPTドキュメントの以下のリンクをご覧ください。簡易設定から完全なFCBを作成する手順が明記されています:https://mcuxpresso.nxp.com/secure/26.03/05_user_interface.html#spi-nor また、FCBはペリフェラルツールを使ってMCUXpressoから作成できるとも書かれています。 最後に一つ、SPTの新しいバージョン(v26.06)が存在することを覚えておいてください。最新バージョンの開発を続けることをお勧めします。 BR、 エドウィン。 Re: how i can build FCB data from MCUXpresso Secure Provisioning Tool こんにちは、 @TnseoRnr さん。 これらのフィールドが作成中の OTFAD 構成でどのように使用されるかという意味であれば、おそらく次のリンクが参考になるでしょう: https://mcuxpresso.nxp.com/secure/latest/06_processor_specific_workflow.html#booting-otfad-encrypted-image-unsigned-with-user-keys とはいえ、これらの鍵の内部構造やより詳細な説明を求める場合は、RT1010のセキュアファイルへのアクセスを申請し、RT1010のセキュリティ機能を詳細に説明したセキュリティリファレンスマニュアルを参照する必要があります。 このファイルのダウンロードやアクセス申請は、RT1010製品ページのドキュメントセクションの「Secure」チェックボックスをクリックすることで表示されます。 https://www.nxp.com/products/i.MX-RT1010#documentation BR、 エドウィン。

i.MX93ボードを再プロビジョニングすることは可能ですか？ すでにEdgeLock 2GOを使ってFRDM i.MX93ボードのプロビジョニングを完了しており、プロビジョニングは無事完了しています。 今は同じボードに、キーペアやX.509証明書などの新しいまたは更新されたセキュアオブジェクトセットで再プロビジョニングしたいと考えています。 すでにプロビジョニング済みのi.MX93デバイスでの再プロビジョニングはサポートされていますか? もしそうなら、推奨される手順を教えていただけますか?具体的には、以前にプロビジョニングされたセキュアオブジェクトは、再度プロビジョニングする前に削除またはリセットする必要がありますか?それともEdgeLock 2GOを通じて更新できるのでしょうか? また、再プロビジョニングを試みる前に知っておくべき制限や不可逆的な設定はありますか? ログは:-- エラー:iot_agent_utils_create_self_signed_edgelock2go_certificate L#1035 mbedtls_pk_setup_opaque 失敗:0xffffc180 エラー:iot_agent_utils_write_edgelock2go_datastore L#1150 iot_agent_utils_create_self_signed_edgelock2go_certificate 失敗:0xffffffff エラー:iot_agent_utils_create_self_signed_edgelock2go_certificate L#1035 mbedtls_pk_setup_opaque 失敗:0xffffc180 エラー:iot_agent_utils_write_edgelock2go_datastore L#1150 iot_agent_utils_create_self_signed_edgelock2go_certificate 失敗:0xffffffff エラー:iot_agent_utils_create_self_signed_edgelock2go_certificate L#1035 mbedtls_pk_setup_opaque 失敗:0xffffc180 エラー:iot_agent_update_device_configuration_from_constants L#614 iot_agent_utils_create_self_signed_edgelock2go_certificate 失敗:0xffffffff エラー:iot_agent_update_device_configuration L#657 iot_agent_update_device_configuration_from_constants 0xffffffffで故障 Status(oem-prov-app): FAILURE(Status(oem-prov-app): FAILURE(FAILURE) FRDMトレーニング ハンズオン・トレーニング Security Yocto Project Re: Is it possible to reprovision the i.MX93 board? こんにちは、 再プロビジョニングも可能であり、EdgeLock 2GOは初期展開後の証明書や鍵の更新、ローテーション、取り消しを含む完全なライフサイクルマネジメントを目的に設計されています。 安全なプロビジョニングのためにどのような手順を踏みましたか? キーやライフサイクルなど、ヒューズ内の焼き付き構成に関わる手順について理解しておく必要があります。 よろしくお願いいたします。 Re: Is it possible to reprovision the i.MX93 board? サービスレベルでの再プロビジョニングがサポートされていることを確認していただきありがとうございます。明確にしておきますが、これは新規のプロビジョニング試行ではなく、既に一度正常にプロビジョニングされたボード（ライフサイクルOEM_OPEN、ELEファームウェア2.0.5-7a34cee、初回プロビジョニング時に既にキーと証明書オブジェクトが存在する状態）に対する再プロビジョニング試行です。 この 2 回目のパスで、oem-prov-app は iot_agent_update_device_configuration_from_constants() → iot_agent_utils_create_self_signed_edgelock2go_certificate() 内の mbedtls_pk_setup_opaque() 呼び出しで失敗し、MBEDTLS_ERR_PK_BAD_INPUT_DATA (0xffffc180) を返します。バージョン: el2go-agent 6.4.2-r0、smw 5.3-r0、mbedtls 3.6.5-r0。 2つの質問があります。 1.再プロビジョニングでは、oem-prov-appを再実行する前に、既存のキーオブジェクトを明示的に消去する必要がありますか（psa_destroy_keyまたはSMWキーストレージAPI経由）、それともエージェントが同じキーIDで上書きする必要がありますか？現在、明示的な消去手順は実行していません。 2. el2go-agent 6.4.2-r0 と smw 5.3-r0 の間には、特に再プロビジョニング/更新パスに関して既知の互換性の問題がありますか？というのも、初期起動時にも同じエラーが発生し、そこでもバージョン不一致が疑われたからです。 また、プロビジョニングされた鍵と証明書オブジェクトがELE管理のNVMに存在しているのか確認できますか?つまり、再プロビジョニングに失敗してもその鍵IDが永久に使えなくなるわけではありません。 Re: Is it possible to reprovision the i.MX93 board? こんにちは、 情報ありがとうございます。 1. はい、署名付きメッセージを使用してキーストアの再プロビジョニングを実行してください。キーストアの再プロビジョニングを行うと、HSMによって管理されているすべてのキーストアが消去されます。 2. いいえ、互換性の問題は報告されていません。 3. その通り、アプリケーション鍵や証明書はヒューズではなくELE管理のNVMに保存されます。 よろしくお願いいたします。

IMX95 Aquila ISP usage Hello, I bought an Aquila IMX95 Evaluation Kit 2 with two ov5640 sensors (https://www.toradex.com/cart). I have the drivers for the sensors. The board is flashed correctly, with the isp module active : root@imx95-1:~# lsmod | grep -i isp neoisp 69632 0 The cameras are showing in libcamera : root@imx95-1:~# libcamera -sh: libcamera: command not found root@imx95-1:~# cam -l [17:17:31.010001558] [2747] INFO Camera camera_manager.cpp:327 libcamera v0.4.0+dirty (2026-06-03T11:26:44UTC) [17:17:31.044088474] [2748] WARN CameraSensor camera_sensor_legacy.cpp:354 'ov5640 4-003c': Recommended V4L2 control 0x009a0922 not supported [17:17:31.044159391] [2748] WARN CameraSensor camera_sensor_legacy.cpp:426 'ov5640 4-003c': The sensor kernel driver needs to be fixed [17:17:31.044178224] [2748] WARN CameraSensor camera_sensor_legacy.cpp:428 'ov5640 4-003c': See Documentation/sensor_driver_requirements.rst in the libcamera sources for more information [17:17:31.044882558] [2748] WARN CameraSensor camera_sensor_legacy.cpp:594 'ov5640 4-003c': Failed to retrieve the camera location [17:17:31.044918891] [2748] WARN CameraSensor camera_sensor_legacy.cpp:616 'ov5640 4-003c': Rotation control not available, default to 0 degrees [17:17:31.045722599] [2748] WARN CameraSensor camera_sensor_legacy.cpp:354 'ov5640 3-003c': Recommended V4L2 control 0x009a0922 not supported [17:17:31.045762974] [2748] WARN CameraSensor camera_sensor_legacy.cpp:426 'ov5640 3-003c': The sensor kernel driver needs to be fixed [17:17:31.045783849] [2748] WARN CameraSensor camera_sensor_legacy.cpp:428 'ov5640 3-003c': See Documentation/sensor_driver_requirements.rst in the libcamera sources for more information [17:17:31.046362016] [2748] WARN CameraSensor camera_sensor_legacy.cpp:594 'ov5640 3-003c': Failed to retrieve the camera location [17:17:31.046388308] [2748] WARN CameraSensor camera_sensor_legacy.cpp:616 'ov5640 3-003c': Rotation control not available, default to 0 degrees [17:17:31.048068724] [2748] WARN V4L2 v4l2_pixelformat.cpp:346 Unsupported V4L2 pixel format AR30 [17:17:31.048640224] [2748] WARN V4L2 v4l2_pixelformat.cpp:346 Unsupported V4L2 pixel format AR30 [17:17:31.048904099] [2748] WARN V4L2 v4l2_pixelformat.cpp:346 Unsupported V4L2 pixel format AR30 [17:17:31.049145974] [2748] WARN V4L2 v4l2_pixelformat.cpp:346 Unsupported V4L2 pixel format AR30 [17:17:31.049451724] [2748] WARN V4L2 v4l2_pixelformat.cpp:346 Unsupported V4L2 pixel format AR30 [17:17:31.049694683] [2748] WARN V4L2 v4l2_pixelformat.cpp:346 Unsupported V4L2 pixel format AR30 [17:17:31.049937141] [2748] WARN V4L2 v4l2_pixelformat.cpp:346 Unsupported V4L2 pixel format AR30 [17:17:31.050184266] [2748] WARN V4L2 v4l2_pixelformat.cpp:346 Unsupported V4L2 pixel format AR30 [17:17:31.050477516] [2748] WARN V4L2 v4l2_pixelformat.cpp:346 Unsupported V4L2 pixel format AR30 [17:17:31.050720433] [2748] WARN V4L2 v4l2_pixelformat.cpp:346 Unsupported V4L2 pixel format AR30 [17:17:31.050962433] [2748] WARN V4L2 v4l2_pixelformat.cpp:346 Unsupported V4L2 pixel format AR30 [17:17:31.051201724] [2748] WARN V4L2 v4l2_pixelformat.cpp:346 Unsupported V4L2 pixel format AR30 [17:17:31.051441724] [2748] WARN V4L2 v4l2_pixelformat.cpp:346 Unsupported V4L2 pixel format AR30 [17:17:31.051683308] [2748] WARN V4L2 v4l2_pixelformat.cpp:346 Unsupported V4L2 pixel format AR30 [17:17:31.051925308] [2748] WARN V4L2 v4l2_pixelformat.cpp:346 Unsupported V4L2 pixel format AR30 [17:17:31.052259141] [2748] WARN V4L2 v4l2_pixelformat.cpp:346 Unsupported V4L2 pixel format AR30 [17:17:31.052510099] [2748] WARN V4L2 v4l2_pixelformat.cpp:346 Unsupported V4L2 pixel format AR30 [17:17:31.061185308] [2748] WARN V4L2 v4l2_pixelformat.cpp:346 Unsupported V4L2 pixel format AR30 [17:17:31.061469974] [2748] WARN V4L2 v4l2_pixelformat.cpp:346 Unsupported V4L2 pixel format AR30 [17:17:31.061736058] [2748] WARN V4L2 v4l2_pixelformat.cpp:346 Unsupported V4L2 pixel format AR30 [17:17:31.061988683] [2748] WARN V4L2 v4l2_pixelformat.cpp:346 Unsupported V4L2 pixel format AR30 [17:17:31.062242933] [2748] WARN V4L2 v4l2_pixelformat.cpp:346 Unsupported V4L2 pixel format AR30 [17:17:31.062489474] [2748] WARN V4L2 v4l2_pixelformat.cpp:346 Unsupported V4L2 pixel format AR30 [17:17:31.062733266] [2748] WARN V4L2 v4l2_pixelformat.cpp:346 Unsupported V4L2 pixel format AR30 [17:17:31.062980349] [2748] WARN V4L2 v4l2_pixelformat.cpp:346 Unsupported V4L2 pixel format AR30 [17:17:31.063228266] [2748] WARN V4L2 v4l2_pixelformat.cpp:346 Unsupported V4L2 pixel format AR30 [17:17:31.063470391] [2748] WARN V4L2 v4l2_pixelformat.cpp:346 Unsupported V4L2 pixel format AR30 [17:17:31.063712849] [2748] WARN V4L2 v4l2_pixelformat.cpp:346 Unsupported V4L2 pixel format AR30 [17:17:31.063953933] [2748] WARN V4L2 v4l2_pixelformat.cpp:346 Unsupported V4L2 pixel format AR30 [17:17:31.064216891] [2748] WARN V4L2 v4l2_pixelformat.cpp:346 Unsupported V4L2 pixel format AR30 [17:17:31.064463349] [2748] WARN V4L2 v4l2_pixelformat.cpp:346 Unsupported V4L2 pixel format AR30 [17:17:31.064706683] [2748] WARN V4L2 v4l2_pixelformat.cpp:346 Unsupported V4L2 pixel format AR30 [17:17:31.064958766] [2748] WARN V4L2 v4l2_pixelformat.cpp:346 Unsupported V4L2 pixel format AR30 [17:17:31.065200974] [2748] WARN V4L2 v4l2_pixelformat.cpp:346 Unsupported V4L2 pixel format AR30 Available cameras: 1: 'ov5640' (/base/soc/bus@42000000/i2c@42540000/camera@3c) 2: 'ov5640' (/base/soc/bus@42000000/i2c@426e0000/camera@3c) Just to check if the mipis are fine, I started a gstreamer pipeline and managed to get a stable 30fps stream on both cameras. I also managed to take snapshots with v4l2-ctl. Now, I'd like to test the Aquila's ISP with my cameras to see what it can do. Following the https://www.nxp.com/docs/en/user-guide/UG10215.pdf I added the environment variable : root@imx95-1:~# export LIBCAMERA_PIPELINES_MATCH_LIST='nxp/neo' But, doing so, the camera is not detected anymore by libcamera and I don't know why : root@imx95-1:~# cam -l [17:36:38.947430563] [2788] INFO Camera camera_manager.cpp:327 libcamera v0.4.0+dirty (2026-06-03T11:26:44UTC) Available cameras: root@imx95-1:~# Thank you for your reply ! Cordially, Re: IMX95 Aquila ISP usage After looking at your logs, I believe the issue is not related to the MIPI interfaces or the OV5640 driver itself. The fact that: both OV5640 cameras are detected by libcamera GStreamer can stream at 30 fps v4l2-ctl can capture images indicates that the sensor drivers, I2C communication,  CSI-2  links and media topology are all working correctly. The key point is that the NXP Neo ISP pipeline expects a RAW Bayer sensor input. OV5640 is a SoC image sensor with its own internal image processing pipeline, and in the NXP BSP it is typically used in YUV output mode (for example YUV422) rather than as a RAW Bayer sensor. In such a configuration, the camera can be used through the standard V4L2/libcamera pipeline, but it does not match the requirements of the Neo ISP pipeline. This would explain why: `cam -l` shows both OV5640 cameras by default after setting export LIBCAMERA_PIPELINES_MATCH_LIST='nxp/neo' no cameras are detected anymore The cameras are still present in the system, but the NEO pipeline handler cannot find a compatible camera topology and therefore exposes zero cameras to libcamera. To verify the actual sensor output format, could you please provide the outputs of: ```bash media-ctl -p v4l2-ctl --list-formats-ext We are particularly interested in whether the sensor exposes any RAW Bayer formats such as: SBGGR8 SBGGR10 SRGGB10 RG10 BA10 If only YUV formats (for example YUYV/UYVY) are available, then the camera is not operating in RAW mode and cannot be processed by the Neo ISP pipeline. Although the OV5640 hardware is capable of RAW Bayer output, RAW support is not commonly enabled in BSP camera drivers, and the NXP Neo ISP stack also relies on sensor-specific tuning data. Even if RAW output can be enabled, the absence of a dedicated OV5640 tuning profile may prevent proper ISP operation (AE/AWB/image quality tuning). If your goal is to evaluate the Neo ISP framework itself, it may be easier to use a sensor that is known to work with the NXP ISP stack. Common candidates include: OS08A20 OX03C10 OX05B1S AR0521 AR1335 (may require additional tuning work) Could you share the output of the commands above? That will allow us to confirm whether the current OV5640 configuration is exposing RAW Bayer formats to the system. Best regards, Re: IMX95 Aquila ISP usage Thanks for the reply. I did some additional checks: You were right and the OV5640 was initially running in UYVY mode, but I manually switched one sensor to RAW Bayer (SRGGB8). media-ctl -p now shows:   root@imx95-1:~# media-ctl -p Media controller API version 6.12.55 Media device information ------------------------ driver mxc-isi model FSL Capture Media Device serial bus info platform:4ad50000.isi hw revision 0x0 driver version 6.12.55 Device topology - entity 1: crossbar (13 pads, 11 links, 8 routes) type V4L2 subdev subtype Unknown flags 0 device node name /dev/v4l-subdev0 routes: 2/0 -> 5/0 [ACTIVE] 3/0 -> 6/0 [ACTIVE] 2/0 -> 7/0 [ACTIVE] 3/0 -> 8/0 [ACTIVE] 2/0 -> 9/0 [ACTIVE] 3/0 -> 10/0 [ACTIVE] 2/0 -> 11/0 [ACTIVE] 3/0 -> 12/0 [ACTIVE] pad0: SINK,MUST_CONNECT pad1: SINK,MUST_CONNECT pad2: SINK,MUST_CONNECT [stream:0 fmt:SRGGB8_1X8/1920x1080 field:none] <- "4ac10000.syscon:formatter@20":1 [ENABLED,IMMUTABLE] pad3: SINK,MUST_CONNECT [stream:0 fmt:UYVY8_1X16/1920x1080 field:none] <- "4ac10000.syscon:formatter@120":1 [ENABLED,IMMUTABLE] pad4: SINK,MUST_CONNECT <- "mxc_isi.output":0 [ENABLED,IMMUTABLE] pad5: SOURCE [stream:0 fmt:SRGGB8_1X8/1920x1080 field:none] -> "mxc_isi.0":0 [ENABLED,IMMUTABLE] pad6: SOURCE [stream:0 fmt:UYVY8_1X16/1920x1080 field:none] -> "mxc_isi.1":0 [ENABLED,IMMUTABLE] pad7: SOURCE [stream:0 fmt:SRGGB8_1X8/1920x1080 field:none] -> "mxc_isi.2":0 [ENABLED,IMMUTABLE] pad8: SOURCE [stream:0 fmt:UYVY8_1X16/1920x1080 field:none] -> "mxc_isi.3":0 [ENABLED,IMMUTABLE] pad9: SOURCE [stream:0 fmt:SRGGB8_1X8/1920x1080 field:none] -> "mxc_isi.4":0 [ENABLED,IMMUTABLE] pad10: SOURCE [stream:0 fmt:UYVY8_1X16/1920x1080 field:none] -> "mxc_isi.5":0 [ENABLED,IMMUTABLE] pad11: SOURCE [stream:0 fmt:SRGGB8_1X8/1920x1080 field:none] -> "mxc_isi.6":0 [ENABLED,IMMUTABLE] pad12: SOURCE [stream:0 fmt:UYVY8_1X16/1920x1080 field:none] -> "mxc_isi.7":0 [ENABLED,IMMUTABLE] - entity 15: mxc_isi.0 (2 pads, 2 links, 0 routes) type V4L2 subdev subtype Unknown flags 0 device node name /dev/v4l-subdev1 pad0: SINK [stream:0 fmt:UYVY8_1X16/1920x1080 field:none compose.bounds:(0,0)/1920x1080 compose:(0,0)/1920x1080] <- "crossbar":5 [ENABLED,IMMUTABLE] pad1: SOURCE [stream:0 fmt:YUV8_1X24/1920x1080 field:none crop.bounds:(0,0)/1920x1080 crop:(0,0)/1920x1080] -> "mxc_isi.0.capture":0 [ENABLED,IMMUTABLE] - entity 18: mxc_isi.0.capture (1 pad, 1 link) type Node subtype V4L flags 0 device node name /dev/video2 pad0: SINK <- "mxc_isi.0":1 [ENABLED,IMMUTABLE] - entity 26: mxc_isi.1 (2 pads, 2 links, 0 routes) type V4L2 subdev subtype Unknown flags 0 device node name /dev/v4l-subdev2 pad0: SINK [stream:0 fmt:UYVY8_1X16/1920x1080 field:none compose.bounds:(0,0)/1920x1080 compose:(0,0)/1920x1080] <- "crossbar":6 [ENABLED,IMMUTABLE] pad1: SOURCE [stream:0 fmt:YUV8_1X24/1920x1080 field:none crop.bounds:(0,0)/1920x1080 crop:(0,0)/1920x1080] -> "mxc_isi.1.capture":0 [ENABLED,IMMUTABLE] - entity 29: mxc_isi.1.capture (1 pad, 1 link) type Node subtype V4L flags 0 device node name /dev/video3 pad0: SINK <- "mxc_isi.1":1 [ENABLED,IMMUTABLE] - entity 37: mxc_isi.2 (2 pads, 2 links, 0 routes) type V4L2 subdev subtype Unknown flags 0 device node name /dev/v4l-subdev3 pad0: SINK [stream:0 fmt:UYVY8_1X16/1920x1080 field:none colorspace:jpeg xfer:srgb ycbcr:601 quantization:full-range compose.bounds:(0,0)/1920x1080 compose:(0,0)/1920x1080] <- "crossbar":7 [ENABLED,IMMUTABLE] pad1: SOURCE [stream:0 fmt:YUV8_1X24/1920x1080 field:none colorspace:jpeg xfer:srgb ycbcr:601 quantization:full-range crop.bounds:(0,0)/1920x1080 crop:(0,0)/1920x1080] -> "mxc_isi.2.capture":0 [ENABLED,IMMUTABLE] - entity 40: mxc_isi.2.capture (1 pad, 1 link) type Node subtype V4L flags 0 device node name /dev/video4 pad0: SINK <- "mxc_isi.2":1 [ENABLED,IMMUTABLE] - entity 48: mxc_isi.3 (2 pads, 2 links, 0 routes) type V4L2 subdev subtype Unknown flags 0 device node name /dev/v4l-subdev4 pad0: SINK [stream:0 fmt:UYVY8_1X16/1920x1080 field:none colorspace:jpeg xfer:srgb ycbcr:601 quantization:full-range compose.bounds:(0,0)/1920x1080 compose:(0,0)/1920x1080] <- "crossbar":8 [ENABLED,IMMUTABLE] pad1: SOURCE [stream:0 fmt:YUV8_1X24/1920x1080 field:none colorspace:jpeg xfer:srgb ycbcr:601 quantization:full-range crop.bounds:(0,0)/1920x1080 crop:(0,0)/1920x1080] -> "mxc_isi.3.capture":0 [ENABLED,IMMUTABLE] - entity 51: mxc_isi.3.capture (1 pad, 1 link) type Node subtype V4L flags 0 device node name /dev/video5 pad0: SINK <- "mxc_isi.3":1 [ENABLED,IMMUTABLE] - entity 59: mxc_isi.4 (2 pads, 2 links, 0 routes) type V4L2 subdev subtype Unknown flags 0 device node name /dev/v4l-subdev5 pad0: SINK [stream:0 fmt:UYVY8_1X16/1920x1080 field:none colorspace:jpeg xfer:srgb ycbcr:601 quantization:full-range compose.bounds:(0,0)/1920x1080 compose:(0,0)/1920x1080] <- "crossbar":9 [ENABLED,IMMUTABLE] pad1: SOURCE [stream:0 fmt:YUV8_1X24/1920x1080 field:none colorspace:jpeg xfer:srgb ycbcr:601 quantization:full-range crop.bounds:(0,0)/1920x1080 crop:(0,0)/1920x1080] -> "mxc_isi.4.capture":0 [ENABLED,IMMUTABLE] - entity 62: mxc_isi.4.capture (1 pad, 1 link) type Node subtype V4L flags 0 device node name /dev/video6 pad0: SINK <- "mxc_isi.4":1 [ENABLED,IMMUTABLE] - entity 70: mxc_isi.5 (2 pads, 2 links, 0 routes) type V4L2 subdev subtype Unknown flags 0 device node name /dev/v4l-subdev6 pad0: SINK [stream:0 fmt:UYVY8_1X16/1920x1080 field:none colorspace:jpeg xfer:srgb ycbcr:601 quantization:full-range compose.bounds:(0,0)/1920x1080 compose:(0,0)/1920x1080] <- "crossbar":10 [ENABLED,IMMUTABLE] pad1: SOURCE [stream:0 fmt:YUV8_1X24/1920x1080 field:none colorspace:jpeg xfer:srgb ycbcr:601 quantization:full-range crop.bounds:(0,0)/1920x1080 crop:(0,0)/1920x1080] -> "mxc_isi.5.capture":0 [ENABLED,IMMUTABLE] - entity 73: mxc_isi.5.capture (1 pad, 1 link) type Node subtype V4L flags 0 device node name /dev/video7 pad0: SINK <- "mxc_isi.5":1 [ENABLED,IMMUTABLE] - entity 81: mxc_isi.6 (2 pads, 2 links, 0 routes) type V4L2 subdev subtype Unknown flags 0 device node name /dev/v4l-subdev7 pad0: SINK [stream:0 fmt:UYVY8_1X16/1920x1080 field:none colorspace:jpeg xfer:srgb ycbcr:601 quantization:full-range compose.bounds:(0,0)/1920x1080 compose:(0,0)/1920x1080] <- "crossbar":11 [ENABLED,IMMUTABLE] pad1: SOURCE [stream:0 fmt:YUV8_1X24/1920x1080 field:none colorspace:jpeg xfer:srgb ycbcr:601 quantization:full-range crop.bounds:(0,0)/1920x1080 crop:(0,0)/1920x1080] -> "mxc_isi.6.capture":0 [ENABLED,IMMUTABLE] - entity 84: mxc_isi.6.capture (1 pad, 1 link) type Node subtype V4L flags 0 device node name /dev/video8 pad0: SINK <- "mxc_isi.6":1 [ENABLED,IMMUTABLE] - entity 92: mxc_isi.7 (2 pads, 2 links, 0 routes) type V4L2 subdev subtype Unknown flags 0 device node name /dev/v4l-subdev8 pad0: SINK [stream:0 fmt:UYVY8_1X16/1920x1080 field:none colorspace:jpeg xfer:srgb ycbcr:601 quantization:full-range compose.bounds:(0,0)/1920x1080 compose:(0,0)/1920x1080] <- "crossbar":12 [ENABLED,IMMUTABLE] pad1: SOURCE [stream:0 fmt:YUV8_1X24/1920x1080 field:none colorspace:jpeg xfer:srgb ycbcr:601 quantization:full-range crop.bounds:(0,0)/1920x1080 crop:(0,0)/1920x1080] -> "mxc_isi.7.capture":0 [ENABLED,IMMUTABLE] - entity 95: mxc_isi.7.capture (1 pad, 1 link) type Node subtype V4L flags 0 device node name /dev/video9 pad0: SINK <- "mxc_isi.7":1 [ENABLED,IMMUTABLE] - entity 103: mxc_isi.output (1 pad, 1 link) type Node subtype V4L flags 0 pad0: SOURCE -> "crossbar":4 [ENABLED,IMMUTABLE] - entity 110: 4ac10000.syscon:formatter@120 (2 pads, 2 links, 1 route) type V4L2 subdev subtype Unknown flags 0 device node name /dev/v4l-subdev9 routes: 0/0 -> 1/0 [ACTIVE] pad0: SINK [stream:0 fmt:UYVY8_1X16/1920x1080 field:none] <- "csidev-4ad40000.csi":1 [ENABLED,IMMUTABLE] pad1: SOURCE [stream:0 fmt:UYVY8_1X16/1920x1080 field:none] -> "crossbar":3 [ENABLED,IMMUTABLE] - entity 115: 4ac10000.syscon:formatter@20 (2 pads, 2 links, 1 route) type V4L2 subdev subtype Unknown flags 0 device node name /dev/v4l-subdev10 routes: 0/0 -> 1/0 [ACTIVE] pad0: SINK [stream:0 fmt:SRGGB8_1X8/1920x1080] <- "csidev-4ad30000.csi":1 [ENABLED,IMMUTABLE] pad1: SOURCE [stream:0 fmt:SRGGB8_1X8/1920x1080] -> "crossbar":2 [ENABLED,IMMUTABLE] - entity 120: csidev-4ad30000.csi (2 pads, 2 links, 1 route) type V4L2 subdev subtype Unknown flags 0 device node name /dev/v4l-subdev11 routes: 0/0 -> 1/0 [ACTIVE] pad0: SINK [stream:0 fmt:SRGGB8_1X8/1920x1080 colorspace:srgb xfer:srgb ycbcr:601 quantization:full-range] <- "ov5640 4-003c":0 [ENABLED] pad1: SOURCE [stream:0 fmt:SRGGB8_1X8/1920x1080 colorspace:srgb xfer:srgb ycbcr:601 quantization:full-range] -> "4ac10000.syscon:formatter@20":0 [ENABLED,IMMUTABLE] - entity 125: csidev-4ad40000.csi (2 pads, 2 links, 1 route) type V4L2 subdev subtype Unknown flags 0 device node name /dev/v4l-subdev12 routes: 0/0 -> 1/0 [ACTIVE] pad0: SINK [stream:0 fmt:UYVY8_1X16/1920x1080 field:none] <- "ov5640 3-003c":0 [ENABLED] pad1: SOURCE [stream:0 fmt:UYVY8_1X16/1920x1080 field:none] -> "4ac10000.syscon:formatter@120":0 [ENABLED,IMMUTABLE] - entity 130: ov5640 4-003c (1 pad, 1 link, 0 routes) type V4L2 subdev subtype Sensor flags 0 device node name /dev/v4l-subdev13 pad0: SOURCE [stream:0 fmt:SRGGB8_1X8/1920x1080@1/30 colorspace:srgb xfer:srgb ycbcr:601 quantization:full-range crop.bounds:(0,0)/2624x1964 crop:(336,434)/1952x1088] -> "csidev-4ad30000.csi":0 [ENABLED] - entity 134: ov5640 3-003c (1 pad, 1 link, 0 routes) type V4L2 subdev subtype Sensor flags 0 device node name /dev/v4l-subdev14 pad0: SOURCE [stream:0 fmt:UYVY8_1X16/1920x1080@1/30 field:none colorspace:srgb xfer:srgb ycbcr:601 quantization:full-range crop.bounds:(0,0)/2624x1964 crop:(336,434)/1952x1088] -> "csidev-4ad40000.csi":0 [ENABLED] (The second OV5640 remains in UYVY mode for comparison) So : OV5640 -> SRGGB8 CSI -> SRGGB8 Formatter -> SRGGB8 Crossbar -> SRGGB8 => RAW Bayer is successfully propagated through the sensor, CSI and formatter. The neoisp kernel module is loaded: root@imx95-1:~# modprobe neoisp root@imx95-1:~# lsmod | grep -i isp neoisp 69632 0 An ISP node is present in the running device tree:   /sys/firmware/devicetree/base/soc/isp@4ae00000   => However, I only see a single media device (/dev/media0) exposing the CSI/Formatter/ISI pipeline. No neoisp entity appears in the media graph. I do not see any neoisp entity in the media graph, and I do not know whether this is expected. => cam -l (libcamera) still returns no available cameras. At this point the RAW Bayer path appears functional, but I cannot identify where the Neo ISP becomes part of the active pipeline.   How can I verify that the stream is actually processed by the Neo ISP rather than simply following the CSI -> Formatter -> ISI path?   Also, is https://www.nxp.com/docs/en/user-guide/UG10215.pdf still the recommended guide for this setup, or is there a more specific reference for OV5640 + Neo ISP on i.MX95?       Cordially, Re: IMX95 Aquila ISP usage My current suspicion is that one of the following is happening: OV5640 is running in YUV mode rather than RAW Bayer mode (most likely). The camera DT overlay is not the ISP-enabled variant. The Neo IPA/calibration components are missing from the root filesystem. The media topology seen by the Neo pipeline does not match the expected i.MX95 ISP graph. The media-ctl -p output will usually pinpoint which of these is the actual issue. Re: IMX95 Aquila ISP usage Hello ! Here is the output : root@imx95-1:~# v4l2-ctl --list-formats-ext -d /dev/video2 ioctl: VIDIOC_ENUM_FMT Type: Video Capture Multiplanar [0]: 'YUYV' (YUYV 4:2:2, csc-colorspace, csc-ycbcr, csc-quantization, csc-xfer-func) Size: Stepwise 1x1 - 4096x8191 with step 1/1 [1]: 'YUVA' (32-bit YUVA 8-8-8-8, csc-colorspace, csc-ycbcr, csc-quantization, csc-xfer-func) Size: Stepwise 1x1 - 4096x8191 with step 1/1 [2]: 'NV12' (Y/UV 4:2:0, csc-colorspace, csc-ycbcr, csc-quantization, csc-xfer-func) Size: Stepwise 2x2 - 4096x8190 with step 2/2 [3]: 'NM12' (Y/UV 4:2:0 (N-C), csc-colorspace, csc-ycbcr, csc-quantization, csc-xfer-func) Size: Stepwise 2x2 - 4096x8190 with step 2/2 [4]: 'NV16' (Y/UV 4:2:2, csc-colorspace, csc-ycbcr, csc-quantization, csc-xfer-func) Size: Stepwise 2x1 - 4096x8191 with step 2/1 [5]: 'NM16' (Y/UV 4:2:2 (N-C), csc-colorspace, csc-ycbcr, csc-quantization, csc-xfer-func) Size: Stepwise 2x1 - 4096x8191 with step 2/1 [6]: 'YM24' (Planar YUV 4:4:4 (N-C), csc-colorspace, csc-ycbcr, csc-quantization, csc-xfer-func) Size: Stepwise 1x1 - 4096x8191 with step 1/1 [7]: 'RGBP' (16-bit RGB 5-6-5, csc-colorspace, csc-ycbcr, csc-quantization, csc-xfer-func) Size: Stepwise 1x1 - 4096x8191 with step 1/1 [8]: 'RGB3' (24-bit RGB 8-8-8, csc-colorspace, csc-ycbcr, csc-quantization, csc-xfer-func) Size: Stepwise 1x1 - 4096x8191 with step 1/1 [9]: 'BGR3' (24-bit BGR 8-8-8, csc-colorspace, csc-ycbcr, csc-quantization, csc-xfer-func) Size: Stepwise 1x1 - 4096x8191 with step 1/1 [10]: 'XR24' (32-bit BGRX 8-8-8-8, csc-colorspace, csc-ycbcr, csc-quantization, csc-xfer-func) Size: Stepwise 1x1 - 4096x8191 with step 1/1 [11]: 'AR24' (32-bit BGRA 8-8-8-8, csc-colorspace, csc-ycbcr, csc-quantization, csc-xfer-func) Size: Stepwise 1x1 - 4096x8191 with step 1/1 [12]: 'RA24' (32-bit ABGR 8-8-8-8, csc-colorspace, csc-ycbcr, csc-quantization, csc-xfer-func) Size: Stepwise 1x1 - 4096x8191 with step 1/1 [13]: 'AB24' (32-bit RGBA 8-8-8-8, csc-colorspace, csc-ycbcr, csc-quantization, csc-xfer-func) Size: Stepwise 1x1 - 4096x8191 with step 1/1 [14]: 'RX24' (32-bit XBGR 8-8-8-8, csc-colorspace, csc-ycbcr, csc-quantization, csc-xfer-func) Size: Stepwise 1x1 - 4096x8191 with step 1/1 [15]: 'XB24' (32-bit RGBX 8-8-8-8, csc-colorspace, csc-ycbcr, csc-quantization, csc-xfer-func) Size: Stepwise 1x1 - 4096x8191 with step 1/1 [16]: 'AR30' (32-bit ARGB 2-10-10-10, csc-colorspace, csc-ycbcr, csc-quantization, csc-xfer-func) Size: Stepwise 1x1 - 4096x8191 with step 1/1 [17]: 'GREY' (8-bit Greyscale, csc-colorspace, csc-ycbcr, csc-quantization, csc-xfer-func) Size: Stepwise 1x1 - 4096x8191 with step 1/1 [18]: 'Y10 ' (10-bit Greyscale, csc-colorspace, csc-ycbcr, csc-quantization, csc-xfer-func) Size: Stepwise 1x1 - 4096x8191 with step 1/1 [19]: 'Y12 ' (12-bit Greyscale, csc-colorspace, csc-ycbcr, csc-quantization, csc-xfer-func) Size: Stepwise 1x1 - 4096x8191 with step 1/1 [20]: 'Y14 ' (14-bit Greyscale, csc-colorspace, csc-ycbcr, csc-quantization, csc-xfer-func) Size: Stepwise 1x1 - 4096x8191 with step 1/1 [21]: 'BA81' (8-bit Bayer BGBG/GRGR, csc-colorspace, csc-ycbcr, csc-quantization, csc-xfer-func) Size: Stepwise 1x1 - 4096x8191 with step 1/1 [22]: 'GBRG' (8-bit Bayer GBGB/RGRG, csc-colorspace, csc-ycbcr, csc-quantization, csc-xfer-func) Size: Stepwise 1x1 - 4096x8191 with step 1/1 [23]: 'GRBG' (8-bit Bayer GRGR/BGBG, csc-colorspace, csc-ycbcr, csc-quantization, csc-xfer-func) Size: Stepwise 1x1 - 4096x8191 with step 1/1 [24]: 'RGGB' (8-bit Bayer RGRG/GBGB, csc-colorspace, csc-ycbcr, csc-quantization, csc-xfer-func) Size: Stepwise 1x1 - 4096x8191 with step 1/1 [25]: 'BG10' (10-bit Bayer BGBG/GRGR, csc-colorspace, csc-ycbcr, csc-quantization, csc-xfer-func) Size: Stepwise 1x1 - 4096x8191 with step 1/1 [26]: 'GB10' (10-bit Bayer GBGB/RGRG, csc-colorspace, csc-ycbcr, csc-quantization, csc-xfer-func) Size: Stepwise 1x1 - 4096x8191 with step 1/1 [27]: 'BA10' (10-bit Bayer GRGR/BGBG, csc-colorspace, csc-ycbcr, csc-quantization, csc-xfer-func) Size: Stepwise 1x1 - 4096x8191 with step 1/1 [28]: 'RG10' (10-bit Bayer RGRG/GBGB, csc-colorspace, csc-ycbcr, csc-quantization, csc-xfer-func) Size: Stepwise 1x1 - 4096x8191 with step 1/1 [29]: 'BG12' (12-bit Bayer BGBG/GRGR, csc-colorspace, csc-ycbcr, csc-quantization, csc-xfer-func) Size: Stepwise 1x1 - 4096x8191 with step 1/1 [30]: 'GB12' (12-bit Bayer GBGB/RGRG, csc-colorspace, csc-ycbcr, csc-quantization, csc-xfer-func) Size: Stepwise 1x1 - 4096x8191 with step 1/1 [31]: 'BA12' (12-bit Bayer GRGR/BGBG, csc-colorspace, csc-ycbcr, csc-quantization, csc-xfer-func) Size: Stepwise 1x1 - 4096x8191 with step 1/1 [32]: 'RG12' (12-bit Bayer RGRG/GBGB, csc-colorspace, csc-ycbcr, csc-quantization, csc-xfer-func) Size: Stepwise 1x1 - 4096x8191 with step 1/1 [33]: 'BG14' (14-bit Bayer BGBG/GRGR, csc-colorspace, csc-ycbcr, csc-quantization, csc-xfer-func) Size: Stepwise 1x1 - 4096x8191 with step 1/1 [34]: 'GB14' (14-bit Bayer GBGB/RGRG, csc-colorspace, csc-ycbcr, csc-quantization, csc-xfer-func) Size: Stepwise 1x1 - 4096x8191 with step 1/1 [35]: 'GR14' (14-bit Bayer GRGR/BGBG, csc-colorspace, csc-ycbcr, csc-quantization, csc-xfer-func) Size: Stepwise 1x1 - 4096x8191 with step 1/1 [36]: 'RG14' (14-bit Bayer RGRG/GBGB, csc-colorspace, csc-ycbcr, csc-quantization, csc-xfer-func) Size: Stepwise 1x1 - 4096x8191 with step 1/1 [37]: 'BYR2' (16-bit Bayer BGBG/GRGR, csc-colorspace, csc-ycbcr, csc-quantization, csc-xfer-func) Size: Stepwise 1x1 - 4096x8191 with step 1/1 [38]: 'GB16' (16-bit Bayer GBGB/RGRG, csc-colorspace, csc-ycbcr, csc-quantization, csc-xfer-func) Size: Stepwise 1x1 - 4096x8191 with step 1/1 [39]: 'GR16' (16-bit Bayer GRGR/BGBG, csc-colorspace, csc-ycbcr, csc-quantization, csc-xfer-func) Size: Stepwise 1x1 - 4096x8191 with step 1/1 [40]: 'RG16' (16-bit Bayer RGRG/GBGB, csc-colorspace, csc-ycbcr, csc-quantization, csc-xfer-func) Size: Stepwise 1x1 - 4096x8191 with step 1/1 [41]: 'MJPG' (Motion-JPEG, compressed, csc-colorspace, csc-ycbcr, csc-quantization, csc-xfer-func) Size: Stepwise 1x1 - 4096x8191 with step 1/1 If I read it correctly, camera does take raw bayer, and I configured it to aswell (hopefully I did it correctly). I'll try to flash again with another image to see if the issue is somewhere around there. Cordially, Re: IMX95 Aquila ISP usage Thank you for the update. The  v4l2-ctl  output confirms that the ISI capture node supports RAW Bayer formats, and the  media-ctl -p  output from your previous message already shows that the RAW Bayer path is correctly propagated through the pipeline: OV5640 (SRGGB8) -> CSI (SRGGB8) -> Formatter (SRGGB8) -> Crossbar (SRGGB8) So the sensor-side configuration looks correct. The core issue now is that the  neoisp  module is loaded but does not appear in the media graph, and no  /dev/media1  is created. This typically indicates that the  neoisp  driver loaded successfully as a kernel module but failed during device probe, which would prevent it from registering a media device. Could you please provide the following diagnostic information: # Check neoisp probe status dmesg | grep -i neoisp dmesg | grep -i "isp@4ae" dmesg | grep -i "probe failed" dmesg | grep -i "4ae00000" # Confirm all available media devices ls -la /dev/media* # Check neoisp status in sysfs ls /sys/bus/platform/drivers/nxp-neoisp/ cat /sys/firmware/devicetree/base/soc/isp@4ae00000/status In parallel, we would also like to ask: do you have access to any of the following sensors that are officially supported by the NXP Neo ISP stack with complete tuning profiles? OS08A20 OX03C10 OX05B1S Testing with one of these sensors would allow us to quickly verify whether the Neo ISP driver itself is functioning correctly in your environment, and help isolate whether the issue is driver/environment-related or specific to the OV5640 configuration. Note that while OV5640 is capable of RAW Bayer output, it does not have an official NXP Neo ISP tuning profile, which means even if the pipeline is connected correctly, AE/AWB and image quality tuning will not be available. Re: IMX95 Aquila ISP usage Some update: We checked this internally and would like to share the following observations regarding OV5640 and the i.MX95 Neo ISP pipeline. Although the OV5640 is capable of outputting RAW Bayer data, we generally do not recommend the OV5640 + Neo ISP combination for new designs for the following reasons: OV5640 is already an end-of-life (EOL) sensor. Although RAW output is supported, the sensor itself provides only limited tunable controls compared to more recent RAW sensors. NXP's i.MX95 reference camera solution is based on RAW sensors such as OS08A20, which are already supported and validated within the Neo ISP software framework. Therefore, our recommendation would be one of the following: Use OV5640 together with its existing image processing path (without relying on Neo ISP AE/AWB tuning functionality). Use an NXP-supported RAW sensor such as OS08A20 if full Neo ISP functionality is required. If OV5640 must be used with the Neo ISP pipeline, additional software enablement work will be required. For the OV5640 + Neo ISP approach, a libcamera CameraHelper needs to be implemented. The following file can be used as a starting reference: camera_helper_ov5640.cpp https://github.com/nxp-imx/libcamera/blob/lf-6.6.52_2.2.0/src/ipa/nxp/cam_helper/camera_helper_ov5640.cpp Please note that this CameraHelper implementation is only the first step. Its primary purpose is to allow libcamera to recognize and identify the OV5640 sensor. Additional sensor-specific adaptation is still required. For example, if Neo ISP Auto Exposure (AE) is expected to work, APIs such as the sensor gain conversion functions need to be implemented. A simple example can be found in the IMX219 CameraHelper implementation: https://github.com/nxp-imx/libcamera/blob/lf-6.18.20_2.0.0/src/ipa/nxp/cam_helper/camera_helper_imx219.cpp In particular, the customer would need to determine and implement the mapping between: Sensor gain code Real analog gain multiplier (gain value) so that the Neo ISP AE algorithm can correctly control the sensor exposure and gain. For CameraHelper development details, please refer to the Camera Porting Guide: Section 5.3 – "Implementing a libcamera CameraHelper for a new sensor" One special consideration for OV5640 is that it already contains its own AE functionality. Therefore, if the intention is to continue using the sensor's internal AE instead of the Neo ISP AE algorithm, implementations such as gainCodeToGain() and gainToGainCode() may not be strictly required. In this case, a basic CameraHelper used only for sensor detection may be sufficient to bring up the pipeline. However, image quality tuning would still need to be evaluated and adjusted. Since OV5640 was not originally characterized and tuned as a Neo ISP reference sensor, additional ISP tuning work may be required to achieve optimal image quality. Overall, while OV5640 RAW output can be connected to the i.MX95 Neo ISP pipeline, some sensor-specific libcamera and ISP integration work is expected. For new developments, we would recommend using a Neo ISP validated RAW sensor such as OS08A20 whenever possible. Re: IMX95 Aquila ISP usage Following up on our previous discussion, we have investigated the root cause of the Neo ISP pipeline not recognizing the OV5640 sensor. The issue is that the NXP Neo IPA (Image Processing Algorithm) framework uses a  CameraHelper  factory to look up sensor-specific gain/exposure algorithms by matching the kernel V4L2 subdev model string. Since no  CameraHelper  was registered for  "ov5640" , the factory returned  nullptr  and the ISP pipeline could not be configured for this sensor. To address this, we have implemented a  CameraHelper  for the OV5640 sensor based on the in-tree NXP kernel driver ( drivers/media/i2c/ov5640.c 😞 Gain register mapping: Register:  OV5640_REG_AEC_PK_REAL_GAIN  ( 0x350a ), 10-bit value Format: Q6.4 fixed point, unity gain = 16 gainCode(g) = round(g * 16) gain(code) = code / 16.0 Two files have been modified: camera_helper_ov5640.cpp  – new CameraHelper implementation for OV5640, registered as  "ov5640"  to match the kernel subdev model string meson.build  – added  camera_helper_ov5640.cpp  to the build source list Please rebuild libcamera with these two files and retry with  LIBCAMERA_PIPELINES_MATCH_LIST='nxp/neo' . The Neo ISP pipeline should now be able to find and configure the OV5640 sensor. Note that while this enables the gain/exposure control path, a full ISP tuning profile (AE/AWB parameters) for OV5640 is not yet available. Image quality tuning may still require further work. Please let us know the results after rebuilding.

SE050漏洞报告   我有一个关于SE050的技术支持问题。我们将推出一款使用 SE050 的产品，该产品在现场不会获得软件更新。根据欧盟网络弹性法案 (CRA)，我们有义务监测我们使用的组件中的漏洞，并在规定的时间内报告已被积极利用的漏洞和严重事件。   请问您能告诉我们以下信息吗： - NXP 是否针对 SE050 运行漏洞披露或网络安全通知流程（例如邮件列表、网络安全公告页面或 PSIRT 信息流），我们可以订阅或监测？ - 鉴于该特定产品线不支持现场更新，如何将已知的漏洞及其状态（已修复、已缓解、不适用）传达给使用 SE050 的客户？ - 是否有办法接收主动通知，而不是手动查看？ SE050 Re: SE050 vulnerability reporting 嗨@djdirkj ， [产品网络安全漏洞 | 恩智浦半导体 | https://www.nxp.com/support/support/product-security-vulnerability:PSIRT ]PSIRT 团队可以接到漏洞报告，他们会进行评估，找到合适的解决方案，并与受影响的产品购买者（直接客户和分销商）沟通，然后分销商再通知他们的购买者。 错误及补救措施记录在勘误表和用户指南中。任何人都可以通过点击产品页面上的“接收提醒”选项来接收这些文档的更新信息，从而了解文档的更新情况。 祝你有美好的一天， 坎 ------------------------------------------------------------------------------- 笔记： - 如果此回复解答了您的问题，请点击“标记为正确答案”按钮。谢谢你！ - 我们会持续关注帖子，从最后一条回复发出后持续7周，之后的回复将被忽略。 如果您之后有相关问题，请另开新帖并引用已关闭的帖子。 -------------------------------------------------------------------------------

KW45B41Z EVKが搭載デバッガーMCUリンクでプログラムされていないこと。 こんにちは、 kw45b41zevk_hello_world SDKのサンプルコードを使ってKW45B41Z-EVKをプログラムしようとしています。デバッグを開始すると、オンボードデバッガーは検出されますが、その後、次のエラーが発生します。 検出された利用可能なSWDデバイスは0個です。 デバイスを接続して、もう一度お試しください。 USBケーブルは J14 に接続し、 JP22はオン ボードデバッガでプログラムするために開いたままにしています。また、 KW45UMで述べられているように、 JP28のピン1と2は短絡されています。しかし、その後もサンプルプログラムをプログラミングしたりデバッグしたりすることができません。 kw45b41zevk_led_blinky SDKの例も試しましたが、同じように動作します。 KW45UMで説明されているように、外部デバッガを使用してJP22をショートさせてボードのデバッグも試みましたが、同じ問題が発生します。 発生している問題のスクリーンショットを添付しました。 セキュアプロビジョニングツールを使用して、フラッシュメモリを消去してイメージを書き込むことも試しました。まず、 JP25をショートさせてSW4を有効にし、次にSW4とリセット（SW3）を長押ししてISPモードに入りました。接続テストが成功した後、フラッシュメモリ（位置0x00000000 、サイズ0x100000 ）の消去に成功しました。次に、以下の画像を使用しました。 ${SPT_INSTALL_BIN} \data\sample_data\targets\KW45B41Z8\source_images\kw45b41zevk_led_blinky.s19 画像の構築とプログラムは無事にでき、意図した RGB LED1 も点滅しており、KW45B41Z マイクロコントローラが正常に動作していることを示しています。しかし、それでもなお、基板のプログラミングやデバッグができません。 Re: KW45B41Z EVK not programming over on board Debugger MCU Link. こんにちは、 @kaif1 どのIDEを使っていますか? MCUXpresso IDEまたはMCUXpresso for VS Code? 私の方で試してみて、デフォルトのジャンパー設定をお知らせします。 よろしくお願いいたします。 Christine。 Re: KW45B41Z EVK not programming over on board Debugger MCU Link. こんにちは、 @kaif1 ジャンパーの設定を参照してください。ローカル側で確認済みで、hello_world例をボードに正常にフラッシュできます。 そして、MCUXpresso IDEとSDK 25.12.00を使っています。 私のジャンパー設定を試してみて、うまくいくかどうか教えてください。 よろしくお願いいたします。 Christine。

「セキュアボックス版」とは何ですか？ AN12413仕様のGetVersion-APDUでは、「VersionInfo」に2バイトの「セキュアボックスバージョン」が定義されています。それが一体何なのか、明確な定義はない。 なぜこの情報が必要なのですか？ 私は現在、通知機関との製品の認証手続きの最中です。この製品は特定のセキュリティ機能のためにSE050を使用しており、SE050にはファームウェアも含まれているため、これは認証の一部です。 SE050 Re: What is "Secure Box version"? こんにちは@Kan_Liさん 迅速なご返信ありがとうございます。感謝いたします。 すべての SE050A2 が同じかどうか確認できますか? OEF ID、プラットフォームビルドID、OSパッチレベル、アプレットのバージョン、機能設定。 そして、新たなロットを注文した場合でも、この点は変わりません。 この話題について知っておくべきことはこれだけです。 敬具 ダーク・ヤン Re: What is "Secure Box version"? こんにちは、 @djdirkj さん。 SE050A2すべてのチップが文字通り同一であることを証明しようとしないでください。OEF ID、プラットフォームビルドID、OSパッチレベル、アプレットバージョン、機能構成が同じであることを証明しつつ、トレーサビリティのために独自のシリアル/バッチデータを記録してください。 すてきな一日を、 カン ------------------------------------------------------------------------------- 注記： この投稿があなたの質問への回答になっている場合は、「正解としてマーク」ボタンをクリックしてください。ありがとうございます! - 前回の投稿から7週間Threadをフォローしており、その後の返信は無視しています もし後で関連する質問があれば、新しいThreadを開き、閉じたThreadを参照してください。 ------------------------------------------------------------------------------- Re: What is "Secure Box version"? こんにちは@Kan_Liさん ご回答ありがとうございます！ 質問を言い換えてみましょう。 弊社のEMS（電子機器受託製造業者）には、SE050A2部品が約500個入ったリールがあります。これらのSE050で500個の製品を生産した場合、すべてのSE050がまったく同じかどうかどうやって確信できますか? SE050に違いがある場合、証明書に適合しておらず、証明書の修正が必要です。これが望ましい状況ではないことをご理解いただければ幸いです。 Re: What is "Secure Box version"? こんにちは、 @djdirkj さん。 Secure Box版はSE050ソフトウェア/構成証拠の一部として記録してください。ただし、NXPが管理された定義を提供しない限り、独立して解釈しようとしないでください。認証の場合は完全なものが必要です  GetVersion  /  se05x_GetInfo  出力はより強力なトレーサビリティのアーティファクトです。 すてきな一日を、 カン ------------------------------------------------------------------------------- 注記： この投稿があなたの質問への回答になっている場合は、「正解としてマーク」ボタンをクリックしてください。ありがとうございます! - 前回の投稿から7週間Threadをフォローしており、その後の返信は無視しています もし後で関連する質問があれば、新しいThreadを開き、閉じたThreadを参照してください。 ------------------------------------------------------------------------------- Re: What is "Secure Box version"? こんにちは、 @djdirkj さん。 はい、SE050Aではこれらのパラメータはすべて静的です。 すてきな一日を、 カン ------------------------------------------------------------------------------- 注記： この投稿があなたの質問への回答になっている場合は、「正解としてマーク」ボタンをクリックしてください。ありがとうございます! - 前回の投稿から7週間Threadをフォローしており、その後の返信は無視しています もし後で関連する質問があれば、新しいThreadを開き、閉じたThreadを参照してください。 -------------------------------------------------------------------------------

如何将 S32 Design Studio 许可证转移/重新注册到我自己的 NXP 帐户 你好， 尊敬的技术支持团队： 这是第二条信息 （第一页： https ://community.nxp.com/t5/MPC5xxx/Request-for-Software-License-Extension-Due-to-Expiration/mp/2396968#M28490） 我的办公电脑是我从前任经理那里继承来的，S32 Design Studio 仍然是在他的 NXP 账户下激活的，而不是我的。因此，我电脑上安装的许可证似乎已经过期了。 我已经确认我的许可证有效期至 2028 年，因此我想将这台电脑上的 S32DS 切换到我的 NXP 帐户和许可证，而不是前任所有者的帐户和许可证。 请问正确的操作步骤是什么？具体来说： 1. 是否有办法停用或解除与先前帐户关联的现有激活状态？ 2. 我能否使用我自己的帐户凭据重新激活 S32DS，还是需要完全卸载并重新安装？ 感谢您的帮助。 顺祝商祺！ Re: How to transfer/re-register an S32 Design Studio license to my own NXP account 你好， 您可以使用之前用户的旧激活码。激活码与特定账户无关。 您可以使用旧代码重新激活现有安装。