フラッシュ消去時にRAM内でピット割り込みが実行されます フラッシュを消している間にタイマー割り込みに入れないことがわかりました。私の要件を満たすために、タイマー割り込みをRAM上で実行する予定です。linker_flash_s32k388.ld ファイルを修正して IntCtrl_Ip.o と Pit_Ip.o を RAM に配置するようにしましたが、フラッシュを消去すると、タイマー割り込みの発生により依然としてエラーが発生します。私が見落としている点があれば教えてください。#s32k388 Re: Pit interrupt runs in ram wen flash erase こんにちは、 IntCtrl_Ip.oとPit_Ip.oを配置するだけでRAMに書き込むだけでは通常は不十分です。PFLASH消去操作中は、CPUは影響を受けたフラッシュアレイへのアクセスを避けなければなりません。 割り込みベクタテーブル、PIT ISR、ISRによって呼び出されるすべての関数、およびISRで使用されるすべてのデータ/定数がSRAMに配置されていることを確認してください。さらに、VTORレジスタがRAMベースのベクタテーブルを指していることを確認してください。リンカーマップファイルは通常、残りのフラッシュアクセスを特定する最良の方法です。 S32K3リファレンスマニュアルには、フラッシュ操作が継続実行を必要とする場合はコード実行をSRAMに移す必要があると記載されています。 よろしくお願いいたします。 ピーター Re: Pit interrupt runs in ram wen flash erase 私のISRとISRが呼び出す関数はRAMに配置されており、VTORのアドレスも0x2...0x4ではなく...RTDの設定時にフラッシュドライバーがRAMで動作するのを選びました。PITが閉じている間は正常に動作しますが、PITを有効にするとフリーズします。ただ、デバッグしても問題の原因を特定できません Re: Pit interrupt runs in ram wen flash erase こんにちは、 説明文だけでは判断しにくい。 見落とされがちなこと： 割り込みベクタテーブルはまだフラッシュメモリに保存されています CPUはまずベクタテーブルからISRアドレスを取得する。 ベクターテーブルがP-Flashに残る場合、割り込みは消去中にFlashにアクセスし続けます。 ベクトルテーブルはRAMにコピーされ、それに応じてVTORが更新される必要がある。 PIT ISR関数自体はRAMに存在しなければならない。 PITドライバ( Pit_Ip.o )だけでなく、アプリケーションのコールバックやISRも含まれます。 ISRから呼び出されるものはすべてRAMに存在しなければならない。 アプリケーション機能 OSサービス スケジューラフック ログ記録/デバッグ機能 ISRによって呼び出されるヘルパー関数 Flashに常駐する定数はありません たとえコードがRAMから実行されていても、以下へのアクセスがあります: const 表 補正データ 文字列リテラル 構成構造は依然としてフラッシュ読み取りを生じさせることがあります。 スタックトレース/デバッグインフラストラクチャによるフラッシュアクセスはありません デバッグビルドでは、予期しないFlash参照が混入することがよくあります。 よろしくお願いいたします。 ピーター

执行 fls_Erase() 操作期间断电后，数据闪存损坏和 ECC 错误 我们发现，当由于断电/RESET情况导致Fls_Erase()操作中断时，数据闪存会发生损坏。系统重启后，受影响的数据闪存区域似乎已损坏。 在随后尝试使用Fls_Erase()恢复扇区时，当 Flash 驱动程序在执行擦除操作之前尝试访问受影响的地址范围时，会生成 ECC 错误。因此，擦除操作无法成功进行。 我们希望了解闪存控制器在此场景下的预期行为，并请求就以下几点提供指导： 如果在Fls_Erase()操作进行期间断电，数据闪存是否会损坏？ 在发生此类中断后，访问部分擦除/损坏的闪存扇区时，是否预期会出现 ECC 错误？ 是否有任何机制或寄存器可以暂时禁用 Flash ECC 检查，以便擦除和恢复损坏的 Flash 扇区？ 断电后，对于包含无法纠正的ECC错误的闪存扇区，推荐的恢复程序是什么？ 目标设备： [MPC5746C] 软件栈： [AUTOSAR / 裸机] Re: Data Flash Corruption and ECC Errors After Power Abort During Fls_Erase() Operation 你好， 如果在Fls_Erase()操作进行期间断电，数据闪存是否会损坏？ 是的，这是正确的做法。由于编程/擦除过程中断电，闪存中的数据将与 ECC 纠错码不匹配。 在发生此类中断后，访问部分擦除/损坏的闪存扇区时，是否预期会出现 ECC 错误？ 是的。 是否有任何机制或寄存器可以暂时禁用 Flash ECC 检查，以便擦除和恢复损坏的 Flash 扇区？ 不，这是硬件的永久性功能。 断电后，对于包含无法纠正的ECC错误的闪存扇区，推荐的恢复程序是什么？ 在这种情况下，您需要初始化（擦除）损坏的闪存块。一旦完成 ECC 纠错，闪存中的数据将与 ECC 纠错匹配，访问不会触发 ECC 错误。 有关闪存擦除步骤，请参阅参考手册： 顺祝商祺！ Peter

S32K396的ETPU的例子 您好，我需要一个S32K396的RTD5.0.0用于S32DS3.5中生成的ETPU的demo，然后我想将它用于喷油功能，可以给我一个软件包和代码例子吗 Re: S32K396的ETPU的例子 嗨@大概， 实时驱动程序 (RTD)中已有 ETPU 和 S32K396 的示例： 此外，您可以在S32K3 - eTPU软件包中找到各种示例。它独立于RTD，这意味着可以使用任何版本，但是，eTPU软件仅使用特定的RTD 7.0.0版本进行了验证。版本，且无法保证与其他版本的兼容性。 此致， 朱利安

S32 Design Studio for ARM v2.2许可延期 あなたは好,S32 Design Studio for ARM v2.2提示許可馬上到期,Activation Code:FAF2-FCC2-8A8E-87AC,麻烦延期,谢谢!

i.MX 8M Plus LPDDR4 EVK - eMMC boot0/boot1 の有効化 ボード:i.MX 8M Plus LPDDR4 EVK(MIMX8ML8DVNLZAA年)、IMX8MPEVKHUG rev 0 HAB:融合オープン(SRKは意図的に燃焼せず、まだ評価中) 私はRAUCベースのA/B更新システム向けにブートローダーと更新の冗長性を実装しており、eMMCのハードウェアboot0/boot1パーティション(BOOT_PARTITION_ENABLE)を多くのi.MX8M設計のように使いたいと考えています。つまり、新しいブートローダーを非アクティブなブートパーティションに書き込み、どちらがアクティブかを反転させ、新たにアクティブなブートローダーが故障した場合はROMがもう一方にフォールバックする形です。私は特に、このためにBOOT_CFG/efuseを焼却することを避けたいのです。 EVK上で、poky/oe-core mmc-utilsレシピからビルドしたmmc-utilsを使用して観察した結果は以下のとおりです。 - mmc extcsd read /dev/mmcblk2 は PARTITION_CONFIG を報告し、BOOT_PARTITION_ENABLE は既に boot0 (値 0x08) に設定されています。 - boot0 (/dev/mmcblk2boot0) には有効なイメージ (オフセット 0 に正しい IVT タグ) が含まれていますが、現在デプロイされているブートローダーと一致しません。 - boot1 (/dev/mmcblk2boot1) は完全に空です (すべてゼロ)。 - バイト単位の正確な比較により、ボードは実際には標準の32 KiBオフセットで生のeMMCユーザーエリアから起動していることが確認できます(コンテンツは現在デプロイしているimx-bootと完全に一致します)。boot0から起動しているわけではありません。boot0が有効であることを示すPARTITION_CONFIGもあります。 このボードでは、EXT_CSDのBOOT_PARTITION_ENABLEはROMの実際のブートソースに影響を与えていないようです。IMX8MPEVKHUG 2.2節によると、EVKのSW4スイッチは粗いブートデバイスクラス(eMMC、SD、QSPI、NAND、ヒューズ、USBシリアルダウンロード)のみを選択し、eMMCブートパーティションサブモードのスイッチ位置は存在しません。 質問: 1. LPDDR4 EVK上で「eMMC boot0/boot1ハードウェアパーティションからのROMブート」を特に選択する方法は、BT_FUSE_SEL=1設定やBOOT_CFGエフューズの焼却なしに選択できるサポート方法はありますか?例えば、ジャンパー、抵抗オプション、またはrev 0に記載されていない代替のSW4/SW1101の組み合わせなどIMX8MPEVKHUG?それとも、このボードのPCBにハードストラップされていて、状態に関係なく常にeMMCユーザーエリアから起動するようにEXT_CSD? 2. BOOT_CFG efuseがeMMCブートパーティションモードを有効にする唯一の方法である場合、これを制御するBOOT_CFGヒューズバンクは、HABに使用されるSRKハッシュヒューズとは独立していますか？ヒューズを介してeMMCブートパーティションの冗長性を有効にすると、同時にHAB（SRK書き込み）を終了する必要が生じるのか、それともこれらは別々の決定事項なのかを理解したい。 3. i.MX 8M PlusとeMMCを使ったカスタムボード設計(EVKではありません)の場合、eMMCのboot0/boot1冗長性を最初の起動時から利用可能にする推奨方法は何でしょうか?つまり、BOOT_CFG GPIOのストラップやPCB設計において、後でヒューズのコミットメントを必要としないよう、初日の選択肢として何が真であるべきか? また、eMMCブートパーティション選択のBOOT_CFGビット定義(IMX8MPEVKHUGで既に扱われているSW4デバイスクラスビット以外)を扱ったリファレンスマニュアルのセクションへの指し印も教えていただけると助かります。 ご回答をお待ちしています。 Re: i.MX 8M Plus LPDDR4 EVK - enabling eMMC boot0/boot1 i.Mx8 UMに関する参考までに、第5章の第5.8.2.2.1章「高レベルeMMCブートフロー」 SCU ROMは4つのeMMCブートシナリオをサポートします: 1.このシナリオでは、「eMMC高速ブート」ヒューズが切れています。一次および二次 イメージコンテナセットは両方ともブートパーティション内にあり、BOOT_PARTITION_ENABLE = 1 または 2 です。 2. このシナリオでは、「eMMC 高速ブート」ヒューズが切れています。小学校と中学校 イメージコンテナセットはどちらもユーザーエリアにあり、BOOT_PARTITION_ENABLE=7です。 3.このシナリオでは、「eMMC高速ブート」ヒューズは切れません。起動モードはノーマルです Bootとプライマリおよびセカンダリイメージコンテナセットはどちらもユーザーエリアにあります。 4. この場合、「eMMCファストブート」ヒューズは 切れていません。起動モードは通常です ブート、プライマリおよびセカンダリイメージコンテナセットは両方ともブート内にあります パーティション、および BOOT_PARTITION_ENABLE = 1 または 2。 Re: i.MX 8M Plus LPDDR4 EVK - enabling eMMC boot0/boot1 アドバイスありがとうございます。ただ、第5.8.2.2.1章で別のチップファミリが説明されていると思います。「SCU ROM」eMMCブートフローは、専用のシステムコントローラユニット(Cortex-M4ブートサブシステム)を持つi.MX8QuadMax/QuadXPlus/DualXPlus専用です。i.MX8M PlusにはSCUがなく、起動ROMはCortex-A53上で直接動作するため、その章の BOOT_PARTITION_ENABLE=1/2/7 シナリオはここでは当てはまりません。 i.MX8M Plusの場合、冗長性はi.MX8M Plusリファレンスマニュアル(図6-1)のプライマリ/セカンダリイメージ機構で処理されているようです。ROMはBT_FUSE_SEL/BOOT_CFGで選択したデバイスから起動し、故障時には同じブートデバイス上でIMG_CNTN_SET1_OFFSETヒューズオフセットのセカンダリイメージにフォールバックします。 別々のboot0/boot1パーティションではありません。これはLPDDR4 EVKで見ているものと一致します。BOOT_PARTITION_ENABLE=1はEXT_CSDに設定されていますが、ROMはそれを無視し、生のユーザーエリアのオフセットから起動します。 そこで、私の質問はi.MX8M Plusに限定されました: 1. LPDDR4のEVK(ジャンパー、抵抗、または非公式のSW1101/SW4位置)でeMMC boot0/boot1をブートソースとして選択する方法はありますか?それとも純粋にストラップやBT_FUSE_SELの判断BOOT_CFGに過ぎませんか? 2. BOOT_CFGヒューズバンクはHABのSRKハッシュヒューズとは独立しているのか、それともBOOT_CFGヒューズ経由のコミットもHABのクロージングを強制するのか? 3.カスタムボード設計の場合、レイアウト時にハードウェアのブートパーティション冗長性を後でヒューズに縛り付けずに維持するために、どのようなBOOT_CFGものが必要ですか? もし私が第5.8.2.2.1章のどの部分に適用されるのかを誤解しているようでしたら、ご指摘いただければ幸いです。

Example of an ETPU based on S32K396 Hello, I need a demo of RTD 5.0.0 for S32K396 used in an ETPU generated by S32DS3.5. I want to use it for fuel injection functionality. Could you provide a software package and code examples? Re: S32K396的ETPU的例子 Hi @大概, There is an existing example for ETPU & S32K396 inside the Real-Time Drivers (RTD): Additionally, you can find various examples inside the S32K3 - eTPU SW package. It is independent from RTDs, meaning any version can be used, however, the eTPU SW has been validated only with the specific RTD 7.0.0 version, and compatibility with other versions cannot be guaranteed. Best regards, Julián

Data Flash Corruption and ECC Errors After Power Abort During Fls_Erase() Operation We are observing Data Flash corruption when a Fls_Erase() operation is interrupted due to a power abort/reset condition. After the system restarts, the affected Data Flash region appears corrupted. During a subsequent attempt to recover the sector using Fls_Erase(), ECC errors are generated when the Flash driver tries to access the affected address range before performing the erase operation. As a result, the erase operation cannot proceed successfully. We would like to understand the expected behavior of the Flash controller in this scenario and request guidance on the following points: Is Data Flash corruption expected if power is lost during an ongoing Fls_Erase() operation? Are ECC errors expected when accessing a partially erased/corrupted Flash sector after such an interruption? Is there any mechanism or register available to temporarily disable Flash ECC checking so that the corrupted Flash sector can be erased and recovered? What is the recommended recovery procedure for handling Data Flash sectors that contain uncorrectable ECC errors following a power interruption? Target Device: [MPC5746C] Software Stack: [AUTOSAR / Bare Metal] Re: Data Flash Corruption and ECC Errors After Power Abort During Fls_Erase() Operation Hello, Is Data Flash corruption expected if power is lost during an ongoing Fls_Erase() operation? Yes, that is correct behavior. As data in flash will not match ECC syndromes in flash due to power loss during programming / erase process. Are ECC errors expected when accessing a partially erased/corrupted Flash sector after such an interruption? Yes. Is there any mechanism or register available to temporarily disable Flash ECC checking so that the corrupted Flash sector can be erased and recovered? No. It is permanent HW feature. What is the recommended recovery procedure for handling Data Flash sectors that contain uncorrectable ECC errors following a power interruption? You need to initialize (erase) the corrupted flash block in such case. Once done ECC syndrome will match the data in flash and access wont trigger ECC faults. For flash erase procedure please refer to reference manual: Best regards, Peter

i.MX 8M Plus LPDDR4 EVK - enabling eMMC boot0/boot1 Board: i.MX 8M Plus LPDDR4 EVK (MIMX8ML8DVNLZAA), IMX8MPEVKHUG rev 0 HAB: fused OPEN (SRK not burned, deliberately, still evaluating) I am implementing bootloader-update redundancy for a RAUC-based A/B update system and want to use the eMMC's hardware boot0/boot1 partitions (BOOT_PARTITION_ENABLE) the way many i.MX8M designs do — write the new bootloader to the inactive boot partition, flip which one is active, and rely on the ROM to fall back to the other if the newly-active one fails. I specifically want to avoid burning any BOOT_CFG/efuses for this. What I have observed on the EVK, using mmc-utils built from the poky/oe-core mmc-utils recipe: - mmc extcsd read /dev/mmcblk2 reports PARTITION_CONFIG with BOOT_PARTITION_ENABLE already set to boot0 (value 0x08). - boot0 (/dev/mmcblk2boot0) contains a valid-looking image (correct IVT tag at offset 0), but it does not match my currently deployed bootloader. - boot1 (/dev/mmcblk2boot1) is completely empty (all zero). - A byte-exact comparison confirms the board is actually booting from the raw eMMC user area at the standard 32 KiB offset (content matches my currently deployed imx-boot exactly) — not from boot0, despite PARTITION_CONFIG indicating boot0 is enabled. So on this board, EXT_CSD's BOOT_PARTITION_ENABLE appears to have no effect on the ROM's actual boot source. Per IMX8MPEVKHUG section 2.2, the EVK's SW4 switch only selects the coarse boot device class (eMMC vs SD vs QSPI vs NAND vs fuses vs USB serial download) — there is no switch position for the eMMC boot-partition sub-mode. Questions: 1. Is there a supported way to select "ROM boots from eMMC boot0/boot1 hardware partition" on the LPDDR4 EVK specifically, without setting BT_FUSE_SEL=1 / burning BOOT_CFG efuses — e.g. a jumper, resistor option, or alternate SW4/SW1101 combination not documented in IMX8MPEVKHUG rev 0? Or is this hard-strapped on this board's PCB to always boot from the eMMC user area regardless of EXT_CSD state? 2. If BOOT_CFG efuses are the only way to enable eMMC boot-partition mode: are the BOOT_CFG fuse banks that control this independent of the SRK-hash fuses used for HAB? I want to understand whether enabling eMMC boot-partition redundancy via fuses would force me to also commit to closing HAB (SRK burn) at the same time, or whether these are separable decisions. 3. For a custom board design (not the EVK) using the i.MX 8M Plus with eMMC, what is the recommended way to make eMMC boot0/boot1 redundancy available from first bring-up — i.e., what needs to be true in the BOOT_CFG GPIO strapping / PCB design so this is a day-one option rather than something that requires a later fuse commitment? Any pointers to the specific Reference Manual section covering the BOOT_CFG bit definitions for eMMC boot-partition selection (beyond the SW4 device-class bits already covered in IMX8MPEVKHUG) would also be appreciated. Thank you! Re: i.MX 8M Plus LPDDR4 EVK - enabling eMMC boot0/boot1 FYI for i.Mx8 UM at chapter 5.8.2.2.1 High Level eMMC Boot Flow The SCU ROM supports 4 eMMC boot scenarios: 1. In this scenario, the "eMMC fast boot" fuse is blown. The primary and secondary image container set are both in the boot partitions, and BOOT_PARTITION_ENABLE = 1 or 2. 2. In this scenario, the "eMMC fast boot" fuse is blown. The primary and secondary image container set are both in the User Area, and BOOT_PARTITION_ENABLE =7. 3. In this scenario, the "eMMC fast boot" fuse is not blown. The boot mode is Normal Boot, and the primary and secondary image container set are both in the User Area. 4. In this scenario, the "eMMC fast boot" fuse is not blown. The boot mode is Normal Boot, and the primary and secondary image container set are both in the boot partitions, and BOOT_PARTITION_ENABLE = 1 or 2. Re: i.MX 8M Plus LPDDR4 EVK - enabling eMMC boot0/boot1 Thanks for the pointer — though I believe chapter 5.8.2.2.1 describes a different chip family. The "SCU ROM" eMMC boot flow is specific to the i.MX8QuadMax/QuadXPlus/DualXPlus, which have a dedicated System Controller Unit (separate Cortex-M4 boot subsystem). The i.MX8M Plus has no SCU — its boot ROM runs directly on a Cortex-A53 — so the BOOT_PARTITION_ENABLE=1/2/7 scenarios in that chapter don't apply here. For i.MX8M Plus, redundancy appears to be handled via the Primary/Secondary Image mechanism in the i.MX8M Plus Reference Manual (Figure 6-1): the ROM boots from the device selected by BT_FUSE_SEL/BOOT_CFG, and on failure falls back to a Secondary Image at the IMG_CNTN_SET1_OFFSET fuse offset — on the same boot device, not a separate boot0/boot1 partition. This matches what I'm seeing on the LPDDR4 EVK: BOOT_PARTITION_ENABLE=1 is set in EXT_CSD, but the ROM ignores it and boots from the raw user-area offset regardless. So my questions remain, scoped to i.MX8M Plus: 1. Is there any non-efuse way on the LPDDR4 EVK (jumper, resistor, or undocumented SW1101/SW4 position) to select eMMC boot0/boot1 as the boot source, or is that purely a BOOT_CFG strap/BT_FUSE_SEL decision? 2. Are the BOOT_CFG fuse banks independent of the SRK-hash fuses for HAB, or does committing to BOOT_CFG-via-fuse also force HAB closure? 3. For a custom board design, what BOOT_CFG strapping is needed at layout time to keep hardware boot-partition redundancy available without a later fuse commitment? Happy to be corrected if I'm misreading which part chapter 5.8.2.2.1 actually applies to.

Fls_Erase() 操作中の電源中断後のデータフラッシュ破損および ECC エラー 電源の中断/リセットによってFls_Erase()操作が中断された場合、データフラッシュの破損が発生することを確認しています。システムを再起動すると、影響を受けたデータフラッシュ領域が破損しているように見える。 その後、セクターを Fls_Erase()で復旧しようとする際、フラッシュドライバが消去操作を行う前に影響を受けたアドレス範囲にアクセスしようとした際にECCエラーが発生します。その結果、消去作業は成功裏に進められません。 このシナリオにおけるフラッシュコントローラの期待される挙動を理解し、以下の点についての指針をお願いしたいと思います。 Fls_Erase()操作の実行中に電源が切断された場合、データフラッシュの破損が発生する可能性はありますか？ このような中断後に部分的に消去・破損したフラッシュセクターにアクセスする際にECCエラーが起こることは予想されますか? 破損したフラッシュセクターを消去・復元するために 、フラッシュECCチェックを一時的に無効 化する仕組みやレジスタはありますか? 電源遮断後に訂正不可能なECCエラーを含むデータフラッシュセクターを処理するための推奨される復旧手順は何ですか？ ターゲット装置: [MPC5746C] ソフトウェアスタック: [AUTOSAR / ベアメタル] Re: Data Flash Corruption and ECC Errors After Power Abort During Fls_Erase() Operation こんにちは、 Fls_Erase()操作の実行中に電源が切断された場合、データフラッシュの破損が発生する可能性はありますか？ はい、それは正しい行動です。フラッシュメモリ内のデータは、プログラミング／消去処理中の電源喪失により、フラッシュメモリ内のECC症候群と一致しなくなります。 このような中断後に部分的に消去・破損したフラッシュセクターにアクセスする際にECCエラーが起こることは予想されますか? はい。 破損したフラッシュセクターを消去・復元するために 、フラッシュECCチェックを一時的に無効 化する仕組みやレジスタはありますか? いいえ。これは恒久的なハードウェア機能です。 電源遮断後に訂正不可能なECCエラーを含むデータフラッシュセクターを処理するための推奨される復旧手順は何ですか？ その場合は破損したフラッシュブロックを初期化(消去)する必要があります。一度実行すると、ECC症候群はフラッシュのデータと一致し、アクセスによってECCの故障が起きません。 フラッシュ消去の手順については、リファレンス・マニュアルをご参照ください: よろしくお願いいたします。 ピーター

i.MX 8M Plus LPDDR4 EVK - 启用 eMMC boot0/boot1 主板：i.MX 8M Plus LPDDR4 EVK (MIMX8ML8DVNLZAA), IMX8MPEVKHUG rev 0 HAB：熔断 OPEN（SRK 未烧毁，故意，仍在评估中） 我正在为基于 RAUC 的 A/B 更新系统实现启动加载程序更新冗余，并希望像许多 i.MX8M 设计那样使用 eMMC 的硬件 启动0/启动1 分区（BOOT_PARTITION_ENABLE）——将新的启动加载程序写入非活动启动分区，切换哪个分区处于活动状态，并依靠 ROM 在新激活的分区发生故障时回退到另一个分区。我特别想避免为此烧毁任何 BOOT_CFG/efuse。 我在 EVK 上使用基于 poky/oe-core mmc-utils 配方构建的 mmc-utils 时观察到以下情况： - mmc extcsd 读取 /dev/mmcblk2 报告 PARTITION_CONFIG 中 BOOT_PARTITION_ENABLE 已设置为 boot0（值为 0x08）。 - boot0 (/dev/mmcblk2boot0) 包含一个看起来有效的映像（偏移量 0 处有正确的 IVT 标签），但它与我当前部署的引导加载程序不匹配。 - boot1 (/dev/mmcblk2boot1) 完全为空（全部为零）。 - 逐字节比较证实，该板实际上是从标准的 32 KiB 偏移处的原始 eMMC 用户区启动（内容与我当前部署的 imx-boot 完全匹配）——而不是从 boot0 启动，尽管 PARTITION_CONFIG 指示 boot0 已启用。 因此，在这个板上，EXT_CSD 的 BOOT_PARTITION_ENABLE 似乎对 ROM 的实际启动源没有影响。根据 IMX8MPEVKHUG 第 2.2 节，EVK 的 SW4 开关仅用于选择粗略的启动设备类别（eMMC vs SD vs QSPI vs NAND vs 熔丝 vs USB 串行下载）——没有用于 eMMC 启动分区子模式的开关位置。 问题： 1. 在LPDDR4 EVK上，是否有支持的方法可以选择“ROM从eMMC boot0/boot1硬件分区启动”，而无需设置BT_FUSE_SEL=1或烧录BOOT_CFG熔丝？例如，是否可以通过跳线、电阻或IMX8MPEVKHUG rev 0中未记录的SW4/SW1101组合来实现？或者，该板的PCB是否已硬性规定始终从eMMC用户区启动，而不管EXT_CSD状态如何？ 2. 如果 BOOT_CFG 熔丝是启用 eMMC 启动分区模式的唯一方法：控制此模式的 BOOT_CFG 熔丝组是否独立于用于 HAB 的 SRK 哈希熔丝？我想了解通过熔丝启用 eMMC 启动分区冗余是否会迫使我同时关闭 HAB（SRK 烧录），或者这些是否是可分离的决定。 3. 对于使用 i.MX 8M Plus 和 eMMC 的定制板设计（非 EVK），推荐的方法是如何在首次启动时就使 eMMC boot0/boot1 冗余可用？也就是说，BOOT_CFG GPIO 跳线/PCB 设计中需要满足哪些条件，才能使其成为第一天就能使用的功能，而不是需要稍后进行熔丝位绑定？ 如果能提供一些关于 eMMC 启动分区选择的 BOOT_CFG 位定义的具体参考手册章节的链接（除了 IMX8MPEVKHUG 中已经涵盖的 SW4 设备类位之外），我们将不胜感激。 谢谢！ Re: i.MX 8M Plus LPDDR4 EVK - enabling eMMC boot0/boot1 供参考，请参阅 i.Mx8 UM 第 5.8.2.2.1 节“高级 eMMC 启动流程”。 SCU ROM 支持 4 种 eMMC 启动方案： 1.在这种情况下，“eMMC 快速启动”熔丝被烧断。小学和中学 镜像容器集均位于启动分区中，且 BOOT_PARTITION_ENABLE = 1 或 2。 2. 在这种情况下，“eMMC 快速启动”熔丝烧断了。小学和中学 镜像容器集均位于用户区域，且 BOOT_PARTITION_ENABLE =7。 3.在这种情况下，“eMMC 快速启动”熔丝没有熔断。启动模式为正常模式 启动、主镜像容器集和辅助镜像容器集都在用户区域。 4. 在这种情况下，“eMMC 快速启动”熔丝没有熔断。启动模式为正常模式 启动时，主镜像容器集和辅助镜像容器集都在启动过程中。 分区，并且 BOOT_PARTITION_ENABLE = 1 或 2。 Re: i.MX 8M Plus LPDDR4 EVK - enabling eMMC boot0/boot1 谢谢你的指点——不过我认为第 5.8.2.2.1 章描述的是不同的芯片系列。“SCU ROM” eMMC 启动流程是 i.MX8QuadMax/QuadXPlus/DualXPlus 特有的，它们具有专用的系统控制器单元（独立的 Cortex-M4 启动子系统）。i.MX8M Plus 没有 SCU – 其启动 ROM 直接在 Cortex-A53 上运行 – 因此该章节中的 BOOT_PARTITION_ENABLE=1/2/7 场景不适用于这里。 对于 i.MX8M Plus，冗余似乎是通过 i.MX8M Plus 参考手册中的主/辅助映像机制来处理的（图 6-1）：ROM 从 BT_FUSE_SEL/BOOT_CFG 选择的设备启动，如果失败，则回退到 IMG_CNTN_SET1_OFFSET 熔丝偏移处的辅助映像——在同一引导设备上，而不是单独的 boot0/boot1 分区。这与我在 LPDDR4 EVK 上看到的情况一致：EXT_CSD 中设置了 BOOT_PARTITION_ENABLE=1，但 ROM 忽略了它，仍然从原始用户区偏移量启动。 所以我的问题仍然是，仅限于 i.MX8M Plus： 1. 在 LPDDR4 EVK 上，是否有任何非熔丝方法（跳线、电阻或未记录的 SW1101/SW4 位置）来选择 eMMC boot0/boot1 作为启动源，还是这完全取决于 BOOT_CFG 跳线/BT_FUSE_SEL 的决定？ 2. BOOT_CFG 熔丝组是否独立于 HAB 的 SRK 哈希熔丝，或者通过熔丝提交 BOOT_CFG 是否也会强制关闭 HAB？ 3.对于定制板设计，在布局时需要进行哪些 BOOT_CFG 绑定才能在不进行后续熔丝分配的情况下保持硬件启动分区冗余？ 如果我误解了第 5.8.2.2.1 章实际适用的部分，请指正。

S32K396をベースとしたETPUの例 こんにちは。S32DS3.5で生成されたETPUで使用されるS32K396用のRTD 5.0.0のデモが必要です。燃料噴射機能に使用したいと考えています。ソフトウェアパッケージとコード例を提供していただけますでしょうか？ Re: S32K396的ETPU的例子 こんにちは@大概さん リアルタイム・ドライバ内にETPUおよびS32K396の既存例があります: さらに、S32K3 - eTPU SWパッケージの中には様々な例も見つかります。RTDとは独立しており、どのバージョンでも使用可能ですが、eTPUのSWは特定のRTD 7.0.0でのみ検証されていますバージョンや他のバージョンとの互換性は保証できません。 よろしくお願いします、 ジュリアン

中断在内存中运行，闪存擦除 我发现擦除闪存时无法进入定时器中断。为了满足我的需求，我计划在 RAM 中运行定时器中断。我修改了 linker_flash_s32k388.ld 文件，将 IntCtrl_Ip.o 和 Pit_Ip.o 放入 RAM 中，但是当我擦除闪存时，由于定时器中断的到来，我仍然会遇到错误。请告诉我我遗漏了哪些细节。#s32k388 Re: Pit interrupt runs in ram wen flash erase 你好， 只需放置 IntCtrl_Ip.o 和 Pit_Ip.o仅仅存入内存通常是不够的。在 PFLASH 擦除操作期间，CPU 必须避免对受影响的闪存阵列进行任何访问。 请确认中断向量表、PIT ISR、ISR 调用的所有函数以及 ISR 使用的任何数据/常量也位于 SRAM 中。此外，确保 VTOR 寄存器指向基于 RAM 的向量表。链接器映射文件通常是识别剩余闪存访问的最佳方法。 S32K3 参考手册还指出，当闪存操作需要持续执行时，代码执行必须移至 SRAM。 顺祝商祺！ Peter Re: Pit interrupt runs in ram wen flash erase 我的中断服务例程 (ISR) 和 ISR 调用的函数都已放置在 RAM 中，VTOR 的地址也是 0x2...而不是 0x4...我的闪存驱动程序在 RTD 配置期间选择在 RAM 中运行。只要 PIT 关闭，程序就能正常运行；但启用 PIT 后就会卡死，但我无法通过调试找到问题所在。 Re: Pit interrupt runs in ram wen flash erase 你好， 仅凭描述很难判断。 常被忽视的事情： 中断向量表仍然保存在闪存中。 CPU 首先从向量表中获取 ISR 地址。 如果向量表仍然保存在 P-Flash 中，则在擦除过程中中断仍会访问 Flash。 必须将向量表复制到 RAM 中，并相应地更新 VTOR。 PIT ISR 函数本身必须位于 RAM 中 不仅是 PIT 驱动程序（ Pit_Ip.o ），而且还有应用程序回调/ISR。 ISR 调用的所有函数都必须位于 RAM 中。 应用程序功能 操作系统服务 调度器钩子 日志/调试功能 ISR 调用的任何辅助函数 没有 Flash 驻留常量 即使代码从 RAM 执行，也会访问： const 表 校准数据 字符串字面量 配置结构仍然可能导致闪存读取。 堆栈跟踪/调试基础架构不会访问 Flash。 调试版本经常会引入意想不到的 Flash 引用。 顺祝商祺！ Peter

Pit interrupt runs in ram wen flash erase I found that I cannot enter the timer interrupt while erasing flash. To meet my requirements, I plan to run the timer interrupt in RAM. I modified the linker_flash_s32k388.ld file to place IntCtrl_Ip.o and Pit_Ip.o in RAM, but when I erase flash, I still encounter errors due to the arrival of the timer interrupt. Please tell me what details I have overlooked.#s32k388 Re: Pit interrupt runs in ram wen flash erase Hello, Simply placing IntCtrl_Ip.o and Pit_Ip.o into RAM is usually not enough. During a PFLASH erase operation, the CPU must avoid any access to the affected flash array. Please verify that the interrupt vector table, the PIT ISR, all functions called by the ISR, and any data/constants used by the ISR are also located in SRAM. Additionally, ensure that the VTOR register points to a RAM-based vector table. A linker map file is typically the best way to identify remaining flash accesses. The S32K3 Reference Manual also notes that code execution must be moved to SRAM when flash operations require continued execution. Best regards, Peter Re: Pit interrupt runs in ram wen flash erase My ISR and the functions called by ISR have been placed in RAM, and the address of VTOR is also 0x2... rather than 0x4... My flash driver chose to run in RAM during configuration in RTD. It runs normally as long as the PIT is closed, but it freezes when the PIT is enabled, but I cannot trace where the problem is through debugging Re: Pit interrupt runs in ram wen flash erase Hello, its hard to judge from the description. Things that are commonly overlooked: Interrupt vector table is still in Flash The CPU first fetches the ISR address from the vector table. If the vector table remains in P-Flash, the interrupt will still access Flash during erase. The vector table must be copied to RAM and VTOR updated accordingly. The PIT ISR function itself must be in RAM Not only the PIT driver ( Pit_Ip.o ) but also the application callback/ISR. Everything called from the ISR must be in RAM Application functions OS services Scheduler hooks Logging/debug functions Any helper functions invoked by the ISR No Flash-resident constants Even if the code executes from RAM, accesses to: const tables calibration data string literals configuration structures can still result in Flash reads. No Flash accesses by the stack trace/debug infrastructure Debug builds often introduce unexpected Flash references. Best regards, Peter

How to use LPI2C peripheral with DMA without enabling any interrupts? Hello, I am working with an NXP S32K396 MCU and would like to perform an LPI2C master transaction using eDMA without enabling any interrupts. In my project, I am using the LPI2C1 peripheral. I can successfully perform LPI2C read and write transactions using DMA when the following interrupts are enabled: LPI2C1_IRQn eDMA0_DMATTCD_CH16_CH17_IRQn However, it appears that the RTD LPI2C DMA implementation depends on these interrupts. In Lpi2c_Ip_MasterSendData(), the LPI2C master interrupts are always enabled by the driver: In addition, the DMA TCDs configured for TX and RX by Lpi2c_Ip_MasterTxDmaConfig() and Lpi2c_Ip_MasterRxDmaConfig() always enable the DMA major-loop completion interrupt: Lpi2c_DmaTransferList[9u].Param = DMA_IP_CH_SET_CONTROL_EN_MAJOR_INTERRUPT; Lpi2c_DmaTransferList[9u].Value = 1U; I also noticed that in other function - Lpi2c_Ip_MasterSendDataBlocking() does not appear to configure a DMA TCD for the LPI2C transfer. I would like to perform the complete LPI2C transmit and receive transaction using DMA while keeping LPI2C1_IRQn disabled and the eDMA channel interrupt disabled.   If possible, could NXP provide an example for LPI2C master TX/RX using DMA with both LPI2C and DMA interrupts disabled?   MCU: NXPS32K396 RTD: 6.0.0 NXP Studio: 3.6.1   Any help would be greatly appreciated. Thanks a lot in advance! If needed, I can attach my project. Re: How to use LPI2C peripheral with DMA without enabling any interrupts? Hi@rkhw From the current driver implementation, the “Lpi2c_Ip_MasterSendData()” depend on both LPI2C master interrupts and DMA major-loop completion interrupts for transfer completion and state handling. Therefore, you cannot enable DMA without enabling interrupts. The RTD driver does not support this usage.

S32 Design Studio for ARM v2.2许可延期 您好，S32 Design Studio for ARM v2.2提示许可马上到期，Activation Code：FAF2-FCC2-8A8E-87AC，麻烦延期，谢谢！

FRDM i.MX93におけるAP1302 MIPI CSIストリーミングの問題 こんにちは、 私はFRDM i.MX93ボードとX-RPI-CAM-MIPI A1カメラモジュールを使用しています。 私が直面している問題は、この設定からMIPI CSIストリームをキャプチャできないことです。 ファームウェアバイナリap1302_60fps_ar0144_27M_2Lane_awb_tuning.binを次の場所に配置しました: "/lib/firmware" 起動時にAP1302が正常に検出されていることは確認できますが、ビデオストリーミングを開始しようとすると、 VIDIOC_STREAMONが 「パイプが壊れています」という エラー で失敗します 。 以下に、関連するログを示します。 カーネルログ: root@imx93evk:~# dmesg | grep ap1302 [ 0.340980] /soc@0/bus@42000000/i2c@42530000/ap1302_mipi@3c: Fixed dependency cycle(s) with /soc@0/bus@42800000/csi@4ae00000 [ 0.371014] /soc@0/bus@42800000/csi@4ae00000: Fixed dependency cycle(s) with /soc@0/bus@42000000/i2c@42530000/ap1302_mipi@3c ... [ 10.088832] ap1302 2-003c: AP1302 revision 0.2.6 detected ストリーミングテスト: root@imx93evk:~# v4l2-ctl -d /dev/video0 \ --verbose \ --stream-mmap=3 \ --stream-count=10 VIDIOC_QUERYCAP: ok VIDIOC_REQBUFS returned 0 (Success) VIDIOC_CREATE_BUFS returned 0 (Success) VIDIOC_QUERYBUF returned 0 (Success) VIDIOC_QUERYBUF returned 0 (Success) VIDIOC_QUERYBUF returned 0 (Success) VIDIOC_G_FMT returned 0 (Success) VIDIOC_QBUF returned 0 (Success) VIDIOC_QBUF returned 0 (Success) VIDIOC_QBUF returned 0 (Success) VIDIOC_STREAMON returned -1 (Broken pipe) なぜ VIDIOC_STREAMON が「 Broken pipe(パイプ破損) 」エラー で故障しているのか 、教えていただけません か? ストリーミングを正常に開始する前に、AP1302のファームウェア、デバイスツリー、メディアパイプライン、またはセンサの初期化に追加の設定が必要ですか? さらに、現時点では「LF_v6.18.2-1.0.0_images_IMX93EVK」というプリビルドイメージを使用しています。 追加のログや情報が必要な場合はお知らせください。 再開まで今しばらくお待ちください。 Re: AP1302 MIPI CSI Streaming Issue on FRDM i.MX93 AEチームと話し合っています。 Re: AP1302 MIPI CSI Streaming Issue on FRDM i.MX93 こんにちは@yipingwang ご返信ありがとうございます。 参考までに、私の回答を以下に記載します。 1. ファームウェアの場所 推奨されているファームウェアのインストール場所と、それぞれの場所を個別に試してみました。カメラプローブは、 ap1302_ar0144_single_fw.binを使用した場合にのみ成功します。 root@imx93evk:~# ls -la /lib/firmware/ap1302_ar0144_single_fw.bin -rw-r--r-- 1 root root 80528 Aug 5 15:36 /lib/firmware/ap1302_ar0144_single_fw.bin root@imx93evk:~# ls -la /lib/firmware/imx/camera/ap1302.fw -rw-r--r-- 1 root root 80528 Aug 5 15:38 /lib/firmware/imx/camera/ap1302.fw AP1302は起動時に正常に検出されました。 root@imx93evk:~# dmesg | grep -i ap1302 ... [ 9.962705] ap1302 2-003c: AP1302 revision 0.2.6 detected しかし、カーネルログにはAP1302に関連するファームウェアの読み込みメッセージは一切見当たりません。 2. ソフトウェア環境 私はFRDM i.MX93ボード用に提供されているプリビルドイメージを使用しています。 root@imx93evk:~# cat /proc/device-tree/model NXP FRDM-IMX93 root@imx93evk:~# cat /proc/cmdline console=ttyLP0,115200 earlycon root=/dev/mmcblk0p2 rootwait rw AP1302は正常に検出され、CSI/ISIデバイスも存在しています。参考までに、ログ全体を添付しました。 3. メディアパイプライン メディアパイプラインは正しく作成されているようです。 root@imx93evk:~# ls /dev/media0 /dev/media0 root@imx93evk:~# ls /dev/video* /dev/video0 /dev/video1 media-ctlの出力はAP1302、CSI、ISIエンティティが有効であることを示しています。参照のために、完全なmedia-ctl出力を添付します。 4. 追加情報 ご依頼いただいた情報については、添付ファイルfourth_point.txtをご参照ください。 5. ストリーミングの失敗 ストリーミングコマンドが失敗した際に、カーネルから追加のメッセージは表示されません。 root@imx93evk:~# dmesg -c root@imx93evk:~# v4l2-ctl -d /dev/video0 --stream-mmap=3 --stream-count=10 VIDIOC_STREAMON returned -1 (Broken pipe) root@imx93evk:~# dmesg 障害後もdmesg出力は空のままなので、根本原因を特定するための追加のカーネルログはありません。 AP1302が正常に検出され、メディアグラフも正しく作成され、VIDIOC_STREAMON中にカーネルエラーも報告されていないので、「 Broken pipe」 エラーでストリーミングが失敗する原因を特定するために、どのような追加のチェックやデバッグステップを教えていただけますか? 再開まで今しばらくお待ちください。 root@imx93evk:~# v4l2-ctl --list-devices mxc-isi-cap (platform:4ae40000.isi): /dev/video0 /dev/video1 /dev/media0 root@imx93evk:~# v4l2-ctl -d /dev/video0 --all Driver Info: Driver name : mxc-isi Card type : mxc-isi-cap Bus info : platform:4ae40000.isi Driver version : 6.18.2 Capabilities : 0xa4201000 Video Capture Multiplanar I/O MC Streaming Extended Pix Format Device Capabilities Device Caps : 0x24201000 Video Capture Multiplanar I/O MC Streaming Extended Pix Format Media Driver Info: Driver name : mxc-isi Model : FSL Capture Media Device Serial : Bus info : platform:4ae40000.isi Media version : 6.18.2 Hardware revision: 0x00000000 (0) Driver version : 6.18.2 Interface Info: ID : 0x0300000a Type : V4L Video Entity Info: ID : 0x00000008 (8) Name : mxc_isi.0.capture Function : V4L2 I/O Pad 0x01000009 : 0: Sink Link 0x0200000c: from remote pad 0x1000007 of entity 'mxc_isi.0' (Video Pixel Formatter): Data, Enabled, Immutable Priority: 2 Video input : 0 (mxc_isi.0.capture: ok) Format Video Capture Multiplanar: Width/Height : 1920/1080 Pixel Format : 'YUYV' (YUYV 4:2:2) Field : None Number of planes : 1 Flags : Colorspace : sRGB Transfer Function : sRGB YCbCr/HSV Encoding: ITU-R 601 Quantization : Limited Range Plane 0 : Bytes per Line : 3840 Size Image : 4147200 User Controls horizontal_flip 0x00980914 (bool) : default=0 value=0 flags=0x00001000 vertical_flip 0x00980915 (bool) : default=0 value=0 flags=0x00001000 alpha_component 0x00980929 (int) : min=0 max=255 step=1 default=0 value=0 flags=0x00001000 root@imx93evk:~# media-ctl -p Media controller API version 6.18.2 Media device information ------------------------ driver mxc-isi model FSL Capture Media Device serial bus info platform:4ae40000.isi hw revision 0x0 driver version 6.18.2 Device topology - entity 1: crossbar (3 pads, 3 links, 1 route) type V4L2 subdev subtype Unknown flags 0 device node name /dev/v4l-subdev0 routes: 0/0 -> 2/0 [ACTIVE] pad0: SINK,MUST_CONNECT [stream:0 fmt:UYVY8_1X16/1920x1080 field:none colorspace:srgb xfer:srgb ycbcr:601 quantization:lim-range] <- "csidev-4ae00000.csi":1 [ENABLED,IMMUTABLE] pad1: SINK,MUST_CONNECT <- "mxc_isi.output":0 [ENABLED,IMMUTABLE] pad2: SOURCE [stream:0 fmt:UYVY8_1X16/1920x1080 field:none colorspace:srgb xfer:srgb ycbcr:601 quantization:lim-range] -> "mxc_isi.0":0 [ENABLED,IMMUTABLE] - entity 5: 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 colorspace:jpeg xfer:srgb ycbcr:601 quantization:full-range compose.bounds:(0,0)/1920x1080 compose:(0,0)/1920x1080] <- "crossbar":2 [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.0.capture":0 [ENABLED,IMMUTABLE] - entity 8: mxc_isi.0.capture (1 pad, 1 link) type Node subtype V4L flags 0 device node name /dev/video0 pad0: SINK <- "mxc_isi.0":1 [ENABLED,IMMUTABLE] - entity 16: mxc_isi.output (1 pad, 1 link) type Node subtype V4L flags 0 pad0: SOURCE -> "crossbar":1 [ENABLED,IMMUTABLE] - entity 23: csidev-4ae00000.csi (2 pads, 2 links, 1 route) type V4L2 subdev subtype Unknown flags 0 device node name /dev/v4l-subdev2 routes: 0/0 -> 1/0 [ACTIVE] pad0: SINK [stream:0 fmt:UYVY8_1X16/1920x1080 field:none colorspace:smpte170m xfer:709 ycbcr:601 quantization:lim-range] <- "ap1302 2-003c":2 [ENABLED] pad1: SOURCE [stream:0 fmt:UYVY8_1X16/1920x1080 field:none colorspace:smpte170m xfer:709 ycbcr:601 quantization:lim-range] -> "crossbar":0 [ENABLED,IMMUTABLE] - entity 28: ap1302 2-003c (3 pads, 2 links, 0 routes) type V4L2 subdev subtype Unknown flags 0 device node name /dev/v4l-subdev4 pad0: SINK [stream:0 fmt:SGRBG12_1X12/1280x800 field:none colorspace:srgb crop.bounds:(0,0)/1280x800 crop:(0,0)/1280x800] <- "ar0144 0":0 [ENABLED,IMMUTABLE] pad1: SINK [stream:0 fmt:SGRBG12_1X12/1280x800 field:none colorspace:srgb crop.bounds:(0,0)/1280x800 crop:(0,0)/1280x800] pad2: SOURCE [stream:0 fmt:UYYVYY8_0_5X24/4224x4092 field:none colorspace:srgb crop.bounds:(0,0)/1280x800 crop:(0,0)/1280x800] -> "csidev-4ae00000.csi":0 [ENABLED] - entity 32: ar0144 0 (1 pad, 1 link, 0 routes) type V4L2 subdev subtype Sensor flags 0 device node name /dev/v4l-subdev3 pad0: SOURCE [stream:0 fmt:SGRBG12_1X12/1280x800 field:none colorspace:srgb] -> "ap1302 2-003c":0 [ENABLED,IMMUTABLE] よろしくお願いします、 ミラフ Re: AP1302 MIPI CSI Streaming Issue on FRDM i.MX93 AP1302プローブが成功したとしても、カメラパイプライン全体が構成され、ストリーミングが開始されることを保証するものではありません。i.MX93では、VIDIOC_STREAMONが-1(破損パイプ)を返すと、通常、メディアパイプラインのコンポーネント(AP1302→MIPI、CSI-2レシーバ、→ISIキャプチャパス)が有効なストリームを開始または交渉できなかったことを意味します。ログには、AP1302 I²Cデバイスが検出されたという情報しか記録されていません。 ap1302 2-003c: AP1302 リビジョン 0.2.6 が検出されました しかし、それは以下のことを確認するものではありません。 ファームウェアのロードに成功しました。 正しいDTBが使用されました。 メディアグラフが作成されました。 CSIレシーバは受信するMIPIデータにロックされています。 AP1302は、対応する出力フォーマットで設定されています。 まず最初に確認すべきことは、ファームウェアの場所と名前です。 FRDM-i.MX93 AP1302のサポートについては、NXPのドキュメントには以下が記載されています: ap1302_60fps_ar0144_27M_2Lane_awb_tuning.bin をダウンロードしてください。 名前をap1302.fwに変更してください。 配置場所： /lib/firmware/imx/camera/ap1302.fw 単に /lib/firmware ではない。 ご確認ください： ls -l /lib/ファームウェア/imx/カメラ/ap1302.fw そしてブートログを確認してください。 dmesg | grep -i firmware dmesg | grep -i ap1302 次のようなメッセージを探してください。 ファームウェアを要求する ファームウェアがロードされました ファームウェアの読み込みに失敗しました 2つ目の確認事項：正しいDTBを使用していますか？ リリースノートによると、AP1302のサポートはi.MX93 EVKデバイスツリーのサポートと関連しています。 確認： cat /proc/device-tree/model cat /proc/cmdline そして、実際にロードされるDTBを特定します。 こちらもご確認ください： dmesg | grep -i ap1302 dmesg | grep -i csi dmesg | grep -i isi 三つ目のチェック:メディアトポロジーの検証 v4l2-ctlを試す前に、メディアグラフが存在するか確認してください: シェル media-ctl -p もっと行を表示 以下のようなエンティティが表示されるはずです。 ap1302 CSI イシ ビデオX /dev/media0が存在しない場合、カメラパイプラインが正しく作成されていません。非常に似たFRDM-i.MX93 AP1302 CASEは以下の通りでした: media-ctl -p /dev/media0 の列挙に失敗しました これはメディアパイプラインがインスタンス化されていないことを示していました。 チェックしてください： ls -l /dev/media* 4つ目の確認事項：交渉済みのフォーマットを検査する 次を実行します。 v4l2-ctl --list-devices そして、 v4l2-ctl -d /dev/video0 --all また： media-ctl -p AP1302のファームウェアは通常、RAWベイヤーではなく、処理済みのYUVフォーマットを出力します。もう一つよくある失敗例は次のとおりです。 AP1302はフォーマットAを出力する ISIはフォーマットB用に構成されています ストリームの起動失敗を引き起こしています。フォーマットの不一致は、STREAMONの失敗やCSIパイプラインのエラーとして現れることが多い。 5回目のチェック：STREAMON実行中のCSIエラーを検査する 別のターミナルを開いて監視します。 dmesg -w そして、以下を実行します。 v4l2-ctl -d /dev/video0 \ --stream-mmap=3 \ --stream-count=10 次のようなメッセージを探してください。 CSIタイムアウト フレーム開始タイムアウト データを受信しませんでした FIFOオーバーフロー MIPIエラー リンクが有効になっていません これらのメッセージは通常、配管破損の本当の原因を明らかにします。 Re: AP1302 MIPI CSI Streaming Issue on FRDM i.MX93 キャプチャを開始する前に、以下のコマンドを使用してパイプラインを設定する必要があります。 $ media-ctl -l "'ap1302 2-003c':2 -> 'csidev-4ae00000.csi':0 [1]" $ media-ctl -V "'ap1302 2-003c':0 [fmt: UYVY8_1X16/1280x800 field:none]" $ media-ctl -V "'ap1302 2-003c':2 [fmt: UYVY8_1X16/1280x800 field:none]" $ media-ctl -V "'ar0144 0':0 [fmt: UYVY8_1X16/1280x800 field:none]" $ media-ctl -V "'csidev-4ae00000.csi':1 [fmt: UYVY8_1X16/1280x800 field:none]" $ media-ctl -V "'crossbar':2 [fmt: UYVY8_1X16/1280x800 field:none]"

S32 Design Studio for ARM v2.2 许可延期 您好，S32 Design Studio for ARM v2.2提示立即授权，激活码：FAF2-FCC2-8A8E-87AC，麻烦延期，谢谢！

AP1302 MIPI CSI Streaming Issue on FRDM i.MX93 Hello, I am using an FRDM i.MX93 board with the X-RPI-CAM-MIPI A1 camera module. The issue I am facing is that I am unable to capture the MIPI CSI stream from this setup. I have placed the firmware binary ap1302_60fps_ar0144_27M_2Lane_awb_tuning.bin in the following location: "/lib/firmware" During boot, I see that the AP1302 is detected successfully, but when I attempt to start video streaming, VIDIOC_STREAMON fails with a "Broken pipe" error. Below are the relevant logs. Kernel log: root@imx93evk:~# dmesg | grep ap1302 [ 0.340980] /soc@0/bus@42000000/i2c@42530000/ap1302_mipi@3c: Fixed dependency cycle(s) with /soc@0/bus@42800000/csi@4ae00000 [ 0.371014] /soc@0/bus@42800000/csi@4ae00000: Fixed dependency cycle(s) with /soc@0/bus@42000000/i2c@42530000/ap1302_mipi@3c ... [ 10.088832] ap1302 2-003c: AP1302 revision 0.2.6 detected Streaming test: root@imx93evk:~# v4l2-ctl -d /dev/video0 \ --verbose \ --stream-mmap=3 \ --stream-count=10 VIDIOC_QUERYCAP: ok VIDIOC_REQBUFS returned 0 (Success) VIDIOC_CREATE_BUFS returned 0 (Success) VIDIOC_QUERYBUF returned 0 (Success) VIDIOC_QUERYBUF returned 0 (Success) VIDIOC_QUERYBUF returned 0 (Success) VIDIOC_G_FMT returned 0 (Success) VIDIOC_QBUF returned 0 (Success) VIDIOC_QBUF returned 0 (Success) VIDIOC_QBUF returned 0 (Success) VIDIOC_STREAMON returned -1 (Broken pipe) Could you please help me understand why VIDIOC_STREAMON is failing with a "Broken pipe" error? Is there any additional configuration required for the AP1302 firmware, device tree, media pipeline, or sensor initialization before streaming can start successfully? Furthermore, i am using "LF_v6.18.2-1.0.0_images_IMX93EVK" pre-built images for now. Please let me know if you need any additional logs or information. Thank you for your support. Re: AP1302 MIPI CSI Streaming Issue on FRDM i.MX93 Discussing with the AE team. Re: AP1302 MIPI CSI Streaming Issue on FRDM i.MX93 Hello @yipingwang  Thank you for your response. Please find my answers below for your reference. 1. Firmware Location I tried both the recommended firmware locations as well as each location individually. The camera probe is successful only when using ap1302_ar0144_single_fw.bin. root@imx93evk:~# ls -la /lib/firmware/ap1302_ar0144_single_fw.bin -rw-r--r-- 1 root root 80528 Aug 5 15:36 /lib/firmware/ap1302_ar0144_single_fw.bin root@imx93evk:~# ls -la /lib/firmware/imx/camera/ap1302.fw -rw-r--r-- 1 root root 80528 Aug 5 15:38 /lib/firmware/imx/camera/ap1302.fw The AP1302 is detected successfully during boot. root@imx93evk:~# dmesg | grep -i ap1302 ... [ 9.962705] ap1302 2-003c: AP1302 revision 0.2.6 detected However, I do not see any firmware loading messages related to AP1302 in the kernel log. 2. Software Environment I am using the pre-built images provided for the FRDM i.MX93 board. root@imx93evk:~# cat /proc/device-tree/model NXP FRDM-IMX93 root@imx93evk:~# cat /proc/cmdline console=ttyLP0,115200 earlycon root=/dev/mmcblk0p2 rootwait rw The AP1302 is detected successfully, and the CSI/ISI devices are also present. I have attached the complete logs for your reference. 3. Media Pipeline The media pipeline appears to be created correctly. root@imx93evk:~# ls /dev/media0 /dev/media0 root@imx93evk:~# ls /dev/video* /dev/video0 /dev/video1 The outputs from media-ctl show that the AP1302, CSI, and ISI entities are enabled. The complete media-ctl output is attached for your reference. 4. Additional Information Please refer to the attached file fourth_point.txt for the requested information. 5. Streaming Failure I do not see any additional kernel messages when the streaming command fails. root@imx93evk:~# dmesg -c root@imx93evk:~# v4l2-ctl -d /dev/video0 --stream-mmap=3 --stream-count=10 VIDIOC_STREAMON returned -1 (Broken pipe) root@imx93evk:~# dmesg The dmesg output remains empty after the failure, so there are no additional kernel logs to help identify the root cause. Since the AP1302 is detected successfully, the media graph is created correctly, and no kernel errors are reported during VIDIOC_STREAMON, could you please suggest what additional checks or debugging steps I should perform to identify why streaming fails with a "Broken pipe" error? Thank you for your support. root@imx93evk:~# v4l2-ctl --list-devices mxc-isi-cap (platform:4ae40000.isi): /dev/video0 /dev/video1 /dev/media0 root@imx93evk:~# v4l2-ctl -d /dev/video0 --all Driver Info: Driver name : mxc-isi Card type : mxc-isi-cap Bus info : platform:4ae40000.isi Driver version : 6.18.2 Capabilities : 0xa4201000 Video Capture Multiplanar I/O MC Streaming Extended Pix Format Device Capabilities Device Caps : 0x24201000 Video Capture Multiplanar I/O MC Streaming Extended Pix Format Media Driver Info: Driver name : mxc-isi Model : FSL Capture Media Device Serial : Bus info : platform:4ae40000.isi Media version : 6.18.2 Hardware revision: 0x00000000 (0) Driver version : 6.18.2 Interface Info: ID : 0x0300000a Type : V4L Video Entity Info: ID : 0x00000008 (8) Name : mxc_isi.0.capture Function : V4L2 I/O Pad 0x01000009 : 0: Sink Link 0x0200000c: from remote pad 0x1000007 of entity 'mxc_isi.0' (Video Pixel Formatter): Data, Enabled, Immutable Priority: 2 Video input : 0 (mxc_isi.0.capture: ok) Format Video Capture Multiplanar: Width/Height : 1920/1080 Pixel Format : 'YUYV' (YUYV 4:2:2) Field : None Number of planes : 1 Flags : Colorspace : sRGB Transfer Function : sRGB YCbCr/HSV Encoding: ITU-R 601 Quantization : Limited Range Plane 0 : Bytes per Line : 3840 Size Image : 4147200 User Controls horizontal_flip 0x00980914 (bool) : default=0 value=0 flags=0x00001000 vertical_flip 0x00980915 (bool) : default=0 value=0 flags=0x00001000 alpha_component 0x00980929 (int) : min=0 max=255 step=1 default=0 value=0 flags=0x00001000 root@imx93evk:~# media-ctl -p Media controller API version 6.18.2 Media device information ------------------------ driver mxc-isi model FSL Capture Media Device serial bus info platform:4ae40000.isi hw revision 0x0 driver version 6.18.2 Device topology - entity 1: crossbar (3 pads, 3 links, 1 route) type V4L2 subdev subtype Unknown flags 0 device node name /dev/v4l-subdev0 routes: 0/0 -> 2/0 [ACTIVE] pad0: SINK,MUST_CONNECT [stream:0 fmt:UYVY8_1X16/1920x1080 field:none colorspace:srgb xfer:srgb ycbcr:601 quantization:lim-range] <- "csidev-4ae00000.csi":1 [ENABLED,IMMUTABLE] pad1: SINK,MUST_CONNECT <- "mxc_isi.output":0 [ENABLED,IMMUTABLE] pad2: SOURCE [stream:0 fmt:UYVY8_1X16/1920x1080 field:none colorspace:srgb xfer:srgb ycbcr:601 quantization:lim-range] -> "mxc_isi.0":0 [ENABLED,IMMUTABLE] - entity 5: 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 colorspace:jpeg xfer:srgb ycbcr:601 quantization:full-range compose.bounds:(0,0)/1920x1080 compose:(0,0)/1920x1080] <- "crossbar":2 [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.0.capture":0 [ENABLED,IMMUTABLE] - entity 8: mxc_isi.0.capture (1 pad, 1 link) type Node subtype V4L flags 0 device node name /dev/video0 pad0: SINK <- "mxc_isi.0":1 [ENABLED,IMMUTABLE] - entity 16: mxc_isi.output (1 pad, 1 link) type Node subtype V4L flags 0 pad0: SOURCE -> "crossbar":1 [ENABLED,IMMUTABLE] - entity 23: csidev-4ae00000.csi (2 pads, 2 links, 1 route) type V4L2 subdev subtype Unknown flags 0 device node name /dev/v4l-subdev2 routes: 0/0 -> 1/0 [ACTIVE] pad0: SINK [stream:0 fmt:UYVY8_1X16/1920x1080 field:none colorspace:smpte170m xfer:709 ycbcr:601 quantization:lim-range] <- "ap1302 2-003c":2 [ENABLED] pad1: SOURCE [stream:0 fmt:UYVY8_1X16/1920x1080 field:none colorspace:smpte170m xfer:709 ycbcr:601 quantization:lim-range] -> "crossbar":0 [ENABLED,IMMUTABLE] - entity 28: ap1302 2-003c (3 pads, 2 links, 0 routes) type V4L2 subdev subtype Unknown flags 0 device node name /dev/v4l-subdev4 pad0: SINK [stream:0 fmt:SGRBG12_1X12/1280x800 field:none colorspace:srgb crop.bounds:(0,0)/1280x800 crop:(0,0)/1280x800] <- "ar0144 0":0 [ENABLED,IMMUTABLE] pad1: SINK [stream:0 fmt:SGRBG12_1X12/1280x800 field:none colorspace:srgb crop.bounds:(0,0)/1280x800 crop:(0,0)/1280x800] pad2: SOURCE [stream:0 fmt:UYYVYY8_0_5X24/4224x4092 field:none colorspace:srgb crop.bounds:(0,0)/1280x800 crop:(0,0)/1280x800] -> "csidev-4ae00000.csi":0 [ENABLED] - entity 32: ar0144 0 (1 pad, 1 link, 0 routes) type V4L2 subdev subtype Sensor flags 0 device node name /dev/v4l-subdev3 pad0: SOURCE [stream:0 fmt:SGRBG12_1X12/1280x800 field:none colorspace:srgb] -> "ap1302 2-003c":0 [ENABLED,IMMUTABLE] Best regards, Milav Re: AP1302 MIPI CSI Streaming Issue on FRDM i.MX93 the AP1302 probe succeeding does not guarantee that the complete camera pipeline is configured and streaming. On i.MX93, a VIDIOC_STREAMON returned -1 (Broken pipe) typically means that one of the media pipeline components (AP1302 → MIPI CSI-2 receiver → ISI capture path) failed to start or negotiate a valid stream. Your log only confirms that the AP1302 I²C device was detected: ap1302 2-003c: AP1302 revision 0.2.6 detected but it does not confirm that: the firmware was loaded successfully, the correct DTB was used, the media graph was created, the CSI receiver is locked to incoming MIPI data, the AP1302 has been configured with a matching output format. First thing I would check: firmware location/name For the FRDM-i.MX93 AP1302 support, NXP documentation indicates: Download ap1302_60fps_ar0144_27M_2Lane_awb_tuning.bin Rename it to ap1302.fw Place it in: /lib/firmware/imx/camera/ap1302.fw not simply /lib/firmware. Please verify: ls -l /lib/firmware/imx/camera/ap1302.fw and check boot log: dmesg | grep -i firmware dmesg | grep -i ap1302 Look for messages such as: request firmware firmware loaded failed to load firmware Second check: are you using the correct DTB? The release notes indicate AP1302 support is associated with the i.MX93 EVK device tree support. Check: cat /proc/device-tree/model cat /proc/cmdline and determine the actual DTB being loaded. Also check: dmesg | grep -i ap1302 dmesg | grep -i csi dmesg | grep -i isi Third check: verify media topology Before trying v4l2-ctl, verify that the media graph exists: Shell media-ctl -p Show more lines You should see entities similar to: ap1302 csi isi videoX If /dev/media0 does not exist, the camera pipeline is not being created correctly. A very similar FRDM-i.MX93 AP1302 case showed: media-ctl -p Failed to enumerate /dev/media0 which indicated the media pipeline was not instantiated. Please check: ls -l /dev/media* Fourth check: inspect the negotiated formats Run: v4l2-ctl --list-devices and v4l2-ctl -d /dev/video0 --all also: media-ctl -p The AP1302 firmware normally outputs processed YUV formats rather than RAW Bayer. Another common failure is: AP1302 outputs format A ISI configured for format B causing stream startup failure. A format mismatch often surfaces as STREAMON failure or CSI pipeline errors. Fifth check: inspect CSI errors during STREAMON Open another terminal and monitor: dmesg -w then run: v4l2-ctl -d /dev/video0 \ --stream-mmap=3 \ --stream-count=10 Look for messages such as: CSI timeout frame start timeout no data received FIFO overflow MIPI error link not enabled These messages usually reveal the real reason behind the Broken pipe. Re: AP1302 MIPI CSI Streaming Issue on FRDM i.MX93 It's required to set up the pipeline using the following commands before capturing. $ media-ctl -l "'ap1302 2-003c':2 -> 'csidev-4ae00000.csi':0 [1]" $ media-ctl -V "'ap1302 2-003c':0 [fmt: UYVY8_1X16/1280x800 field:none]" $ media-ctl -V "'ap1302 2-003c':2 [fmt: UYVY8_1X16/1280x800 field:none]" $ media-ctl -V "'ar0144 0':0 [fmt: UYVY8_1X16/1280x800 field:none]" $ media-ctl -V "'csidev-4ae00000.csi':1 [fmt: UYVY8_1X16/1280x800 field:none]" $ media-ctl -V "'crossbar':2 [fmt: UYVY8_1X16/1280x800 field:none]"

HMAC検証ジョブのリクエスト時にHSEが「HSE_SRV_RSP_INVALID_PARAM」を返す NXPチームの皆様、こんにちは。 HMACのVerifyジョブを使うユースケースがあります。ジョブ暗号ドライバーをトリガーした後、DETを投げると、HSEからの返答は「HSE_SRV_RSP_INVALID_PARAM」でした。 現在の設定のどこが間違っているのか理解できません。添付されたconfig zipファイルを確認していただけますか? 問題解決のためのサポートが必要です。 ありがとうございます アディティヤ Re: HSE return "HSE_SRV_RSP_INVALID_PARAM" when request for HMAC verify job こんにちは、 @lukaszadrapa さん。 詳細： デバイス: S32K311 HSE FW: HSE_FW_S32K311_0_2_55_0 RTD: SW32K3_S32M27x_RTD_R21-11_6.0.0_QLP01 ありがとうございます アディティヤ Re: HSE return "HSE_SRV_RSP_INVALID_PARAM" when request for HMAC verify job こんにちは、 @WagdeoA さん。 どのデバイス、どのRTD、どのHSEファームウェアバージョンを使っているか確認していただけますか? よろしくお願いいたします。 ルーカス Re: HSE return "HSE_SRV_RSP_INVALID_PARAM" when request for HMAC verify job こんにちは、 @WagdeoA さん。 設定に問題はありません。 私の環境では問題なく動作しています。しかし、タグの長さ(secondaryInputLength)が一つの問題かもしれません。 これは関数Crypto_Ipw_HmacVerifyで確認できます: リダイレクトが無効になっている場合は、タグの長さをバイト単位ではなくビット単位で指定する必要があります。これこそが問題なのではないですか？ よろしくお願いいたします。 ルーカス

SDK 中未实现 IMXRT EDMA 错误 IRQ 处理程序。 您好， SDK 中的 IMXRT EDMA API 似乎能够正确处理“正常情况”中断。然而，似乎没有任何处理错误中断的机制。不仅如此，似乎所有 DMA 都只有一个全局的 DMA_ERROR_IRQHandler。因此，如果您同时使用 DMA0 和 DMA1，当一切正常时，DMA0/DMA1 IRQHandler 将被调用，SDK 可以区分哪个 DMA 收到了正常中断。但是，如果出现 DMA 错误，由于只有一个全局错误中断处理程序，因此没有简单的方法可以知道错误发生在哪个 DMA（0 或 1 或其他）上。 就像我之前关于 LPUART 错误 IRQ 处理的问题一样。为什么 SDK 没有内置处理 DMA 错误并调用相应回调的功能？现在我必须手动确定错误发生在哪个 DMA 上，并在 SDK 之外调用特殊处理，而不是让它为我调用回调。 对于一个本应在生产代码中使用的 SDK 来说，似乎缺少很多健壮性功能，我敢打赌大多数人只是假设这些错误是由 SDK 在底层处理的，而没有考虑到它们实际上并没有被处理。 -m Re: IMXRT EDMA error IRQ handler is not implemented in the SDK 尊敬的@nxp16 ， 您使用的是哪款 i.MX RT 设备？当您提到 DMA0 和 DMA1 时，您指的是两个 DMA 通道，还是两个 DMA 控制器外设？ 并非所有 i.MX RT 设备都具有两个 eDMA 控制器。例如： i.MX RT1180 包含两个 eDMA 控制器。在启动文件（例如 startup_mimxrt1189_cm33.c）中，您可以找到两个 DMA 错误处理程序：DMA_ERROR_IRQHandler 和 DMA4_ERROR_IRQHandler。 i.MX RT1050 仅包含一个 eDMA 控制器。在启动文件（例如 startup_mimxrt1052.c）中，只有一个 DMA 错误处理程序：DMA_ERROR_IRQHandler。 一般来说，DMA 错误是相对不常发生的事件。从硬件架构的角度来看，通道错误状态被聚合为模块级错误请求，从而触发 DMA 错误中断。因此，该软件必须检查每个通道的错误状态寄存器（例如，CHn_ES），以确定哪个特定通道导致了错误。 顺祝商祺！ 张雪莉 Re: IMXRT EDMA error IRQ handler is not implemented in the SDK 抱歉，我指的是频道。我使用的是 IMXRT1172。 如果与之连接的外设出现问题，难道不会发生DMA错误吗？也就是说，如果是 LPSPI 和 DMA，那么任何 SPI 错误都会导致 DMA 错误吗？如果不是，那么在使用DMA时，SPI错误是否会触发SPI错误中断？ 谢谢！ -m Re: IMXRT EDMA error IRQ handler is not implemented in the SDK 尊敬的@nxp16 ， 不。在使用DMA时发生的外围设备错误并不一定意味着DMA控制器本身会报告错误。大多数情况下，SPI 错误和 DMA 错误由两个独立的状态和中断机制处理。 DMA 只报告 DMA 层、总线层或传输层错误。LPSPI 中的协议级或 FIFO 相关错误应通过 LPSPI 外设自身的状态标志和错误中断来处理。以 DMA 模式运行并不会自动将所有 SPI 错误转换为 DMA 错误。 顺祝商祺！ 张雪莉 Re: IMXRT EDMA error IRQ handler is not implemented in the SDK 我猜也是这样。在这种情况下，SDK 的传输 API 就更不可靠了。必须在 SDK 之外处理外围设备和 DMA 错误，这需要相当多的额外工作，包括对默认 IRQ 处理程序进行一些变通的覆盖，并确保它们在处理任何错误后仍然调用 SDK 处理程序。令人沮丧的是，这些内容并未包含在 SDK 传输 API 中。 Re: IMXRT EDMA error IRQ handler is not implemented in the SDK 尊敬的@nxp16 ， 我理解您的担忧，我也同意将外围错误状态的处理与 SDK 传输 API 分开处理可能会增加所需的应用程序级代码量。感谢您的反馈。我会将您的意见转达给SDK团队。 顺祝商祺！ 张雪莉 Re: IMXRT EDMA error IRQ handler is not implemented in the SDK 实际上，情况比我想象的还要糟糕。使用 EDMA LPSPI 传输 API 无法捕获 SPI 错误，因为 LPSPI_MasterTransferEDMA 调用的函数LPSPI_PrepareTransferEDMA会禁用所有 SPI 中断。因此，在调用它之前不可能启用错误中断，因为它会再次禁用它们，而之后就太晚了，因为 SPI EDMA 传输已经开始了。这是该API的一个重大漏洞。 -m