S32K3のデバッグに関する問題 こんにちは。S32DS3.6.7を使用してS32K324のデバッグを行っていた際、純正のJ-Linkを使用していました。V11. 次のような問題が発生しました。どうすれば解決できますか？ このボードにはデバッグパスワードが設定されていないため、PEを使用して通常どおり接続およびデバッグできます。 Re: S32K3 Debug问题 こんにちは@Chenxu1 SEGGERは、IDコードダイアログ（共有画像に示されているとおり）を介した認証メカニズムを使用していることを理解しています。彼らのドキュメントによると、デバッグアクセスを有効にするには有効なキーを提供する必要がある。詳細については、リンク先の「デバッグ認証」セクションを参照してください。 この現象はSEGGERのツール特有のものであるため、SEGGERのサポートにお問い合わせいただくことをお勧めします。 ご理解いただき、ありがとうございます。 BR、VaneB

S32G3上のTrustZone こんにちは、 現在、S32G3上でARM TrustZoneを有効化する作業に取り組んでいます。 私の状況は以下の通りです。 私のテストカードでは、Rich OSとOP-TEEを起動できます。NXPリポジトリからこのOP-TEEを取得しました https://github.com/nxp-auto-linux/optee_os/tree/release/bsp46.0-4.0 。 ビルドプロセス中に、OP-TEEクライアントとOP-TEEサンプルをビルドします。サンプルとして提示された信頼できるアプリに関連するバイナリファイルは、私のテスト用カードのファイルシステム上の適切な場所に存在しています。 サンプルとして提供されている信頼済みアプリをテストしようとしています。そのためには、まずtee-supplicantを起動し、次にテストしたいtrusted-appに関連するバイナリを実行します。 しかし、次のようなエラーが発生します。 E/LD: init_elf:486 sys_open_ta_bin(8aaaf200-2450-11e4-abe2-0002a5d5c51b) 等：？0 ldelf_init_with_ldelf:152 ldelf が res: 0xffff0000 で失敗しました optee_example_hello_world: TEEC_Opensession がコード 0xffff0000 で失敗しました。発生元 0x3 コードを確認したり、他のフォーラムを読んだりしたところ、tee-supplicantはOP-TEEからの指示を受け取っていないようです。 より正確に言うと、/proc/$(tee_supplicant_pid)/maps を見ると、OP-TEE の共有マップが tee_supplicant のアドレス空間にマッピングされていないことがわかります。 [ 0.000000] OF: 予約済みメモリ: 0x00000000fe000000..0x00000000ff3fffff (20480 KiB) nomap 再利用不可 optee@fe000000 [ 0.000000] OF: 予約済みメモリ: 0x00000000ff400000..0x00000000ff5fffff (2048 KiB) nomap 再利用不可optee-shm@ff400000 しかし、/proc/$(tee_supplicant_pid)/maps では： 5567a84000-5567a8f000 r-xp 00000000 01:00 402 /usr/sbin/tee-supplicant 5567a8f000-5567a90000 r--p 0000a000 01:00 402 /usr/sbin/tee-supplicant 5567a90000-5567ad1000 rw-p 0000b000 01:00 402 /usr/sbin/tee-supplicant 5567ad1000-5567ad2000 rw-p 00000000 00:00 0 55a4ca6000-55a4cc7000 rw-p 00000000 00:00 0 [ヒープ] 7fbe028000-7fbe02a000 rw-p 00000000 00:00 0 7fbe02a000-7fbe1ad000 r-xp 00000000 01:00 155 /lib/libc.so.6 7fbe1ad000-7fbe1b0000 r--p 00183000 01:00 155 /lib/libc.so.6 7fbe1b0000-7fbe1b2000 rw-p 00186000 01:00 155 /lib/libc.so.6 7fbe1b2000-7fbe1bf000 rw-p 00000000 00:00 0 7fbe1bf000-7fbe1c2000 r-xp 00000000 01:00 184 /lib/libteec.so.2 7fbe1c2000-7fbe1c3000 r--p 00002000 01:00 184 /lib/libteec.so.2 7fbe1c3000-7fbe1c4000 rw-p 00003000 01:00 184 /lib/libteec.so.2 7fbe1c4000-7fbe1c6000 rw-p 00000000 00:00 0 7fbe1c6000-7fbe1c8000 r--p 00000000 00:00 0 [vvar] 7fbe1c8000-7fbe1c9000 r-xp 00000000 00:00 0 [vdso] 7fbe1c9000-7fbe1f0000 r-xp 00000000 01:00 151 /lib/ld-linux-aarch64.so.1 7fbe1f0000-7fbe1f2000 r--p 00026000 01:00 151 /lib/ld-linux-aarch64.so.1 7fbe1f2000-7fbe1f3000 rw-p 00028000 01:00 151 /lib/ld-linux-aarch64.so.1 7fbe1f3000-7fbe1f4000 rw-p 00000000 00:00 0 7fc6441000-7fc6462000 rw-p 00000000 00:00 0 [スタック] 今のところ、なぜこのようなことが起こるのか原因が分かりません。 どなたか何かご存知の方はいらっしゃいますか？ よろしくお願いいたします。 ユーザー6 Re: TrustZone on S32G3 こんにちは、 @user6 ご返信ありがとうございます。 どうやらあなたはBSP45のカーネルとBSP46のカーネルが混在した環境で作業しているようですね。BSP46で完全にテストしてみることをお勧めします。 簡単に言うと、Yoctoを使って構築してみると良いでしょう。 BR チェイン Re: TrustZone on S32G3 こんにちは、 @chenyin_h さん。 迅速なご回答ありがとうございます。 私はカスタム基板でテストを行っています。 私のセットアップについて： - LinuxはBSP 45.0-6.6.87-rtに基づいています - このdtsは、OP-TEEの要件に適合するカスタムdtsです。 - RootfsはOP-TEEの要件を満たす古典的なものです この設定で問題になりそうな点はありますか？ よろしくお願いいたします。 ユーザー6 Re: TrustZone on S32G3 こんにちは、 @user6 投稿ありがとうございます テスト環境についてもう少し詳しく教えていただけますか？ 1. それは、自社開発のボードでテストされたものですか、それともリファレンスボード（例えばRDB3やEVB3）でテストされたものですか？ 2. あなたはBSP46で使用されているOPTEEバージョンに取り組んでいると理解していますが、テスト環境もBSP46（Linux、dts、Rootfsなど）に基づいているのでしょうか？ BR チェイン Re: TrustZone on S32G3 こんにちは、 @chenyin_h さん。 お返事ありがとうございます。 BSP46 で完全に試してみましたが、bsp46 のベースとなっている optee-os のバージョンが 4.0.0 であるため、optee-client と optee-examples のバージョンも 4.0.0 に変更しました。 しかし、エラーは依然として発生している。S32G3ベースのSoCにTrustZoneを統合した社内事例はありますか？ よろしくお願いいたします。 ユーザー6

SPI problem example read ID from TJA1145 When trying to read the ID via SPI, I receive the following responses. 0xFD74. From data sheet 0x74 is expected.    But if I send the service 0xFD00  again, I get a different response from TJA1145. Why is that the case? The responses repeat cyclically which means BufferRx[4] would be 0xFD74.   I would like to set the transceiver to normal mode using 0x0207. However, here as well I receive different responses but not the response I expect.   Thanks for the support!  Re: SPI problem example read ID from TJA1145 Thanks for the reply.  If I send the message as recommended, I get the following answer: It looks like the TJA1145 is responding with following register values  (16 Bit)and  reflecting SDI on SDO. I can also see if I sent Frame 1, pull SDI to low and start with reading register 0x7E, the response comes as expected.   According to the datasheet, SDI can be left floating after the transfer. Does the slave need a low level to reset its internal state machine? Thanks in advance!  Re: SPI problem example read ID from TJA1145 Hello, The SPI interface operates in full‑duplex mode, meaning that data is transmitted and received simultaneously. However, the device does not return the result of the current command within the same SPI frame. Instead, the response corresponds to the previously received command. So, could you please try  Frame 1: TX (MOSI): Read command → Address 0x7E with RO = 1 RX (MISO): Undefined or previous data Frame 2: TX (MOSI): Dummy data (e.g., 0x0000) RX (MISO): Valid response → Device ID value (e.g., 0x74) Re: SPI problem example read ID from TJA1145 What is the external pull-up value connected to SDI? Please see AH1903 Application Hints - High speed CAN transceiver for partial networking TJA1145A section 7.4.1 SDI pin input behavior that is under secure files!

如何为新的 SJA1110-MGS-EVM 主板刷新 " flash_image_single_bank.bin "？ 恩智浦团队你好， 目前，我正在尝试将 " flash_image_single_bank.bin " 闪存到新的 SJA1110-MGS-EVM 板上。但是，我遇到了以下问题： C:\tools\sw576913_SJA1110-EVM-Configuration-Tools\examples\SJA1110EVM>python read_deviceid.py 设备 ID SW0: 0xffffffff 设备 ID SW1: 0xffffffff C:\tools\sw576913_SJA1110-EVM-Configuration-Tools\examples\SJA1110EVM>python example_read_deviceid.py 设备 ID SW 0：0xFFFFFFFF 状态 SW 0: 0xFFFFFFFF 设备标识 SW 1: 0xFFFFFFFF 状态 SW 1: 0xFFFFFFFF 访问设备 ID 的不同方式： 直接注册访问： 0xFFFFFFFF 辅助函数：0xFFFFFFF 抽象寄存器访问权限 (RAW)：0xFFFFFFF 抽象寄存器访问权限（对象）：{'ID'：30 70231311，'内容'： 4294967295} C:\tools\sw576913_SJA1110-EVM-Configuration-Tools\examples\SJA1110EVM>example_load_sw.py --bin flash_image_single_bank.bin 未提供 deviceID。正在从连接的设备获取 deviceID... 在 CS=0 处找不到 SJA1110 设备（改为找到 id=fffffff） Traceback（最后一次通话） ： 文件 " C:\tools\sw576913_SJA1110-EVM-Configuration-Tools\ examples\ SJA1110EVM\ example_load_sw.py "，第 78 行，位于 print ( " 交换机 {:} 的未知设备 ID ({: 08X}) " .format (_sw.DeviceID，_sw.cs)) ^^^^^ AttributeError：'SJA1110' 对象没有属性 'cs' 以下两种配置都会出现同样的问题： SW 2.6 SW 2.7 启动模式 关 关 SDL ON 状态 ON 状态 SDL 您能否帮助审查这个问题并提供支持？ Br、 Pham Quoc Vi   Re: How to flash "flash_image_single_bank.bin" for new SJA1110-MGS-EVM board? 你好@ViPhamQuoc、 看来您使用的是 SJA1110-EVM 配置工具。请尝试使用 SJA1110-EVM 主机工具，它提供了所有源代码，因此可以在必要时对其进行修改。 我将通过私人电子邮件把我修复的 sja11xx_ftdi4232.py 发送给你。 FtdiPlatform.__init__例程进行了修改，以正确找到端口 A 和端口 C。 如果连接了更多 4 端口 FTDI 设备，则脚本将结束。 此外，还添加了一些调试打印。 我能从我的 MGS 主板上读取 deviceID SW1:0xb700030F。 请注意，SJA1110-EVM 配置工具和 SJA1110-EVM 主机工具专用于带有 2 个开关的 SJA1110-EVM 板，因此，预计会对 python 脚本进行改编。 顺祝商祺！ 帕维尔 Re: How to flash "flash_image_single_bank.bin" for new SJA1110-MGS-EVM board? 你好@ViPhamQuoc、 改编时需要通过您要使用的脚本（例如SJA1110-EVM 主机工具 / read_device.py)并删除/注释涉及 SJA1110-EVM 第 2 个开关的行（例如print("DeviceId SW2: 0x%08X" % （platform.spi_read(0、cs=1))) ). SJA1110-EVM 配置工具中的脚本和 SJA1110-EVM 主机工具中的脚本都需要进行适配。 顺祝商祺！ 帕维尔

S32K344 Mini EVB + GMAC RMII + KSZ8091RND: RXフレームがCRC_ERROR + DRIBBLE_ERRORで破棄されました こんにちは、 私はS32K344上でイーサネットを動作させる作業を行っており、ベースボードとしてS32K344 Mini EVBを使用しています。このプロジェクトは、lwIPを使用せずにRTD Eth_43_GMACドライバを使用しています。このアプリケーションはNXPのethernet_no_lwipサンプルをベースにしていますが、当社のボードに合わせて調整されています。 ハードウェアは、Microchip/Micrel製のKSZ8091RND PHYをRMIIモードで使用しています。回路図によると、PHYはXIピンで50MHzのクロックを受信します。KSZ8091RNDのPHY制御2レジスタのビット7（RMIIリファレンスクロック選択）は0です。これは、XIで50MHzクロックを使用するRNDモードと一致していると考えられます。 MCUとPHY間のインターフェースは、RMII、100Mbps、全二重として構成されている。 .mexファイルではファイルにおいて、GMAC/EMACピンは以下のように構成されます。 PTD16、ピン 34: RMII_MDIO、emac_mii_rmii_mdio PTD17、ピン 31: RMII_MDC、emac_mii_rmii_mdc PTB5、ピン47：RMII_TX0、emac_mii_rmii_txd0 PTB4、ピン48：RMII_TX1、emac_mii_rmii_txd1 PTE9、ピン 36: RMII_TX_EN、emac_mii_rmii_tx_en PTC0、ピン62：RMII_TX_CLK、emac_mii_rmii_tx_clk PTD9、ピン63：RMII_RX0、emac_mii_rmii_rxd0 PTD8、ピン 64: RMII_RX1、emac_mii_rmii_rxd1 PTC15、ピン 68: RMII_RX_DV、emac_mii_rmii_rx_dv PTC16、ピン 66: RMII_RX_ER、emac_mii_rmii_rx_er PTC1、ピン61：RMII_RX_CLK、emac_mii_rx_clk PTE21、ピン153：ENET_RESET .mexファイル内の関連するイーサネット構成ファイル： EthCtrlMacLayerType = ETH_MAC_LAYER_TYPE_XMII EthCtrlMacLayerSubType = 縮小 EthCtrlMacLayerSpeed = ETH_MAC_LAYER_SPEED_100M EthDuplexMode = ETH_FULL_DUPLEX EthCtrlEnableRxInterrupt = false EthCtrlEnableTxInterrupt = false RTDによって生成された関連GMAC構成： miiMode = GMAC_RMII_MODE 速度 = GMAC_SPEED_100M デュプレックス = GMAC_FULL_DUPLEX また、ドライバがコントローラをリセットする前にRMIIインターフェースを選択していることも確認しました。Eth_43_GMAC_Ipw.c では、モードがGMAC_RMII_MODEの場合、DCMRWF1 MAC_CONF_SELに値2Uを書き込みます。 生成されたコードに基づくと、MAC_CONF_SELはRMII用に設定されているようです。 時計に関しては、.mexファイルには以下が表示されます： external_clocks.emac_mii_rmii_tx.outFreq = 50 MHz EMAC_MII_RMII_TX.outFreq = 50 MHz EMAC0_RX_CLK.outFreq = 25 MHz EMAC0_TX_CLK.outFreq = 25 MHz EMAC0_TS_CLK.outFreq = 50 MHz EMACクロックマルチプレクサは、EMAC_MII_RMII_TX_CLKをソースとして使用します。 McuCgm0ClockMux7_Source = EMAC_MII_RMII_TX_CLK McuCgm0ClockMux8_Source = EMAC_MII_RMII_TX_CLK McuCgm0ClockMux9_Source = EMAC_MII_RMII_TX_CLK これをNXPの.mexの例と比較するとファイルを確認したところ、EMAC_MII_RMII_TXが50MHz、EMAC0_RX_CLK / EMAC0_TX_CLKが25MHzと表示されていました。そのため、これはツール上では正常な動作だと思われますが、確認したいと思います。 このアプリケーションは、lwIPを使用せずに、Eth_43_GMACを介してイーサネットフレームを直接送受信します。 送信時には、以下のシーケンスを使用します。 Eth_43_GMAC_ProvideTxBuffer Eth_43_GMAC_送信 Eth_43_GMAC_TxConfirmation RX（受信）に関しては、RX/TX割り込みが無効になっているため、ポーリングを使用します。 ETH_43_GMAC_RX_IRQ_ENABLED = STD_OFF ETH_43_GMAC_TX_IRQ_ENABLED = STD_OFF RXコードは、CtrlIdx、FifoIdx、およびreceiveStatusを引数としてEth_43_GMAC_Receiveを繰り返し呼び出します。 また、EthIf_RxIndications[0]も監視します。なぜなら、ドライバは受信したフレームにエラーがない場合にのみEthIf_RxIndicationを呼び出すからです。 観測された挙動は以下のとおりです。 TXは複数回正常に確認されました。 一方、一部のフレームは受信されているように見える。 S32K344のRXはデータを受信するが、その後ドライバによって全てのフレームが破棄される。 receiveStatusは、フレームが受信されたことを示す場合があります。 しかし、ドライバがフレーム内のエラーを検出したため、EthIf_RxIndicationは呼び出されません。 Eth_43_GMAC_Ipw_axRxFrameInfo[0][0].ErrMask を検査したところ、観測された値は次のとおりでした。 ErrMask = 0x01080000 ドライバヘッダーによると、これは以下に対応します。 GMAC_RX_ERR_CRC_ERROR = 0x01000000 GMAC_RX_ERR_DRIBBLE_ERROR = 0x00080000 つまり、フレームはGMACに到達するが、CRCエラーとドリブルエラーが記録されている。 主な疑問は、GMACがRMII 100M全二重として構成され、KSZ8091RND PHYがXIで50MHzクロックを受信し、ドライバがMAC_CONF_SEL値2Uを選択している場合、RXでCRCエラーとドリブルエラーが同時に発生する原因は何なのか、ということです。 特に確認したい点は以下のとおりです。 S32K344、GMAC、RMII の場合、.mex はファイルにはEMAC_MII_RMII_TX = 50 MHzと記載されているが、EMAC0_RX_CLKとEMAC0_TX_CLKは25 MHzとなっている。 S32K344のRMIIモードでは、PTC0上のemac_mii_rmii_tx_clkとPTC1上のemac_mii_rx_clkの両方を設定することが想定されていますか、それともこのモードではこれらの信号のいずれかを使用またはルーティングしない必要がありますか？ MAC_CONF_SELの値が2Uであること以外に、RMIIのDCM_GPR、クロックツリー、またはピンマルチプレクサで追加の設定が必要ですか？ PHY制御2のビット7を0に設定し、XIに外部50MHzクロックを接続したKSZ8091RNDは、このGMAC構成と互換性がありますか？ RXでCRC_ERRORとDRIBBLE_ERRORが同時に発生した場合、オシロスコープまたはロジックアナライザで最初に確認すべきRMII信号はどれですか？REF_CLK、CRS_DV、RXD0、RXD1、RX_ER? NXPの公式S32K344用サンプルコードで、lwIPを使用せずにRMIIモードでKSZ8091RND PHYを使用するものはありますか？ 要約：リンクが確立され、TXが確認され、RXがフレームを検出しますが、CRC_ERRORとDRIBBLE_ERRORによりフレームが破棄されます。これがRMIIクロックの問題、ピン多重化／物理信号の問題、あるいはGMAC／RTDの追加設定要件を示しているのかどうかを判断しようとしています。 サポートとご指導を賜り、誠にありがとうございます。 Re: S32K344 Mini EVB + GMAC RMII + KSZ8091RND: RX frames discarded with CRC_ERROR + DRIBBLE_ERROR こんにちは、パベルさん。 重要なお知らせが1つあります。 S32K344の内部MACループバックを有効にし、PHYループバックを有効にせず、PHYリンクの自動ネゴシエーションを待たずに、TXの後にRXのみを実行するようにテストを調整しました。 MAC内部ループバックを使用すると、テストは正しく合格します。受信したフレームは有効であり、CRCエラーやドリブルエラーはありません。 しかし、KSZ8091RND PHYのループバックを有効にしても問題は解決しません。フレームはRXバッファに到達しますが、一部のバイトが破損し、GMACがCRCエラーを報告します。 現在の結果は以下のとおりです。 MAC内部ループバック：OK、CRCドリブルエラーなし PHYループバック：失敗、CRCエラーが残っています 通常の外部受信: 失敗、CRCエラーが残っています これは、GMACドライバ、TX-RXソフトウェアフロー、バッファ、および内部MACパスが正しく動作していることを示しており、残りの問題はS32K344とKSZ8091RND間の外部RMIIパス、またはPHY-RMIIパッド構成にある可能性が高いことを示唆している。 MAC内部ループバックは合格しているのにPHYループバックが不合格となっている場合、次に何をチェックすべきか、何かおすすめはありますか？ よろしくお願いします。 Re: S32K344 Mini EVB + GMAC RMII + KSZ8091RND: RX frames discarded with CRC_ERROR + DRIBBLE_ERROR こんにちは、パベルさん。 ご返信とご指導ありがとうございます。 ご指摘いただいた内容に基づき、ハードウェアとソフトウェアの追加チェックを実施しました。 まず、オシロスコープを使用して、PTC0であるemac_mii_rmii_tx_clkとして設定されたMCUピンに50MHzのRMIIクロックが存在し、安定していることを確認しました。また、このクロックはイーサネットドライバの初期化前に存在していることも確認しました。 emac_mii_rx_clk信号に関して、S32K344のRMIIモードでは使用されないというご説明は理解いたしました。混乱を避けるため、この信号を設定から削除しましたが、エラーの動作は変わりませんでした。 DCMRWF1も確認しました。ご指摘のとおり、RTDドライバはMAC_CONF_SEL = 2UでRMIIモードを設定しています。 回路図と基板の検査中に、ハードウェアの問題が見つかりました。PHY CRS_DV信号をMCUピンに接続する抵抗R190が断線しているか、取り付けられていませんでした。この信号は、mmac_mii_rmii_rx_dvとして構成されたMCUピンに接続されたRMII CRS_DV信号に対応します。 これを特定した後、抵抗器R190を取り付け/接続しました。その後、オシロスコープにCRS_DV信号が現れ始め、受信時にはMCUのピンでトグルするようになった。また、RX_ERも測定しましたが、フレーム中にパルスが発生しないため、常に低い値のままでした。 CRS_DVを修正した後も、問題は解決しなかった。ドライバは依然として ErrMask = 0x01080000 を報告しており、これは CRC_ERROR + DRIBBLE_ERROR を意味します。 RXバッファの内容も確認しました。フレームはGMACに到達しているようだが、一部のバイトに誤ったビットが含まれている。例えば、期待されるフレームは次のとおりでした。 宛先MACアドレス: 02:00:00:00:00:02 ソースMAC: 11:12:21:77:77:77 イーサリアムタイプ: 88:88 しかし、RXバッファに現れたのは次のようなものだった。 宛先MACアドレス: 21:00:00:00:00:02 送信元MACアドレス: 11:21:11:76:77:77 イーサリアムタイプ: 8B:88 その後、バイト08が現れ、残りのバイトはすべてゼロになった。 これは、フレームがGMACに到達しているものの、データが不正確または位置ずれしたビットでサンプリングされていることを示唆しています。 オシロスコープ上でCRS_DVも観測した。フレームの最後に、レベルが低くなると、数サイクルの間トグルした後、完全にレベルが低くなります。我々の理解では、RMIIではCRS_DVがCRSとRX_DVを統合しているため、この動作は正常である可能性がありますが、S32K344/GMACでも同様の挙動が想定されるかどうかを確認したいと思います。 その後、基板を再度確認し、残りのRMII信号用の抵抗器／ジャンパーが正しく取り付けられていることを確認しました。R190に問題が見つかった後、他のRMII信号も確認しましたが、他に欠落または断線している抵抗は見つかりませんでした。 また、KSZ8091RND PHY上でループバックテストを実施しました。基本制御レジスタにおいて、MDIOを介してPHYをループバック用に構成しました。デバッガーで、ビットが次のようになっていることを確認しました。 ループバック = 1 speedSelect = 1 autoNegotiationEnable = 0 デュプレックスモード = 1 つまり、PHYはループバックモード、100Mbps、全二重、オートネゴシエーション無効の状態です。 このモードでは、当社のソフトウェアはフレームをGMAC経由で送信し、Eth_43_GMAC_Receiveを使用して受信を即座にポーリングします。TXシーケンスは、Eth_43_GMAC_TxConfirmationと正しく照合されます。 PHYをループバックモードにしても、問題は解決しない。フレームは依然としてRXバッファに到達しますが、バイトが破損しており、ドライバは依然としてErrMask = 0x01080000を報告します。これはCRC_ERROR + DRIBBLE_ERRORを意味します。 このことから、ケーブルと他のデバイスは分析から除外されるようです。なぜなら、問題はローカルパス MCU -> PHY -> 内部 PHY ループバック -> MCU でも発生するからです。 現時点で、ご質問に対する回答は以下のとおりです。 1->EMAC_MII_RMII_TX = 50 MHz、EMAC0_RX_CLK / EMAC0_TX_CLK = 25 MHz は RMII で正常であることを確認しました。 2->RMIIではemac_mii_rx_clkは不要であることを確認しました。設定から削除したが、問題は解決しなかった。 3->ドライバがDCMRWF1.MAC_CONF_SEL = 2Uを構成することを確認しました。 4->オシロスコープで、50 MHz クロックが MCU ピン PTC0 / emac_mii_rmii_tx_clk に到達していることを確認しました。 5->抵抗R190を取り付け/閉じた後、CRS_DVがMCUに到達することを確認しました。 6->受信中は常にRX_ERが低いままであることを確認しました。 7->BMCRの読み出しにより、PHYループバックが実際にアクティブであることを確認しました。 8->残りのRMII信号用の抵抗器/ジャンパーが正しく取り付けられていることを確認しました。 それでも、破損したバイトとCRC_ERROR + DRIBBLE_ERRORを含むフレームを受信し続けています。 このシナリオでは、問題は依然としてS32K344とKSZ8091RND間のローカルRMIIインターフェースに関連しているようで、おそらくREF_CLK、TXD0/TXD1/TX_EN、CRS_DV、RXD0/RXD1間のタイミング/スキュー、またはRMII信号の電気的/パッド構成に問題があると考えられます。 PHYループバックを有効にした場合でもエラーが発生するようになったため、このケースについて何か具体的な推奨事項はありますか？S32K344 Mini EVBのRMIIに関して、確認すべきパッド構成、クロック位相、駆動強度、スルーレート、または直列抵抗の要件はありますか？ MCUからPHYへのTX RMIIパスに問題があるのか、それともPHYからMCUへのRX RMIIパスに問題があるのかを判別するために推奨されるGMACまたはPHYテストはありますか？ ご支援とご指導を賜り、誠にありがとうございます。 Re: S32K344 Mini EVB + GMAC RMII + KSZ8091RND: RX frames discarded with CRC_ERROR + DRIBBLE_ERROR こんにちは、@brunoGT88 さん。 詳細な説明をありがとうございました。あなたの設定を注意深く確認しました。 ご説明いただいた内容に基づくと、これはEth_43_GMACのTX/RXソフトウェアフローの問題というよりは、典型的なRMIIクロックの問題のように見えます。 まず、Eth_43_GMAC_Init() を呼び出す前に、外部 RMII 50 MHz クロックが存在し、安定していることを確認してください。これはS32K344 RMIIの設定において重要な点です。 ご質問について： 1. はい - RMII モードでは、クロック構成で EMAC_MII_RMII_TX = 50 MHz と表示され、内部 EMAC0_RX_CLK と EMAC0_TX_CLK は 25 MHz として導出されることが想定されます。 2. いいえ - emac_mii_rx_clk は S32K344 EMAC の RMII モードでは使用されません。通常のS32K3 RMII構成では、PHYがMACに50MHzのTXクロックを供給し、内部EMACのRX/TXクロックは分周器2を使用してそのクロックから生成されます。 3. 私の場合、通常はDCMRWF1のRMII選択のみを主要な追加設定として使用し、通常はプロジェクトの最初の行に配置します。 IP_DCM_GPR -> DCMRWF1 = ( IP_DCM_GPR -> DCMRWF1 & ~DCM_GPR_DCMRWF1_MAC_CONF_SEL_MASK) | DCM_GPR_DCMRWF1_MAC_CONF_SEL(2U);   4. PHYクロックの部分については、あなたの説明からはまだ完全には理解できません。KSZ8091RNDがXIで50MHzを受信しているというだけでは、S32K344 MACがemac_mii_rmii_tx_clkで必要な50MHz RMIIリファレンスクロックを受信していることを自動的に確認することはできません。PHY/発振器とMCUの間で50MHz RMIIリファレンスクロックがどのように接続されているかを正確に確認し、可能であればその部分の回路図を共有してください。 5. RXでCRCエラーとドリブルエラーが発生した場合、RMIIクロック/信号を次の順序で確認します。 REF_CLK / RMII_TX_CLK (50 MHz) CRS_DV RXD0 / RXD1 RX_ER 6. S32K344 + KSZ8091RND + RMII + lwIPなしという構成に特化したNXPの公式サンプルは知りません。ただし、このS32K344 EMACの例を参照して、クロック/ピン設定をそれと比較するか、ボードに合わせて調整することもできます。 例：S32K344 EMAC lwIP FreeRTOS miniEVB S32DS 3.6.1 RTD 6.0.0 追加のデバッグ手順として、PHYが対応している場合は、PHY側でMII/RMIIループバックを有効にして、MACが送信したフレームを受信できるようにしてみてください。これは、PHY/リンクレベルの問題とMCUの受信サンプリングの問題を区別するのに役立ちます。 よろしくお願いいたします。 パベル Re: S32K344 Mini EVB + GMAC RMII + KSZ8091RND: RX frames discarded with CRC_ERROR + DRIBBLE_ERROR 私はRTD 5.0.0を使用しています。 Re: S32K344 Mini EVB + GMAC RMII + KSZ8091RND: RX frames discarded with CRC_ERROR + DRIBBLE_ERROR こんにちは、 @PavelL さん。 重要な新たな発見がありました。 PC上でWiresharkを使用して、ボードのTX（送信）機能をテストしました。ファームウェアは以下のフレームを送信します。 宛先MACアドレス: 70:69:79:A6:74:4F ソースMAC: 11:12:21:77:77:77 イーサリアムタイプ: 0x8888 ペイロード: 0x55 パターン しかし、Wiresharkで確認したところ、PCに届いたフレームは既に破損していた。送信元MACアドレス、宛先MACアドレス、およびEtherTypeが正しくありません。 つまり、問題はS32K344へのRXだけにあるわけではない。S32K344からPHY-PCへのTXパスでもビットが破損している。 MACの内部ループバックは正常に機能しているため、フレームはGMAC内部で正しく構築されます。フレームが外部RMIIインターフェースを介して送信される際に、破損が発生する。 これは、外部RMII TXパスまたはパッド構成に問題があることをより強く示唆している。 TXD0 TXD1 TX_EN REF_CLK - RMII_TX_CLK S32K344のRMII TXに関して、駆動強度、スルーレート、キーパー、プル構成など、特定のパッド設定を推奨しますか？現在生成されているピン構成では、TXD0、TXD1、TX_EN、およびTX_CLKのdriveStrengthEnableが無効になっています。 よろしくお願いします。 Re: S32K344 Mini EVB + GMAC RMII + KSZ8091RND: RX frames discarded with CRC_ERROR + DRIBBLE_ERROR こんにちは、 @PavelL さん。 根本原因を突き止めました。 問題は初期化順序に関連していた。私のプロジェクトでは、SIUL2ピンマルチプレクサの初期化よりも前にMCUクロックの初期化が実行されていました。起動フローを変更し、MCUクロックの初期化よりも先にピン多重化の設定を行うようにしたところ、イーサネットフレームが正しく送信されるようになった。 これは、私が比較対象としたNXPのクリーンなサンプルで使用されている初期化順序とも一致します。 サポートありがとうございます。 Re: S32K344 Mini EVB + GMAC RMII + KSZ8091RND: RX frames discarded with CRC_ERROR + DRIBBLE_ERROR こんにちは、@brunoGT88 さん。 詳細なアップデートと追加チェックを実施していただき、ありがとうございます。最新の結果は大変参考になります。MAC内部ループバックは通過するが、PHYループバックは依然として失敗し、 PC上で確認した時点で、送信時に既にフレームが破損している。これは、問題がGMACドライバのフロー、バッファ処理、または内部MACパスにあるのではないことを強く示唆している。 残りの疑わしい領域は、S32K344とKSZ8091RND間の外部RMIIインターフェースであり、信号ルーティング、ピンマッピング、I/O電圧互換性、またはRMIIライン上のタイミング/信号完全性などが含まれます。私の提案をぜひご検討ください。 KSZ8091RNDとS32K344のRMIIピン間のI/O電圧の互換性を確認してください。 すべてのRMIIラインについて、ピン間の導通と信号マッピングを確認してください。 基板上のどこでもTXD0/TXD1とRXD0/RXD1が入れ替わっていないことを確認してください。 RMII TXインターフェースのPHYピン（REF_CLK、TX_EN、TXD0、TXD1）を直接プローブします。 RMII TX信号から送信されたフレームを再構築し、期待されるフレームと比較する。 リセット後、PHYストラップの設定を再確認し、意図したRMII/リファレンスクロックモードになっていることを確認してください。 よろしくお願いいたします。 パベル

MPX5999D アプリケーション このセンサを電子圧力コントローラに使用した場合、P2 = 100 kPa のときは電子圧力コントローラは正常に動作しますが、P2 が 100 kPa から 80 kPa に低下すると、電子圧力コントローラの出力流量はゼロに近づき、設定値よりもはるかに低くなります。基準圧力が低いことがセンサの誤作動の原因になっていると推測されます。 Re: MPX5999D applycation 親愛なるユウウェイさん MPX5999Dおよびその他のMEMSセンサーはSTマイクロエレクトロニクス社に譲渡されましたのでご注意ください。サポートについては、STマイクロエレクトロニクス社のウェブサイト（https://www.st.com/content/st_com/en/support/support-home.html）をご覧ください。 MPX5999Dのデータシートの表2の下にある注記を参照してください。ポートP1に加える圧力は、常にポートP2に加える圧力以上でなければならない。 敬具、 ヨゼフ

Guider Emulation Error Guider version 1.10.1 creates projects using LVGL 8.3.10 Simulation suddenly reports an error after a few new pages, what's the reason? ✓ Compilation completed! build\bin\simulator.exe mingw32-make: *** [run] Error -1073741819

MCXE316はデバッガーなしでは動作しません 48ピンパッケージのMCXE316を使用したカスタム基板を開発中です。デバッガ（PE Micro）を接続した状態では、問題なくコードをダウンロードして実行できますが、MCUXpressoでデバッグセッション中にデバッガを接続しないと、プロセッサが動作していないようです。電源を入れ直すと基板が動作しなくなりますが、デバッガーを接続してデバッグセッションを開始すると基板は正常に動作します。私がテスト/検証した事項の一部： 1) Semihosting を有効にせずにプロジェクトをビルドし、Semihosting を無効にすると思われる Redlib の nohost -nf ライブラリを使用したことを確認しました。また、semihost_hardfault.c には、デバッガがない状態でハードフォルトを捕捉するコードが含まれているようです。 2) デバッガでリセットレジスタMC_RGM.FESとDESを確認したところ、電源投入リセットビットのみがアクティブになっています。デバッガを接続せずにPORを適用し（ハングアップ）、その後デバッガを物理的に接続して電源サイクルなしでデバッグセッションを開始しても、設定されているビットは電源投入のみです。 3) PTB13のボードにはLEDが1つ搭載されています。クロックなどの設定を変更することなく、無限ループでメイン関数の最初の操作としてLEDを点滅させるだけの、最もシンプルなLED点滅コードを作成しました。以下がテストコードです。 #include "fsl_siul2.h" main( ) { // PTB13を出力にする SIUL2-> MSCR [45] = 0x200000; （ １） { for ( volatile uint32_t s=0; s<100000; s++); SIUL2_PortToggle(SIUL2, kSIUL2_PTB , 1u << 13U); } } このコードはデバッガーが接続されているときは正常に動作しますが、スタンドアロンでは何も起こりません。SDK関数を使用して同じコードを作成してみましたが、結果は同じで、デバッガーセッションがアクティブな状態でのみ動作します。 コード内でSWTウォッチドッグを無効にしてみましたが、結果は同じでした。これはウォッチドッグリセットイベントではないと思います。 何かアイデアや、自分でできることはありますか？ありがとう！ ブートROM|ブート|フラッシュ Re: MCXE316 will not run without debugger こんにちは、セレステさん。 ご回答と確認事項をありがとうございます。デバッガーなしでは動作しないという問題が依然として発生しています。以下に、確認すべき個々の項目に対する回答を示します。 - オシロスコープを使用して電源投入時の RESET ピンを監視しましたが、POR リセット時には常に RESET ピンのレベルが +5V になります (つまり、リセット状態ではない）。部品が繰り返しリセットされるようなジャンプやその他の視覚的な現象は発生せず、ラインは論理ハイのままです。リセットラインを手動でローにしてから放すと（手動リセット）、信号はロジックハイになり、そのまま維持されます。 - 電源を維持したまま（確認済み）、手動でリセットラインをローにしてから放しましたが、それでも動作しません。これにより、電源投入速度に関する問題はすべて回避できると私は考えています。 - デバッガを接続せずにボードの電源を入れ（実行状態ではないが電源は供給されている）、その後デバッガケーブルを物理的に接続し（外部電源は中断なく供給されたまま）、デバッガでFESレジスタとDESレジスタを確認したところ、PORリセット理由のみが表示され、他の障害は発生していませんでした。PCはmain()エントリブレークポイントを指しています。デバッガはデバッグセッションの開始時にリセットを発行するため、コードはmainの開始時に実行され停止すると思われますが、ボードは電源を維持しているため、部品がハングアップした時点でDESとRESは元のPORから有効なままであるはずです。 - 私は時計の設定を一切行っていません。SDKプロジェクトによって提供されるリセット時のデフォルトの時計設定を使用しています。外部水晶発振器とPLLを使用するようにコードでクロックを設定しようと試みましたが、デバッガ上では正常に動作し、デバッガ上でも高いPLLクロックが問題なく取得できました。しかし、デバッガがないと、その部品は完全に動作しなくなります。コードに**ピー**を設定しても、起動時に内部クロックソースをデフォルトで使用するようにしても、状況は変わりません。 私が測定した限りでは、電源の立ち上がり時間は仕様の範囲内です。違いがあるかどうかを確認するために、外部電源を使って基板を起動してみます。しかし、いったん部品に電源が投入されると、その後外部リセットによって起動されるはずです。チップがハードラッチアップされた場合、基板への電源供給を維持してデバッガを再接続してもロック状態のままになりますが、デバッガは常に動作します。 他に確認や検証が必要な場合はお知らせください。アイデアが尽きてきた。ありがとう Re: MCXE316 will not run without debugger こんにちは、 @brucebowling さん、 詳細な説明と、既にいくつかの潜在的な原因を調べていただいたことに感謝いたします。大変助かります。 ご説明いただいた内容に基づくと、この現象は通常、アプリケーションコード自体というよりも、起動時の状況に関連していると考えられます。以下の主要分野に重点を置くことをお勧めします。 1. リセットまたは早期起動の失敗がないか確認する 電源投入時（デバッガを接続せずに）に、オシロスコープでRESET_Bピンを監視してください。予期しないパルス、グリッチ、またはリセットの繰り返し発生がないか確認してください。 可能であれば、デバッガーを接続せずにボードに電源を投入し、デバイスをリセットせずにデバッガーを接続し、実行を停止して、以下を確認してください。 プログラムカウンタ (PC) MC_RGM.FES および MC_RGM.DES レジスタ これは、デバイスがフリーズしているのか、繰り返しリセットされているのかを特定するのに役立ちます。 2. クロック構成を確認する これは、この種の問題の最も一般的な根本原因の一つです。 プロジェクトで外部クロックソースまたはPLLを設定する場合： コアクロックだけでなく、すべてのクロックドメインが正しく設定されていることを確認してください。 例えば、一部の派生クロック（HSEやその他のシステムクロックなど）は、コアクロックとの特定の関係に従う必要があります。 クロック設定が正しくないと、デバッグが正常に動作しているように見えても、起動初期段階で予期しないリセットや実行エラーが発生する可能性があります。 3. 電源の立ち上がり速度を確認する カスタム基板を使用しているため、起動時の電源安定性も再度確認してください。設計は、MCX E31x ハードウェア設計ガイドおよび DS に規定されている要件に準拠する必要があります。 詳細については、以下のスクリーンショットをご参照ください。     お役に立てば幸いです。 BR セレステ Re: MCXE316 will not run without debugger こんにちは、 @brucebowling さん、 ご回答ありがとうございます。以下のチェック項目を順番に実施してください。 1. フラッシュベースに有効なIVTが存在するかどうかを確認します。 読み取りアドレス 0x0040_0000 、期待値: 0x5AA5_5AA5 チェック 0x0040_0004 （ブート構成ワード）：CM7_0_ENABLEが1に設定されていることを確認します。 0x0040_000C に有効なCM7_0アプリケーションエントリアドレスが含まれていることを確認します。 2. プロジェクト／リンカースクリプト／プログラミング方法が有効なMCXE31ブートイメージを生成することを確認する。 標準のELFまたはベクターテーブルのみをプログラミングしていないことを確認してください。 画像には、Secure BAF が認識できる IVT が含まれている必要があります。 IVTは、MCXE316でサポートされているIVTアドレスのいずれかに配置する必要があります。 3. リセット後、できるだけ早くPOR関連のステータスを取得する PMC.LVSC: PORF / LVR フラグを確認する DCMの読み取り専用レジスタ：POR_WDG_ENとPOR_WDOG_TRIMを確認してください。 4. 真の独立したアプリケーション入力を確認するための最小限の実験を実施する LEDの点滅だけに頼るのは避けましょう。 代わりに、ResetISRまたは起動コードのごく初期段階で、予約済みのRAMフラグまたは専用のGPIO状態を設定します。 次に、デバッガのリセットをトリガーせずにアタッチモードを使用してステータスを読み取ります。これにより、デバッガによって引き起こされるリセットによる干渉を排除できます。 よろしくお願いいたします。 セレステ Re: MCXE316 will not run without debugger はい、ご回答で説明いただいた手順を開始したところ、すぐに問題が発生しました。0x0040_0000番地のメモリをチェックしたところ、0xFFFFFFFFという値が得られ、それ以降のアドレスの内容もすべて同じ値でした。つまり、これらの領域はSDKのデフォルトプロジェクトによってプログラミングされていなかったということだ。 画像ベクトル表（31.5節）については、リファレンスマニュアルを確認してください。IVTにプログラムする必要があるマジックナンバーなどに関するセクションを確認しました。MCXE316デバイスのデフォルトのプロジェクト設定にはこのセクションの初期化が含まれているものと想定していましたが、それに関する記述は見当たりませんでした。 FRDM MCXE31Bボード（MCXE316の上位チップ）のLED_Blinkyなどのデモアプリケーションは、予想通り、デバッガーを接続しなくてもプログラムを正しく実行できることに気づきました。そして、LED_BlinkyをFRDM-MCXE31Bボードにロードした後、メモリアドレス位置0x0040_0000を確認したところ、期待どおり0x5AA5_5AA5でした。つまり、このプロジェクトには、私がMCXE316版で使用していたデフォルトのSDKプロジェクトに欠けていた設定が含まれているということですね。 LED_Blinkyのプロジェクトを少し調べてみると、「boot_header」フォルダの中に「boot_header.c」と「boot_header.h」というファイルがあることがわかります。boot_header.c を見てみるとソースによると、これはプロジェクトがIVTのマジックナンバーやその他の項目を初期化する場所のようです。ソースと.hファイルをコピーしましたLED_Blinkyプロジェクトのファイルを私のSDKプロジェクトにコピーします。コードをビルドに含めるためには、#define BOOT_HEADER_ENABLE 1U を設定する必要もありました。 これはうまくいった！私のカスタムテストボードでは、デバッガーハードウェアなしでもアプリケーションは正常に動作し続けています。どうやらこのファイルは、テスト2のセクションであなたが以前尋ねていたことを実行するようです。 NXPはMCXE316デバイス向けの次期SDKリリースにこれを含める必要がある。さもなければ、他のユーザーも同様の問題に直面するだろう。 この件についてご協力いただき、ありがとうございました！

FRDM-IMX8MPLUS：Lauterbach TRACE32を接続すると、システムがすぐにリセットされます。 NXPコミュニティの皆様、こんにちは。 私はFRDM-IMX8MPLUS開発ボードを使用しており、10ピンJTAGインターフェースを介してLauterbach TRACE32を使用してデバッグを試みています。 深刻な問題が発生しています。JTAGケーブルをボードに接続した瞬間に、システムが即座にリセット/電源オフしてしまいます。 TRACE32ソフトウェアでSYStem.Mode Attachを実行しようとしましたが、失敗して「デバッグポートタイムアウト（UNKNOWN）」というエラーが返されました。 この動作はコールドリセット信号経路に関連していると思われます。デバッガを接続する前は、VTREF（ピン1）とJTAG_RESET（ピン10）の両方が1.8Vで安定しています。TRACE32を接続すると、JTAG_RESETが瞬時に0Vに低下し、同時にVTREFが0.7Vに低下してシステムがクラッシュします（緑色のLEDが消灯します）。 リセットの問題を回避し、デバッガーを正常に接続するために、ハードウェア/ソフトウェアを適切に設定するにはどうすればよいですか？ 前もって感謝します！ FRDMトレーニング i.MX 8ファミリ | i.MX 8QuadMax (8QM) | 8QuadPlus i.MX 8M | i.MX 8M Mini | i.MX 8M Nano Re: FRDM-IMX8MPLUS: System resets immediately when connecting Lauterbach TRACE32. こんにちは、 Trace32を接続した状態と接続を解除した状態の基板の画像も添付します。 尊重する Re: FRDM-IMX8MPLUS: System resets immediately when connecting Lauterbach TRACE32. こんにちは、ジョセフさん。 私は以下の手順に従っています。 IMX8MPボードの電源を切り、Trace32を接続します。 ボードの電源をオンにします。 しかし、ボードは起動しません。シリアルUARTからの出力がなく、LED D16も点灯しません。 Trace32の接続を解除すると、ボードは再び正常に起動する。 よろしくお願いいたします。 Re: FRDM-IMX8MPLUS: System resets immediately when connecting Lauterbach TRACE32. こんにちは、 NXP Semiconductors製品にご関心をお寄せいただきありがとうございます。 ターゲットPORの前にTRACE32を接続してみてください。 よろしくお願いします。

マルチタスクのプリエンプションによりMAC生成に異常が生じた SOCモデル：S32G399A、RTDバージョン4.0.2、HSEバージョン2.22.0、コンパイラ：GHS SecOC機能を実装する際、顧客はHSEを使用してMACアドレスを生成しました。このプロジェクトでは、同じコア上の複数のタスクで同じキースロットが使用され、MACアドレスはCrypto_ProcessJob()関数を呼び出すことで生成されました。CANパケットを監視したところ、MACアドレスが更新されない異常が時折発生することが判明しました（パケットデータは更新されましたが、MACアドレスは更新されず、関数はE_OKを返しました）。 1. 添付ファイル「MAC value not updated.png」は、問題が再現された際にCANメッセージのMAC値に対応する信号が更新されていないことを示す波形図です。 2. 添付文書「S32G_MAC Generation Anomaly Analysis.7z」は、この異常に関するプロジェクトコードの概要です。 テストの結果、MAC生成関連の処理を同一タスクにまとめることで、MACが更新されない問題が解消されることが明らかになった。現在の分析では、この異常は複数のタスクでグローバルデータが上書きされることが原因である可能性が示唆されている。 MACアドレスを生成するためにcryptoを呼び出すという現在のマルチタスク機能を維持するために、 cryptoドライバを更新するか、設定を再構成することでこの問題を解決することは可能でしょうか？ Re: 多任务抢占导致MAC生成异常 こんにちは、 @RoseRice こんにちは。暗号化ドライバの観点から言うと、関連するAPIは後続バージョンでも変更されていません。トラブルシューティングの履歴を見ると、CSMレイヤーで競合状態を解決するのが良いと思います。これはCSMレイヤーの定義にも合致しています。 BR チェイン

Configure WDOG within 128 Bus Clocks Clarification I am experiencing unexpected WDOG behavior according to my understanding of the reference manual in regard to the following: "All watchdog control bits, timeout value, and window value are write-once after reset within 128 bus clocks. This means that after a write has occurred they cannot be changed unless a reset occurs." My initial interpretation of this is that you must configure the WDOG within the first 128 bus clocks after reset, or it will use the default configuration with UPDATE=0. This will then prevent you from re-configuring the WDOG again. I however am experiencing something different. Since the KE1 out of reset runs the Bus and Core clock at the same frequency, I decided to look at the CYCLECOUNTER in the IAR debugger when I reconfigure the WDOG, as I thought it would tell me how many bus clocks have also passed since reset. It showed 144 cycles had passed since release from reset. So I started adding longer and longer delay loops at the start of the function to see if it would still allow me to reconfigure well past 144 cycles. No matter how long the delay, as long as it was below the default 8ms timeout of the WDOG, it would successfully reconfigure the WDOG. I observed this behavior with, and without the debugger, just to ensure the debugger did not play any role. I was also able to confirm timing via strobing the reset signal with Oscope. So now my understanding of the reference manual is that you can reconfigure the WDOG once out of reset. And once you perform the first write to the WDOG, you get 128 bus clocks to reconfigure the remaining register fields. For example, lets say I wait 1000 bus clocks out of reset and then configures the WDOG_CS register. I then get 128 bus clocks after configuring the WDOG_CS to configure the WDOG_TOVAL. Once TOVAL is configured, the new configuration takes effect. Is this the correct interpretation of the reference manual? Or is my previous interpretation correct where you get 128 bus clocks out of reset, or the default configuration takes effect? Re: Configure WDOG within 128 Bus Clocks Clarification Hello @sean_dvorscak , Thanks for you post. You may refer to section "30.4.3.2.1 Unlocking the Watchdog" and section "30.5.2 Configure Watchdog" in KE1xFP100M168SF0RM. The correct interpretation appears to be as follows: After reset, the WDOG is enabled and operates with its reset-default settings. The WDOG configuration registers are still available for an initial configuration sequence. Once the watchdog is unlocked , the remaining configuration registers must be written within 128 bus clocks . If UPDATE=0, then after that initial configuration is completed, the WDOG configuration cannot be changed again until the next reset. If UPDATE=1, the WDOG can be unlocked and reconfigured again later, with the same 128 bus clock window applying after each unlock. This interpretation is consistent with your measurements: even when more than 128 bus clocks had elapsed since reset, the WDOG could still be reconfigured successfully, provided this happened before the default watchdog timeout expired. In other words, the 128 bus clock configuration window is associated with the unlock sequence, not simply with the elapsed time since reset release. If no new configuration is completed, the WDOG continues operating with its reset default settings. Hope it helps. BR Celeste ------------------------------------------------------------------------------------------------------------------------ Note: If this post answers your question, please click the "ACCEPT AS SOLUTION" button. Thank you! ------------------------------------------------------------------------------------------------------------------------ Re: Configure WDOG within 128 Bus Clocks Clarification There are certain command sequence need to follow in order to update WATCHDOG setting.I dont know where the 128 bus clocks come from but take the K80 Sub-Family Reference Manual, Rev. 4, 09/2015 for example： As long as ALLOW_UPDATE in the watchdog control register is set, you can unlock and modify the write-once-only control and configuration registers: 1. Write 0xC520 followed by 0xD928 within 20 bus clock cycles to a specific unlock register (WDOG_UNLOCK). 2. Wait one bus clock cycle. You cannot update registers on the bus clock cycle immediately following the write of the unlock sequence. 3. An update window equal in length to the watchdog configuration time (WCT) opens. Within this window, you can update the configuration and control register bits. These register bits can be modified only once after unlocking.If none of the configuration and control registers is updated within the update window,the watchdog issues a reset, that is, interrupt-then-reset, to the system. Trying to unlock the watchdog within the WCT after an initial unlock has no effect. Re: Configure WDOG within 128 Bus Clocks Clarification Thank you for the clarification. Glad to know I have more than 128 bus clocks out of reset to configure WDOG. If they ever make a new revision of KE1xFP100M168SF0RM, I'd like to suggest removing the "... within 128 bus clocks." from the first sentence of section 30.4.3.1. Appreciate the suggestion might be silly, but I only suggest it because I found some misinformation online citing that wording to suggest you only get 128 bus clocks to configure WDOG out of reset. It also unfortunately makes the Google AI overview regurgitate the same misinformation (... gotta love the future 🙂 ). Which is why I had to ask the question here myself. Re: Configure WDOG within 128 Bus Clocks Clarification Understood. Unfortunately, to the best of my knowledge, there is no new roadmap for the Kinetis family. We have recently introduced the MCX family, which you may consider exploring if you’re interested. MCX Arm Cortex-M Industrial and IoT MCUs | NXP Semiconductors

MPX5999D いくつかの用途 このセンサを電子圧力コントローラで使用する場合、電子圧力コントローラの動作原理は、比例弁の開度を調整することによって流量を変化させ、それによって圧力を変化させることである。圧力測定には、圧力センサーを使用します。センサーの読み取り値と設定値を比較することにより、比例弁の開度が調整され、ホストコンピュータによって設定された圧力値が実際の圧力値と一致するようにする。制御対象となる圧力値は、センサが出力する差圧値である。このプロセス全体を通して、ホストコンピュータからの設定値は変更されません。設定値は差圧値であり、制御値もまた差圧値です。P2 = 100 kPaの場合、電子圧力コントローラは正常に動作します。P2が100kPaから80kPaに低下すると、電子圧力コントローラ出力流量はゼロに近づき、設定値よりもはるかに低くなります。これはセンサに起因する問題でしょうか？考えられる解決策は何ですか？ Re: MPX5999D 一些应用问题 こんにちは、ユウウェイです。 制御システムについてのご説明、ありがとうございました。ご説明いただいた内容から判断すると、これはMPX5999Dの故障によるものではありません。センサーは正常に動作しています。 流量の低下は、制御ループの自然な空気圧反応です。基準圧力P2が100kPaから80kPaに低下すると、コントローラは絶対圧力P1を自動的に下げて、まったく同じ差圧設定値を維持する必要があります。この絶対圧力の低下により、ガスの密度と駆動力が低下し、比例弁を通過する流量が自然とほぼゼロまで減少する。 この問題を解決するには、P2ポートを安定した大気圧基準に開放して圧力変動から切り離すか、P2が低下した際に失われるガス密度を補償するためにソフトウェアで差動設定値を動的に増加させるかのどちらかの方法が有効だと思います。 BRs、トーマス 追記：STマイクロエレクトロニクスは、NXPのMEMSセンサ事業の買収を既に完了しています。これらのセンサの製造、サポート、およびドキュメントはすべてST社に完全に移管されました。

How to increase the ECSPI of imx8mmini baud rate to 52Mbps? hi        For the M4 core of i.MX8M Mini, using the ECSPI peripheral with SDMA to read data at a rate of 32 Mbps (the datasheet says the maximum ECSPI rate is 52 Mbps), the example used is "SDK_2.5.0/boards/evkmimx8mm/cmsis_driver_examples/ecspi/sdma_loopback_transfer". However, this example reinitializes both SPI and DMA for each data read, wasting a lot of time. Which functions and statements do not need to be reinitialized in the ECSPI_MasterTransferSDMA function? Also, I have increased the clock frequency, but the issue remains the same.now my code below:   status_t ECSPI_MasterTransferSDMA(ECSPI_Type *base, ecspi_sdma_handle_t *handle, ecspi_transfer_t *xfer) { //    assert(base && handle && xfer);   //    sdma_transfer_config_t xferConfig = {0U}; //    sdma_peripheral_t perType = kSDMA_PeripheralNormal;       /* Check if ECSPI is busy */     if (handle->state == kECSPI_Busy)     {         return kStatus_ECSPI_Busy;     }       /* Check if the input arguments valid */     if (((xfer->txData == NULL) && (xfer->rxData == NULL)) || (xfer->dataSize == 0U))     {         return kStatus_InvalidArgument;     } // if(test_init_flg == 0) {     ECSPI_Enable(base, true); } handle->state = kECSPI_Busy; if(test_init_flg == 0) {       ECSPI_SetChannelSelect(base, xfer->channel); } #if defined(FSL_FEATURE_SOC_SPBA_COUNT) && (FSL_FEATURE_SOC_SPBA_COUNT > 0) if(test_init_flg == 0) {       bool isSpba = SDMA_IsPeripheralInSPBA((uint32_t)base);     /* Judge if the instance is located in SPBA */     if (isSpba)     {         perType = kSDMA_PeripheralNormal_SP;     } } #endif /* FSL_FEATURE_SOC_SPBA_COUNT */ if(test_init_flg == 0) {       /* Prepare transfer. */     SDMA_PrepareTransfer(&xferConfig, (uint32_t)xfer->txData, (uint32_t) & (base->TXDATA), sizeof(uint8_t),                          sizeof(uint8_t), sizeof(uint8_t), xfer->dataSize, handle->txSdmaHandle->eventSource, perType,                          kSDMA_MemoryToPeripheral); }     /* Submit transfer. */     SDMA_SubmitTransfer(handle->txSdmaHandle, &xferConfig);   if(test_init_flg == 0) {     /* Prepare transfer. */     SDMA_PrepareTransfer(&xferConfig2, (uint32_t) & (base->RXDATA), (uint32_t)xfer->rxData, sizeof(uint8_t),                          sizeof(uint8_t), sizeof(uint8_t), xfer->dataSize, handle->rxSdmaHandle->eventSource, perType,                          kSDMA_PeripheralToMemory); }     /* Submit transfer. */     SDMA_SubmitTransfer(handle->rxSdmaHandle, &xferConfig2);     /* Start Rx transfer */     handle->rxInProgress = true;     SDMA_StartTransfer(handle->rxSdmaHandle);     ECSPI_EnableDMA(base, kECSPI_RxDmaEnable, true);       /* Start Tx transfer */     handle->txInProgress = true;     SDMA_StartTransfer(handle->txSdmaHandle);     ECSPI_EnableDMA(base, kECSPI_TxDmaEnable, true); test_init_flg=1;       return kStatus_Success; } void main(void) { ... while(1) {       DRIVER_MASTER_SPI.Transfer(masterTxData, masterRxData, TRANSFER_SIZE);//call ECSPI_MasterTransferSDMA       /* Wait slave received all data. */     while (!isTransferCompleted)     {     }     ... } }   回复： How to increase the ECSPI of imx8mmini baud rate to 52Mbps? attach source code Re: How to increase the ECSPI of imx8mmini baud rate to 52Mbps? Hello @sofia_0571  Hope you are doing very well. You can try instead of bypassing the setup using a flag inside the function, keep ECSPI_MasterTransferSDMA purely for your high-speed loop by stripping out the heavy lifting. Create a "Fast Trigger" function that assumes preparation is already complete. Something like: status_t ECSPI_MasterTransferSDMA_FastTrigger(ECSPI_Type *base, ecspi_sdma_handle_t *handle, uint32_t size) { handle->state = kECSPI_Busy; xferConfig.dataSize = size; xferConfig2.dataSize = size; SDMA_SubmitTransfer(handle->txSdmaHandle, &xferConfig); SDMA_SubmitTransfer(handle->rxSdmaHandle, &xferConfig2); handle->rxInProgress = true; SDMA_StartTransfer(handle->rxSdmaHandle); ECSPI_EnableDMA(base, kECSPI_RxDmaEnable, true); handle->txInProgress = true; SDMA_StartTransfer(handle->txSdmaHandle); ECSPI_EnableDMA(base, kECSPI_TxDmaEnable, true); return kStatus_Success; } Best regards, Salas.

i.MX8ULPでのSPI NANDブート こんにちは、 i.MX8ULPのSPI NANDからブートしようとしています。 evkにはSPI NORが搭載されており、そこから起動することはできましたが、当社のボード上のNANDで試したところ、うまくいきませんでした。BT*_CFG*ピンを設定したところ、ブートROMがNANDを読み取ろうとしていることは確認できましたが、M33コアもA35コアも起動しないようなので、ブートイメージが正しくないのではないかと考えています。 imx-mkimage flash_singleboot_m33_flexspiターゲットを使用してイメージを構築していますが、このターゲットはヘッダーブロックとしてfspi_headerファイルを使用します。しかし、このファイル内のコメントを見ると、これはシリアルNOR用でありNAND用ではないようですので、このflexspi構成ブロックヘッダーについて調べています。 ターゲットに適したヘッダーファイルを作成するにはどうすればよいでしょうか？ kobs-ngを見つけたのですが、8ulp向けには設計されていないようです（GPMI NANDコントローラーがなく、軽くパッチを適用しても動作しません）。 8ulpのドキュメントにも、FCFBブロックに関するドキュメントは見当たりませんでした。i.MX 8M Mini Applications Processorのリファレンスマニュアル（およびu-boot mkimageにそれに関するオプションを追加するu-bootパッチ）でそれに関するドキュメントを見つけましたが、たとえそれが本当に同じフォーマットだとしても、i.MX8ULPでそれを使用する方法（特にどのLUTテーブルを使用するか）を教えていただけると助かります。 ありがとうございました。 ドミニク・マルティネ Re: SPI NAND boot on i.MX8ULP メッセージを見逃してしまい申し訳ありません。そちらの8ULPとSPI-NANDの回路図の一部を共有していただけますか？また、エラーログ全体も共有していただけますか？ Re: SPI NAND boot on i.MX8ULP ご回答ありがとうございます。 ボードはSDカードから正常に起動するため、SoC/メモリに明らかな問題はありません（BT*_CFG*からの切り替え）。 BT CFGの正確なピンと使用されているピンについては後ほど投稿しますが、SPI転送を見ると起動時にNANDが読み取られていることがはっきりと確認できるので、この部分は恐らく正しいと思われます。まずはfspi_headerを確認したいと思います。 昨日さらに調べてみたところ、SPSDKのnxpimageにこのためのコマンドがあることが分かりましたが、8ulpのnorフラッシュしかサポートしていないようです。そのため、依然として様々なパラメータを手動で試すしかなく、デバイス上で実行できるkobsのようなドキュメントやツールがあればありがたいです。 ありがとう Re: SPI NAND boot on i.MX8ULP 遅れてごめんなさい。 参考までに、ボードの構成は以下のとおりです。 - ブートヒューズをクリアしました（受領時の初期状態）。 - QSPI NANDは以下のように接続されます。 PTD12（FLEXSPI2_A_SS0_b） /CS PTD13（FLEXSPI2_A_SCLK） CLK PTD14（FLEXSPI2_A_DATA3） /HOLD(IO3) PTD15（FLEXSPI2_A_DATA2） /WP(IO2) PTD16（FLEXSPI2_A_DATA1） DO(IO1) PTD17（FLEXSPI2_A_DATA0） DI(IO0) - ブートピンは以下のとおり BOOT_MODE0が開いている（0）、BOOT_MODE1がプルアップされている（1）＝ピンからブートする BT0_CFG0がプルダウンされました（低電力ブートなし） BT0_CFG1 がダウンロードされました (デュアルブート M33/A35 "eMMC から"...) BT0_CFG2は無視されました BT0_CFG3がプルダウンされ、CFG4がプルアップされました（m33ブートインターフェース。デュアルブートでは無視すべきでしょうか？）。 BT0_CFG5は無視されました BT0_CFG6/7は両方ともプルダウンされています（24MHz外部OSC）。 BT0_CFG[8-11]は無視されました BT0_CFG12/13 はフローティング、CFG14 はプルダウンされています (「flexspi デバイスタイプ」が m33 とは独立したブート設定なのか、両方に影響するのかは不明です。念のため、011 (4B READ(0x13) でフラッシュ、これは当社の NAND がサポートしているもの) に設定してみましたが、目に見える違いはありませんでした)。 BT0_CFG15は無視されました BT1_CFG[0-3]は無視されました BT1_CFG4 がダウンロードされました (eMMC 高速ブートが無効になっています) BT1_CFG5 プルダウン (速度は通常) BT1_CFG6/7 がプルダウンされました (バス幅 4) BT1_CFG8は無視されました BT1_CFG9が起動しました（SDカードブート、SPIブートモードでは無視してください） BT1_CFG10/11/12はそれぞれ下落/上昇/下落しました（USDHC2も同様に無視してください）。 BT1_CFG13/14はそれぞれプルアップ/プルダウンされます（SPI NAND）。 BT1_CFG15 がプルダウンされました (SD ブートへのリカバリ) 他に確認すべき点があれば教えてください。そうでなければ、フラッシュブート設定ブロックに関するドキュメントに引き続き興味があります。 よろしくお願い申し上げます。 Re: SPI NAND boot on i.MX8ULP SPI NANDとブートモードに関するハードウェア設計はどうでしょうか？ボードには、eMMCやSDカードなど、他のフラッシュメモリが搭載されていますか？はいの場合、システムが起動できるかどうか試してみていただけますか？ Re: SPI NAND boot on i.MX8ULP こんにちは、 @Rita_Wang お返事ありがとうございます。私はミゾ族で、martinetdの同僚です。 現在、私たちが具体的に知りたいのは、SPI NAND用のブートイメージファイルを作成する方法です。 リファレンス・マニュアルには、FlexSPI2にコネクテッドされたSPI NANDからのブートがサポートされていると記載されています。しかしながら、イメージファイルヘッダーに必要な正確なフォーマットが不明なため、現時点ではブートイメージを作成することができません。 NXPは既に内部的にSPI NANDからi.MX8ULPの起動に成功していると想定します。画像ファイルのヘッダー形式を共有していただくか、このヘッダーを生成するために使用したソフトウェア／ツールをご提供いただければ大変ありがたいです。 ご支援ありがとうございます。 Re: SPI NAND boot on i.MX8ULP こんにちは、 @Rita_Wang さん。 何か進展はありましたか？この件で行き詰まっており、どんなご支援でも大変ありがたく思います。 よろしくお願いします！ Re: SPI NAND boot on i.MX8ULP 私はGolden Shiny Oscilloscope ™にアクセスし、その構成で起動すると、チップがNANDの最初の部分を正常に読み取ることを確認しました（ブロック0に対して0x13の読み取りを発行し、NANDがビジー状態でなくなるまでステータスレジスタをポーリングし、その後少なくとも2KBのデータを読み取ります。特に、読み取られたデータは、1KBのゼロとFCFBヘッダーが続くimx-bootイメージの開始部分と一致することを確認しました）。 この時点ではそれ以上何も起こりません。スコープの扱いに慣れていないため、後でさらにデータが読み込まれたかどうかは判断できませんが、読み取りが停止したようです。そのため、私が書いた fspi_header が正しいかどうかを確認したいです (シリアル NOR の 0x01 の代わりにシリアル NAND の 0x02 を入力し、SFlashA1Size、ページ サイズ、セクタ サイズ、ブロック サイズも入力しましたが、それ以外は imx-mkimage リポジトリにあったものをそのまま残しました)。 NAND用の有効なFSPIヘッダーの書き方について、何かヒントをいただけるとありがたいです。 ありがとう Re: SPI NAND boot on i.MX8ULP こんにちは、 @Rita_Wang さん。 この件に関する最新情報はありますか？ i.MX 8ULPでSPI NANDからのブートがサポートされていない場合、できるだけ早く代替方法の調査を開始する必要があります。このSoCでSPI NANDブートが実際に可能かどうか、少なくとも確認していただけますか？ uboot-imxのソースコードにあるarch/arm/mach-imx/cmd_nandbcb.cを確認したところ、imx8mn、imx8qx/qmなどがサポートされていることがわかりました。このことから、SPI NANDブートは可能であると推測される。 また、i.MX 8ULPと全く同じSPI NANDブート仕様を持つi.MXシリーズのプロセッサが他に存在する場合、それらを参考にさせていただきたいので、どの製品か教えていただけますでしょうか？ ご支援いただき、改めて感謝申し上げます。 Re: SPI NAND boot on i.MX8ULP 私も試してみます。完了したらまたご連絡します。

RK055MHD091A0-CTG (HX8394-F) Display Initialization with STM32H747XG over MIPI-DSI. Hello NXP support team, We are using an STM32H747XG MCU with the RK055MHD091A0-CTG display module, which uses the HX8394-F TFT driver IC and a MIPI-DSI interface. Our current display initialization sequence is: Configure the LTDC parameters. Configure the DSI Host parameters. Send the HX8394-F initialization commands using HAL_DSI_LongWrite() and HAL_DSI_ShortWrite(). Start the DSI interface using HAL_DSI_Start(). We would like to confirm whether this is the correct initialization sequence for the HX8394-F when operating in MIPI-DSI Video Mode. Additionally, is sending the initialization commands through HAL_DSI_LongWrite() and HAL_DSI_ShortWrite() the recommended method for configuring the HX8394-F, or are there any additional steps required for this driver IC? Currently, after initialization: The display backlight turns on successfully. No image is displayed on the screen. No colour output is visible (for example, a solid-colour background configured in the application is not shown). Could you please advise whether there are any additional display configuration requirements, such as: HX8394-F specific initialization commands. DSI Video Mode settings. LTDC timing configuration. Pixel format configuration. Any other panel-specific settings required for the RK055MHD091A0-CTG display. We would appreciate any guidance, reference code, application notes, or example projects related to the HX8394-F display driver. Thank you for your support. Best regards, Shivani. Re: RK055MHD091A0-CTG (HX8394-F) Display Initialization with STM32H747XG over MIPI-DSI. Hi @EdwinHz , Thank you for your response and for sharing the RT1170-EVKB SDK reference. We have reviewed the HX8394F initialization sequence provided in the RT1170-EVKB software package. We observed that the HX8394F initialization commands are transmitted through the MIPI DSI interface using DSI Generic Write commands. We would like to clarify the following points: Is MIPI DSI Generic Write the only supported/recommended method to initialize the HX8394F Driver IC, or is there any alternative interface or initialization mechanism available for this display controller? Currently, our objective is only to enable the display through the MIPI DSI Host interface. We are not planning to use the touch panel and would like to confirm whether the display can be fully initialized and operated without configuring the GT911 touch controller. The RK055MHD091A0-CTG display module includes the GT911 Capacitive Touch Panel (CTP) Controller. Could you please confirm whether initialization and configuration of the GT911 is mandatory for the display to operate? Can the display panel and HX8394F Driver IC be fully initialized and operated using only the MIPI DSI interface, without configuring or communicating with the GT911 touch controller? We would appreciate your confirmation on the above points so that we can focus on the display bring-up and MIPI DSI communication. Thank you for your support. Best Regards, Shiavani e. Re: RK055MHD091A0-CTG (HX8394-F) Display Initialization with STM32H747XG over MIPI-DSI. Hi @Shivani_Elavena, It seems that you are using STM32 HAL API, which is not developed by NXP and therefore I'm not familiar with and wouldn't be able to provide suggestions on whether the initialization sequence is correct or not. We provide drivers and support for initializing and using the RK055MHD091A0-CTG with our SDK packages on our MCUs, so I would recommend downloading the SDK for the RT1170-EVKB here (Select Board | MCUXpresso SDK Builder) to get a better look on how we officially set up and use the RK055MHD091A0-CTG, and this way you can find the corresponding APIs on the HAL for your MCU. BR, Edwin.

U4N：レアなイベントカーコレクションを収録したForza Horizon 6アカウント 『フォルツァ ホライゾン 6』では、東京のネオン輝く街並みと日本の山岳峠が正式にオープンしました。しかし、このシリーズのベテランなら誰でも知っているように、本当の勝負はアスファルトの上だけで行われるのではなく、ガレージで行われるのだ。 2026年5月19日にゲームが店頭やデジタルストアで発売されると、プレイヤーはすでにこのシリーズの特徴である、お馴染みの、そして疲れる壁、つまりFOMO（取り残されることへの恐怖）に真っ向からぶつかっている。季節限定の報酬車、レアなフェスティバルプレイリストのアンロック、そして2000万クレジット以上もするハイパーカーといった要素は、すでにゲームを第二の仕事のように真剣に取り組む時間のあるプレイヤーと、ただ運転を楽しみたいだけのプレイヤーとにコミュニティを二分している。 まさにこれが、プリロード済みで改造済みのForza Horizon 6アカウントの人気が爆発的に高まった理由です。プレイヤーは週40時間もひたすらプレイする代わりに、エンドゲームに直行できる専用プラットフォームを利用するようになっている。 グリッドの現実：FH6で資本が王様である理由 Forza Horizon 6には、550台を超える膨大な数の車が基本収録されています。これらの車両の大部分は、ゲーム内の標準クレジットを使用してオートショーから直接購入できますが、伝説的なJDMアイコン、希少な納屋で見つかった車両、期間限定イベント限定車両など、最も魅力的な車両は、厳しい進行の壁の向こう側にロックされています。 競争力のある完全なコレクションをゼロから構築するために必要な実際の計算を詳しく見ていきましょう。 クレジット不足：標準的なハイエンドハイパーカーを購入し、競争力のあるチューニングアップグレードに資金を提供するには、数億クレジットが必要です。最高級のカスタムを1台作成するだけでも、ベース車両、エンジン交換、駆動系チューニングなどを合わせると、簡単に200万～500万クレジットを消費してしまう。 プレイリストの落とし穴：毎週のフェスティバルプレイリストを1つ見逃すと、限定の季節限定車を入手できなくなる。その期間が終了すると、それらの車は通常の販売ルートから姿を消し、オークションハウスで探すしかなくなります。 オークションハウスのインフレ：期間限定イベントによって供給量が人為的に制限されているため、希少な車はオークションハウスで瞬時に最大価格の20,000,000クレジットに達します。莫大な資金力がないなら、完全に価格的に手が届かない。 事例研究：正規の努力と改造アカウントのコスト比較 例えば、Forza Horizon 6に週におよそ8時間を費やすことができる典型的なプレイヤー「アレックス」を考えてみましょう。 アレックスは、最高級の2000万クレジットの車を5台（合計1億クレジット）購入するのに十分なクレジットを稼ぐために、時間当たりのクレジット獲得効率を最適化する必要がある。平均的に、非常に効率的なレースプレイでは、1時間あたり約20万～30万クレジットを獲得できます（ラッキーなホイールスピンを除く）。 グラインド計算：1億クレジット ÷ 25万クレジット/時間 = 400時間の純粋で反復的なレース。 アレックスにとって、それは50週間、つまりほぼ1年間、カジュアルゲームをプレイしてようやく5種類の特定の車両をアンロックできたことを意味する。しかも、これにはプレイヤーハウスの購入費用や、レジェンドアイランドへのアクセス権を得るための憧れのゴールドリストバンドの入手費用は含まれていません。 では、別の選択肢を見てみましょう。U4Nのような専門的なマーケットプレイスでは、プレイヤーはこのタイムラインを完全に無視している。ドライバーは、1年間の自由時間を数個のデジタルキーと交換する代わりに、最大9億9900万クレジット、数百回のスーパーホイールスピン、そして550台以上の基本車両すべてと期間限定イベント限定車両を含む厳選されたガレージがプリロードされた、完全に新規の未所有アカウントを取得できます。 苦労を安全に回避する方法 導入部分の無駄な説明を飛ばして、最高のパフォーマンスを発揮するマルチプレイヤーや複雑なチューニングに直接取り組みたいプレイヤーにとって、そのプロセスは驚くほど簡素化されました。複雑なサードパーティ製ソフトウェアを理解したり、ゲーム機やPCのファイルを破損させるリスクを冒したりする必要はもうありません。 何百時間にも及ぶ単調なファーミング作業を省きたいなら、U4Nのような信頼できるプラットフォームを利用してFH6のMODを購入したり、Xbox Series X|S、PC、Steam間でクロスセーブに対応した、完全に強化されたアカウントを入手したりすることができます。 これらのアカウントを検討する際には、以下の条件を満たすパッケージをターゲットにするのが賢明です。 クレジットプールを最大まで維持する：残高を9億9900万の上限付近に維持することで、将来配信されるDLCや拡張パックの車がリリースされた瞬間に購入できるようになります。 スーパーホイールスピンをストックしておく：マップイベントをクリアしなくても、レアなコスメティックアイテム、ホーン、追加のキャッシュフローを獲得するために不可欠です。 履歴をクリーンに保つ：アカウントに以前の所有者がいないこと、および競合するマッチングによるペナルティがないことを確認することで、オンラインプロフィールを安全に保つことができます。 究極的に言えば、『Forza Horizon 6』は、カーカルチャー、探検、そして山道で最高のチューニングを追求するスリルを称えるために作られたゲームだ。現代のゲーマーにとって、オークションハウスで人工的な希少性と戦うために何百時間も費やすのは、初日からサンドボックスのすべてをアンロックできるのに、全く意味がない。

在 i.mx8ULP 上启动 SPI 与非 你好 我正在尝试从 i.MX8ULP 上的 SPI 与非 启动。 evk 连接了 SPI 或非，我可以从中启动，但是在我们的主板上尝试使用 与非 时我无法让它起作用。我已经配置了 BT*_CFG* 引脚，我看到启动 ROM 尝试读取与非，但是 M33 和 A35 内核似乎都无法启动，所以我认为启动映像不正确。 我正在使用 imx-mkimage flash_singleboot_m33_flexspi 目标构建映像，它使用 fspi_header 文件作为头块，但是这个文件中的注释似乎表明这是针对串行 或非 而不是 与非 的，所以我正在研究这个 flexspi 配置块标头。 如何为我们的目标制作合适的头文件？ 我找到了 kobs-ng 但它似乎不适合 8ulp（没有 GPMI 与非 控制器，无论如何即使在轻微打补丁之后也无法运行） 我在 8ulp 文档中也找不到任何关于 FCFB 块的文档。我在 i.MX 8M 迷你应用处理器参考手册（以及在 u-boot mkimage 中添加了相关选项的 u-boot 补丁）中找到了一些关于它的文档，但即使它的格式确实相同，那么如何将其用于 i.MX8ULP（尤其是要使用哪个 LUT 表）也将不胜感激。 谢谢！ 多米尼克-马蒂内 Re: SPI NAND boot on i.MX8ULP 谢谢您的回答。 主板成功从 SD 卡启动，因此 soc/内存（从 BT*_CFG* 切换）没有明显的问题，稍后 我会发布确切的 BT CFG 引脚和引脚，但我们可以清楚地观察到 SPI 传输时正在读取与非，所以我认为这部分可能是正确的，想先检查 fspi_header。 昨天再看我发现 SPSDK 的 nxpimage 有这方面的命令，但它似乎只支持 8ulp 不支持 Flash，所以我仍然无法手动尝试各种参数，一些文档/工具（比如 kobs）可以在设备上运行将不胜感激谢谢 Re: SPI NAND boot on i.MX8ULP 很抱歉错过了你的留言，你能在这里分享一下你身边关于 8ULP 和 SPI-与非 的构思部分吗？也请与我们分享您的失败日志？ Re: SPI NAND boot on i.MX8ULP 抱歉耽搁了。 供参考，以下是主板的配置方式： -启动熔丝已清除（初始状态为已接收） -QSPI 与非 连接方式如下 PTD12(FLEXSPI2_A_SS0_b） /CS ptd13（flexspi2_a_sclk） CLK ptd14（flexspi2_a_data3） /保持（IO3） ptd15（flexspi2_a_data2） /WP（IO2） ptd16（flexspi2_a_data1） 操作（IO1） ptd17（flexspi2_a_data0） DI(IO0) -启动引脚如下所示 BOOT_MODE0 打开 (0)，BOOT_MODE1 向上拉出 (1) = 从引脚启动 BT0_CFG0 已下拉（无法启动低功耗） BT0_CFG1 下线（来自 eMMC " 的双启动 M33/A35 "...） BT0_CFG2 被忽略 BT0_CFG3 下拉/CFG4 拉起（m33 启动界面，双启动时应该忽略吗？） BT0_CFG5 被忽略 BT0_CFG6/7 均被拉低（24MHz 外部 OSC） BT0_CFG[8-11] 被忽略 BT0_CFG12/13 浮空，CFG14 向下拉（我不清楚 " flexspi 设备类型 " 是指独立启动设置还是两者兼而有之，以防万一我尝试将其设置为 011（带有 4B 读取 (0x13) 的闪存，这是我们的 与非 支持的），没有明显的区别） BT0_CFG15 被忽略 BT1_CFG[0-3] 被忽略 BT1_CFG4 已下拉（禁用 eMMC 快速启动） BT1_CFG5 下拉（速度正常） BT1_CFG6/7 已下拉（总线宽度 4） BT1_CFG8 被忽略 BT1_CFG9 已启动（SD 启动，在 spi 启动模式下应忽略） BT1_CFG10/11/12 分别下拉/上拉/下拉（USDHC2，同样应忽略） BT1_CFG13/14 分别向上/向下拉动（SPI 与非） BT1_CFG15 已下线（恢复到 SD 启动） 如果你能想到其他要检查的内容，请告诉我，否则我仍然对有关闪存启动配置块的文档感兴趣。 谢谢 Re: SPI NAND boot on i.MX8ULP 你为SPI 与非和启动模式设计的硬件怎么样？你的主板上还有其他闪存吗，比如 emmc 或 SD 卡？如果是，你可以试试看系统能否启动？ Re: SPI NAND boot on i.MX8ULP 你好，@Rita_Wang 谢谢您的答复。我是 mizo，是 martinetd 的同事。 目前，我们特别需要知道的是如何为SPI NAND创建启动映像文件。 参考手册指出，支持从连接到 FlexSPI2 的 SPI NAND 启动。但是，我们目前无法创建启动映像，因为我们不知道映像文件头所需的确切格式。 我们假设恩智浦已经成功地从内部的SPI 与非启动了i.MX8ULP。如果您能与我们分享图像文件页眉格式或提供用于生成该页眉的软件/工具，我们将不胜感激。 提前感谢您的支持。 Re: SPI NAND boot on i.MX8ULP 我可以访问 Golden Shiny Oscilloscope™ 并且可以确认，在以这种配置启动时，芯片成功读取了 NAND 的第一部分（它对方块 0 发出读取 0x13 的读取，轮询状态寄存器直到 NAND 不再忙碌，然后读取至少 2KB 的数据 —— 特别是我已经确认读取的数据与 imx-boot 映像的开头相匹配，其次是 1KB FCFB 标题） 此时没有发生任何其他事情，我对范围还不够好，无法分辨稍后是否读取了更多数据，但看起来好像停止了阅读，所以我很想检查一下我写的 fspi_header 是否有意义（我填写了 0x02 表示串行 NAND 而不是串行或非的 0x01，还有 SFlashA1Size、页面大小、扇区大小和区块大小，但其余部分与 imx-mkimage 仓库中的位置保持不变） 如果能提供任何关于如何为 NAND 编写有效的 fspi 标头的指示，我将不胜感激。 谢谢 Re: SPI NAND boot on i.MX8ULP 你好@Rita_Wang 有新进展吗？我们在这个问题上受阻，如果能得到任何帮助，我们将不胜感激。 谢谢您！ Re: SPI NAND boot on i.MX8ULP 你好@Rita_Wang 关于这个问题有什么最新进展吗？ 如果i.MX 8ULP不支持从SPI NAND启动，我们需要尽快开始研究替代方法。你能否至少确认一下在这个 SoC 上是否真的可以启动 SPI 与非？ 我在 uboot-imx 源代码中查看了 arch/arm/mach-imx/cmd_nandbcb.c，我可以看到支持 imx8mn、imx8qx/qm 等。基于此，我认为 SPI NAND 启动应该是可能的。 此外，如果还有其他i.MX系列处理器的SPI 与非启动规格与i.MX 8ULP完全相同，您能否告诉我们它们是哪些，以便我们将其用作参考？ 再次感谢您的支持。 Re: SPI NAND boot on i.MX8ULP 我这边正在尝试，完成后会向您汇报。

128バスクロック内でのWDOGの設定に関する説明 リファレンスマニュアルの理解に基づくと、以下の点に関してWDOGの予期せぬ動作が発生しています。 「すべてのウォッチドッグ制御ビット、タイムアウト値、およびウィンドウ値は、一度書き込んだ後 128バスクロック以内にリセットします。これは、書き込みが行われた後、 リセットが発生しない限り変更されない。」 私の最初の解釈では、リセット後最初の128バスクロック以内にWDOGを設定する必要があり、そうしないとUPDATE=0のデフォルト設定が使用されるということです。これにより、WDOGを再度再構成することができなくなります。 しかし、私はそれとは異なる経験をしています。KE1がリセットから復帰すると、バスクロックとコアクロックが同じ周波数で動作するため、WDOGを再構成する際にIARデバッガのCYCLECOUNTERを確認することにしました。そうすれば、リセットからどれだけのバスクロックが経過したかが分かると思ったからです。リセット解除後、144サイクルが経過したことが示された。そこで、関数の開始時に遅延ループをどんどん長くしていき、144サイクルをはるかに超えても再構成が可能かどうかを確認することにしました。 遅延時間がどれほど長くても、WDOGのデフォルトのタイムアウトである8ms以内であれば、WDOGの再構成は正常に完了する。デバッガーが何らかの役割を果たしていないことを確認するため、デバッガーを使用した場合と使用しない場合の両方でこの動作を観察しました。オシロスコープを使ってリセット信号をストロボ照射することで、タイミングを確認することもできました。 つまり、リファレンスマニュアルを読んだ限りでは、リセット状態から復帰した後はWDOGを再構成できるということだ。そして、WDOGへの最初の書き込みを実行すると、残りのレジスタフィールドを再構成するために128個のバスクロックが利用可能になります。 例えば、リセットから1000バスクロック待ってからWDOG_CSレジスタを設定するとします。WDOG_CSを設定してWDOG_TOVALを設定した後、128個のバスクロックを取得します。TOVALが設定されると、新しい設定が有効になります。 これはリファレンス・マニュアルの正しい解釈でしょうか？それとも、リセット後に128個のバスクロックが取得される、あるいはデフォルト設定が有効になるという私の以前の解釈が正しいのでしょうか？ Re: Configure WDOG within 128 Bus Clocks Clarification こんにちは、 @sean_dvorscak さん、 投稿ありがとうございます。 KE1xFP100M168SF0RM の「 30.4.3.2.1 ウォッチドッグのロック解除」および「 30.5.2 ウォッチドッグの設定」のセクションを参照してください。 正しい解釈は以下のとおりと思われる。 リセット後、WDOGは有効化され、リセット時のデフォルト設定で動作します。 WDOG構成レジスタは、初期構成シーケンスのために引き続き利用可能です。 監視犬が ロック解除済み 残りの構成レジスタは、 バス用時計128個 。 UPDATE=0の場合、初期設定が完了した後は、次のリセットまでWDOGの設定を再度変更することはできません。 UPDATE=1の場合、WDOGは後でロック解除して再構成することができ、ロック解除のたびに同じ128バスクロックウィンドウが適用されます。 この解釈はあなたの測定結果と一致しています。リセットから128バスクロック以上経過した場合でも、デフォルトのウォッチドッグタイムアウトが期限切れになる前に再構成が行われれば、WDOGは正常に再構成される可能性があります。 つまり、128バスクロックの設定ウィンドウは、リセット解除からの経過時間だけでなく、ロック解除シーケンスにも関連付けられている。 新しい設定が完了しない場合、WDOGはリセットされたデフォルト設定で動作を継続します。 お役に立てば幸いです。 BR セレステ ------------------------------------------------------------------------------------------------------------------------ 注：この投稿があなたの質問への回答になっている場合は、「解決策として承認」ボタンをクリックしてください。ありがとう！ ------------------------------------------------------------------------------------------------------------------------ Re: Configure WDOG within 128 Bus Clocks Clarification ウォッチドッグ設定を更新するには、特定のコマンドシーケンスに従う必要があります。128バスクロックがどこから来たのかはわかりませんが、例えばK80サブファミリリファレンス・マニュアル、改訂版4、2015年9月を参照してください。 ウォッチドッグ制御レジスタのALLOW_UPDATEが設定されている限り、一度だけ書き込み可能な制御レジスタと構成レジスタのロックを解除して変更できます。 1. 20バスクロックサイクル以内に、特定のロック解除レジスタ（WDOG_UNLOCK）に0xC520に続いて0xD928を書き込みます。 2. バスのクロックサイクルを1回待つ。ロック解除シーケンスの書き込み直後のバスクロックサイクルでは、レジスタを更新することはできません。 3.ウォッチドッグ構成時間（WCT）と同じ長さの更新ウィンドウが開きます。このウィンドウ内で、設定レジスタと制御レジスタのビットを更新できます。 これらのレジスタビットは、ロック解除後に一度だけ変更できます。更新ウィンドウ内に構成レジスタと制御レジスタのいずれも更新されない場合、ウォッチドッグはシステムにリセット、つまり割り込み後にリセットを発行します。初回ロック解除後にWCT内のウォッチドッグを再度ロック解除しようとしても効果はありません。 Re: Configure WDOG within 128 Bus Clocks Clarification ご説明いただきありがとうございます。 WDOGを設定するために、リセットされていないバスクロックが128個以上あることが分かって安心しました。 もしKE1xFP100M168SF0RMの新しい改訂版が作られるなら、「...128バスクロック以内」という部分を削除することを提案したいと思います。セクション30.4.3.1の最初の文から。 この提案は馬鹿げているかもしれませんが、リセットからWDOGを設定するために利用できるバスクロックは128個しかないという誤った情報がオンラインで見つかったため、あえて提案しました。残念ながら、Google AIの概要にも同じ誤情報が繰り返されてしまう（…FUTUREって素晴らしいよね）。 🙂 )だからこそ、私自身がここでこの質問をせざるを得なかったのです。 Re: Configure WDOG within 128 Bus Clocks Clarification 理解した。残念ながら、私の知る限りでは、Kinetisファミリ向けの新しいロードマップは存在しません。この度、MCXファミリを発表いたしました。ご興味がおありでしたら、ぜひご検討ください。MCX Arm Cortex-M インダストリアル＆IoT MCUs | NXP Semiconductors

RK055MHD091A0-CTG (HX8394-F) による MIPI-DSI を介した STM32H747XG のディスプレイ初期化。 NXPサポートチームの皆様、こんにちは。 当社では、STM32H747XG MCUとRK055MHD091A0-CTGディスプレイモジュールを使用しています。このモジュールは、HX8394-F TFTドライバICとMIPI-DSIインターフェースを採用しています。 現在のディスプレイ初期化シーケンスは以下のとおりです。 LTDCのパラメータを設定します。 DSIホストのパラメータを設定します。 HAL_DSI_LongWrite()とHAL_DSI_ShortWrite()を使用して、HX8394-Fの初期化コマンドを送信します。 HAL_DSI_Start()を使用してDSIインターフェースを開始します。 HX8394-FをMIPI-DSIビデオモードで動作させる場合、これが正しい初期化シーケンスであるかどうかを確認したいと思います。 さらに、HAL_DSI_LongWrite() と HAL_DSI_ShortWrite() を介して初期化コマンドを送信する方法は、HX8394-F を構成するための推奨される方法でしょうか、それともこのドライバ IC には他に何か必要な手順がありますか？ 現在、初期化後： ディスプレイのバックライトが正常に点灯しました。 画面に画像が表示されません。 カラー出力は表示されません（例えば、アプリケーションで設定された単色の背景は表示されません）。 ディスプレイの設定に関して、以下のような追加の要件があるかどうか教えていただけますでしょうか？ HX8394-F固有の初期化コマンド。 DSIビデオモードの設定。 LTDCタイミング設定。 ピクセルフォーマットの設定。 RK055MHD091A0-CTGディスプレイに必要なその他のパネル固有の設定。 HX8394-Fディスプレイドライバに関するガイダンス、リファレンスコード、アプリケーションノート、またはサンプルプロジェクトなどをご提供いただければ幸いです。 再開まで今しばらくお待ちください。 よろしくお願いいたします。 シヴァニ。 Re: RK055MHD091A0-CTG (HX8394-F) Display Initialization with STM32H747XG over MIPI-DSI. こんにちは、 @EdwinHz さん。 ご回答いただき、またRT1170-EVKB SDKのリファレンスを共有していただき、ありがとうございます。 RT1170-EVKBソフトウェアパッケージに付属のHX8394F初期化シーケンスを確認しました。HX8394Fの初期化コマンドは、DSI汎用書き込みコマンドを使用してMIPI DSIインターフェースを介して送信されることが確認されました。 以下の点について明確にしておきたいと思います。 HX8394FドライバICを初期化するための唯一のサポート/推奨方法はMIPI DSI Generic Writeですか？それとも、このディスプレイコントローラには他に利用可能なインターフェースや初期化メカニズムはありますか？ 現時点での私たちの目標は、MIPI DSIホストインターフェースを介してディスプレイを有効化することのみです。弊社ではタッチパネルを使用する予定はありませんので、GT911タッチコントローラーの設定を行わなくても、ディスプレイを完全に初期化して操作できるかどうかを確認したいと考えています。 RK055MHD091A0-CTGディスプレイモジュールには、GT911静電容量式タッチパネル（CTP）コントローラが内蔵されています。ディスプレイを動作させるには、GT911の初期化と設定が必須かどうか確認していただけますか？ ディスプレイパネルとHX8394FドライバICは、GT911タッチコントローラの設定や通信を行わずに、MIPI DSIインターフェースのみを使用して完全に初期化および動作させることは可能ですか？ 上記点についてご確認いただければ幸いです。確認が取れ次第、ディスプレイの起動とMIPI DSI通信に集中して取り組むことができます。 再開まで今しばらくお待ちください。 よろしくお願いいたします。 シアヴァニ e. Re: RK055MHD091A0-CTG (HX8394-F) Display Initialization with STM32H747XG over MIPI-DSI. こんにちは、 @Shivani_Elavena さん。 どうやらあなたはSTM32 HAL APIを使用しているようですが、これはNXPが開発したものではないため、私はそれについて詳しくなく、初期化シーケンスが正しいかどうかについて助言することはできません。 弊社では、弊社のSDKパッケージを使用してRK055MHD091A0-CTGを初期化および使用するためのドライバとサポートをMCU上で提供しています。そのため、こちらからRT1170-EVKB用のSDKをダウンロードすることをお勧めします（ボードを選択 | MCUXpresso SDK Builder ）。これにより、弊社がRK055MHD091A0-CTGを公式にどのようにセットアップして使用するかをより詳しく確認でき、MCUのHAL上で対応するAPIを見つけることができます。 BR、 エドウィン。

imx8mminiのECSPIボーレートを52Mbpsに上げるにはどうすればよいですか？ こんにちは i.MX8M Mini の M4 コアの場合、ECSPI ペリフェラルと SDMA を使用して 32 Mbps の速度でデータを読み取る場合 (データシートでは ECSPI の最大速度は 52 Mbps と記載されています)、使用されているサンプルは「 SDK_2.5.0/boards/evkmimx8mm/cmsis_driver_examples/ecspi/sdma_loopback_transfer」です。しかし、このサンプルではデータ読み取りごとに SPI と DMA の両方を再初期化するため、多くの時間が無駄になります。ECSPI_MasterTransferSDMA 関数で再初期化する必要のない関数とステートメントはどれですか? また、クロック周波数を上げましたが、問題は解決しません。以下に私のコードを示します。   status_t ECSPI_MasterTransferSDMA(ECSPI_Type *base, ecspi_sdma_handle_t *handle, ecspi_transfer_t *xfer) { // assert(base && handle && xfer);   // sdma_transfer_config_t xferConfig = {0U}; // sdma_peripheral_t perType = kSDMA_PeripheralNormal;   /* ECSPIがビジー状態かどうかを確認する */ if (handle->state == kECSPI_Busy)     { return kStatus_ECSPI_Busy;    }   /* 入力引数が有効かどうかを確認します */ (((xfer->txData == NULL) && (xfer->rxData == NULL)) || (xfer->dataSize == 0U)) の場合     { kStatus_InvalidArgument を返します。    } // if(test_init_flg == 0) { ECSPI_Enable(base, true); } handle->state = kECSPI_Busy; if(test_init_flg == 0) {       ECSPI_SetChannelSelect(base, xfer->チャネル); } #if defined(FSL_FEATURE_SOC_SPBA_COUNT) && (FSL_FEATURE_SOC_SPBA_COUNT > 0) if(test_init_flg == 0) {   bool isSpba = SDMA_IsPeripheralInSPBA((uint32_t)base); /* インスタンスが SPBA に存在するかどうかを判定する */ if (isSpba)     { perType = kSDMA_PeripheralNormal_SP;    } } #endif /* FSL_FEATURE_SOC_SPBA_COUNT */ if(test_init_flg == 0) {   /* 転送を準備します。*/ SDMA_PrepareTransfer(&xferConfig, (uint32_t)xfer->txData, (uint32_t) & (base->TXDATA), sizeof(uint8_t), sizeof(uint8_t)、sizeof(uint8_t)、xfer->dataSize、handle->txSdmaHandle->eventSource、perType、 kSDMA_メモリから周辺機器へ); } /* 送金を送信します。*/ SDMA_SubmitTransfer(handle->txSdmaHandle, &xferConfig);   if(test_init_flg == 0) { /* 転送を準備します。*/ SDMA_PrepareTransfer(&xferConfig2, (uint32_t) & (base->RXDATA), (uint32_t)xfer->rxData, sizeof(uint8_t), sizeof(uint8_t)、sizeof(uint8_t)、xfer->dataSize、handle->rxSdmaHandle->eventSource、perType、 kSDMA_周辺機器からメモリへ); } /* 送金を送信します。*/ SDMA_SubmitTransfer(handle->rxSdmaHandle, &xferConfig2); /* 受信転送開始 */ handle->rxInProgress = true; SDMA_StartTransfer(handle->rxSdmaHandle); ECSPI_EnableDMA(base, kECSPI_RxDmaEnable, true);   /* 送信転送開始 */ handle->txInProgress = true; SDMA_StartTransfer(handle->txSdmaHandle); ECSPI_EnableDMA(base, kECSPI_TxDmaEnable, true); test_init_flg=1;   kStatus_Success を返します。 } void main(void) { ... while(1) {   DRIVER_MASTER_SPI.Transfer(masterTxData, masterRxData, TRANSFER_SIZE); // ECSPI_MasterTransferSDMA を呼び出す   /* スレーブがすべてのデータを受信するまで待機します。*/ while (!isTransferCompleted)     {    } ... } }   回复： How to increase the ECSPI of imx8mmini baud rate to 52Mbps? ソースコードを添付する Re: How to increase the ECSPI of imx8mmini baud rate to 52Mbps? こんにちは、@sofia_0571さん お元気でお過ごしのことと思います。 関数内のフラグを使用してセットアップをバイパスする代わりに、ECSPI_MasterTransferSDMA を高速ループ専用にし、不要な処理を取り除いてみてください。準備が既に完了していることを前提とした「高速トリガー」関数を作成します。 例えばこんな感じです。 status_t ECSPI_MasterTransferSDMA_FastTrigger(ECSPI_Type *base, ecspi_sdma_handle_t *handle, uint32_t size) { handle->state = kECSPI_Busy; xferConfig.dataSize = size; xferConfig2.dataSize = size; SDMA_SubmitTransfer(handle->txSdmaHandle, &xferConfig); SDMA_SubmitTransfer(handle->rxSdmaHandle, &xferConfig2); handle->rxInProgress = true; SDMA_StartTransfer(handle->rxSdmaHandle); ECSPI_EnableDMA(base, kECSPI_RxDmaEnable, true); handle->txInProgress = true; SDMA_StartTransfer(handle->txSdmaHandle); ECSPI_EnableDMA(base, kECSPI_TxDmaEnable, true); return kStatus_Success; } よろしくお願いいたします。 サラス。