T Embed 使用的是哪种接口？ 我有一台标准的 T 型嵌入式开发板，但我不知道它用的是哪种接口（不是 USB-C 接口），因为官方网站说它是 Grove 接口，而 Lilygo Wiki 网站说它是 Qwiic 接口。请问有人可以帮帮我吗？

FRDM-MCX N947およびOV5640カメラ 現在、カメラストリーミングパイプライン（以前はESP32-S3で動作させていたもの）をFRDM-MCXN947に移植しています。目標解像度は1080pで、OV5640カメラモジュールからのキャプチャ、MCXN947ハードウェアアクセラレータによるプロセッシング、そしてSPI経由でESP32-C5へのストリーミングによるWi-Fi伝送が可能です。 ハードウェアパイプライン: OV5640カメラ（DVP 8ビット）→ MCXN947（FlexIO / SmartDMA）→ 外部PSRAM→ SPI→ ESP32-C5→ Wi-Fi 現在の進捗状況とセットアップ SCCB / I2C制御：完全に機能します。カメラレジスタの読み書き操作は成功し、初期化も完了しました。 SmartDMAベースライン:OV7670用の標準NXP SDKスマートDMA例(内部SRAM使用)をテストし、期待通りに動作しました。 目標：OV5640と外部PSRAMバッファリング、FlexIOキャプチャを使用して、これを1080p解像度に拡張する。 問題1：FlexIOピンのリマッピングとD4/D5の無効なデータ FlexIO を介して 8 ビット並列キャプチャを試みると、データライン D4 と D5 は有効なピクセルデータを読み取ることができませんが、ライン D0～D3、D6、および D7 は正しく動作します。 初期ピンマッピング： D0-D3: P1_4、P1_5、P1_6、P1_7 D4-D5: P3_4、P3_5（問題あり：有効なピクセルデータがありません） D6-D7: P1_10、P1_11 制御: VSYNC -> P1_18、HREF -> P1_19、XCLK -> P2_2 SCCB: SCL -> P3_2、SDA -> P3_3 トラブルシューティングの試み: D4とD5を別のピンに再マッピングし、対応するFlexIOとピンマルチプレクサの設定を更新しました。 D4を再マッピング: P2_8 D5を再マッピング: P2_9 この再マッピングを行っても、D4とD5は依然として有効なデータを取得できません。 問題2：1080pにおける外部PSRAMへのSmartDMAルーティング 1080pのフレームバッファは内部SRAMの容量を超えるため、フレームはリアルタイムで外部PSRAMにバッファリングする必要がある。 SmartDMAを設定して、受信したFlexIOカメラデータをCPUの介入やフレームティアリングなしに外部PSRAMに直接ルーティングするための最適な方法と設定手順を探しています。 ご意見、ピン配置に関するご提案、参考コードなどございましたら、ぜひお聞かせください！ ボード設計 通信・制御(I3C |I2C |SPI |FlexCAN |イーサネット |FlexIO) MCX N Re: FRDM-MCX N947 and OV5640 Camera こんにちは、 @DocMonster7さん 公式SDKの例は、FRDM-MCXN947ボード上でfrdmmcxn947_smartdma_camera_flexio_mculcd_cm33_core0されており、J9カメラインターフェースを通じてOV7670カメラが接続されていることを検証しました。このリファレンスデザインでは、CAMERA_D4とCAMERA_D5がそれぞれP3_4とP3_5にマッピングされ、画像キャプチャは正しく動作します。 この検証に基づくと、P3_4とP3_5はカメラデータ入力として正しく機能しているようです。したがって、この問題はこれらのMCUピン自体の制限による可能性は低いです。 OV5640のハードウェア接続、信号の完全性、ピン多重化構成、および元のSmartDMAカメラキャプチャ実装に加えられた変更点について、さらに確認することをお勧めします。 Harry_Zhang_0-1786329719002.pngHarry_Zhang_0-1786329719002.pngHarry_Zhang_0-1786329719002.png BR ハリー Re: FRDM-MCX N947 and OV5640 Camera こんにちは、ハリーさん。 J9のSmartDMA OV7670 SDK例を検証してくれてありがとうございます。これで違いが明確になった。 この不一致の理由は、使用されているキャプチャ ペリフェラルにあります SmartDMA (EZH エンジン): GPIO/EZH ポートを直接サンプリングします (J9 上の P3_4 および P3_5 が EZH_LCD_D4/D5 として正しく機能する場合)。 FlexIOパラレルエンジン（fsl_flexio_camera）：連続する8つのFlexIOシフターデータピン（FLEXIO0_D12～FLEXIO0_D19）が必要です。FRDM-MCXN947では、J9上のP3_4とP3_5にはFlexIOピンの多重化機能がありません。連続したFlexIO D16/D17回線を取得するには、それらをP3_8（TP16）とP3_9（TP15）にルーティングする必要があります。 FlexIOキャプチャのためにD4をP3_8（TP16）にルーティングする際、P3_8がオンボードQSPIフラッシュ（U8 Winbond W25Q64、FlexSPI0_A_DATA0）と共有されているため、P3_8でアクティブなハードウェア競合が発生しました（アクティブドライブGPIOテストは0.15V～1.3Vにクランプされています）。 Re: FRDM-MCX N947 and OV5640 Camera こんにちは、 @DocMonster7さん 共有していただきありがとうございます。他に質問がない場合は、これを解決策として承認してください。 BR ハリー

USB串口下载模式是否可行 您好，先生， 在我们目前的项目中，我们的产品只有一个“USB-C”端口，运行USB 2.0高速。我们的目标应用是将此 USB 端口用作 USB 主机角色，连接 U 盘或固态硬盘进行本地录制。 但是，我们下一版 PCB 电路将在 USB-C 的两个 CC 引脚上将 56K 欧姆电阻上拉至 VCC_5V0，如下图所示。也就是说，我们根据 CC 配置定义，将 USB 端口硬连接到 USB 主机。没有单独的跳线/开关/C型控制器（DRP（双角色端口）逻辑IC）电路可以在主机和设备之间切换CC引脚。 Esther_Liu_0-1786180179443.png 我们想知道，基于这种电路设计，i.MX8M+ USB 串口下载模式是否还能正常工作？我们了解到，当 i.MX8M+ 启动 ROM 激活 USB 串行下载模式时，端口会自动配置为 USB 设备（以便 USB 串行下载模式工作），但这应该意味着芯片的 ROM 代码仅控制内部 USB PHY 处于设备模式，它不能覆盖硬件的外部 CC 电阻状态（Type-C 端口的作用）。因此，PC 完全无法通过 USB 枚举 i.MX 8M Plus（从 USB 物理层的角度来看，两者无法完成握手（Type-C Attach）），这导致 UUU 编程失败。如果上述说法正确，则 USB 串行下载模式将在启动前失效（即完全无法工作） ，导致失去出厂刷写和系统修复功能。 我们的理解是否正确？ 顺祝商祺！ Re: Whether USB serial download mode can work or not 你好@Esther_Liu 你说得对，如果强制 CC 为上拉模式，它将保持在主机模式，而 UUU 可能会出现故障。 B.R

S32K338 的详细信息 早上好， 我需要知道 S32K388 微控制器是否像 K324（有两个）一样有三个独立的内核，以及其中两个内核是否也可以用于锁步执行。 如果我想要一个单核处理器 + 一个锁步内核，我应该使用 K358 吗？ 谢谢 Re: Detail about S32K338 你好@gianpiero_lenta ， 同步操作不是可以在两个独立内核之间启用的软件可配置功能。相反，Lockstep 是一种专用的硬件配置，在特定的 S32K3 衍生产品中实现。 因此，如果您的应用需要一个独立的 Cortex-M7 内核以及一对 Lockstep Cortex-M7 内核，我建议使用 S32K358，它是为这种硬件配置而设计的。 顺祝商祺！ 帕维尔

在待机模式下，S32K328 的引脚无法输出高电平。 我按照操作手册中的配置步骤，将 S32K328 的一些 GPIO 引脚配置为在待机模式下保持高电平，但失败了。以下是我的配置过程。我没有按照手册中的建议执行第四步。这会产生影响吗？我之前在 S32K312 上进行过类似的配置，没有出现任何错误。我的理解是，由于我没有在RESET后禁用引脚保持功能，即使我将 GPIO 引脚配置为在唤醒后输出低电平，输出引脚电平仍应保持进入待机模式之前设置的高电平。目前，在实际测量中，配置为待机模式和运行模式的几个 GPIO 引脚均保持低电平。 6ABE3FCC-00F4-4165-B025-E31BB4B1BEBC.png de7ee9ab18af4cbe9fe5a0f4dbd21427.png Re: In standby mode, the pins of the S32K328 cannot output a high level 你好@hhggll23 ， 我没有按照手册中的建议执行第四步。这会产生影响吗？ 是的，确实如此。如果在进入待机模式之前启用了焊盘保持（写入 DCM_GPR->DCMRWF1[STANDBY_IO_CONFIG] = 0，无论 SIUL2 的 PKE 是否设置，这都是默认寄存器值），但在唤醒后没有禁用它，则 SIUL2 模块将无法再次初始化。如果 MCU 需要进入待机模式和唤醒时不需要 Pad Keeping 功能，则需要将 1 写入该位（任意位置）并保持不动。 这是通过 Power_Ip_Init() API 实现的： Julin_AragnM_3-1786127814879.png 现在，无论焊盘保持配置如何，I/O 引脚在待机模式下都会保持其在运行模式下的最后设置状态。 由于 S32K3 在唤醒后总是会执行复位序列，并且 SIUL2 模块在功能复位时会将 GPIO 焊盘复位到其默认状态，因此焊盘保持功能可确保引脚从唤醒到用户解锁期间保持其状态。 Julin_AragnM_0-1786126733106.png Julin_AragnM_4-1786128871517.png 您是想将图中所示的所有引脚在待机状态下都设置为高电平吗？它们进入待机状态时都会变成低电压吗？或者在离开时？ 此致， 朱利安 Re: In standby mode, the pins of the S32K328 cannot output a high level 非常感谢您的回复。我重新检查了程序，发现待机前将引脚拉高后，运行了一个意外的例程，重新初始化了所有 GPIO 引脚，导致引脚在待机期间保持低电平。修改后，待机模式下 GPIO 引脚电平已成功上拉。现在出现了一个新问题：在待机模式下将 GPIO 引脚拉高后，待机电流似乎增加了。目前，在待机状态下，控制器的静态电流在 24V 电源供电下约为 3mA。在排查了其他电路之后，我怀疑 S32K328 消耗了大部分电流。在 24V 电压下，3mA 电流相当于控制器 5V 电源下的约 14.4mA 电流。我已将 8 个 GPIO 引脚拉高至待机模式。这个待机电流正常吗？为了解决这个问题，我能否将 S32K328 的 GPIO 引脚配置为待机模式下的高阻抗，以便外部上拉电阻可以在待机期间保持引脚上的高电平？

スキッドステアロボットの状態空間モデリング???? 皆さん、こんにちは！ 私は初心者で、大勢の人がいるそこそこ大きな研究室で働き始めたばかりなので、いくつか調べなければならないことがありました。 私たちはスキッドステア式ロボットを開発中です。運動方程式と動力学方程式は数学的には理解しているのですが、それらを状態空間に変換する具体的な方法がわかりません。（それが要件だった） 私のチームはCADモデルを持っていて、慣性質量パラメータを抽出する必要があります。 彼らはとても混沌としたグループで、聞いてみましたが、彼ら自身がうまくいっていません。😭 こういったことに関する適切な情報源も全くなく、どうすれば有意義な行動を起こせるのか、本当に途方に暮れています。 アドバイス、ご協力、参考資料など、どんな情報でも歓迎いたします！乾杯。 Re: Skid-steer robot state space modelling???? こんにちは、 @prash さん。 以下の情報を教えていただけますか? -現在どのNXP製品を使っていますか?当社のEVKやNXP MCU/MPU製品をベースにしたカスタムボード、または他のハードウェアソリューションを使っていますか? -どのIDEを使っていますか? BR ハビブ

MIMXRT1170-EVK FreeRTOS Hello サンプル問題 チームの皆さん、こんにちは。 MCUXpresso SDKから evkbmimxrt1170_freertos_hello_cm7 例プロジェクトをMCUXpresso IDEにインポートし、大きな変更は加えませんでした。 プロジェクトはエラーや警告なしに正常にビルドされ、MIMXRT1170-EVK(MIMXRT1176DVMAA)ボードへのダウンロードも正常に完了しました。 タスクは正常に作成され、一度だけ実行された後、アドレス0xDEADBEEEで停止します。この現象は毎回発生します。 LED切り替えタスク: 問題がvTaskSuspend()に関連しているかどうかを確認するために、単純なLED点滅タスクを含む別のタスクを作成しました。 期待される動作: LEDは100ミリ秒ごとに連続的に点滅するべきである。 実際の動作: LEDは一度だけ点滅します。 最初の実行後、デバッガーは再び0xDEADBEEEで停止します。 以下の質問についてご説明いただけますでしょうか。 RT1170のMCUXpresso SDKでアドレス 0xDEADBEEE は何 i.MX 示していますか? なぜこのタスクは定期的に実行されず、一度しか実行されないのですか？ MIMXRT1170-EVKを正しく動作させるために、他に何か設定が必要ですか？ タスクが期待どおりに定期的に実行されるようにするには、どのような変更が必要ですか？ Rosh_0-1786093292545.png Rosh_1-1786093311524.png Rosh_2-1786093339102.png Re: MIMXRT1170-EVK FreeRTOS Hello Example Issue こんにちは、 @Rosh さん。 現在、MIMXRT1170-EVKをご利用されているとのことですね。MIMXRT1170-EVK用のSDKはMIMXRT1170-EVKB用のSDKとは異なりますのでご注意ください。RT1170-EVK専用に作成されたSDKをMCUXpresso SDK Builderでダウンロードしてテストしていただけますか? Habib_MS_0-1786125239179.png あなたの言いたいことは理解できます。SDKの例は、各ペリフェラル機能の共通ユースケースを提供することを目的としています。0xDEADBEEという値は、通常、ハードフォルト状態に関連付けられています。 最新のSDKバージョンを使って、修正なしでこの例を実行させて、結果を教えていただけませんか? BR ハビブ Re: MIMXRT1170-EVK FreeRTOS Hello Example Issue こんにちは@Habib_MS  MCUXpresso SDK Builderを使ってRT1170-EVK専用に生成されたSDKをダウンロードしてテストしました。今は正常に動作しています。 サポートありがとうございます。

S32K566 LPUART 通信问题 您好， 我正在使用 S32K566 微控制器上的 Uart_Example_S32K566_M7 模块，LPUART 模块时钟频率为 50 MHz。我已将波特率配置为 115200，并使用 UART 转 USB 转换器向 PC 发送 0xAA 数据。但是，接收到的数据不正确（0x00 0x80 0x80）。当我将波特率配置为 115200/8 = 14400 时，数据可以正确接收。我还尝试了不同的波特率，例如 9600 和 19200。 我使用的是 S32DS 3.6.6 和 SDK 0.8.0。 Uart_Example_S32K566_M7 的源代码也附在这里，请查收。 我已附上配置信息和接收数据的截图供您参考。 Manikandan_Aruchamy_0-1786092514163.png 接收终端窗口波特率为 115200： Manikandan_Aruchamy_1-1786092584169.png 接收终端窗口波特率为 14400： Manikandan_Aruchamy_2-1786092633034.png Re: S32K566 LPUART Communication Issue 你好@Manikandan_Aruchamy ， 希望你一切安好。我写信给您是关于您目前拥有的一款产品——一款尚未正式上市的新产品（NPI）。 请注意，已获准提前体验此类产品的客户已指派了现场工程师。您指定的现场工程师应作为您解决有关本产品任何问题、疑虑或疑问的主要支持渠道。 我们的在线支持团队将在该产品正式发布后，提供更广泛的支持服务。在此之前，我们将无法提供所需的帮助。 感谢您的理解。 顺祝商祺！ 帕维尔

I.MX93 启动等待已知的 USB 设备 我从 Mouser 购买了 IMX93 用于 NXPLinux 暑期学校项目，我在那里使用了自动脚本来启动板，./scripts/ loss.py boot 命令。执行命令后，我一直收到“正在等待已知的 USB 设备”的提示。非常感谢各位的帮助，我目前遇到了瓶颈，希望能继续前进。 FRDM-i.MX93 Re: I.MX93 boot waiting for known usb device 嗨@Fidelbanks 您指的是哪个项目？如果您想开始使用开发板，可以直接使用 NPX 网站上的演示图像。我不了解你们的暑期学校项目是如何实施的。 B.R Re: I.MX93 boot waiting for known usb device @Fidelbanks非常感谢您对 i.MX FRDM 开发板的关注。我认为你的问题与此类似。 https://community.nxp.com/t5/i-MX-Processors/I-MX93-UUU-emmc-sdcard-LIBUSB-ERROR-TIMEOUT-Error/td-p/2402801 @pengyong_zhang Linux 内核暑期学校是一个旨在帮助人们使用 i.MX93 frdm 板开始学习 Linux 内核的项目。 https://nxp-research.github.io/lkss-main/2026/about.html#getting-started 我们提供了一个脚本，可以帮助用户使用串行下载模式启动开发板。

MC33 PT2000 ICを使用してSOI -EOIを調整する方法 トピックとして、PT2000を用いてフルー注入SOI-EOI測定を適用する全工程を確立する助けが必要です Hブリッジドライバー 小型機関運転士 ソレノイドコントローラー Re: How use adjust SOI -EOI with use MC33 PT2000 IC 感謝します！ Re: How use adjust SOI -EOI with use MC33 PT2000 IC 親愛なるKaijinbin様、 PT2000のインジェクション終了検出アプリケーションノートは、有効なNDAとともに PT2000製品ページからダウンロード可能です。 JozefKozon_0-1786079976443.png まだNDAを持っていない方で署名を希望される場合は 、こちらから 新しいチケットを作成してください。NDA関連の担当者が手続きをサポートします。 さらに、FRDMPKPT2000EVM製品ページからPT2000SWUGとPT2000-IDEUGをダウンロードしてください。同じページからPT2000 Developer Studio IDEやPeak and HoldおよびDCDCソフトウェアのソフトウェアファイルをダウンロードできます。その後、FRDMPKPT2000EVM評価ボードでソフトウェアの例をテストできます。 JozefKozon_1-1786080423866.png 敬具、 ヨゼフ

IMX8MPのLinuxのubootは、デフォルトの環境+追加の変数で設定する必要があります IMX8MP Linux ubootは、ブートローダーをuuuでフラッシュした後、デフォルトの環境ネットワーク+さらにいくつかの変数を設定する必要があります。 ユースケース: IMX8MP SoMには、ベンダー提供のデフォルトのu-bootが付属しています。初めて新しいubootイメージを書き込む必要があり、デフォルト環境に設定し、工場プロセスでボード固有の環境変数をいくつか追加しました。 つまり、コマンドを使うときはuuu -b emmc_all bl-imx8mp.bin image.wic.zstが内蔵スクリプトを使っています uuu_version 1.4.149 # @_flash.bin |WICイメージから抽出できるブートローダー # @_image [_flash.bin]| wicイメージをemmcに書き込む。 # このコマンドは、i.MX6/7、i.MX8MM、i.MX8MQ の場合に実行されます SDP: boot -f bl-imx8mp.bin -scanlimited 0x800000 # このコマンドはROMがストリームモードをサポートするときに実行されます # i.MX8QXP、i.MX8QM SDPS: boot -scanterm -f bl-imx8mp.bin -scanlimited 0x800000 # これらのコマンドはSPLを使用する場合に実行され、SPLを使用しない場合はスキップされます # SDPU は非推奨になります。SDPUの代わりにSDPVを使用してください # ヤミン・アメックス SDPU: 遅延 1000 SDPU: write -f bl-imx8mp.bin -offset 0x57c00 SDPU: ジャンプ -scanlimited 0x800000 # } # これらのコマンドはSPLを使うときに実行され、SPLがなければスキップされます # もし(SPLがSDPVをサポートする場合) # { SDPV:ディレイ1000 SDPV: write -f bl-raptor-imx8mp.bin -skipspl -scanterm -scanlimited 0x800000 SDPV:ジャンプスキャン制限0x800000 # } FB: ucmd setenv fastboot_dev mmc FB: ucmd setenv mmcdev ${emmc_dev} FB: ucmd mmc dev ${emmc_dev} FB: flash -raw2sparse all image.wic.zst/* FB: flash -scanterm -scanlimited 0x800000 ブートローダー bl-imx8mp.bin FB: ucmd if env exists emmc_ack; then ; else setenv emmc_ack 0; fi; FB: ucmd mmc partconf ${emmc_dev} ${emmc_ack} 1 0 FB: 完了 私の要件は ブートローダーをフラッシュ + rootfs / イメージ デフォルトにリセットしてください。 新しい変数を追加します。 適切な動作をする新しいブートローダーと想定される環境で再起動してください。 しかし今は、まずルートファイルシステムをフラッシュしてから、新しいブートローダーをフラッシュするようになっています。だから、envのデフォルト-f -aを実行してから実行すると、SoMボードの古いブートローダーの環境のデフォルト状態になります。リセットされると、新しいブートローダーで起動しますが、古いブートローダーのデフォルト設定がそのまま使用されます。この問題を解決するための提案はありますか？ Re: IMX8MP linux uboot need to be set up with the default environment + extra variables こんにちは、@jake4さん お元気でお過ごしのことと思います。 自分でカスタムスクリプトを作成して、以下に追加してみてください: FB: ucmd env default -f -a 完全なスクリプトの例： uuu_version 1.4.149 SDP: boot -f bl-imx8mp.bin -scanlimited 0x800000 SDPS: boot -scanterm -f bl-imx8mp.bin -scanlimited 0x800000 SDPU: delay 1000 SDPU: write -f bl-imx8mp.bin -offset 0x57c00 SDPU: jump -scanlimited 0x800000 SDPV: delay 1000 SDPV: write -f bl-imx8mp.bin -skipspl -scanterm -scanlimited 0x800000 SDPV: jump -scanlimited 0x800000 FB: ucmd setenv fastboot_dev mmc FB: ucmd setenv mmcdev ${emmc_dev} FB: ucmd mmc dev ${emmc_dev} FB: flash -raw2sparse all image.wic.zst/* FB: flash -scanterm -scanlimited 0x800000 bootloader bl-imx8mp.bin FB: ucmd if env exists emmc_ack; then ; else setenv emmc_ack 0; fi; FB: ucmd mmc partconf ${emmc_dev} ${emmc_ack} 1 0 FB: ucmd env default -f -a FB: ucmd setenv board_version "1.0" FB: ucmd setenv my_custom_var "value" FB: ucmd saveenv FB: ucmd reset FB: done よろしくお願いいたします。 サラス。 Re: IMX8MP linux uboot need to be set up with the default environment + extra variables こんにちは、 @Manuel_Salas さん。 ubootではeth fastbootのみを有効にしているため、SDPのブートスイッチは使えません。fastbootコマンドだけのオプションがあるかどうか教えていただけませんか? よろしくお願いします。

I.MX93ブート、既知のUSBデバイスを待機中 NXPLinuxサマースクールプログラム用にMouserからIMX93を購入し、そこでボードを起動するための自動スクリプト、./scripts/loss.py boot commandを使用しました。コマンドを実行した後、「既知の USB デバイスを待機しています」というメッセージが表示され続けます。行き詰まっているので、先に進むためのあらゆる支援に感謝いたします。 FRDM-i.MX93 Re: I.MX93 boot waiting for known usb device こんにちは、 @Fidelbanksさん。 どのプロジェクトのことをおっしゃっているのですか？開発ボードの使い方を始めたいなら、NPXの公式サイトにあるデモ画像を直接使うことができます。貴校のサマースクールプログラムがどのように実施されているのか、私はよく存じ上げません。 B.R Re: I.MX93 boot waiting for known usb device @Fidelbanks i.MX FRDMボードにご興味をお持ちいただき、誠にありがとうございます。あなたの問題は、 https://community.nxp.com/t5/i-MX-Processors/I-MX93-UUU-emmc-sdcard-LIBUSB-ERROR-TIMEOUT-Error/td-p/2402801 @pengyong_zhangLinuxカーネルサマースクールは、i.MX93 frdmボードを使ってLinuxカーネルの学習を始める人々を支援するプロジェクトです。 https://nxp-research.github.io/lkss-main/2026/about.html#getting-started ユーザーがシリアルダウンロードモードでボードを起動できるのを支援するスクリプトも提供しました

滑移转向机器人状态空间建模？ 大家好！ 我是一个新手，刚开始在一个规模相当大的实验室工作，和很多人一起工作，我需要弄清楚一些事情。 我们正在研发一款滑移装载机器人。我从数学上理解动力学和运动学方程，但我不知道如何将它们准确地转换为状态空间。（这是要求） 我的团队有CAD模型，他们需要提取惯性质量参数。 他们是一群非常混乱的人，我试着问过他们，但他们自己也搞不清楚状况。😭 这类事情也没有什么好的资源，我真的不知道该如何进行一些有意义的工作。 任何建议、帮助和资源都非常感谢！干杯。 Re: Skid-steer robot state space modelling???? 你好@prash ， 请问您能否提供以下信息？ -您目前使用的是NXP的哪款产品？您使用的是我们的 EVK、基于 NXP MCU/MPU 产品的定制板，还是其他硬件解决方案？ 你使用的是哪个集成开发环境（IDE）？ BR 哈比卜

相机模块与 OX05B1S 传感器和内置 ISP 与 i.MX95 FRDM 的兼容性 大家好， 想知道带有 ox05b1s 传感器和内置 ISP 的摄像头模块（类似于NVIDIA Jetson AGX Orin 的 5MP RGB-IR 全局快门 GMSL2 摄像头）是否与 i.MX95 FRDM 板兼容。 我明白 i.MX95 只有 MIPI_CSI2 端口，因此我需要找到 GMSL2 到 MIPI_CSI2 的转换器，但我的问题具体与 NXP Linux 电路板支持包中现有驱动程序的兼容性有关。NXP Linux 版本的摄像头驱动程序是否可以直接与此摄像头模块配合使用？ 我需要修改dtb文件吗？还有其他需要修改的地方吗？或者我需要计划一些额外的工作吗？

MCALコンポーネントSbc_fs26とOSコンポーネントfreeRTOSを使用したK344およびFS26のサンプルコード こんにちは、 Sbc_fs26とfreeRTOSのコンポーネントを統合したS32K344とFS26チップのソースコード例(S32DSプロジェクト)を教えてもらえますか? 個別のRTDの例があることは承知しています。 1) Sbc_fs26_example_HLD_S32K344 (FreeRTOSなし) 2) FreeRTOS_Toggle_Led_Example_S32K344 (Sbc_fs26なし) そして、例を挙げると次のようになります。 3) MR_CANHUBK3_IEEE1722（ウォッチドッグが無効で、Sbc_fs26コンポーネントが使用されていない） 要するに、FreeRTOS環境でFS26チップを適切に設定および更新するための基本的なソースコード例を探しています。 よろしくお願いします。 Re: Example code for K344 & FS26 with MCAL component Sbc_fs26 and OS component freeRTOS こんにちは、スラヴコさん。 現時点では、これらの要素を組み合わせたプロジェクト例は把握していません。   あなたが挙げた例は、関連する参考資料です。 - Sbc_fs26_example_HLD_S32K344 これはFS26/SBCの統合を示すものですが、FreeRTOSは使用していません。 - FreeRTOS_Toggle_Led_Example_S32K344 これはS32K344上での基本的なFreeRTOSのセットアップ例を示していますが、FS26 SBCコンポーネントは含まれていません。 - MR_CANHUBK3_IEEE1722 これにはより広範なシステムレベルの実装が含まれますが、FS26ウォッチドッグは無効になっており、Sbc_fs26コンポーネントは使用されていません。 あなたのユースケースでは、実用的な方法はSbc_fs26_example_HLD_S32K344プロジェクトから始めて、FreeRTOSの例からFreeRTOS構成を統合することです。FS26の初期化はシステムの起動シーケンスの一部として残し、ウォッチドッグの更新はFreeRTOSタスクや他のデターミニスティックなタイミング機構から定期的に処理されるべきです。   BRs、トーマス

Himiway：ミッドドライブ方式とハブモーター方式：メリットとデメリット 電動自転車を購入する際、最も重要な決断の一つは、ミッドドライブモーターとハブモーターのどちらを選ぶかということです。 どちらのデザインも自動的に優れているわけではありません。ミッドドライブモーターは、自転車のギアを駆使して急な坂道やテクニカルな地形を走行するのに特に優れている一方、ハブモーターは構造がシンプルで、通常は価格も手頃であり、駆動系のメンテナンスも少なくて済む。 多くの日常的なライダーにとって、優れたハブモーターは十分すぎるほどの性能を提供する。急な坂道や山道、あるいは荷物を積んで走行するようなライダーは、ミッドドライブシステムの方がよりメリットを得られるかもしれません。 具体的な比較をしてみましょう。 ミッドドライブとハブモーターの比較を一目で見た 特徴:ミッドドライブモーターハブモーター エンジンの位置 クランク/ペダル周辺 フロントホイールハブかリアホイールハブ 丘陵、トレイル、テクニカルライディング、通勤、レジャー、混合の日常走行に最適です 坂道性能:トルクに応じて良好から優秀 重量配分は非常にバランスが取れている。片方の車輪に重さが増す。 駆動系の摩耗は高く、低くなっています メンテナンスはより手間がかかる。一般的には簡単です。 パンクタイヤ修理 通常、モーターホイールの取り外しは簡単なものの、より難しいことがあります ペダルの感触はしばしば非常に自然で、センサーのチューニングに大きく依存します 価格が通常は高く、通常はより手頃です。 ミッドドライブモーターとは何ですか? ミッドドライブモーターは、ペダルとクランクセットがフレームに接するボトムブラケット付近に配置されています。 モーターは車輪を直接回転させるのではなく、自転車の駆動系を通して動力を伝達する。つまり、モーターはライダーと同じようにバイクのギアを活用できるのです。 例えば急な登りでは低速ギアに切り替えると、モーターはより有利な速度で動作し、強力な登坂補助を得られます。 これが、高性能な電動マウンテンバイクや、険しい地形向けに設計されたその他の自転車でミッドドライブシステムが人気を集めている最大の理由です。 ミッドドライブモーターの利点 1. 優れた登坂性能 これはおそらく、ミッドドライブエンジンを支持する最も強力な論拠だろう。 モーターのパワーは自転車のギアを通るため、登る際には低いギアを選ぶことができます。これにより、モーターが非常に低い回転数で自転車を坂道で引っ張ろうとするのではなく、効率的に動作させることができます。 非常に起伏のある地域に住むライダーにとっては、これは目に見える違いを生み出します。 しかし、ミッドドライブモーター搭載の自転車がすべてハブモーター搭載の自転車よりも自動的に登坂性能に優れているとは限らないので、その点は注意が必要です。モータートルク、コントローラーのチューニング、ライダーの重量、ギア比、タイヤサイズ、そしてバイク全体の重量がすべて重要です。 高トルクの750Wギア付きハブモーターは、通常の道路や中程度のトレイルでも優れたヒルクライマーです。 2. 重量配分の改善 ミッドドライブモーターは、その重量を自転車の低い位置、かつ中心付近に配置する。 一般的に、前輪や後輪の中に大きなモーターが集中していないため、バイクの操縦性はよりニュートラルになります。 その利点は、テクニカルなマウンテンバイク走行時、素早い方向転換時、そして起伏の多い地形を走行する際に特に顕著になる。 3. モーター動力の効率的な利用 モーターは自転車のギアを使えるため、ミッドドライブシステムはより効率的な回転数範囲でモーターを動作させることができます。 これにより、頻繁に高低差が起こるルートの効率が向上します。 しかし、だからといってミッドドライブの方が必ずしも飛距離が長いとは限らない。バッテリー容量、速度、タイヤ空気圧、ライダーの重量、気温、標高、風速、アシストレベルなどが実際の航続距離に大きな影響を与えることがあります。 4. 自然なペダリング体験 多くの上位ミッドドライブシステムはトルクセンサーと組み合わされています。 トルクセンサーはペダルをどれだけ強く踏んでいるかを測定し、それに応じてモーターの補助を調整します。 もっと強く押せば、もっと多くの支援が得られる。ペダルを軽く踏むと、モーターの反応も穏やかになります。 その結果、普通の自転車に乗るのと驚くほど似た感覚になることがありますが、突然脚がずっと強くなるだけです。 ミッドドライブモーターのデメリット 1.ドライブトレインの摩耗が増加 ミッドドライブエンジンの登坂性能における利点となる同じ特徴が、同時に最大の欠点の1つにもなっている。 ライダーとモーターの両方が、以下のようなコンポーネントを通して動力を伝達します。 チェーン チェーンリング カセット ディレイラーシステム 高いモータートルクと悪いシフト習慣が組み合わさると、駆動系の摩耗が加速します。 モーターが最大出力を発揮している状態で頻繁にギアチェンジを行うと、チェーンやカセットスプロケットの歯が著しく早く摩耗する可能性があります。 2. より高価 ミッドドライブシステムは一般的に高価です。 モーターはクランク周辺に組み込む必要があり、フレームは多くの場合、その駆動ユニットに合わせて特別に設計する必要がある。 主に舗装路や比較的緩やかな地形を走行するライダーにとって、割増料金を支払うことは、十分な実質的なメリットをもたらさないかもしれない。 3. シフト技術の重要性 ミッドドライブのライダーはギアについてもっと慎重に考える必要があります。 急な坂道を非常に高いギアで発進し、その後、エンジンに大きな負荷がかかった状態でギアチェンジするのは理想的ではありません。優れたライディングテクニックとは、駆動系に大きな負荷がかかる前に適切なギアを選択することである。 経験豊富なサイクリストにとっては、これはすぐに自然な動作となる。初心者には学習曲線があります。 4. チェーンが切れると、より大きな問題になることがあります ミッドドライブはチェーンを通じてモーターの動力を伝達するため、ドライブトレインの故障で後輪を駆動できなくなる可能性があります。 スロットル装備のハブドライブバイクは、モーターが自転車チェーンから独立して動作するため、ここで有利に働きます。 ハブモーターとは何ですか？ ハブモーターは、前輪または後輪の中央に直接組み込まれています。 リアハブモーターは、現代の電動自転車で特に一般的です。 チェーンとカセットを介して動力を伝えるのではなく、モーターが直接ホイールを回転させる。これにより、システムは機械的に簡素化され、モーターの動力を従来の自転車の駆動系から分離することができる。 いくつかのヒミウェイモデルは強力なハブドライブ構成を採用しています。Himiway D5 2.0シリーズのようなバイクは、ハブモーターが実用的なファットタイヤの電動バイクで人気を保ち続けている理由を示しています。大きなトルクと比較的シンプルな操作を組み合わせることができるからです。 ハブモーターの長所 1. シンプルで手間のかかりにくい設計 最大の利点の一つはシンプルさです。 モーターは通常、自転車のチェーンやカセットを通して動力を伝達しません。したがって、駆動系はペダリング力のみを処理すればよく、ペダリング力とモーター出力の両方を処理する必要はありません。 通勤、週末のサイクリング、買い物、レクリエーションなど、電動自転車を様々な用途で利用したいライダーにとって、このシンプルさは非常に価値がある。 2. 毎日力強いパフォーマンスを発揮 ハブモーターは平坦な道路にしか適していないという考え方は時代遅れだ。 現代のギアードハブモーターはかなりのトルクを発生させることができます。 例えば、Himiway D5 2.0は、トルク90Nmの750Wギアードハブモーターを使用しています。それは、完全に平坦な自転車道をただゆったりと走るためではなく、力強い加速と効果的な登坂補助を提供するように設計された仕様です。 D5 2.0 20インチは、同じ一般的な**アイデア**を20インチファットタイヤとフルサスペンションで組み合わせ、快適さと操作性を重視したコンパクトな**プラットフォーム**をライダーに提供しています。 普通の丘や近隣の通り、砂利道、レクリエーション用のトレイルなどでは、よく設計されたハブモーターが十分に対応可能です。 3. 購入コストの削減 ハブモーターは一般的に、メーカーにとって電動自転車への組み込みが比較的簡単で、コストも抑えられる。 これにより、バイクの予算をより多く、例えば以下のような他の機能に充てることができます。 大型バッテリー 油圧ブレーキ より良いサスペンション 統合照明 ファットタイヤ ペイロード容量の増加 これがハブドライブバイクがコストパフォーマンスに見合った非常に魅力的な仕様を提供できる理由の一つです。 4. チェーンとカセットへの負担軽減 モーターの動力は直接車輪に伝わるため、チェーンはモーターの全トルクを伝達する必要がない。 これは、両バイクが適切にメンテナンスされていれば、パワフルなミッドドライブバイクに比べてドライブトレインの部品寿命が長くなることを意味します。 5. スロットル操作が有用であること スロットル付きの対応ハブドライブ電動自転車では、モーターの動作は必ずしも自転車の駆動系に依存しません。 これは、停止からのスタートや交差点を一時的に通過する際、または荷物を運ぶときにバイクを動かす際に便利です。 また、重要な機械的利点も備えている。チェーンが切れても、必ずしもモーターが自転車を動かすのを妨げるわけではないのだ。 ハブモーターズの短所 1. 極限の登りでは効率が劣る 従来のハブモーターでは、ミッドドライブのように自転車のカセットを活用できません。 長く急な登り坂では、モーターは高負荷状態で低速運転を余儀なくされる可能性がある。 これにより熱発生量やエネルギー消費が増加します。 時折の坂道ではあまり気にしない場合もあります。毎日急な山道を登るライダーにとっては、それはさらに重要な意味を持つようになる。 2. 後輪または前輪が重い モーターは、それが搭載されている車輪にかなりの質量を加える。 ほとんどのパワフルな電動自転車はリアハブモーターを使用しているため、持ち上げたり整備したりする際に後部が重く感じられることがあります。 実際に自転車に乗っている時よりも、自転車を階段で運ぶ時に、このことに気づきやすいかもしれません。 3. パンクタイヤの修理はより複雑になることがあります ハブモーターのホイールは、普通の自転車ホイールほど簡単には取り外せません。 モーターケーブルを外して、かなり重い車輪を扱う必要があるかもしれません。 そのため、正しいタイヤ空気圧を維持し、パンクしにくいタイヤを使用することは、ハブドライブの電動自転車では特に有効です。 Himiwayの電動自転車はどうでしょうか？ Himiwayの電動自転車は良い例と言えるでしょう。なぜなら、同社の自転車の多くは、単に高級感があるという理由だけでミッドドライブ方式を採用するのではなく、パワフルなハブ駆動システムを重視しているからです。 Himiway D5、D5 Pro、D5 2.0、D5 2.0 ST、D5 2.0 Camo、D5 2.0 20インチ、C3、A7、A7 Pro、D7、D7 Proなどのモデルは異なるライディングタイプを対象としているため、重要なのはエンジンの位置だけで判断するのではなく、全体のバイクを見ることです。 例えば、D5 2.0の購入を検討しているライダーは、可能な限り軽量なドライブトレインを実現することよりも、強力なトルク、太いタイヤでのトラクション、サスペンションの快適性、航続距離、そして日常的な信頼性を重視するかもしれません。 D5 2.0 20インチは、操作性と快適性を重視するライダーにとって特に魅力的なモデルです。20インチの小型ホイール、4インチ幅のタイヤ、フルサスペンション、そして低重心設計により、従来の大型ホイールのマウンテンバイクとは全く異なる乗り心地を実現しています。 一方、A7とA7 Proは都市交通や日常の使いやすさを重視するライダーにより関連性が高いです。 そしてC1キッズは全く別のカテゴリーに属する。若いライダーにとっては、制御性、適切なサイズ、速度マネジメント、ブレーキング、大人の監督が、最大限のモータートルクを追い求めるよりもはるかに重要です。 これは重要な教訓を浮き彫りにしている。 電動自転車を選ぶ際は、モーターの性能だけで判断しないでください。 ライダーが実際に気づくこと 仕様は役立つが、実際の日常的な運転では、その違いははるかに分かりやすくなる。 適切に調整されたハブモーター搭載の自転車は、通常の通勤において、しばしば楽に感じられる。ペダルを漕ぐとアシストが到着し、ギアのことを常に気にすることなく前進し続けることができます。 優れたミッドドライブシステムは、ギアを積極的に使うライダーに報いる傾向がある。坂道に近づく際は、ギアを一段下げることで、エンジンとライダーが効率的に連携して走行することができる。テクニカルな地形では、重心を中心に置くことで自転車のバランス感も向上します。 平坦な自転車道を中程度の速度で走行している場合、その差ははるかに小さくなる。 そのため、ミッドドライブに大幅に高い費用をかけることが、すべてのライダーにとって必ずしも価値があるとは限らないのです。 坂道走行に適したモーターはどちらですか？ 本格的な登坂には、ミッドドライブが最適だ。 普段の走行ルートに長くて急な山登りが含まれる場合、ミッドドライブモーターが自転車のギアを活用できる点は大きな利点となります。 しかし、「丘」と「極端な丘」の間には重要な違いがある。 ほとんどの人は毎朝山道を登っているわけではない。 高トルクギアードのハブモーターは、典型的な近隣の丘陵地帯、起伏のある田園地帯、砂利道、そして中程度のトレイルクライムにも非常によく対応できます。だからこそ、Himiway D5 2.0のようなバイクは、より高価なミッドドライブプラットフォームに移行せずに登攀能力を求めるライダーにとって理にかなっています。 通勤にはどちらが良いですか？ 一般的な通勤であれば、ハブモーターの方が有利だと思います。 シンプルで比較的安価であり、自転車の駆動系にかかるモーター関連の負荷も少なく、通常の都市部での走行には十分なアシストを提供します。 しかし、通勤経路に非常に急な地形が含まれる場合は、中間地点での運転がより魅力的になる。 マウンテンバイクにはどちらが良いですか？ 本格的なテクニカルマウンテンバイクなら、ミッドドライブを選ぶでしょう。 エンジンを中心に置くことで重量配分が改善され、急な登りやテクニカルな登りでもギア比へのアクセスが役立ちます。 砂利道、森林道、未舗装道路、キャンプ、比較的中程度のレクリエーショントレイルでは、パワフルなファットタイヤのハブドライブバイクは依然として優れた選択肢となり得ます。 初心者にはどちらが良いですか？ 多くの初心者にとって、ハブモーター式の電動自転車の方が理にかなっている。 モーターを適切なギアに入れておく必要性が少なく、駆動系のメンテナンスも簡単で、価格も手頃な場合が多い。 しかし、使いやすさに影響を与える要因はモーターの種類だけではありません。 フレームジオメトリ、ホイールサイズ、バイクの重量、スタンドオーバー高さ、スロットル挙動、トルクやケイデンスのセンス、ブレーキ、サスペンションなどもライダーの自信にさらに大きな影響を与えます。 ミッドドライブ方式 vs ハブモーター方式：最終結論 万人に勝者はいない。 次のような場合は、ミッドドライブモーターを選択してください。 定期的に非常に急な坂道を登る テクニカルな山道を走る 重量バランスの取れた配分を望む 自然でパフォーマンス重視のライディングフィールを好む 追加のドライブトレインメンテナンスは気にしない より多くのお金を支払うことに抵抗がない ハブモーターを選ぶべきなのは、次のような場合です。 通勤やレクリエーションでの乗車 主に平坦から中程度の丘陵地帯に遭遇します メンテナンスを抑えたい 予算に見合ったより良い価値を望む 機械的にシンプルなシステムを好む 自転車の駆動系に依存しないモーターの動作が欲しい 多くの日常的なライダーにとって、高品質なギアードハブモーターはパワー、シンプルさ、信頼性、価格のバランスが良いです。適切に設計された750Wの高トルクハブドライブ電動自転車は、平坦な市街地だけでなく、はるかに多くの道を走行できます。 地形が本当に険しくなった時、ミッドドライブは特に重宝する。 ですから、「どちらのモーターが良いか?」と聞く代わりに、次の質問をしてください。 「この自転車は実際どこで乗るんだろう？」 もし答えが険しい山道や厳しい登り坂であれば、ミッドドライブコースをよく検討してみてください。通勤、週末のライド、砂利道、用事、中程度の坂道など、Himiwayのラインナップにあるいくつかのモデルのような良いハブドライブ電動自転車は、使わない複雑さにお金をかけずに必要なものをすべて提供できるかもしれません。

Eフラッシュ書き込み中のLIN通信障害 LIN通信の障害は、内部EEPROMへの100バイトの書き込み操作中に検出されます。適切なLIN通信回復方法を提案してください。 Re: LIN communication failure during E-Flash write こんにちは、 @SivaB さん。 どのS32Kデバイスを使っているのか教えていただけますか? 一つの説明としては、エミュレーテッドEEPROMの操作には比較的長い時間がかかり、その結果の遅延がソフトウェアが必要なタイミング制約内でLIN割り込みを処理できない可能性があることです。もう一つの可能性として、読み取り同時書き込み競合が考えられます。フラッシュ消去やプログラム操作中、現在プログラムまたは消去中のフラッシュブロック内のコードやデータは取得・読み取れません。もしアプリケーションがそのようなコードやデータを必要とする場合、アプリケーションがクラッシュし、結果的に観察されたLIN通信障害を引き起こす可能性があります。 また、問題が発生した場合に何が起こるのかも説明してもらえますか?アプリケーションは完全にクラッシュするのか、それとも動作を続けてLIN通信だけが機能しなくなるのか? よろしくお願いいたします。 ルーカス Re: LIN communication failure during E-Flash write S32K144:アプリケーションは期待通りに動作しています。しかし、LIN通信が失敗し、その失敗が起こるとLIN通信は復元できません。 EEPROMへの書き込み／保存時間は約175ミリ秒です。

PN512 - 它真的支持 Type 4 Tag (T4T/HCE) 卡模拟吗？ 大家好， 我正在开发一个定制板（LPC54101 + PN512），它既需要读取 NTAG213/216 标签（工作正常），又需要模拟一个提供静态 NDEF（BT-OOB 配对记录）的 Type 4 标签，以便手机可以轻触并读取它。 使用 NxpRdLib V2.0.3.0 和 phpalI14443p4C_Sw / phceT4T_Sw。在循环中调用 phceT4T_Listen() -> 内部调用 phhalHw_Listen() -> PN512 上的 Autocoll。始终出现 PH_ERR_IO_TIMEOUT (0x0201) 错误，不受超时配置、监听前显式 FieldOff 或寄存器级检查的影响（TxControlReg 确认我们自己的字段已关闭，GsNOffReg 处于数据手册默认值，RFCfgReg/RxThresholdReg/DemodReg 均正常）。将安卓手机或iPhone直接放在天线上，没有任何反应。 我找到了这个帖子，NXP 技术支持表示，根据数据手册，PN512 无法进行卡模拟，并推荐使用 CLRC663： https://community.nxp.com/t5/Other-NXP-Products/PN512-Emulation-Tag-Write-issue/mp/2089993 但这似乎与PN512产品页面（将“卡片模拟功能”列为一项特性）以及另一个帖子中有人在PN512上成功实现Mifare Ultralight标签模拟的说法相矛盾： https://community.nxp.com/t5/NFC/Pn512-Tag-Emulation-Callibration/td-p/684135 所以：PN512 的区别在于它可以进行简单的 ISO14443-3 标签模拟（UID/防碰撞，如 Mifare UL），但不能完全激活 ISO14443-4 Type 4 标签（RATS/ATS、APDU 交换）吗？有人成功在 PN512 上运行过真正的 T4T/HCE 吗？还是说这款芯片对于这种特定用途来说已经行不通了？ 另外，我们的 RdLib V2.0.3.0 软件包的 ReleaseNotes.txt 文件中指出，发现循环仅支持轮询/暂停阶段，并且 .chm 文件也存在类似问题。文档中完全没有提到 phceT4T 或 phpalI14443p4C - 所以我也不确定我们拥有的卡模拟组件是否曾经是经过官方验证/记录的版本。非常感谢各位能提供合适的配套软件包信息。 谢谢您！ Re: PN512 - Does it actually support Type 4 Tag (T4T/HCE) card emulation? 您好，先生， 正如您在另一个案例中提到的，PN512 的确支持 HCE，我们甚至有一个使用 Raspberry Pi 的示例。 但请记住，不建议在新设计中使用 PN512。请考虑使用我们完全支持 NFC 模式的NFC 阅读器（ PN5190 、 PN5180 、 PN7462 、 PN7642 ）。 所有这些读卡器都可以与我们的NFC读取器库一起使用。 希望这些信息对您有所帮助。 Re: PN512 - Does it actually support Type 4 Tag (T4T/HCE) card emulation? 快速更新一下，给以后看到这个帖子的人：因为我在这里和我的客服工单里得到了两个不同的答案： AN11480（树莓派/EXPLORE-NFC 指南）仅演示了 PN512 上的 Type 2 标签仿真 - §7.1 中直接说明（“卡仿真示例模拟 NFC Forum Type 2 标签”），并且从未在任何地方提及 phceT4T 或 T4T。如果你是因为 T4T/HCE 而被引导到那里，那不是正确的文档。 有关 PN512 上实际的 4 型标签 (T4T/HCE) 仿真，请参阅 AN11308（PNEV512B/LPC1769 快速启动指南）第 6.8 节“示例 8 - HCE T4T”和第 7.1.6 节。“HCE层”。该示例明确地基于 NFC Forum Type 4 标签操作规范 v2.0 构建，使用 phceT4T_Activate()/phceT4T_AppProcessCmd()，并支持 Select/ReadBinary/UpdateBinary。 所以：是的，PN512 确实支持真正的 T4T 仿真，只是不是通过 Raspberry Pi 软件包，而是通过 PNEV512B/LPC1769（Blueboard）软件包。联系技术支持以确认确切的库版本并核对两个答案。

MIMXRT1040-EVK: RAMからのデバッグは機能しますが、FLASHでは機能しません チームの皆さん、こんにちは。 私は MIMXRT1040-EVK を使っており、 MCUXpresso IDEとLinkServer/SWDを使っています。 私のアプリケーションはRAMからリンクして実行されると正しく動作するのに、外部FlexSPI NOR Flashから実行するように設定すると、デバッガがmain()に到達しないという問題に直面しています。 現在の動作 RAM構成： 「リンクアプリケーションをRAMに」有効化 アプリケーションダウンロード成功 アプリケーションは正しく実行されます デバッガーがmain()に到達しました アプリケーションは通常通りデバッグできます Flash/XIPビルド: 「リンクアプリケーションをRAMに」無効化 アプリケーションは0x60000000から外部フラッシュと連携されます ビルドは正常に完了しました .axf が生成されます デバッグを開始しても、デバッガーは main() に到達しません。 CPUは、想定される0x600xxxxx XIPアドレス範囲から実行されていないようです。 リンカー/マップ情報 生成された.mapファイルには、想定されるXIPレイアウトが示されています。 .boot_hdr 0x60000000 .boot_hdr.conf 0x60000000 .boot_hdr.ivt 0x60001000 .boot_hdr.boot_data 0x60001020 .text 0x60002000 .isr_vector 0x60002000 ResetISR 0x6000231C main 0x60004EF4 したがって、アプリケーションには期待されるFlexSPI NORブートヘッダー、IVT、ブートデータ、ベクターテーブル、ResetISR、アプリケーションコードが含まれているように見えます。 私も以下を持っています： XIP_EXTERNAL_FLASH = 1 XIP_BOOT_HEADER_ENABLE = 1 重要な指摘 フラッシュイメージのデバッグ/プログラミングを試みた後、メモリを以下の場所で確認しました。 0x60000000 0x60001000 0x60002000 メモリウィンドウは期待されるアプリケーション内容ではなく、0x00000000/空のデータを表示します。 例えば、次の場所で： 0x60002000 アプリケーションベクターテーブルを期待していましたが、メモリにはゼロが含まれているようです。 デバッグ試行失敗後のCPUレジスタには、以下の情報も表示されていました。 PC = 0x0020E368 SP = 0x20200F70 LR = 0x0020ED49 想定される0x600xxxxx XIP領域にあるPCではなく。 デバッグ設定 私は以下を使用しています： Debug Connection: SWD Connect script: RT1040_connect.scp デバッグ構成には以下が含まれます。 Load image: enabled Use project binary: igpio_led_output.axf Load symbols: enabled Use project binary: igpio_led_output.axf Set breakpoint at: main Request hardware breakpoint: enabled LinkServerのデバッグ構成が使用されています。 プロジェクトの内容 このプロジェクトには、標準的なXIP関連ファイルが含まれています。 xip/ ├── evkmimxrt1040_flexspi_nor_config.c ├── evkmimxrt1040_flexspi_nor_config.h ├── fsl_flexspi_nor_boot.c └── fsl_flexspi_nor_boot.h 生成されたリンカースクリプトは、ブートヘッダーとアプリケーションを0x60000000から始まるBOARD_FLASH領域に配置します。 私の質問 なぜ外部FlexSPI NORフラッシュがLinkServerデバッグセッションを起動した際に生成されたXIPイメージでプログラムされていないのか、誰か教えていただけませんか? 具体的には： MIMXRT1040-EVK + LinkServerは、XIPアプリケーションのデバッグに特定のFlexSPI NORフラッシュドライバー/設定が必要ですか? RT1040_connect.scpは、外部NORフラッシュの接続とプログラミングの両方に十分ですか？ MCUXpressoのデバッグ設定において、追加のFlashプログラミング設定は必要ですか？ デバッグの設定は特定のflexspi_norフラッシュドライバーを使うべきでしょうか、それともフラッシュツールの設定を使うべきでしょうか? LinkServer + MIMXRT1040 + 外部FlexSPI NOR + XIPデバッグにおいて、.axfファイルがシンボルとしてロードされるものの、外部フラッシュメモリに実際にはプログラムされないという既知の問題はありますか？ 動作する MIMXRT1040-EVK FlexSPI または XIP デバッグセッションで比較できる推奨される NXP の例プロジェクトや設定はありますか? 次に何をチェックすべきか、ご助言いただければ幸いです。 よろしくお願いします。 Re: MIMXRT1040-EVK: Debug works from RAM, but it's not working for FLASH ご回答ありがとうございます。 ご提案通り 、MCU設定→メモリ の詳細を確認しました。スクリーンショットを添付しました。 BOARD_FLASHメモリは以下のように構成されています。 所在地: 0x60000000 サイズ: 0x800000 フラッシュドライバー: MIMXRT1040_SFDP_QSPI.cfx つまり、特定の 外部フラッシュドライバーはすでにBOARD_FLASHに設定されているようです。 シリアル ダウンロードモード+MCUプロビジョニングツール の手順も試しました。MCUプロビジョニングツールを使ってイメージのビルドとイメージの書き込みを成功させることができました。 しかしその後も、通常のMCUXpresso + LinkServerデバッグフローでFlashからアプリケーションのプログラムやデバッグを行うことができませんでした。 興味深いことに、 その後もう一度コードをフラッシュやデバッグで試したところ、突然動作し、アプリケーションはFlashから正常に動作するようになりました。 失敗と成功の試行の間に、プロジェクト設定、Flashドライバ、リンカー設定、起動設定を意図的に変更したわけではありません。 ですので、現時点ではアプリケーションやリンカーの設定自体ではなく、Flashのプログラミングや初期化、リセットシーケンスに起因する断続的な問題があるのではないかと考えています。 MIMXRT1040-EVKでこの挙動が起きる原因について教えていただけますか? 特に： MIMXRT1040_SFDP_QSPI.cfxはEVKの外部FlexSPI NORの正しいフラッシュドライバーでしょうか? Default LinkServer Flash Driverフィールドが空欄であるのは、ドライバ欄にMIMXRT1040_SFDP_QSPI.cfxが割り当てられているにもかかわらず、BOARD_FLASHは重要でしょうか? 以前の失敗したプログラミングやデバッグの試みの後、外部フラッシュが予期せぬ状態のまま残り、特定のリセットや電源サイクルが必要になる可能性はありますか? RT1040_connect.scpやLinkServerのリセット/接続シーケンスが断続的なFlashプログラミングの原因になるのでしょうか? MIMXRT1040-EVK、LinkServer、およびMIMXRT1040_SFDP_QSPI.cfxに関して、フラッシュプログラミングが断続的に失敗する既知の問題はありますか？ 同じ構成が意図的な変更なしで最終的に動作したため、以前の故障の原因を理解し、Flashのデバッグやプログラミングの信頼性を高めたいと考えています。 よろしくお願いします。 Re: MIMXRT1040-EVK: Debug works from RAM, but it's not working for FLASH こんにちは、@Prashanth1 さん。 あなたが提供したスクリーンショットを見る限り、Flashドライバーの設定は問題なさそうです。 まずはボードをシリアルダウンロードモードにして、MCUXpressoのSecure Provisioning Toolを使ってUSBやuartでイメージをFlashにダウンロードしてみてはどうでしょうか? この方法はデバッガの影響を切り離し、ボードにフラッシュハードウェアの問題がないか確認するために使用できます。さらに、デバッガーを使用して、ダウンロード失敗時のログを提供してください。 私側ではできるだけ早くRT1040-EVKを手配し、以前添付されたプロジェクトパッケージを使って問題を再現しようと思います。 よろしくお願いします、 ギャビン Re: MIMXRT1040-EVK: Debug works from RAM, but it's not working for FLASH こんにちは、ギャビンさん。 ご回答ありがとうございます。 ご提案通り、MCUの設定→メモリの詳細を確認しました。スクリーンショットを添付しました。 私のプロジェクトでは、BOARD_FLASHメモリは次のように構成されています。 場所: 0x60000000 サイズ: 0x800000 ドライバ:MIMXRT1040_SFDP_QSPI.cfx つまり、FlexSPI NORフラッシュドライバはすでにBOARD_FLASHメモリ領域に関連付けられているようです。 しかし、MCU設定の上部にある 「Default LinkServer Flash Driver」 フィールドが空欄で、BOARD_FLASHのドライバー欄にはMIMXRT1040_SFDP_QSPI.cfxが表示されていることに気づきました。 確認いただけますか: この構成はMIMXRT1040-EVKにとって正しいですか？ デフォルトの LinkServerフラッシュドライバー フィールドでMIMXRT1040_SFDP_QSPI.cfxも選択すべきでしょうか? それとも、BOARD_FLASH行に示されているドライバーだけで、LinkServerは外部FlexSPI NORをプログラムするのに十分なのでしょうか? 主な問題は、アプリケーションが0x60000000で正しくXIPリンクされているのに、LinkServerのデバッグセッションを起動した後、メモリウィンドウの0x60000000/0x60002000にアプリケーションの内容が表示されないことです。 同じアプリケーションでもRAMデバッグは正常に動作します。 参考までにMCU設定のスクリーンショットを添付しました。 よろしくお願いします。 RT1040MCUsettings.png     Re: MIMXRT1040-EVK: Debug works from RAM, but it's not working for FLASH こんにちは、@Prashanth1 さん。 NXP MIMXRTシリーズにご関心をお寄せいただきありがとうございます！ 外部フラッシュを使用する場合は、専用のフラッシュドライバーが必要です。IDEでFlashドライバーが正しく読み込まれているか確認してください:(私のスクリーンショットはRT1170を例にしていますが、RT1040も同様の手順です。) Gavin_Jia_0-1786341203390.png よろしくお願いします、 ギャビン Re: MIMXRT1040-EVK: Debug works from RAM, but it's not working for FLASH こんにちは、@Prashanth1 さん。 上記の現象に基づくと、最も可能性の高い原因は、以前にフラッシュメモリ内にダーティデータ／イメージが存在していたことである。誤ったFCBヘッダーであれ、実行時にMCUがエラー状態に入るイメージであれ、これらの問題はイメージの再フラッシュ時に失敗につながることがあります。このシナリオでの標準的な復旧方法はシリアルダウンロードモードに入ることです。こちらの記事もご参照ください： https://community.nxp.com/t5/i-MX-RT-Crossover-MCUs-Knowledge/RT-board-recovery-for-debugger-connect-issues/ta-p/1635260 フラッシュローダーの選択については、IDE内の「Flash」行で適切なフラッシュドライバーを選択するだけで済みます。*.scpファイルはSDKに付属しており、リンクサーバーの事前設定に使用されます。各コマンドラインについて詳しく知りたい場合は、ファイルに入ることができます。 よろしくお願いします、 ギャビン

S32G2 启用多核应用程序 各位恩智浦的同事们，大家好： 我们准备在 S32G274A 芯片中使用多核来运行程序，使用 A53 运行 Linux，使用 M7 运行 LLCE_CAN。 根据 5.2，我们参考了“使用 S32G2 平台软件集成在 S32G2 上启用多核应用程序”。配置引导加载程序，安装推荐的软件包，并按照步骤进行配置。 zhipeng_7-1786181958976.pngzhipeng_7-1786181958976.pngzhipeng_7-1786181958976.pngzhipeng_7-1786181958976.pngzhipeng_7-1786181958976.png 5.3 中有错误。在编译过程中构建引导加载程序。 launch.bat 文件已被编辑。 zhipeng_0-1786182860528.pngzhipeng_0-1786182860528.pngzhipeng_0-1786182860528.pngzhipeng_0-1786182860528.pngzhipeng_0-1786182860528.png 运行 launch.bat 后发生错误。 zhipeng_0-1786180508617.pngzhipeng_0-1786180508617.pngzhipeng_0-1786180508617.pngzhipeng_0-1786180508617.pngzhipeng_0-1786180508617.png 在注释掉相关代码之后。 zhipeng_5-1786181360466.pngzhipeng_5-1786181360466.pngzhipeng_5-1786181360466.pngzhipeng_5-1786181360466.pngzhipeng_5-1786181360466.png zhipeng_2-1786180921774.pngzhipeng_2-1786180921774.pngzhipeng_2-1786180921774.pngzhipeng_2-1786180921774.pngzhipeng_2-1786180921774.png 我找到了 CryptoDal.h安装目录中的文件。 zhipeng_4-1786181305215.pngzhipeng_4-1786181305215.pngzhipeng_4-1786181305215.pngzhipeng_4-1786181305215.pngzhipeng_4-1786181305215.png zhipeng_6-1786181450684.pngzhipeng_6-1786181450684.pngzhipeng_6-1786181450684.pngzhipeng_6-1786181450684.pngzhipeng_6-1786181450684.png 哪里可能会出错？ 谢谢。 Re: S32G2 Enabling Multicore Application 嗨，志鹏 对于您的问题，如果添加以下内容，是否会出现错误？注释掉这段代码不会导致错误吗？ Joey_z_0-1786328574726.pngJoey_z_0-1786328574726.pngJoey_z_0-1786328574726.pngJoey_z_0-1786328574726.pngJoey_z_0-1786328574726.png BR 乔伊 Re: S32G2 Enabling Multicore Application 嗨， @Joey_z 是的，添加后，第三张图片上会显示“未声明”。 注释掉该行后，第五张图片将显示“没有该文件或目录”。 zhipeng_1-1786347067301.pngzhipeng_1-1786347067301.pngzhipeng_1-1786347067301.pngzhipeng_1-1786347067301.pngzhipeng_1-1786347067301.png “CryptoDal.h”位于 D:\NXP\Integration_Reference_Examples_S32G2_2022_06\code\framework\realtime\bsw\dal\cryptodal\generic\include “Hse_Ip.h”位于 D:\NXP\SW32G_RTD_4.4_3.0.2_HF01\eclipse\plugins\Crypto_TS_T40D11M30I2R0\include 目录下。 我在各自的文件夹中找到了这两个文件，并且 launch.bat 中也写入了文件路径。 目前的问题似乎是编译过程中没有包含插件路径。 BR Re: S32G2 Enabling Multicore Application 嗨，志鹏 配置中是否启用了安全启动？尝试启用安全启动，看看问题是否会消失。 Joey_z_2-1786353784256.pngJoey_z_2-1786353784256.pngJoey_z_2-1786353784256.pngJoey_z_2-1786353784256.pngJoey_z_2-1786353784256.png BR 乔伊 回复： S32G2 Enabling Multicore Application 嗨，志鹏 谢谢你提供的信息。 您能提供更多信息吗？ 1.您是否只在A核上启动ATF和uboot？A核的UART有任何输出吗？ 2.M核心功能是什么？是关于UART/CAN功能吗？ BR 乔伊 回复： S32G2 Enabling Multicore Application 嗨， @Joey_z 之前的引导加载程序编译成功。现在，我已经将镜像写入 或非 闪存，启动后，UART 上没有任何输出。 我指的是 AN13750。以下是我的操作步骤： 我按照“S32G2_LinuxBSP_42.0_User_Manual.pdf”中的说明操作，并在 Ubuntu 20 中安装了 u-boot bsp42.0-2022.04 和 ATF bsp42.0-2.10。 我修改了 s32_mmc.c以及根据 0001-fip-align-and-mmc-init.patch 的 s32_common.mk。 zhipeng_0-1787646642108.pngzhipeng_0-1787646642108.pngzhipeng_0-1787646642108.png志鹏_0-1787646642108.png zhipeng_1-1787646670172.pngzhipeng_1-1787646670172.pngzhipeng_1-1787646670172.png志鹏_1-1787646670172.png zhipeng_2-1787646683855.pngzhipeng_2-1787646683855.pngzhipeng_2-1787646683855.png志鹏_2-1787646683855.png 我编译了 u-boot 和 ATF。 make CROSS_COMPILE=/opt/S32G/arm-gnu-toolchain-11.3.rel1-x86_64-aarch64-none-linux-gnu/bin/aarch64-none-linux-gnu- ARCH=aarch64 PLAT=s32g274ardb2 BL33=../u-boot/u-boot-nodtb.bin Image Layout DCD: Offset: 0x200 Size: 0x1c IVT: Offset: 0x1000 Size: 0x100 AppBootCode Header: Offset: 0x1200 Size: 0x40 Application: Offset: 0x1240 Size: 0x33e00 Boot Core: A53_0 IVT Location: SD/eMMC Load address: 0x342f8f00 Entry point: 0x34302000 我将 fip.s32 写入了 SD 卡。更换 fip 后，SD 卡仍然能够启动，并且 u-boot 的日期发生了变化。 U-Boot 2022.04-00213-g5a6f62071f (Aug 24 2026 - 10:35:21 +0800) 配置引导加载程序。 zhipeng_3-1787647428751.pngzhipeng_3-1787647428751.pngzhipeng_3-1787647428751.png志鹏_3-1787647428751.png zhipeng_4-1787647490093.pngzhipeng_4-1787647490093.pngzhipeng_4-1787647490093.png志鹏_4-1787647490093.png zhipeng_5-1787647533346.pngzhipeng_5-1787647533346.pngzhipeng_5-1787647533346.png志鹏_5-1787647533346.png zhipeng_6-1787647547310.pngzhipeng_6-1787647547310.pngzhipeng_6-1787647547310.png志鹏_6-1787647547310.png 生成 S32G 启动映像 zhipeng_7-1787647657415.pngzhipeng_7-1787647657415.pngzhipeng_7-1787647657415.png志鹏_7-1787647657415.png 选择 bt_m7_blob.bin 并将其写入地址 0x0。 选择 fip.bin 并将其写入地址 0x100000。 选择 S32G274A_M7.bin 并将其写入地址 0x200000。 zhipeng_8-1787647865193.pngzhipeng_8-1787647865193.pngzhipeng_8-1787647865193.png志鹏_8-1787647865193.png 现在UART和CAN都没有响应了。请帮我分析一下情况。 谢谢。 回复： S32G2 Enabling Multicore Application 嗨， @Joey_z 感谢您的回复。 1. 是的，A 核心上只启动了 ATF 和 u-boot。UART接口没有任何输出。 2. M 内核运行 LLCE_CAN 和 Lpspi 程序，集成了“Can_Llce_DS_Loopback_S32G274A_M7”和“Lpspi_Ip_Transfer_S32G274A_M7”例程。它首先使用 SPI 通信，然后运行 LLCE_CAN。 我想补充一些信息： 1.整个过程按照 AN13750 进行，只有一些不同之处：我使用了 BSP42 和 S32DS3.5 版本；我用 LLCE_CAN 替换了 IPCF 例程，并且只配置了 M7_0。 2. 我使用 Yocto 编译了 BSP42，并生成了 .sdcard。导入SD卡后，即可启动Linux系统。 3. 我按照“AN13750” 4. 为 Cortex-A53 内核准备镜像 部分编译了 BSP42 的 u-boot 和 ATF。将 .sdcard 和 fip.s32 重新导入 SD 卡后，Linux 仍然可以在 SD 模式下启动。但是，当将引导加载程序和 fip.bin 导入到 norflash 时，没有获得任何输出。 4. 我在 norflash 中单独烧录了 M7 内核的 UART 例程，Linux 可以启动并输出。这证明燃烧工具和诺弗拉什（Norflash）都是正常的。 5. 我将 LLCE_CAN 程序单独烧录到 norflash 中。程序没有运行，也没有CAN输出。 6.我尝试配置 EB 引导加载程序以单独启动 A53，但重新烧录 norflash 后仍然没有任何输出。 谢谢。 回复： S32G2 Enabling Multicore Application 嗨，志鹏 1.我了解到您的 LLCE_CAN 运行在 M 内核上。请独立测试该程序 M 核心的引导加载程序启动情况。启动过程中，不要加载 A 核心映像。 2. 在您的测试中，引导加载程序可以启动 M7 的 UART 程序，但无法启动 LLCE_CAN 程序吗？ 3. 你有没有试过只使用引导加载程序启动 A53？ 我已在系统中用中文为此问题创建了一个新案例，案例编号为：01000969。这将有助于沟通。 BR 乔伊