Multi Source Translation Content

キャンセル
次の結果を表示 
表示  限定  | 次の代わりに検索 
もしかして: 

Multi Source Translation Content

ディスカッション

ソート順:
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 Re: EB code failed activate code for license Activation code was updated. Thank you!
記事全体を表示
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 Re: FRDM-i.MX93 Support for Yocto Kirkstone Hi @ap3415  You may try using the Kirkstone-based BSP release lf-5.15.71-2.2.2  and porting the FRDM-i.MX93 configurations from the Scarthgap-based meta-imx-frdm layer. In addition to the machine configuration, please also review the corresponding U-Boot configuration, kernel device tree, board-support patches and recipe dependencies. Since this combination has not been officially validated, some adaptation may be required due to the differences between the Kirkstone and Scarthgap BSP versions. 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社から取得する必要があります。 よろしくお願いいたします ロビン Re: EB code failed activate code for license アクティベーションコードが更新されました。 ありがとう!
記事全体を表示
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リリースが必要です。 よろしくお願いします、 志明 Re: FRDM-i.MX93 Support for Yocto Kirkstone こんにちは、 @ap3415さん KirkstoneベースのBSPリリースlf-5.15.71-2.2.2を使用し、Scarthgapベースのmeta-imx-frdmレイヤーからFRDM-i.MX93構成を移植してみてください。 マシンの設定に加えて、対応するU-Boot設定、カーネルデバイスツリー、ボードサポートパッチ、レシピ依存関係も確認してください。この組み合わせは公式に検証されていないため、カークストーン版とスカースギャップ版のBSPの違いにより、何らかの調整が必要になる場合があります。 よろしくお願いします、 志明
記事全体を表示
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。 此致, 志明 Re: FRDM-i.MX93 Support for Yocto Kirkstone 你好@ap3415 您可以尝试使用基于 Kirkstone 的 电路板支持包。版本 lf-5.15.71-2.2.2,并将 FRDM-i.MX93 配置从基于 Scarthgap 的 meta-imx-frdm 层移植过来。 除了机器配置之外,请同时检查相应的 U-Boot 配置、内核设备树、板级支持补丁和配方依赖项。由于此组合尚未得到官方验证,因此由于 Kirkstone 和 Scarthgap 电路板支持包。版本之间的差异,可能需要进行一些调整。 此致, 志明
記事全体を表示
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 Re: Kernel 6.6: Driver Communication Triggers Board Restart Due to Misaligned Address Access Hi @syedrizwan  This is a custom application-layer issue, and NXP is unable to provide further recommendations based on the customer’s custom application-layer source code. Best Regards, Zhiming
記事全体を表示
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 Re: MCXN947/N547 LPADC temp sensor (ch26): Vbe1/Vbe8 order changes in HW-triggered chain こんにちは、 @ryanhong さん。 ご質問ありがとうございます。 あなたのアプリケーションについては、CH26を独立したコマンドとソフトウェアトリガーで別々に測定することをお勧めします。 高速ハードウェアトリガーチェーンは外部チャネルにのみ使用可能です。例えば100msごとにチェーンを一時停止し、CH26を測定してから外部チャネルチェーンを再開できます。 チップ温度の変化は20μsよりはるかに遅いため、内部温度センサを50kHzで測定する必要は一般的にありません。接合部温度のモニタリングには、通常100ミリ秒の間隔で十分です。 この方法は、外部チャネルと内部温度センサ間の頻繁な切り替えの影響を減らすのにも役立ちます。 よろしくお願いします。 BR アリス
記事全体を表示
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 Re: MCXN947/N547 LPADC temp sensor (ch26): Vbe1/Vbe8 order changes in HW-triggered chain 你好@ryanhong 谢谢你的提问。 针对您的应用,我建议使用独立的命令和软件触发单独测量 CH26。 高速硬件触发链只能用于外部通道。您可以定期暂停链路,例如每 100 毫秒暂停一次,测量 CH26,然后恢复外部通道链路。 由于芯片温度变化速度远慢于 20 µs,因此通常无需以 50 kHz 的频率测量内部温度传感器。通常情况下,100毫秒的间隔足以进行结温监测。 这种方法还有助于减少频繁切换外部通道和内部温度传感器的影响。 谢谢! BR 爱丽丝
記事全体を表示
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 Re: MCXN947/N547 LPADC temp sensor (ch26): Vbe1/Vbe8 order changes in HW-triggered chain Hello @ryanhong  Thanks for your question. For your application, I suggest measuring CH26 separately using an independent command and software trigger. The high-speed hardware-triggered chain can be used only for the external channels. You can periodically pause the chain, for example every 100 ms, measure CH26, and then resume the external-channel chain. Since the chip temperature changes much more slowly than 20 µs, there is generally no need to measure the internal temperature sensor at 50 kHz. A 100 ms interval should normally be sufficient for junction temperature monitoring. This method also helps reduce the impact of frequent switching between the external channels and the internal temperature sensor. Thank you. BR Alice
記事全体を表示
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 Re: TJA1410 Support - Does not accepting commands Hello @Madhan1 , If an external bidirectional level translator is already used between the 1.8 V SoC interface and the 3.3 V TX/RX/ED interface, the voltage domains can be compatible. The “Transmitter Level Shifter” shown in the TJA1410 block diagram is part of the internal analog transmitter path. It converts internal control signals to the voltage domain required by the analog MDI transmitter. It is not a level translator for the external TX/RX/ED host interface. Regarding your CONFIG command example, the proposed timing: 80 ns LOW 80 ns HIGH 64 µs LOW is not a valid CONFIG command timing for the TJA1410. According to the TJA1410 detection limits published in the Data Sheet, Table 14 : the CONFIG LOW pulse must be between 10 ns and 33 ns, the CONFIG HIGH pulse must be between 10 ns and 40 ns, the following CONFIG assertion time must be at least 15 µs. An 80 ns LOW pulse is outside the CONFIG detection range. Moreover, 80 ns falls within the RESET command detection range of 55 ns to 120 ns. Therefore, the first 80 ns LOW pulse may be interpreted as a RESET command after TX returns HIGH. Best regards, Pavel Re: TJA1410 Support - Does not accepting commands Hi @PavelL , Thanks for your reply. I understood your opinion regarding the timings. One more doubt, my hardware setup is like I am having the Pull Up Resistors of 47Kohm connected in all the three pins (RX/TX/ED) does this cause any issue in the communication and the External Pull Up resistors are recommended? I have connected only two nodes one side is my SoC and other side is the Linux PC (connected via 10baseT1S to USB bridge). I think we don't need to worry about the above node details because currently we are stuck with the Analog PHY wake up itself, if it wakes up then only, we can proceed further by transferring some packets. Thanks, Madhan Re: TJA1410 Support - Does not accepting commands Hello @Madhan1 , External 47 kΩ pull-up resistors on TX, RX, and ED are generally not required because the TJA1410 already provides the relevant internal pull-ups. Due to their relatively high resistance, the 47 kΩ pull-ups are unlikely to be the primary cause of the issue. However, they may affect the signal edges together with the level translator and line capacitance, and RX and ED can change direction during Configuration mode. For debugging, I recommend temporarily removing the external pull-ups and measuring TX directly at the TJA1410 pin. Please verify that the RESET command meets the specified timing and check whether RX becomes HIGH and ED LOW after the transition to Normal mode. Bets regards, Pavel Re: TJA1410 Support - Does not accepting commands Hi @PavelL , Thanks for your support.  Using your answers we were looking into the issue, I think we have almost figured out, if any more doubts, I will ping you back in this same thread. 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()へのアクセス時にカーネルはクラッシュしません。上記の問題について、皆さまのサポートとご意見をいただけると幸いです。   よろしくお願いいたします。 リズワン・サイード Re: Kernel 6.6: Driver Communication Triggers Board Restart Due to Misaligned Address Access こんにちは@syedrizwan  これはカスタムアプリケーション層の問題であり、NXPはお客様のカスタムアプリケーションレイヤーソースコードに基づくさらなる推奨を行うことはできません。 よろしくお願いします、 志明
記事全体を表示
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 命令波形。 顺祝商祺! 帕维尔 Re: TJA1410 Support - Does not accepting commands 嗨@PavelL , 感谢您的回复。 我理解你对时间安排的看法。 还有一个疑问,我的硬件设置是在所有三个引脚(RX/TX/ED)上都连接了 47Kohm 的上拉电阻,这会对通信造成任何问题吗?是否建议使用外部上拉电阻? 我只连接了两个节点,一端是我的SoC,另一端是Linux PC(通过10baseT1S转USB桥接器连接)。我认为我们不必担心上述节点细节,因为目前我们只关注模拟 PHY 的唤醒,只有唤醒成功,我们才能继续传输一些数据包。 谢谢, 马丹 Re: TJA1410 Support - Does not accepting commands 你好@Madhan1 , 通常不需要在 TX、RX 和 ED 上使用外部 47 kΩ 上拉电阻,因为 TJA1410 已经提供了相关的内部上拉电阻。 由于其相对较高的电阻,47 kΩ 上拉电阻不太可能是造成问题的主要原因。但是,它们可能会与电平转换器和线路电容一起影响信号边沿,并且在配置模式下,RX 和 ED 可能会改变方向。 为了进行调试,我建议暂时移除外部上拉电阻,直接在 TJA1410 引脚上测量 TX。请验证 RESET 命令是否符合规定的时序,并检查在过渡到正常模式后 RX 是否变为高电平,ED 是否变为低电平。 贝茨致意, 帕维尔 Re: TJA1410 Support - Does not accepting commands 你好@Madhan1 , 如果在 1.8 V SoC 接口和 3.3 V TX/RX/ED 接口之间已经使用了外部双向电平转换器,则电压域可以兼容。 TJA1410框图中所示的“发射器电平转换器”是内部模拟发射器路径的一部分。它将内部控制信号转换为模拟 MDI 发射器所需的电压域。它不是外部 TX/RX/ED 主机接口的电平转换器。 关于您提供的 CONFIG 命令示例,建议的执行时间如下: 80 纳秒 低 80 纳秒高 64 微秒 低 对于 TJA1410 来说,这不是有效的 CONFIG 命令时序。 根据数据表表 14 中公布的 TJA1410 检测限: CONFIG LOW 脉冲的持续时间必须在 10 ns 到 33 ns 之间。 CONFIG HIGH 脉冲的持续时间必须在 10 ns 到 40 ns 之间。 以下 CONFIG 断言时间必须至少为 15 µs。 80 ns 的低电平脉冲超出了 CONFIG 检测范围。此外,80 ns 落在 RESET 命令检测范围 55 ns 至 120 ns 内。因此,第一个 80 ns 低脉冲可以解释为 TX 返回高电平后的 RESET 命令。 顺祝商祺! 帕维尔 Re: TJA1410 Support - Does not accepting commands 嗨@PavelL , 感谢您的支持。 我们根据您的回答调查了这个问题,我想我们已经基本弄清楚了,如果还有任何疑问,我会在这个帖子里再次联系您。 谢谢, 马丹
記事全体を表示
内核 6.6:驱动程序通信因地址访问错位触发信号主板重启 大家好, 我们有一个自定义应用程序和驱动程序,在 i.MX6SoloX 处理器的 4.14内核上可以正常工作。迁移到内核6.6后,我们开始观察到一个问题,即当驱动程序开始与应用程序通信时,板会意外重启。 以下是来自 dmesg 的驱动程序端日志。 在使用 gdb 进行调试时,我们观察到以下回溯信息:   [当前线程为 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 alignment = 2   req_attr_hdr alignment = 0     输入 nfn_fill_attr_rec   条目 resp_attr_hdr=0x5cb1b6   ENTRY align=2       调试信息:resp_attr_hdr=0x5cb1b6   调试:resp_align=2       初始化 resp_attr_header=0x5bc1b6   初始化对齐方式=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-开源 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 嗨,刘志明,   目前,访问 _raw_writel() 时内核不会崩溃。我们非常感谢您能就上述问题提供支持和见解。   此致, 里兹万·赛义德 Re: Kernel 6.6: Driver Communication Triggers Board Restart Due to Misaligned Address Access 嗨@syedrizwan 这是一个自定义应用层问题,NXP 无法根据客户的自定义应用层源代码提供进一步的建议。 此致, 志明
記事全体を表示
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. VIOとVCCに3.3VをEVBに供給し、RX/TX/ED入力に1.8V(ロジックHIGH)から0V(ロジックLOW)を設定していますが、TJA1410Aシリコンには内部電圧レベルシフターはありますか?ページ内のデータシートが見つかりません。 3. このTJA1410Aトランシーバのアプリノートをもらえますか? 今、プロジェクトの途中なので、SO CAN、これを優先度の高いCASEとして考え、できるだけ早く返信していただけませんか? ありがとうございます。 マダン Re: TJA1410 Support - Does not accepting commands こんにちは、 @PavelL さん。 迅速なご返信ありがとうございます。 また、当社のシステム構成では、TX/RX/EDピンの1.8Vを3.3Vに変換するための外部レベルシフターを使用していることを確認しました。 一方で、TJA1410Aトランシーバ内部にある 内部レベルシフター の目的は何ですか? 当初は、内蔵のレベルシフターがこの電圧変換を処理してくれると思っていました。とにかく、外部レベルシフターを使うので心配いりません。また、 VCCとVIOの電源電圧も3.3Vです。終端抵抗もヘッダーにコネクテッドされていました。 OA3Pのタイミング仕様に関してですが、例えば、 CONFIGコマンドを20ns Low/20ns High /16us Lowではなく、80ns Low/80ns High/64us LowとしてTJA1410Aに送信した場合、TJA1410AはそれをCONFIGコマンドとして認識するのでしょうか、それともRESETコマンドとして認識するのでしょうか(Ideal 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.3V VIO仕様です。VIOに3.3Vが供給される場合、TXの1.8V HIGHレベルでは、保証された入力HIGHしきい値を満たすのに十分ではありません。 このデバイスには、VIOに3.3Vが供給されている状態で、1.8VのホストがTJA1410Aを直接駆動できるようにする内部レベルシフト機能がありません。 1.8Vデジタルインターフェースの場合は、以下のいずれかのオプションをご利用ください。 1.8V VIOインターフェースをサポートするTJA1410Bバリアントを使用するか、 SoCとTJA1410Aの間に適切な外部電圧レベル変換器を追加します。 また、RXとEDは選択されたVIO電圧に基づいて駆動されるため、電圧互換性は両方向で確認する必要があります。 ドキュメント 関連文書は以下のとおりです。 TJA1410データシート AN14787、 10BASE-T1SイーサネットPMDトランシーバTJA1410 UM12432、 TJA1410-EVB評価ボードユーザーマニュアル OPEN Alliance 10BASE-T1S PMDトランシーバインターフェース仕様、バージョン1.5 一部のTJA1410ドキュメントにはNXPアカウント、NDA、Secure アクセスの承認が必要な場合があります。 最初のデバッグステップとして、1.8Vと3.3Vのインターフェースの不一致を修正し、その後、TJA1410のデータシートにあるタイミング制限と照らしてTXコマンドの波形を確認することをお勧めします。 よろしくお願いいたします。 パベル Re: TJA1410 Support - Does not accepting commands こんにちは、 @Madhan1 さん。 TJA1410は既に適切な内部プルアップ抵抗を備えているため、TX、RX、EDに外部47kΩプルアップ抵抗を接続する必要は通常ありません。 47kΩのプルアップ抵抗は比較的抵抗値が高いため、問題の主な原因である可能性は低い。しかし、これらは信号エッジやレベルトランスレーター、ライン静電容量に影響を与える可能性があり、構成モードではRXやEDの方向が変わることがあります。 デバッグのためには、一時的に外部プルアップ抵抗を取り外し、TJA1410のピンでTX値を直接測定することをお勧めします。RESETコマンドが指定されたタイミングを満たしていることを確認し、ノーマルモードへの移行後にRXがHIGH、EDがLOWになっているかどうかを確認してください。 よろしくお願いいたします。 パベル Re: TJA1410 Support - Does not accepting commands こんにちは、 @Madhan1 さん。 1.8 V SoCインターフェースと3.3 V TX/RX/EDインターフェース間で外部の双方向レベルトランスレーターが既に使用されている場合、電圧領域は互換性があります。 TJA1410のブロック図に示されている「送信機レベルシフター」は、アナログ送信機内部経路の一部です。内部制御信号をアナログMDIトランスミッタが必要とする電圧領域に変換します。これは外部のTX/RX/EDホストインターフェースのレベルトランスレーターではありません。 CONFIGコマンドの例に関して、提案するタイミングは以下のとおりです。 80 ns LOW 80 ns HIGH 64 µs LOW これはTJA1410の有効なCONFIGコマンドのタイミングではありません。 データシートの表14に記載されているTJA1410の検出限界によると、次のようになります。 CONFIG LOWパルスは10 nsから33 nsの間である必要があります。 CONFIG HIGHパルスは10 nsから40 nsの間でなければなりません。 以下のCONFIGアサーション時間は、少なくとも15µsでなければなりません。 80ナノ秒のLOWパルスは、CONFIGの検出範囲外です。さらに、80 ns は、RESET コマンドの検出範囲である 55 ns ~ 120 ns の範囲内に収まります。したがって、TXがHIGHに戻った後、最初の80ナノ秒のLOWパルスはRESETコマンドとして解釈される可能性があります。 よろしくお願いいたします。 パベル Re: TJA1410 Support - Does not accepting commands こんにちは、 @PavelL さん。 ご返信ありがとうございます。 タイミングに関するあなたの意見は理解しました。 もう一つ疑問があります。私のハードウェア構成では、47KoΩのプルアップ抵抗を3ピンすべて(RX/TX/ED)にコネクテッドになっていますが、これが通信に問題を引き起こすでしょうか?外部プルアップ抵抗を推奨しています。 コネクテッドしたノードは2つだけで、片側はSoC、もう片側はLinux PC(10baseT1S経由でUSBブリッジに接続)です。上記のノードの詳細は気にする必要がないと思います。現状はアナログPHYのウェイクアップ自体に縛られており、もし起動すればそれで、パケットを転送してさらに進めます。 ありがとう、 マダン Re: TJA1410 Support - Does not accepting commands こんにちは、 @PavelL さん。 サポートありがとうございます。 皆さんの回答を参考にして問題を調べましたが、ほぼ分かりました。もし他に疑問があれば、同じThreadで再度連絡します。 ありがとう、 マダン
記事全体を表示
Getting started with NXP's MCUXpresso Hey folks! Software engineer here. I thought I'd get my hands dirty using my K66F evaluation board - which is a bit of an upgrade from their flagship K64F. I've wanted to really understand embedded systems from the ground up for some time - so I picked up a P&E Microlink probe and got started. I've managed to get an SDK example to connect to a SPI TFT module I have leftover from my EE undergrad days. It has a resistive touchscreen - and while the example was set up for an adjacent SPI capacitive touch sensor, I thought a couple of onboard ADCs and a humble voltage division circuit should get the job done. Just needed to replace the callbacks which read in the cap device's x and y readings with similar callbacks to the adc's Unfortunately, it seems the examples were not really made to be expanded. Adding additional components caused some newly generated include errors which I resolved, but for some reason still wound up with memory allocation issues. So while I've made some progress, I thought it might be a good time to ask around for resources https://100001.onl/ . Re: Getting started with NXP's MCUXpresso Hello @louis22 , Thanks for the detailed description. It sounds like you have already made good progress with the FRDM-K66F and the SPI TFT display. Your approach of using the ADC channels to read a resistive touchscreen makes sense. The SDK examples can also be used as a starting point and extended with additional drivers and application code. SDK can be found here: Select Board | MCUXpresso SDK Builder. For the memory allocation issue, I would first like to understand the exact error before concluding that it is caused by the SDK example. The MK66FN2M0 device on the FRDM-K66F has 2 MB Flash and 256 KB SRAM, so simply adding the ADC driver should not normally consume a large amount of memory. Could you please share the following information? Which SDK example did you start from? Which MCUXpresso IDE and SDK versions are you using? The exact build/linker error after adding the ADC functionality. If possible, the memory usage information or linker map file from the failed build. This will help us determine whether the problem is related to Flash/RAM usage, heap or stack allocation, the linker configuration, or an added software component. For learning the peripherals, I also recommend looking at the driver examples included with the MCUXpresso SDK. In your case, the ADC examples are a good reference for initializing and reading the K66 ADC independently. You can then integrate only the required ADC initialization and read functions into your TFT application. Looking forward to your reply. BR Celeste
記事全体を表示
MCP Server is unavailable I'm trying to import NXP's MCP service into VS Code by referring to the Agentic AI Development - NXP Community documentation, but it's not working after importing. The logs show "Discovered 0 tools." Is this the reason it's not working? If so, what are some solutions?
記事全体を表示
AraRT 3.0 x86:联想 Ara240 8GB 配置和 Linux 6.12 驱动程序问题 主机:联想ThinkCentre neo Ultra,12W2CTO1WW NPU FRU:5C50W32071,联想将其描述为 8 GB LPDDR4X PCI ID:1e58:0002,版本 02 运行时:AraRT 3.0 Linux x86-64,运行于 Qubes/Xen 下的 Debian 13 HVM 中。 访客系统:Debian 13,Linux 6.12.113Qubes/Xen PCI 直通 PCI直通检测到设备;当前未绑定NPU驱动程序。 驱动程序来源:nxp-imx-support/uiodma-driver 驱动程序提交:962d11df1a9334e851f1f8a5b00f7e8960609e6a,需要修改回调签名才能在 Linux 6.12.113 上编译。 我恳请社区尽快帮助我解决以下问题: - 维护良好的 x86 驱动程序,与我的内核兼容,解决 IRQ 清理和 eventfd 验证问题。 - 此 FRU 的正确板名称、等级、DDR 配置文件、LPDDR4X 设置和频率。 - AraRT 3.0 是否支持其现有固件并通过 Xen 直通进行操作。 Re: AraRT 3.0 x86: Lenovo Ara240 8GB configuration and Linux 6.12 driver issues 您是否尝试过在官方网站上下载适用于 Ara240 16GB M.2 模块的 AraRT-x86 电路板支持包。 链接? Re: AraRT 3.0 x86: Lenovo Ara240 8GB configuration and Linux 6.12 driver issues 谢谢。我试用了 AraRT 3.0 x86-64 用户空间工具。我的显卡是 Lenovo FRU 5C50W32071,8 GB LPDDR4X,PCI 1e58:0002 rev 02。链接的 电路板支持包。 是否支持此 FRU?如果可以,请分享支持的版本、Linux/内核版本、确切的 8 GB 板配置以及只读检测测试。在 Qubes/Xen 下,设备可以枚举,但访客无法声明 BAR 0、2 和 4,因为没有兼容的桥接窗口。我还没有应用 16GB 配置,也没有刷写存储卡。
記事全体を表示
2026年版 ベストデータ削除サービス:90日間テスト&専門家分析(2026年11月) おすすめ商品: 私たちは実際のユーザーが行うようにテストを行いました。有料サブスクリプション、シードされたアイデンティティ、そして同じブローカーパネルに対して30日/60日/90日ごとの再確認です。その結果、マーケットのトップをめぐる二頭の争いが繰り広げられ、個人データが再表示された後も再提出し続けてこそ、データ削除サービスが機能するという明確な警告となります。 Incogniは、完全自動化された削除機能で第1位を獲得し、プレミアムプランでは最も高いコストパフォーマンスを実現しています。年間プランの場合、月額約6.49ドル(年間一括請求で約77.88ドル)です。自動再提出サイクルとデロイトによる監査済みのレポート機能により、継続的な労力をかけずに問題を解決したい人にとって、このソリューションは最適な選択肢となる。 INCOGNIから始めましょう DeleteMeは、人間主導のコンシェルジュモデルと、私たちが測定した最も広いブローカーのフットプリントである750+のアクティブマネジメントブローカーを基に#2を獲得。複雑な案件、係争案件、あるいは繰り返し再掲載される案件においては、人的要素こそが「要請された」案件と「削除された」案件を分ける決定的な要素となる。 DeleteMe を試してください → 両者に共通する点、そして2026年の最終候補リストに必ず求められる点は、継続的な再監視です。つまり、ブローカーがデータを再掲載するたびに、自動的に再チェックと再提出が行われるということです。それがなければ、削除は一時的なリストからの削除に過ぎず、あなたのデジタル上の足跡は静かに再構築されてしまう。 クイック比較表:2026年版おすすめデータ削除サービス インコグニー:オートメーションと価値 ·~月額6.49ドル(年間77.88ドル)·完全オートメーション ·420+ ブローカー(Unlimitedで3,000+)·★★★★★ 5.0 DeleteMe :人間による削除サービス · 月額約10.75ドル(年間129ドル)·ハイブリッド ·400+車載/560+カスタム ·★★★★★ 4.8 オプトリー:削除の証明が確認済み・~月額3.25ドル(年間39ドルから)・完全オートメーション ·365〜635のブローカー(階層依存)·★★★★1/2 4.5 プライバシービー:最大ブローカーカバレッジ ·~月額8.00ドル(年間96ドルから)·フルオートメーション ·1,128+ ブローカー ·★★★★ 4.0 オーラ:オールインワンセキュリティバンドル ·~月$12.00(年間144ドル)·完全オートメーション ·~140人のブローカー ·★★★★ 4.0 EasyOptOuts :予算設定後はお任せ · 月額約1.67ドル(年間19.99ドル)·完全オートメーション ·200+の高負荷サイト ·★★★★ 4.0 最高のデータ削除サービスをテストし、ランキング付けした方法 私たちは、一貫した名前、生年月日、過去の住所2件、電話番号1件、メールアドレス1件を含む、管理されたテスト用IDを1つ作成し、Whitepages、Spokeo、BeenVerified、Intelius、MyLifeなどのトラフィック量の多い人物検索サイトやデータブローカーサイトの固定パネル全体にそれを散布しました。私たちは各サービスに自費で加入した後、同一の基準となるブローカーを3つのチェックポイントで再確認しました。 30日目:早期除去の兆候。重要な理由:速いサービスは実際の削除を表示し、遅いサービスは「進行中」と表示します。 60日目:安定した確認済み除去率。重要な理由:ほとんどの正当なオプトアウトは4〜6週間以内にクリアされます 90日目:耐久性と再出現。なぜマターなのか:データブローカーはリストを再掲載するため、残ったものを数えています 私たちは、実際に結果に影響を与える4つの変数に重み付けを行いました。 除去の持続性 ― 30日目だけでなく、90日目にどれだけ残っていたか。 カスタム削除能力 — 人間が頑固または争いのあるブローカーをエスカレーションできるかどうか レポートの透明性 — スクリーンショット、アクティビティログ、監査済み請求 一人当たりの年間費用 ― 年間請求額と世帯割引後の実質価格 2024年のコンシューマー・レポートの実地調査は、依然として外部ベンチマークとなっている。有料サービス全体で、平均して4ヶ月以内に削除された掲載情報はわずか約35%だった。その数字は、それ以下の順位の企業が生き残るために乗り越えなければならない現実を突きつけるものだ。 ブローカーが実際に収集するデータとは、なぜ重要なのか データブローカーは、整然とした単一のレコードを販売するわけではない。彼らは公的記録、ロイヤルティプログラム、アプリの権限、スクレイピングしたウェブページなどから複合的な個人情報を作成し、それをマーケティング会社、身元調査サービス、そして悪用されれば犯罪者に転売する。ほとんどの データブローカー は人検索、マーケティングセグメンテーション、リスクスコアリング、本人確認を専門としていますが、結果は同じです。つまり、あなたが同意していない永続的なプロフィールです。 一般的な個人情報パッケージには、ホーム住所、メールアドレス、電話番号、生年月日、親族、不動産記録、そしてソーシャルプロフィールから取得した写真や動画が含まれます。推定される健康関心、財務シグナル、位置履歴などの機密データを加えることで、プライバシー専門家が「個人識別情報(Personally Identifiable Information)」と呼ぶ最も商業的に有用な形が完成します。 だからこそ、単一の検索エンジン検索で、あなたが作成していない個人プロフィールが現れることがあるのです。Google検索結果やその他の検索エンジンは、データブローカーサイト、ブローカーサイト、ピープルファインダーサイトのページをインデックス化しており、メインストリームの検索結果には決して現れない影のサイトも含まれます。個人プロフィールが多ければ多いほど、それらを完全な個人データドシエにクロス・リファレンスしやすくなります。 私たちのテスト用IDは、データ投入から2週間以内に40以上のデータブローカーサイトに表示された。中には明らかに人探しのページもあれば、検索結果の3ページも埋もれたデータブローカーサイトもありました。目に見える暴露と目に見えない暴露の間のギャップこそが、暴露報告書と継続的なモニタリングなしにDIYによる清掃が失敗する理由なのです。 1. Incogni — オートメーション削除と価値において総合的に最適 最適な用途: 幅広いブローカーリーチと定期的なオートメーションを最低プレミアム価格で望む手を離すユーザー。 Incogniはオートメーションを第一にするリーダーであり、プレミアムティアで最も価値の高い存在です。スタンダード年間プランの料金は年間約77.88ドル(月額約6.49ドル)で、420社以上のデータブローカーに対応し、削除リクエストも完全に自動化されています。無制限プラン(年間179.88ドル)無制限のカスタム削除リクエストを追加し、対象範囲を3,000以上のソースに拡大します。 Incogniの特徴は、透明度レイヤーにある。ダッシュボードにはブローカーごとの解決時間や活動履歴が表示され、同社の主張はデロイトの保証レポートによって裏付けられています。これは多くの競合他社がいまだに追及できない第三者によるチェックです。自動再提出は60日から90日のサイクルで実行され、一度限りの削除を無意味にする再露出のライフサイクルに直接対抗します。繰り返し戻ってくる個人データの場合、そのサイクルが製品です。 長所: 最上位の自動化サービスの中で最も低価格(年間約77.88ドル) 420以上の自動化ブローカー、無制限の3,000以上の情報源 デロイト監査済みの撤去請求 継続的な再スキャンと自動再送信 無制限プランでは、カスタム削除リクエストを無制限にご利用いただけます。 短所: 標準プランでは、プロファイルごとに名前を1つしか指定できません。 複雑なエスカレーションに対応する人間のコンシェルジュ層はありません 個々の削除に関するスクリーンショットレベルの証拠はありません 結論: 設定して忘れて最低のプレミアム価格で除去したい大多数のユーザーにとって、Incogniは価値とオートメーションの深さの面で合理的な#1です。 2. DeleteMe — 最高級のデータ削除サービス(人間による対応) 最適なケース:複雑な露出、複数の住所、そして人間による確認済みの削除を希望するすべての人。 DeleteMeは、エリート向けのコンシェルジュ級のオプションであり、自動オプトアウトが滞った場合に人間のケースワーカーが介入するという理由から、第2位にランクインしました。スタンダードプランは1人用129ドル(月10.75ドル)から始まり、ファミリプランは2人用(年間229ドル)と4人用(329ドル/年)のティアがあります。自動削除は400以上のソースを対象とし、カスタム削除は560以上のソースを対象とします。これには、テンプレート削除要求を日常的に無視する頑固なデータブローカーも含まれます。 DeleteMeはさらに、追加料金なしで積極的なプライバシーツールキットをバンドルしています。メールマスキング、電話番号マスキング、クレジットカードマスク機能など、私たちがテストした他のサービスには基本プランには含まれていない機能です。ダッシュボードには、レビューされた情報源の数と、削除に成功した件数が表示されます。過去の住所や旧姓に分散している個人データの場合、人的要素がリクエストと結果の差を生む。 長所: 頑固または複雑なブローカーCASEに対する人間主導のエスカレーション 400以上の自動削除ソース / 560以上のカスタム削除ソース メール、電話、クレジットカード情報のマスキング機能が含まれています ファミリプランは1人あたりのコストを削減します 迅速なカスタマーサポートと活発なユーザーコミュニティ 短所: プレミアム価格:1人あたり年間129ドル ダッシュボードにはスクリーンショットレベルのビフォーアフター証明はありません 標準プランでは、カスタム撤去は年間40回までに制限されます。 結論:あなたの個人情報が複雑な場合(よくある名前、引っ越しの履歴、あるいはあまり知られていない地域ディレクトリのデータなど)、DeleteMeの人的介入が「削除依頼」と「削除済み」の分かれ目となる。 3~10。その他の主要データ削除サービスとの比較 3. Optery — 削除証明の確認に最適 Opteryは検証可能性において第3位にランクインした。そのダッシュボードは、削除の証拠としてスクリーンショットを表示する機能を備えており、競合他社のほとんどが未だに提供していない、削除前後の証拠を提示する。コアプランの料金は年間39ドルからで、最大40社のブローカーへのエクスポージャーを対象とした無料のセルフサービススキャンが付属します。すべてのアカウントには、削除開始前に発見されたプロファイルを正確に一覧表示する暴露レポートが含まれています。独立したテストにおいて、Opteryは約68%の除去率を達成し、管理されたベンチマークの中で最高のスコアを記録した。そのトレードオフとしては、コンシェルジュの深さがDeleteMeにまだ及びず、ニッチな地域ブローカーの個人データの処理に時間がかかることもあります。 4. プライバシービー — 最大限のブローカーカバレッジに最適なサービス プライバシー BeeはPCMagで初めてデータ削除カテゴリーで満点の5つ星評価を獲得し、1,128のデータブローカーをカバーし、185,000以上のカスタムサイトからの削除をサポートしています。料金は年間約96ドルからで、より詳細な監視機能が必要な場合は上位プランも用意されています。これは、最も幅広い公開されたブローカーリストと、削除カテゴリーの細かい管理を求めるユーザーに最適な選択肢です。独立機関による検査では、その除菌率は約45%と評価されている。これは立派な数字だが、目に見える効果という点ではトップ企業に劣る。あまり知られていないブローカーサイト上の個人データに関しては、その網羅性は非常に役立つ。 5. オーラ — ベストオールインワンセキュリティバンドル Auraはデータ削除とウイルス対策、VPN、個人情報盗難保険を一つのサブスクリプションにまとめており、年間約144ドル(月約12ドル)から始まります。自動削除は約140のブローカーをカバーしており、専門業者よりも狭い範囲ですが、3つの別々のサブスクリプションよりも単一のセキュリティスタックを望むファミリにはこのバンドルが理にかなっています。家族全員に一つのセキュリティソリューションを求めるなら、Auraのファミリープランが最大の魅力です。削除エンジンは一般的な個人データ漏洩には適切に対応しますが、専門のブローカー兼削除スペシャリストの代わりになるものではありません。 6. EasyOptOuts — 最も予算に優しい選択肢 EasyOptOutsは年間19.99ドルで、今回テストしたサービスの中で最も低価格です。管理されたベンチマークテストでは約65%の除去率を達成し、Opteryに次ぐ2位、いくつかのプレミアムツールを上回る結果となった。設計上、設定して忘れるタイプで、カスタム削除がなく、ダッシュボードも最小限に抑えられ、セキュリティレポートも少ないです。予算が限られている低リスクユーザーにとっては、個人データのクリーンアップの合理的な入り口となります。 7. Onerep — 最高の無駄な単独除去 Onerepは複数のバンドル製品の除去エンジンであり、年間90ドルから99.96ドル(月7.49ドルから8.33ドル)で直接販売されています。一般的な検索サイトを確実にクリアし、設置も迅速です。カバー範囲は中間的ですが、最上位サービスの追加機能を必要としないユーザーにとって、単体でスキャナー兼リムーバーとして機能します。 8. Kanary — 個人情報暴露とソーシャルメディア露出に最適な場所 Kanaryはニッチなサービスで、ソーシャルメディアの個人情報の監視や、場合によってはドキシングの対策を支援できます。これは多くの競合他社が持っていない機能です。料金は月額9.99ドルから50ドルで、無料プランも用意されています。トレードオフとしては、最も高価な階層のみが完全自動化され、無料版はモバイル専用です。 9. IDX Complete — ベスト・フル・アイデンティティ・トミート・スイート IDX Completeは、データ削除と個人情報盗難監視、3つの信用情報機関にわたる信用監視、パスワードマネージャー、VPN、ダークウェブ監視を統合した完全なセキュリティおよびプライバシースイートです。年間355.32ドル(月額約29.61ドル)年間請求の場合)、このリストの中で最も高額なオプションですが、複数の個別のサブスクリプションを置き換えることができます。データ削除サービスは100社以上のブローカーを対象としており、専門業者に比べると対象範囲は狭いものの、その周辺環境の保護は比類のないものです。 10. ノートン社のReputationDefender ― 著名人に最適 ReputationDefenderは、継続的なデータ漏洩監視と評判保護を必要とする専門家や著名人向けに開発されています。料金は見積もり制で公表されておらず、第三者機関による見積もりでは、基本的なブローカー削除サービスで年間約99ドルから、最高レベルの評判管理サービスで年間25,000ドルまで幅があります。これは低価格帯の選択肢ではないが、経営幹部や著名人にとって、評判管理サービスは差別化要因となる。 データブローカー削除サービスの料金:実際に支払う金額は? 以下の表は、年間料金、自動化されたブローカーによる補償、および人的エスカレーション層という、実際に結果に影響を与える3つの変数を比較したものです。カスタム削除とカスタム削除依頼は同じものではないことに注意してください。前者は通常、手動でのエスカレーションを意味し、後者は標準の自動リスト以外で、お客様に代わって送信される依頼を意味します。 インコグニ:約77.88ドル/年·自動ブローカー:420+(Unlimitedで3,000+)·カスタム削除:Unlimitedでの無制限カスタム削除リクエスト ·人間のエスカレーション:なし DeleteMe:年間129ドル・自動ブローカー:400+ ·カスタム引越し:560+ ソース;標準版で年間40件のカスタム削除 ·人間のエスカレーション:はい(コンシェルジュ) Optery:$39(コア)/ $249(Ultimate)/年 ·自動ブローカー:365–635(ティア依存)·カスタム削除:最大1,345サイト(Ultimate)·人間のエスカレーション:いいえ プライバシービー:年間~$96から・自動ブローカー:1,128+ ·カスタム削除:185,000+サイト ·人間のエスカレーション:部分的 オーラ:~年間$144 ·自動ブローカー:~140 ·カスタム削除:限定的・人為的エスカレーション:なし EasyOptOuts:年間$19.99 ·自動ブローカー:200+ ハイインパクト ·カスタム削除:なし ·人間のエスカレーション:なし Onerep: ~$90–$99.96/年金·自動ブローカー:300+ People-検索 ·カスタム削除:なし ·人間のエスカレーション:なし カナリー:年間約120ドルから・自動ブローカー:下位ティアでは手動・カスタム削除:なし ·人為的エスカレーション:なし IDX完了:年間$355.32・自動化されたブローカー:100以上 ・カスタム削除:なし ・人的エスカレーション:部分的 ReputationDefender:見積もりベース · 自動ブローカー:100以上のソース · カスタム削除:管理対象 · 人間によるエスカレーション:あり(管理対象) 価格が買うもの: Incogniの低いエントリー価格は純粋なオートメーションとデロイト監査による効率性を反映しています。DeleteMeのプレミアム料金は、人件費を反映したものです。Opteryの透明性は、その中間に位置する。EasyOptOutsは削除ループ以外のすべてを削除しますが、それでも削除率の面ではいくつかの有料ツールを上回ります。データブローカーがプロフィールを再掲載する場合、安価なサービスでは多くの場合、ユーザーがそれに気づいて手動で再提出する必要がありますが、プレミアムサービスではそのプロセスが自動化されています。それが、ダッシュボードに表示される削除リクエストの背後にある本当の違いです。 データ削除を超えて:個人情報保護の必須事項 ブローカーのデータベースから個人データを削除することで、情報漏洩のリスクを一つ減らすことはできますが、なりすまし、フィッシング、アカウント乗っ取りを防ぐことはできません。包括的な多層防御アプローチは、駆除と以下の対策を組み合わせたものです。 個人情報盗難防止機能 ― 新規口座開設を監視し、不審な活動を検知すると警告を発します。アラートだけでなく、復旧サポートを含む個人情報盗難防止サービスを探しましょう。 個人情報保護 ― 合成IDやクレジットカードヘッダーの不正使用に対する個人情報保護を含む、より広範なカテゴリー。 信用情報モニタリング ― 主要3つの信用情報機関における変更を追跡します。クレジットモニタリングとクレジットレポーティングレビューを組み合わせて、許可していない照会を見つけることができます。 パスワードマネージャー — 専用のパスワードマネージャーは、オンライン攻撃の最も一般的な侵入口である再利用認証情報を排除します。 ウイルス対策ソフト — 最新のウイルス対策ソフトは、認証情報やセッションクッキーを収集するインフォスティーラーをブロックします。 ダークウェブスキャン ― ダークウェブスキャンは、データ漏洩後に認証情報や個人情報が流出した場合に警告を発します。国立公共データの漏洩は、漏洩後の監視がいかに重要かを示す最も明確な最近の例です。 個人情報盗難保険 ― 個人情報盗難保険は復旧費用を補償しますが、盗難そのものを防ぐものではありません。 デジタルセキュリティ — 多層的なデジタルセキュリティ構成には、MFA、デバイスアップデート、信頼できるセキュリティサービスが含まれます。あなたのオンラインプライバシーはこれらすべてが連携して働くことに依存しています。 単一のセキュリティソリューションがすべてをカバーするものはありません。最も強力なスタックは、削除サービスとパスワードマネージャー、ウイルス対策ソフト、個人情報盗難防止を組み合わせており、個人データを一度のクリーンアップではなく継続的に監視すべきものとして扱います。2回目のデータ漏洩は、数か月にわたるクリーンアップを一つの通知で元に戻すこともあります。 DIY方式:オプトアウト申請、ガイド、およびその限界 手作業による除去は予算ゼロでも可能ですが、規律が求められます。ほとんどのデータブローカーはオプトアウトページを提供しており、多くは具体的な手順を説明するオプトアウトガイドを公開している。問題は規模です。データブローカーサイトが公開記録を再収集するため、数十件のオプトアウト要求を提出し、確認を追跡し、数か月ごとにこのプロセスを繰り返す必要があります。 自分の露出度を見つけましょう。主要な人物検索サイトやデータブローカーサイトで、名前、都市、旧住所を検索してください。URLを保存しておいてください。後で必要になります。 オプトアウトのリクエストは1件ずつ提出してください。各サイトオーナーによってワークフローは異なり、メールアドレスの認証が必要な場合もあれば、身分証明書のアップロードが必要な場合もある。 確認メールには一時的なメールアドレスを使用してください。これにより、削除依頼の処理中に、メインの受信トレイがブローカーのマーケティングリストから除外されます。 すべてを記録しておきましょう。確認メールやスクリーンショットは保存してください;それらがなければ、削除申請が提出されたことを証明できません。 四半期ごとに繰り返す。同じデータブローカーサイトや検索結果を再確認してください。新しいブローカーサイトが絶えず出現し、古いサイトも再掲載される。 大手証券会社には優れた無料のオプトアウトガイドが用意されており、まずはそれらを参考にすると良いでしょう。しかし、DIYは数百のデータブローカーサイトにスケールできず、時間経過で追跡できる曝露レポートも生成しません。ほとんどの人にとって、有料サービスを利用する方が、カスタム削除やカスタム削除依頼を手動で管理するのに必要な時間よりも安価です。ご自身で設定される場合は、弊社のオプトアウトガイドをチェックリストとして活用し、繰り返しの実施予定をカレンダーに記録してください。 データ削除サービスは本当に効果があるのか? はい、ただし、そのサービスに定期的な再除去が含まれている場合、そして、一度限りの除去率ではなく、耐久性に基づいて評価する場合に限ります。独立したテストでは、サービスによって方法論やブローカーパネルが異なるものの、削除される物件の割合は概ね27%から70%と、大きなばらつきがあることが一貫して示されている。OpteryとEasyOptOutsは、それぞれ約68%と65%で、比較対象ベンチマークをリードしました。一方、DeleteMeは、同じ2024年のコンシューマー・レポートの調査で約27%と中位に位置しました。 より重要な数字は、90日後に除去された状態が維持されているかどうかである。データブローカーは、45日から90日の周期で公開記録を再収集し、プロフィールを再掲載する。初月に68%を削除したものの、再掲載後に再提出を怠るサービスは、50%を削除し、それを継続的に抑制するサービスよりも、実質的な保護効果は低い。そのため、当社のランキングでは、90日目の持続性を60日目の除去率と同等に重視しており、Incogniの自動化された60~90日ごとの再提出サイクルは、マーケティング上の付加情報ではなく、真の運用上の利点となっています。同じ論理はあらゆる個人データのクリーンアップにも当てはまります。一度限りの削除は有効な戦略ではありません。 データ削除サービスの費用はいくらですか?+ 最終評決 今回ランキング対象としたサービスの年間料金は、個人向けプランの場合、年間19.99ドルから355.32ドルまで幅があります。プレミアムサービスの年間料金の中央値は96ドルから144ドル程度です。月額料金は、ほぼ例外なく年間実質料金の約2倍になります。例えば、Incogniのスタンダードプランは、月額約15.98ドルであるのに対し、年間プランでは月額6.49ドルです。ファミリプランは特にDeleteMeやAuraを使えば、1人あたりのコストを大幅に削減でき、ほとんどのプロバイダは4〜5人の大人をカバーするファミリプランを提供しています。削除に数週間かかり、再掲載が継続的に行われるカテゴリーでは、1か月のサービスはほとんど意味がなく、ファミリプランは通常、世帯を守る最も安価な方法です。 最終順位: Incogni ― 完全自動化された削除サービス、デロイト監査による透明性、そして最低価格のプレミアムプランでナンバーワン。手を離してデジタルフットプリントのクリーンアップを求めるほとんどのユーザーに最適です。 DeleteMe — プレミアム/エリート向けランキング第2位。人間による検証済みの除去、複雑な露出処理、カスタム除去、および付属のマスキングツールキットが必要な場合は、こちらを選択してください。 Optery ― 削除証明と予算レベルが最も明確に検証されており、明確な露出レポートも提供されます。 プライバシー Bee — マイナーサイトにおける個人データに関する最も広範な公開されたブローカー報道。 Aura — 特にファミリープラン向けのオールインワンセキュリティバンドルでおすすめです。 EasyOptOuts ― 最も低コストで、設定後は放置できるオプションです。 Onerep ― 最もシンプルで使いやすいスタンドアロン型削除エンジン。 Kanary — 個人情報暴露やソーシャルメディア露出に最適です。 IDX Complete — クレジットモニタリングとパスワードマネージャーを備えた最高の完全な身分盗難対策スイート。 ReputationDefender ― 著名人や評判管理に最適なツール。 結論として、あなたのデータ痕跡を100%削除できるサービスはありません。もしそうでないと謳うランキングがあれば、それはテストではなく販売戦略です。上位3人を分けるのはランディングページのブローカー数ではなく、データブローカーが再リストした際にサービスが再提出するかどうか、そしてオートメーションが失敗した際に人間が介入できるかどうかです。Incogniは、1ドルあたりの自動化された耐久性において優位に立っている。DeleteMeは人間的な側面で勝っている。リスクの複雑さに合わせてサービスを選択し、一度限りの復旧ではなく、継続的な保護のための予算を確保しましょう。最高のデータ削除サービスとは、最初の暴露レポート後も継続的に機能するサービスです。なぜなら、あなたのデジタルフットプリント、個人データ、そしてそれらをホストするデータブローカーサイトは常に変化し続けるからです。削除を身元保護、パスワードマネージャー、クレジット監視と組み合わせ、データ削除機能を一時的な解決策ではなく、より広範なデジタルセキュリティ戦略の一層として扱うべきです。
記事全体を表示