KITPF0100EPEVBE KITPF0100EPEVBE評価ボード用の回路図ファイルをお願いします。おそらくCadence OrCad形式で。DSN形式で。 よろしくお願いします。 Re: KITPF0100EPEVBE こんにちは、ミエルコ 直接あなたのメールアドレスに送ります。

imx7ulp A7 配置 IOMUXC0 上的焊盘（LPUART0–3 和 I2C） 你好， 我们是学生，正在开发一块定制的imx7ulp (MCIMX7U3)板。我们希望使用Linux (A7) 系统来控制全部8个LPUART接口以及一些I2C线路。 LPUART4–7 使用 IOMUXC1（A7 功能域），在我们的 DTS 中工作正常。但是，LPUART0–3 和我们的 I2C 线使用IOMUXC0（M4 功能域）中的焊盘。 查看 Linux pinctrl 驱动程序和 U-Boot 源代码，似乎 A7 默认使用 IOMUXC1，而 U-Boot 使用特定的IOMUX_CONFIG_MPORTS标志来访问 IOMUXC0。参考手册也提到 IOMUXC 是“所有权受限”的。 我们卡在了 IOMUXC0 的引脚配置步骤。 我们的疑问： A7 是否有支持的方法（通过 DTS 节点或驱动程序标志）直接从 Linux 配置 IOMUXC0 焊盘？ 如果不是，M4 固件的标准预期流程是否是在启动期间复用这些引脚，然后 A7 接管 UART/I2C 控制器？ 由于障碍在于焊盘控制器（而不是外设协议），我们可以假设 I2C 线路面临与 UART 完全相同的限制吗？ 非常感谢您能就此方面的标准做法提供一些指导。 补充信息：我们的 Linux 系统基于 Wrynrose Yocto 版本，并使用 NXP 电路板支持包。

EB代码激活失败，许可证激活码无法使用。 你好， 我正在尝试激活 EB Tresos Studio 27.1.0。使用我的 NXP 软件帐户中提供的激活码，有效期至 2026 年 12 月 31 日。 但是，激活失败，并出现以下错误： 错误：flxActAppActivationSend (50040, 41147, 10248) 指定的数量超过了允许的最大数量（0）。 请您检查一下许可证是否已用完，并提供更新后的激活码？ 谢谢你！ Re: EB code failed activate code for license 嗨@Cip 给您带来的不便，我们深表歉意！ 我已经将此问题报告给相关团队；请等待他们更新网页上的激活码。 顺便一提，NXP 为 EB Tresos 提供免费评估许可证。生产许可证需要向Elektrobit公司订购。 此致敬礼， Robin

请求提供 MR-CANHUBK344 的已归档 S32K3 FreeRTOS 2.0.0 软件包 你好， 我正在使用 NXP MR-CANHUBK344 评估板，我需要 NXP 原始示例项目所需的已归档的 FreeRTOS 软件包。 所需文件： SW32K3_FreeRTOS_10_4_6_UOS_2_0_0_DS_updatesite_D2204.zip 我的环境： 电路板：MR-CANHUBK344 MCU：S32K344 S32 设计工作室：3.4 S32K3 开发包：3.4.3 S32K3 RTD AUTOSAR 4.4：2.0.0 我已经下载了所需的 S32DS、S32K3 开发包和 RTD 版本，但是 FreeRTOS 2.0.0 在下载门户中已不再提供。 请问您能否提供对已存档的 FreeRTOS 2.0.0 软件包的访问权限，或者为我的 NXP 帐户启用该软件包？ 谢谢！ Re: Request for archived S32K3 FreeRTOS 2.0.0 package for MR-CANHUBK344 嗨@lxndrkurus 您无法查看该产品，因为它已被存档。这意味着其中可能存在无法修复的漏洞。我们通常建议客户使用新版本。 但是，如果您坚持要测试旧版本，请稍等片刻，我会联系内部团队，让他们将软件添加到您的帐户中。 此致， 罗宾 Re: Request for archived S32K3 FreeRTOS 2.0.0 package for MR-CANHUBK344 @lxndrkurus前往： 汽车软件 - S32K3 标准软件->汽车软件 - S32K3 - FreeRTOS ->上一版本：SW32K3_FreeRTOS_10.4.6_2.0.0_D2204

MR-CANHUBK344用のアーカイブされたS32K3 FreeRTOS 2.0.0パッケージのリクエスト こんにちは、 私はNXP MR-CANHUBK344評価ボードを使っており、元のNXPサンプルプロジェクトに必要なアーカイブ済みFreeRTOSパッケージが必要です。 必須ファイル: SW32K3_FreeRTOS_10_4_6_UOS_2_0_0_DS_updatesite_D2204.zip 私の環境： 基板: MR-CANHUBK344 MCU:S32K344 S32 Design Studio:3.4 S32K3開発パッケージ:3.4.3 S32K3 RTD AUTOSAR 4.4: 2.0.0 必要なS32DS、S32K3開発パッケージ、RTD版はすでにダウンロード済みですが、FreeRTOS 2.0.0はダウンロードポータルからは利用できません。 このアーカイブ済みFreeRTOS 2.0.0パッケージへのアクセス権を提供できるか、私のNXPアカウントで有効にしていただけますか? よろしくお願いします。 Re: Request for archived S32K3 FreeRTOS 2.0.0 package for MR-CANHUBK344 こんにちは、 @lxndrkurus さん 製品はアーカイブされているため、見ることができません。つまり、修正されないバグが存在する可能性があるということです。通常、お客様に新しいバージョンの使用を推奨しています。 ただし、どうしても古いバージョンのテストを希望する場合は、内部チームに連絡してソフトウェアをアカウントに追加してもらうまでお待ちください。 よろしくお願いします、 ロビン Re: Request for archived S32K3 FreeRTOS 2.0.0 package for MR-CANHUBK344 @lxndrkurusアクセス先: 自動車ソフトウェア - S32K3標準ソフトウェア - > 自動車ソフトウェアソフトウェア - S32K3 - FreeRTOS ->  前回:SW32K3_FreeRTOS_10.4.6_2.0.0_D2204

Request for archived S32K3 FreeRTOS 2.0.0 package for MR-CANHUBK344 Hello, I am using the NXP MR-CANHUBK344 evaluation board and I need the archived FreeRTOS package required by the original NXP example project. Required file: SW32K3_FreeRTOS_10_4_6_UOS_2_0_0_DS_updatesite_D2204.zip My environment: Board: MR-CANHUBK344 MCU: S32K344 S32 Design Studio: 3.4 S32K3 Development Package: 3.4.3 S32K3 RTD AUTOSAR 4.4: 2.0.0 I have already downloaded the required S32DS, S32K3 Development Package and RTD versions, but FreeRTOS 2.0.0 is no longer available in the download portal. Could you please provide access to this archived FreeRTOS 2.0.0 package or enable it for my NXP account? Thank you. Re: Request for archived S32K3 FreeRTOS 2.0.0 package for MR-CANHUBK344 Hi @lxndrkurus  You cannot see the product because it is archived. It means there can be bugs in it, that will not be fixed. We usually recommend that customers use the newer version. However, if you insist on testing the older version, then please wait while I contact the internal team to have them add the software to your account. Best Regards, Robin Re: Request for archived S32K3 FreeRTOS 2.0.0 package for MR-CANHUBK344 @lxndrkurus  Go to: Automotive SW - S32K3 Standard Software -> Automotive SW - S32K3 - FreeRTOS ->  Previous: SW32K3_FreeRTOS_10.4.6_2.0.0_D2204

EB code failed activate code for license Hello, I’m trying to activate EB tresos Studio 27.1.0 using the activation code available in my NXP Software Account, valid until December 31, 2026. However, the activation fails with the following error: ERROR: flxActAppActivationSend (50040, 41147, 10248) The quantity specified exceeds maximum quantity allowed (0). Could you please check whether the license pool is depleted and provide an updated activation code? Thank you! Re: EB code failed activate code for license Hi  @Cip  Sorry for the inconvenience we bring you! I have reported this issue to the relevant team; please wait for them to update the activation code on the webpage. By the way, NXP provides free evaluation license for EB Tresos. Production license needs to be ordered from Elektrobit. Best Regards, Robin

imx7ulp A7はIOMUXC0（LPUART0～3およびI2C）上のパッドを設定します。 こんにちは、 私たちはカスタムのimx7ulp(MCIMX7U3)ボードで作業している学生です。Linux(A7)で8台すべてのLPUARTと一部のI2C回線を制御したいと考えています。 LPUART4～7はIOMUXC1（A7ドメイン）を使用しており、当社のDTSでは正常に動作しています。しかし、LPUART0～3と当社のI2CラインはIOMUXC0 （M4ドメイン）のパッドを使用しています。 LinuxのpinctrlドライバとU-Bootのソースを見ると、IOMUXC1がA7のデフォルトで、U-Bootは特定の IOMUX_CONFIG_MPORTSフラグを使ってIOMUXC0に触れているようです。リファレンス・マニュアルにはIOMUXCが「所有権ゲート」と書かれています。 IOMUXC0のピン設定手順で詰まっています。 私たちの質問： A7がLinuxから直接IOMUXC0パッドを設定できるサポート方法(DTSノードまたはドライバーフラグを通じて)はありますか? もしそうでなければ、M4ファームウェアの標準的なフローは起動時にこれらのピンを多番に処理し、その後A7がUART/I2Cコントローラを引き継ぐ形になっているのでしょうか? 障害は周辺プロトコルではなくパッドコントローラーなので、I2C回線もUARTsと同じ制限を受けていると考えてよいでしょうか? この件に関する標準的なアプローチについてご教示いただければ大変ありがたいです。 追加情報:私たちはWrynrose Yoctoリリースを基にNXP BSPを使ってLinuxをビルディングしています

FRDM-i.MX93 Support for Yocto Kirkstone Hi, We are currently using Yocto Kirkstone on our i.MX8MQ project and would like to evaluate the same image on the FRDM-i.MX93 board. The meta-imx-frdm repository appears to support Scarthgap. Is there an official Kirkstone-compatible branch or BSP available for FRDM-i.MX93? If not, is there any recommended approach to enable FRDM-i.MX93 support with Kirkstone? Thank you. Yocto Project Re: FRDM-i.MX93 Support for Yocto Kirkstone Hi @Zhiming_Liu , Thank you for your response. We are currently using the NXP Kirkstone BSP (LF5.15.71_2.2.0) for our i.MX8MQ project. Could you please clarify whether this BSP can be used as the starting point for porting the meta-imx-frdm layer to Kirkstone? Also, is there a recommended Kirkstone branch or release of the NXP BSP that already includes the necessary i.MX93 processor support? Our objective is to run our existing Kirkstone-based project image on FRDM-i.MX93, with the necessary board-specific modifications. Thank you for your guidance. With regards Ajil Re: FRDM-i.MX93 Support for Yocto Kirkstone Hi @ap3415  A Yocto release is needed to port the meta-imx-frdm layer to Kirkstone. Best Regards, Zhiming

EBコードがライセンスのアクティベーションコードに失敗しました こんにちは、 EB Tresos Studio 27.1.0 をアクティベートしようとしています。NXPソフトウェアアカウントで利用可能なアクティベーションコードを使用しており、有効期限は2026年12月31日です。 しかし、アクティベーションは以下のエラーで失敗します。 エラー: flxActAppActivationSend (50040, 41147, 10248) 指定された数量は、許容最大数量（0）を超えています。 ライセンスプールが空きしていないか確認し、更新されたアクティベーションコードを教えていただけますか? ありがとうございます! Re: EB code failed activate code for license こんにちは、 @Cipさん ご迷惑をおかけして申し訳ございません！ この件は担当チームに報告済みです。ウェブページ上のアクティベーションコードが更新されるまでしばらくお待ちください。 ちなみに、NXPはEB Tresosの無料評価ライセンスを提供しています。製造ライセンスはElektrobit社から取得する必要があります。 よろしくお願いいたします ロビン

imx7ulp A7 configure pads on IOMUXC0 (LPUART0–3 and I2C) Hello, We are students working on a custom imx7ulp (MCIMX7U3) board. We want Linux (A7) to control all 8 LPUARTs, plus some I2C lines. LPUART4–7 use IOMUXC1 (A7 domain) and are working fine in our DTS. However, LPUART0–3 and our I2C lines use pads in IOMUXC0 (M4 domain). Looking at the Linux pinctrl driver and U-Boot source, it seems IOMUXC1 is the default for A7, and U-Boot uses a specific IOMUX_CONFIG_MPORTS flag to touch IOMUXC0. The reference manual also mentions IOMUXC is "ownership-gated." We are stuck on the pin configuration step for IOMUXC0. Our questions: Is there a supported way (via DTS node or driver flag) for the A7 to configure IOMUXC0 pads directly from Linux? If not, is the standard intended flow for the M4 firmware to mux these pins during boot, and then the A7 just takes over the UART/I2C controllers? Since the obstacle is the pad controller (not the peripheral protocol), can we assume the I2C lines face the exact same restriction as the UARTs? Any guidance on the standard approach for this would be greatly appreciated. Extra info: We're building our linux on the Wrynrose Yocto release using the NXP BSP 

FRDM-i.MX93 Yocto・カークストーン対応 こんにちは、 現在、i.MX8MQプロジェクトでYocto Kirkstoneを使用しており、同じ画像をFRDM-i.MX93ボード上で評価したいと考えています。 meta-imx-frdm リポジトリはScarthgapをサポートしているようです。FRDM-i.MX93用の公式のKirkstone互換ブランチやBSPはありますか? もしそうでなければ、KirkstoneでFRDM-i.MX93のサポートを有効にするための推奨方法はありますか? よろしくお願いします。 Yocto Project Re: FRDM-i.MX93 Support for Yocto Kirkstone こんにちは@Zhiming_Liuさん ご返信ありがとうございます。 現在、i.MX8MQプロジェクトではNXP Kirkstone BSP（LF5.15.71_2.2.0）を使用しています。 このBSPをmeta-imx-frdmレイヤーをKirkstoneに移植する出発点として使えるのか、教えていただけますか? また、必要なi.MX93プロセッササポートが既に含まれている、KirkstoneのおすすめのNXP BSPブランチやリリースはありますか? 私たちの目標は、既存のKirkstoneベースのプロジェクトイメージを、必要なボード固有の変更を加えた上で、FRDM-i.MX93上で実行することです。 ご指導ありがとうございました。 に関して アジル Re: FRDM-i.MX93 Support for Yocto Kirkstone こんにちは、 @ap3415さん Meta-imx-frdmレイヤーをKirkstoneに移植するにはYoctoリリースが必要です。 よろしくお願いします、 志明

FRDM-i.MX93 支持 Yocto Kirkstone 您好， 我们目前正在 i.MX8MQ 项目中使用 Yocto Kirkstone，并希望在 FRDM-i.MX93 板上评估相同的映像。 The meta-imx-frdm代码库似乎支持 Scarthgap。是否有官方的 Kirkstone 兼容分支或电路板支持包。可用于 FRDM-i.MX93？ 如果没有，是否有推荐的方法可以在 Kirkstone 中启用 FRDM-i.MX93 支持？ 谢谢！ Yocto Project Re: FRDM-i.MX93 Support for Yocto Kirkstone 嗨@Zhiming_Liu ， 感谢您的反馈， 我们目前在 i.MX8MQ 项目中使用的是 NXP Kirkstone 电路板支持包。 (LF5.15.71_2.2.0)。 请问这个电路板支持包是否可以作为将 meta-imx-frdm 层移植到 Kirkstone 的起点？ 另外，是否有推荐的 Kirkstone 分支或 NXP 电路板支持包。版本，其中已经包含了必要的 i.MX93 处理器支持？ 我们的目标是在 FRDM-i.MX93 上运行我们现有的基于 Kirkstone 的项目镜像，并进行必要的针对特定电路板的修改。 感谢您的指导。 关于 阿吉尔 Re: FRDM-i.MX93 Support for Yocto Kirkstone 你好@ap3415 需要 Yocto 版本才能将 meta-imx-frdm 层移植到 Kirkstone。 此致， 志明

Kernel 6.6: Driver Communication Triggers Board Restart Due to Misaligned Address Access Hi All, We have a custom application and driver that were working correctly on kernel 4.14 on i.MX6SoloX processor. After migrating to kernel 6.6, we started observing an issue where the board unexpectedly restarts as soon as the driver begins communicating with the application. Below are the driver-side logs from dmesg. During debugging with gdb, we observed the following backtrace:   [Current thread is 1 (LWP 898)]   (gdb) bt   #0 gen_intern_attribute_record (header=0x6181b6 , hysteresis=0, poll_flag=1, type= , status= ,   data_length= ,   format= ,   data= )   at msgutil.c:192   Backtrace stopped: Cannot access memory at address 0x768fe7b4   (gdb) To investigate further, we added debug prints to check whether any addresses were not aligned to a 4-byte boundary. The following debug output was captured:   resp_attr_hdr alignment = 2   req_attr_hdr alignment = 0     ENTER nfn_fill_attr_rec   ENTRY resp_attr_hdr=0x5cb1b6   ENTRY align=2       DEBUG: resp_attr_hdr=0x5cb1b6   DEBUG: resp_align=2       INIT resp_attr_header=0x5bc1b6   INIT align=2       resp_msg_header=0x5bc196   resp_consider_point_type=0x5bc1ac   resp_time_record=0x5bc1ae   resp_poll_rate_ptr=0x5bc1b2   resp_num_attr_ptr=0x5bc1b4   resp_attr_header=0x5bc1b6   The addresses such as 0x5bc1b6 are not aligned to a 4-byte boundary (alignment = 2). This issue was never observed on kernel 4.14, but it consistently occurs on 6.6. What could be causing this behavior in kernel 6.6? One possible workaround is to force 4-byte alignment, but that may introduce protocol incompatibilities and lead to message format mismatches between communicating components. Any insights into alignment-related changes or stricter memory access handling in kernel 6.6 would be greatly appreciated. HW-Open-Source i.MX 8 Family | i.MX 8QuadMax (8QM) | 8QuadPlus i.MX6 All i.MX6DL i.MX6DualPlus | 6QuadPlus i.MX6S i.MX6SoloX Linux Yocto Project Re: Kernel 6.6: Driver Communication Triggers Board Restart Due to Misaligned Address Access Hi @syedrizwan  Please address the register access issues in the kernel driver first, and then look into the application-layer issues. Best Regards, Zhiming Re: Kernel 6.6: Driver Communication Triggers Board Restart Due to Misaligned Address Access Hi Zhiming_Liu,   Currently, the kernel does not crash when _raw_writel() is accessed. We would appreciate your support and insights regarding the issue described above.   Regards, Rizwan Syed

MCXN947/N547 LPADC温度センサ(ch26):HWトリガーチェーンにおけるVbe1/Vbe8の順序変化 こんにちは、 高速のハードウェアトリガーADCコマンドチェーン内のLPADC内部温度センサをMCXN947/MCXN547で測定しています。回避策で有効な温度は得られていますが、リファレンスマニュアルに記載されていない挙動を観察しています。これが想定される動作なのか、また、この回避策が本番環境で安全に使用できるのかを確認したいと思います。 1. 環境 MCU:MCXN947(FRDM-MCXN947に再現);ターゲットデバイスはMCXN547 SDK: MCUXpresso SDK 2026.06.00 ADC0クロック48MHz、16ビット、VREF Alt1 トリガー：PWM0 SM0 → INPUTMUX → ADC0 TRIG0、周期20µs（ハードウェアトリガー） チェーン:CMD1–CMD5(外部入力9本:×デュアルシングルエンド4本+シングルA×1本、ADCK11)→CMD6(ch26温度センサ) CMD6: ch26、差分（DiffBothSide）、STS7（131 ADCK）、ハードウェア平均化なし 2. 観察 チェーン内に LOOP 1 (2 つの結果) を含む CMD6: 両方の結果は Vbe1 レベルにあり、Vbe8 は決して現れません。 チェーン内に LOOP 3 (4 件の結果) を含む CMD6: 順序は Vbe1、Vbe1、Vbe8、Vbe1 です。 温度センサの連続的な単独変換のみ:変換ごとに交互にVbe1とVbe8が発生します。 1倍/8倍の状態は、コマンドごとにリセットされないようです。 RM方法(CMD7、STS7、AVGS 128、LOOP 1、SWトリガー)だけでは、初期化直後に2つ目の結果はVbe8ですが、高速チェーンが実行された後は1つ目がVbe8になります。 単独測定の最初の結果は、一部のブーツではVbe1、他のブーツではVbe8でした。 3. 参照されたSDKコード (MCX-N5XX-EVK SDK 2026.09.00、lpadc_temperature_measurement例) lpadc_temperature_measurement.c、183行目： 「最初の2つの不正確な結果を削除します。」— 初期化直後に1つの測定値（2つの結果）が破棄されます。理由は示されていない。 hardware_init.c、48～53行目（FSL_FEATURE_LPADC_TEMP_SENS_BUFFER_SIZE == 4 のデバイスのみ）：コメントには推奨されるループ回数は 4 とありますが、最初の 2 つの結果は役に立ちません。MCXN547 機能.h(240行目)はバッファサイズを2と定義しているため、これはMCX Nには適用されません。 hardware_init.c、59行目と62行目：2つの結果はVbe1→Vbe8の固定順序で使用されます（大きさのチェックは行われません）。 4. 現在の回避策 CMD6、LOOP 2 (3 結果): [0] を破棄し、[1]/[2] をペアとして使用します。 2つのうち大きい方をVbe8とする（固定されていない順序を処理する）。 ソフトウェアで平均128ペアを使い、RM §41.3.7のA/B/αの式をデータシート表57(771 / 302 / 10.06)から適用します。 RM方法(室温13秒)と比較して、平均差−0.15°C、標準偏差0.26°C。 チェーンは正常に動作しています（約50,000チェーン/秒、FIFOオーバーフローやトリガー例外は発生していません）。 5. 質問 なぜ、ch26が他のチャネルの直後に変換されたときに、最初のch26の結果が予想外になるのでしょうか?最初の変換は不正確(センサ/バッファの沈降)でしょうか?それとも1倍/8倍のスイッチが遅れて適用されているのでしょうか? SDK hardware_init.c で49行目、なぜ最初の2つの結果はバッファサイズ4のデバイスに対して「無意味」なのでしょうか?同じ理由で、他のチャネル変換後に得られる最初のch26もMCX N(バッファサイズ2)で破棄されるべきでしょうか? lpadc_temperature_measurement.c の「最初の 2 つの不正確な結果を削除」の原因は何ですか？183行目？これは初期化直後のみに適用されるのか、それとも他のADCアクティビティ後にも適用されるのか？ センサはどのような条件下で1x電流と8x電流を切り替え、その状態をリセットするもの(電源投入、ADCリセット、コマンド変更など)は何でしょうか?RM 41.3.7とSDK(hardware_init.c59行目/62行目）は「1番目 = Vbe1、2番目 = Vbe8」と仮定していますが、このボードでは順序が逆になることがあります。この注文はどのような条件下で保証されますか？ 上記の回避策(1つを破棄し、次の2つをマグニチュードで分類し、ソフトウェアで平均する)は本番環境で許容できますか?温度範囲全体にわたるリスクや、部品ごとのばらつきはありますか？ 関連する訂正表やアプリケーションノート、その他のドキュメントはありますか?(エラッタ改訂1.0 MCXNx4x_0P02G関連項目は見つかりませんでした。) 必要に応じて追加データやテストコードも提供できます。 よろしくお願いします。 開発ボード FRDMトレーニング MCX N

MCXN947/N547 LPADC 温度传感器（通道 26）：硬件触发链中的 Vbe1/Vbe8 顺序变化 你好， 我正在测量 MCXN947/MCXN547 上高速硬件触发 ADC 命令链中的 LPADC 内部温度传感器。我通过变通方法获得了有效的温度，但我观察到了一些参考手册中没有描述的行为。我想确认一下这是否是预期行为，以及这种变通方法在生产环境中是否安全。 1. 环境 MCU：MCXN947（在FRDM-MCXN947上复现）；目标设备为MCXN547 SDK：MCUXpresso SDK 2026.06.00 ADC0 时钟频率 48 MHz，16 位，VREF Alt1 触发信号：PWM0 SM0 → INPUTMUX → ADC0 TRIG0，周期 20 µs（硬件触发） 链路：CMD1–CMD5（9 个外部输入：4 × 双单端 + 1 × 单 A，ADCK11）→ CMD6（通道 26 温度传感器） CMD6：ch26，差异（DiffBothSide），STS7（131 ADCK），无 HW 平均 2. 观察 CMD6 链中包含 LOOP 1（2 个结果）：两个结果都在 Vbe1 级别；Vbe8 永远不会出现。 CMD6 带有 LOOP 3（4 个结果）链：顺序为 Vbe1、Vbe1、Vbe8、Vbe1。 仅对温度传感器进行连续独立组网 \(SA\)转换：每次转换的结果交替为 Vbe1/Vbe8。 1x/8x 状态似乎不会因命令而 RESET： 仅使用 RM 方法（CMD7、STS7、AVGS 128、LOOP 1、SW 触发信号），初始化后第二个结果是 Vbe8，但高速链运行后，第一个结果是 Vbe8。 独立组网 \(SA\)测量的第一个结果是，有些靴子为 Vbe1，有些靴子为 Vbe8。 3. 参考的 SDK 代码（MCX-N5XX-EVK SDK 2026.09.00，lpadc_temperature_measurement 示例） lpadc_temperature_measurement.c，第 183 行： “消除前两个不准确的结果。”— 初始化后立即丢弃一次测量（2 个结果）。未给出理由。 hardware_init.c，第 48-53 行（仅适用于 FSL_FEATURE_LPADC_TEMP_SENS_BUFFER_SIZE == 4 的设备）：注释说建议的 LOOP 计数为 4，但前两个结果无用。MCXN547 功能.h（第 240 行）定义了缓冲区大小为 2，因此这不适用于 MCX N。 hardware_init.c，第 59 行和第 62 行：这两个结果按固定顺序使用，即 Vbe1 → Vbe8（不进行幅度检查）。 4. 目前的权宜之计 CMD6 LOOP 2（3 个结果）：丢弃 [0]，使用 [1]/[2] 作为一对。 两者中较大的那个被选为 Vbe8（处理非固定顺序）。 在软件中取 128 对的平均值，然后应用 RM §41.3.7 中的公式，其中 A/B/α 来自数据表表 57 (771 / 302 / 10.06)。 与 RM 方法（室温，13 秒）相比：平均差异 −0.15 °C，标准偏差 0.26 °C。 链运行正常（~50,000 链/秒，无 FIFO 溢出或触发信号异常）。 5. 问题 为什么当 ch26 在其他频道之后立即进行转换时，第一个 ch26 结果会出乎意料？是第一次转换不准确（传感器/缓冲区稳定），还是 1x/8x 开关应用得太晚？ 在 SDK hardware_init.c 中第 49 行，为什么缓冲区大小为 4 的设备的前两个结果“无用”？出于同样的原因，在 MCX N（缓冲区大小为 2）上，经过其他通道转换后的第一个 ch26 结果是否也应该被丢弃？ lpadc_temperature_measurement.c 文件中“消除前两个不准确结果”的原因是什么？第 183 行？它是否仅在初始化之后立即生效，还是也适用于其他ADC活动之后？ 传感器在什么情况下会在 1 倍电流和 8 倍电流之间切换？什么情况会 RESET 该状态（上电、ADC 复位、命令更改等）？RM 41.3.7 和 SDK（hardware_init.c）第 59/62 行）假设“第一个 = Vbe1，第二个 = Vbe8”，但在这个电路板上，顺序有时会颠倒。在什么条件下可以保证该订单的有效性？ 上述变通方法（丢弃一个结果，按大小对接下来的两个结果进行分类，在软件中取平均值）是否适用于生产环境？温度范围或部件间差异是否存在风险？ 是否有相关的勘误表、应用笔记或其他文档？（我在 MCXNx4x_0P02G 勘误表 Rev. 1.0 中找不到相关条目。） 如有需要，我可以提供更多数据或测试代码。 谢谢！ 开发板 FRDM 培训 MCX N

MCXN947/N547 LPADC temp sensor (ch26): Vbe1/Vbe8 order changes in HW-triggered chain Hello, I am measuring the LPADC internal temperature sensor inside a high-speed, hardware-triggered ADC command chain on MCXN947/MCXN547. I am getting valid temperatures with a workaround, but I have observed behavior that is not described in the Reference Manual. I would like to confirm whether this is expected behavior and whether the workaround is safe for production. 1. Environment MCU: MCXN947 (reproduced on FRDM-MCXN947); target device is MCXN547 SDK: MCUXpresso SDK 2026.06.00 ADC0 clock 48 MHz, 16-bit, VREF Alt1 Trigger: PWM0 SM0 → INPUTMUX → ADC0 TRIG0, 20 µs period (HW trigger) Chain: CMD1–CMD5 (9 external inputs: 4 × dual single-ended + 1 × single A, ADCK11) → CMD6 (ch26 temperature sensor) CMD6: ch26, differential (DiffBothSide), STS7 (131 ADCK), no HW averaging 2. Observations CMD6 with LOOP 1 (2 results) inside the chain: both results are at the Vbe1 level; Vbe8 never appears. CMD6 with LOOP 3 (4 results) inside the chain: the order is Vbe1, Vbe1, Vbe8, Vbe1. Continuous standalone conversions of the temperature sensor only: results alternate Vbe1/Vbe8 on every conversion. The 1x/8x state does not appear to be reset per command: With the RM method alone (CMD7, STS7, AVGS 128, LOOP 1, SW trigger), the second result is Vbe8 right after initialization, but after the high-speed chain has been running, the first result is Vbe8. The first result of a standalone measurement is Vbe1 on some boots and Vbe8 on others. 3. SDK code referenced (MCX-N5XX-EVK SDK 2026.09.00, lpadc_temperature_measurement example) lpadc_temperature_measurement.c, line 183: “Eliminate the first two inaccurate results.” — one measurement (2 results) is discarded right after initialization. No reason is given. hardware_init.c, lines 48–53 (only for devices with FSL_FEATURE_LPADC_TEMP_SENS_BUFFER_SIZE == 4): the comment says the recommended LOOP count is 4 but the first two results are useless. MCXN547 features.h (line 240) defines a buffer size of 2, so this does not apply to MCX N. hardware_init.c, lines 59 and 62: the two results are used in fixed order as Vbe1 → Vbe8 (no magnitude check). 4. Current workaround CMD6 with LOOP 2 (3 results): discard [0], use [1]/[2] as a pair. The larger of the two is taken as Vbe8 (handles the unfixed order). Average 128 pairs in software, then apply the formula in RM §41.3.7 with A/B/α from datasheet Table 57 (771 / 302 / 10.06). Compared with the RM method (room temperature, 13 s): mean difference −0.15 °C, standard deviation 0.26 °C. Chain runs normally (~50,000 chains/s, no FIFO overflow or trigger exception). 5. Questions What causes the first ch26 result to be unexpected when ch26 is converted right after other channels? Is the first conversion inaccurate (sensor/buffer settling), or is the 1x/8x switch applied late? In SDK hardware_init.c line 49, why are the first two results “useless” for devices with a buffer size of 4? For the same reason, should the first ch26 result after other-channel conversions also be discarded on MCX N (buffer size 2)? What is the cause of “Eliminate the first two inaccurate results” in lpadc_temperature_measurement.c line 183? Does it apply only right after initialization, or also after other ADC activity? Under what conditions does the sensor switch between 1x and 8x current, and what resets that state (power-up, ADC reset, command change, etc.)? RM 41.3.7 and the SDK (hardware_init.c lines 59/62) assume “first = Vbe1, second = Vbe8”, but on this board the order is sometimes reversed. Under what conditions is this order guaranteed? Is the workaround above (discard one result, classify the next two by magnitude, average in software) acceptable for production? Are there risks across the temperature range or part-to-part variation? Is there any related errata, application note, or other documentation? (I could not find a related item in MCXNx4x_0P02G Errata Rev. 1.0.) I can provide additional data or test code if needed. Thank you. Development Board FRDM-Training MCXN

TJA1410 Support - Does not accepting commands Hi Team, I am using the TJA1410 as the External Transceiver for our Project (using the TJA1410A-EVB). Our SoC (which having integrated T1S dPHY) is sending some commands to the Analog PHY, but the commands are not accepting by the TJA1410A. I have few doubts regarding that: 1. Whether the signals sent to the TJA1410 should need to obey the exact timings whatever mentioned in the OA3P document (OPEN_Alliance_10BASE-T1S_PMD_Transceiver_Interface_1p5_Final.pdf), what if we are sending the different Duration clock pulse to the External Analog PHY, will it work still? Which means the clock Frequency for the 10baseT1S-dPHY IP should need to be a fixed one, is it necessary? 2. I am supplying 3.3V to the EVB for VIO and VCC and having the 1.8V (LOGIC HIGH) to 0V (LOGIC LOW) for the RX/TX/ED Inputs, whether the TJA1410A silicon has any Internal Voltage Level shifters? I can't be able to Find the datasheet in the page. 3. Can I get any App notes for this TJA1410A Transceiver? We are in the mid of our Project so can you please consider this as High-Priority case and reply ASAP?  Thanks, Madhan Re: TJA1410 Support - Does not accepting commands Hello @Madhan1 , The most likely issue is the voltage-level mismatch between your SoC and the TJA1410A. OA 3-pin interface timing The OPEN Alliance 3-pin interface is clock-less, so there is no separate interface clock with one fixed frequency. However, the TX command and data pulse widths must meet the timing requirements defined by the OPEN Alliance specification and the TJA1410 data sheet. If the pulse durations are outside the specified ranges, the TJA1410 may not recognize the command correctly. Therefore, please verify the TX waveform directly at the TJA1410A-EVB connector using an oscilloscope or logic analyzer, including the pulse widths, signal rise and fall times, and the command sequence. VIO and digital signal levels The TJA1410A mounted on the TJA1410A-EVB is the 3.3 V VIO variant. When VIO is supplied with 3.3 V, a 1.8 V HIGH level on TX is not sufficient to meet the guaranteed input HIGH threshold. The device does not provide internal level shifting that would allow a 1.8 V host to directly drive the TJA1410A while VIO is supplied with 3.3 V. For a 1.8 V digital interface, please use one of the following options: use the TJA1410B variant, which supports a 1.8 V VIO interface, or add a suitable external voltage-level translator between the SoC and the TJA1410A. Please also note that RX and ED are driven according to the selected VIO voltage, so the voltage compatibility must be checked in both directions. Documentation The relevant documents are: TJA1410 data sheet AN14787, 10BASE-T1S Ethernet PMD Transceiver TJA1410 UM12432, TJA1410-EVB Evaluation Board User Manual OPEN Alliance 10BASE-T1S PMD Transceiver Interface Specification, version 1.5 Some TJA1410 documentation may require an NXP account, NDA and Secure Access approval. As the first debugging step, I recommend correcting the 1.8 V versus 3.3 V interface mismatch and then checking the TX command waveform against the timing limits in the TJA1410 data sheet. Best regards, Pavel Re: TJA1410 Support - Does not accepting commands Hi @PavelL , Thanks for your timely Reply. And I have confirmed that in our setup we are having the External Level Shifter for converting the 1.8V to 3.3V for the TX/RX/ED Pins. Meanwhile what is the purpose of Internal Level Shifter present inside the TJA1410A Transceiver? I initially thought the Internal Level shifter will take care of this Voltage conversion. Anyhow we are having the External Level shifter so no worries. And our VCC and VIO supply is also 3.3V. And the termination Resistors also connected with the Headers. Regarding the OA3P timing specs, for example if I am sending the CONFIG command to TJA1410A as 80ns Low/80ns High/64us Low instead of 20ns Low/20ns High/16us Low will the TJA1410A will recognize it as CONFIG command or RESET command (because as per Ideal OA3P spec 80ns is for the RESET command)? Thanks, Madhan

カーネル6.6:ドライバ通信がアドレスアクセスの不一致によりボード再起動を引き起こす こんにちは、皆さん。 カスタムアプリケーションとドライバは、 i.MX6SoloXプロセッサ上のカーネル4.14で正しく動作していました。カーネル 6.6に移行した後、ドライバがアプリケーションと通信し始めるとすぐにボードが予期せず再起動する問題が観察されました。 以下はdmesgのドライバ側ログです。 gdbを使ったデバッグ中に、以下のバックトレースが観測されました。   [現在のThreadは1(LWP 898)]   (gdb) bt   #0 gen_intern_attribute_record (header=0x6181b6 , hysteresis=0, poll_flag=1, type= , status= ,   data_length= のメモリにアクセスできません。   format= のメモリにアクセスできません。   data= のメモリにアクセスできません)   msgutil.c:192   バックトレース停止:アドレス0x768fe7b4のメモリにアクセスできません   (gdb) さらに調査するため、アドレスが4バイト境界にアラインされていないかどうかを確認するデバッグ出力を追加しました。以下のデバッグ出力が取得されました。   resp_attr_hdr のアライメント = 2   req_attr_hdr の配置 = 0     nfn_fill_attr_rec を入力してください   エントリ resp_attr_hdr=0x5cb1b6   エントリ align=2       デバッグ: resp_attr_hdr=0x5cb1b6   デバッグ: resp_align=2       INIT resp_attr_header=0x5bc1b6   INIT align=2       resp_msg_header=0x5bc196   resp_consider_point_type=0x5bc1ac   resp_time_record=0x5bc1ae   resp_poll_rate_ptr=0x5bc1b2   resp_num_attr_ptr=0x5bc1b4   resp_attr_header=0x5bc1b6   0x5bc1b6などのアドレスは4バイト境界にアラインされていません（アラインメント＝2）。この問題はカーネル4.14では一度も確認されませんでしたが、 6.6では常に発生します。 カーネル6.6でこの動作の原因は何でしょうか?考えられる回避策の一つは、4バイトアライメントを強制することですが、これはプロトコルの非互換性を引き起こし、通信コンポーネント間でメッセージフォーマットの不一致につながる可能性があります。 カーネル6.6におけるアライメント関連の変更やメモリアクセス処理の厳格化に関する洞察があれば大変ありがたいです。 HW-Open-Source i.MX 8ファミリ | i.MX 8QuadMax (8QM) | 8QuadPlus i.MX6 全て i.MX6DL i.MX6DualPlus | 6QuadPlus i.MX6S i.MX6SoloX Linux Yocto Project Re: Kernel 6.6: Driver Communication Triggers Board Restart Due to Misaligned Address Access こんにちは@syedrizwan  まずカーネルドライバーのレジスタアクセスの問題に対処し、その後アプリケーション層の問題を調べてください。 よろしくお願いします、 志明 Re: Kernel 6.6: Driver Communication Triggers Board Restart Due to Misaligned Address Access こんにちは、 Zhiming_Liuさん   現在、_raw_writel()へのアクセス時にカーネルはクラッシュしません。上記の問題について、皆さまのサポートとご意見をいただけると幸いです。   よろしくお願いいたします。 リズワン・サイード

TJA1410 支持 - 不接受命令 大家好， 我正在使用 TJA1410 作为我们项目的外部收发器（使用 TJA1410A-EVB）。我们的 SoC（集成了 T1S dPHY）正在向模拟 PHY 发送一些命令，但 TJA1410A 不接受这些命令。对此我几乎没有什么疑问： 1. 发送到 TJA1410 的信号是否需要严格遵守 OA3P 文档（ OPEN_Alliance_10BASE-T1S_PMD_Transceiver_Interface_1p5_Final.pdf ）中提到的任何时序？如果我们向外部模拟PHY发送不同持续时间的时钟脉冲，它还能正常工作吗？这意味着 10baseT1S-dPHY IP 的时钟频率需要是固定的，这是必要的吗？ 2. 我给EVB的VIO和VCC供电3.3V，RX/TX/ED输入端的电压范围为1.8V（逻辑高）到0V（逻辑低），TJA1410A芯片是否有内部电压等级转换器？我无法在页面上找到数据表。 3. 能否提供关于TJA1410A收发器的应用笔记？ 我们的项目正在进行中，所以请您将此事视为高优先级事项并尽快回复。 谢谢， 马丹 Re: TJA1410 Support - Does not accepting commands 嗨@PavelL ， 感谢您的及时回复。 我已经确认，在我们的设置中，我们使用了外部电平转换器，将 1.8V 转换为 3.3V，用于 TX/RX/ED 引脚。 同时，TJA1410A 收发器内部的内部电平转换器的作用是什么？ 我最初认为内部电平转换器会处理这种电压转换。总之，我们有外部电平转换器，所以不用担心。我们的VCC 和 VIO 电源也是 3.3V 。终端电阻器也与接头连接。 关于 OA3P 时序规范，例如，如果我向 TJA1410A 发送CONFIG命令时序为80ns 低/80ns 高/64us 低，而不是20ns 低/20ns 高/16us 低，TJA1410A 会将其识别为 CONFIG 命令还是RESET命令（因为根据理想的 OA3P 规范，80ns 是 RESET 命令的时序）？ 谢谢， 马丹 Re: TJA1410 Support - Does not accepting commands 你好@Madhan1 ， 最可能的问题是您的 SoC 和 TJA1410A 之间的电压等级不匹配。 OA 3 针接口时序 OPEN Alliance 的 3 针接口没有时钟，因此没有单独的固定频率接口时钟。但是，TX 命令和数据脉冲宽度必须满足 OPEN Alliance 规范和 TJA1410 数据手册中定义的时序要求。 如果脉冲持续时间超出指定范围，TJA1410 可能无法正确识别命令。因此，请使用示波器或逻辑分析仪直接在 TJA1410A-EVB 连接器处验证 TX 波形，包括脉冲宽度、信号上升和下降时间以及命令序列。 VIO 和数字信号电平 安装在 TJA1410A-EVB 上的 TJA1410A 是 3.3 V VIO 版本。当 VIO 供电为 3.3V 时，TX 上的 1.8V 高电平不足以满足保证的输入高电平阈值。 该设备不提供内部电平转换，因此无法让 1.8 V 主机直接驱动 TJA1410A，而 VIO 供电电压为 3.3 V。 对于 1.8V 数字接口，请使用以下选项之一： 使用支持 1.8 V VIO 接口的 TJA1410B 型号，或者 在 SoC 和 TJA1410A 之间添加合适的外部电压等级转换器。 另请注意，RX 和 ED 是根据选定的 VIO 电压驱动的，因此必须双向检查电压兼容性。 文档 相关文件如下： TJA1410 数据表 AN14787，10BASE -T1S 以太网 PMD 收发器 TJA1410 UM12432、 TJA1410-EVB 评估板用户手册 开放联盟 10BASE-T1S PMD 收发器接口规范，版本 1.5 某些 TJA1410 文档可能需要 NXP 帐户、NDA 和安全访问批准。 作为第一个调试步骤，我建议纠正 1.8 V 与 3.3 V 接口不匹配的问题，然后根据 TJA1410 数据手册中的时序限制检查 TX 命令波形。 顺祝商祺！ 帕维尔