UCM-iMX95：无法从 SD 卡启动 Yocto Linux – mmc0 错误 -110 | Linux 无法初始化 SD 卡 您好，我正在使用 CompuLab UCM-iMX95，并且我正在尝试从 micro-SD 卡安装和启动 Yocto Linux。 启动过程开始，U-Boot 成功加载 Linux 内核。但是，Linux 无法初始化 SD/MMC 接口。 我收到以下错误信息： mmc0：等待硬件中断超时。 mmc0: sdhci: ============ SDHCI 寄存器转储 ============= ... mmc0：初始化 MMC 卡时出错 -110，内核随后在启动过程中卡住。 我的Linux版本是：Linux 6.12.34-2.0-...板是：CompuLab UCM-iMX95。我正在构建自己的 Yocto 镜像并将其写入 micro-SD 卡。 请问有人能帮我理解一下导致 mmc0 错误 -110 的原因吗？具体来说：这是否可能是硬件/SD卡的问题？ 或者这可能与设备树有关？UCM-iMX95 上的 micro-SD 接口对应哪个 MMC 控制器？ SD接口是否需要特定的设备树设置？ 是否有推荐的 U-Boot 命令可以在 Linux 启动前验证 SD 卡是否被检测到？是否有已知的、性能良好的 UCM-iMX95 Yocto 配置可供我参考，以便与我的配置进行比较？ Re: UCM-iMX95: Unable to boot Yocto Linux from SD card – mmc0 error -110| Linux cannot initialize th 你好， 您收到的错误日志告诉我们，MMC 控制器正在尝试与一个不存在或未正常响应的设备进行通信。建议的解决方案是禁用未使用的 MMC 接口或修复 DT 配置。 我们的 EVK 参考设计设备树采用以下配置： mmc0 usdhc1 eMMC mmc1 usdhc2 SD card 您可以参考我们的设备树： https://github.com/nxp-imx/linux-imx/blob/lf-6.18.y/arch/arm64/boot/dts/freescale/imx95-19x19-evk.dts 顺祝商祺！

PIC CLBのユーレカ 特定のPIC MCU(例:pic16f13145ファミリ)には、Configurable Logic Blockと呼ばれるFPGA風のプログラム可能なロジックがあります。 私が使用しているpic16f13115は、それぞれ4入力ルックアップテーブルとDフリップフロップを備えた32個のセルで構成されています。 ツールの使い方を学ぶために、今日はPWM明るさ制御付き6つのLEDのチャーリープレックス対応を実装し、シミュレーションしました。ロジックCADキャンバスを使用する代わりに、Verilogを使用して回路を定義しました。 私は時間の半分くらいを壁に頭を打ち付けて過ごしていた。少しずつ、Verilogを正しく記述し、合成（ビルド）を行い、そしてシミュレーションを実行できるようにした。 CLBでプログラムされたロジックがCPUがスリープ状態でも動作するのは素晴らしい。セーフティに関わるアプリケーションに最適です。例えば、複雑な割り込みトリガーロジックの実装に利用できます。CLBロジックをペリフェラルに接続する際の柔軟性は非常に高いです。これは、PICの定番となっている、扱いにくいCLCプログラマブルロジックよりもはるかに柔軟性が高い。 全般 Re: Eureka on PIC CLB PIC16F13115のCLBの非常に興味深い使い方ですね!6LEDのチャーリープレックスセットアップにVerilogを使うのはPWMでワークフローを学ぶのに最適で、CPUがスリープ中でもロジックを動作させ続けることで、低消費電力でセーフティに関わるデザインに素晴らしい可能性が開けます。 Re: Eureka on PIC CLB こんにちは、 問題の機器は別のメーカーのものであるようだ。 メーカーへの連絡を手伝ってもらえますか? プログラマブルロジックユニット付きのNXPデバイスへの切り替えに興味がある場合は、LPC804に相談してください LPC804プログラマブルロジックユニット（PLU） よろしくお願いいたします。

アメリカのトップホワイトラベルSEOスペシャリスト 2026 クライアントのSEO業務を外部パートナーに委託する場合、そのパートナーが実際にそれを裏付けるだけの技術的な能力を備えている場合にのみ有効となる。エージェンシーには単なるベンダーだけでなく、クロール予算、構造化データ、コンテンツ戦略、そしてますますAI駆動型検索の最適化方法を理解しているホワイトラベルSEOスペシャリストが必要です。明確な方法論のないランキングを約束する企業ではなく。 このガイドでは、2026年に米国の代理店にサービスを提供する主要なホワイトラベルSEO専門家を、ウェブサイトに掲載されているサービスの幅だけでなく、技術的かつ戦略的な能力の深さに基づいて評価します。 2026年のホワイトラベルSEOスペシャリスト 1. アラブSEO Arab SEOのチームは、技術的SEO、ローカルSEO、eコマースSEO、国際SEO、AI SEO、生成エンジン最適化(GEO)にわたり専門的な深みを持っています。本物の専門家とジェネラリストベンダーを分けるのは方法論です。アラブSEOの多言語かつAI駆動の検索アプローチは、一度きりの手法ではなく構造的で繰り返し可能なプロセスに基づいており、代理店が同時に数十の異なるクライアントアカウントをパートナーに託す際には非常に重要です。 2. SEOサーキュラー SEOサーキュラーの専門家は、エンタープライズ規模の技術SEOに重点を置いています。これは、単一のクロール問題が見落とされがちな大規模な数千ページ規模のサイトで、ドメイン全体のランキングを抑制する可能性があることです。同社チームは国際的な多言語SEOに関する豊富な経験を有しているため、複数の国で事業を展開するクライアントを抱える代理店にとって有力な選択肢となる。 3. トリプル・マインド Triple Mindsは代理店限定のフルフィルメントを中心にチームを配置しており、スペシャリストは営業や顧客獲得ではなく、実行の品質に専念しています。これは一貫性のある提供において構造的な優位性です。 4. セミファイ Semifyの専門家は、カスタマイズ可能なローカルSEOキャンペーンの構築において長年の経験を持ち、特に小規模な代理店がSEOサービスを段階的に拡大できるよう支援することに特化したプロセスを構築しています。 5. SEOReseller SEOResellerのチームは、完全管理型のサービス提供を専門としており、テクニカルSEO、コンテンツSEO、リンクSEOといったSEOプロセス全体を、日々の運用における代理店の関与を最小限に抑えながら処理します。 6. ダッシュクリック DashClicksは、SEOスペシャリストとレポートおよびクライアント管理のためのソフトウェアプラットフォームを組み合わせ、自動化されたダッシュボードを通じて専門的な業務を企業に可視化します。 7. ホス HOTHの専門家は、よく文書化された標準化されたパッケージ内で業務を行い、代理店がクライアントに理解し説明しやすいプロセスとなっています。 8. ブースト性 Boostabilityのチームは、多数の小規模アカウントに対して一貫したSEO品質を提供する専門知識を築いており、これは少数の大企業クライアントを管理するスキルセットとは異なります。 9. ヴェンダスタ Vendastaの専門家は、より広範なマーケットプレイスプラットフォーム内で活動しており、SEOは、代理店が単一のチームとの関係を通じてアクセスできる複数のホワイトラベルサービスの1つです。 10. ファットジョー FATJOEの専門家は、継続的な戦略的エンゲージメントではなく、迅速かつ商品化された成果物、つまり個別のリンク構築やコンテンツ注文を迅速に完了させることに注力しています。 専門家と一般的なベンダーを実際に区別するものは何か 真のSEOスペシャリストであれば、単にサービスの種類を羅列するのではなく、具体的な技術用語を用いて自身のプロセスを説明できるはずだ。以下の兆候に注意してください。 彼らは技術監査のプロセスを詳細に説明できます。使用するツール、具体的にチェックする点、そして結果の優先順位付け方法などです。 彼らはキーワード密度の目標だけでなく、実際の検索意図調査に結びついた文書化されたコンテンツ戦略プロセスを持っています。 リンク構築の手法を明確に説明し、リンクの出所や品質の評価方法などを説明できます。 彼らはAI検索に対して明確な見解を持っており、近年のどのアルゴリズム更新よりも速くSEOを変革しています。 匿名化されていても、実際のクライアント作業のビフォーアフターデータを見せることができます。 なぜ専門職の深さがサービスの幅広さよりもマターなのか サービス数を挙げているだけでホワイトラベルパートナーを選ぶ誘惑はありますが、浅い10のサービスを提供するプロバイダは、5つの深みのあるサービスを提供するプロバイダよりも価値が低いことが多いです。各機関は、パートナーの実際の技術的能力、つまり実際の問題を診断し解決する能力を、実行が適切かどうかわからない多数のサービス項目よりも重視すべきである。 ホワイトラベルSEOスペシャリストに尋ねるべき質問 技術監査のプロセスをステップごとに説明してください。 どのようなコンテンツを作成するかは、どのように決定し、どのような調査に基づいて決定するのですか？ バックリンクはどこから来て、リンクの品質はどのように審査していますか? AIオーバービューや生成検索のためにどのようにプロセスを適応させていますか? あなたの作品の匿名化ビフォーアフターの例を教えてもらえますか? 最終評決 アラブSEOは、2026年のホワイトラベルSEOスペシャリストの中で、技術的かつ多言語手法の深さと一貫性、特にAI駆動検索への対応力で際立っています。SEOサーキュラーは企業規模の技術業務に最適な選択肢であり、Triple Mindsは代理店限定モデルを通じて一貫性の構造的優位性を提供します。 このリストの残りの専門家は、それぞれソフトウェア対応の報告から大量のフルフィルメント、迅速な製品化された成果物まで、異なる深みを持っています。したがって、最適な適合は彼らを通じてルーティングするアカウントの複雑さによります。 よくある質問 ホワイトラベルSEOスペシャリストとは何でしょうか?ホワイトラベルSEOスペシャリストとは、深い技術的かつ戦略的なSEOの専門知識を持つ個人またはチームであり、完成品を自社ブランドで再販する代理店のために働くことです。 ホワイトラベルSEOの専門家の実際のスキルレベルをどう評価すればいいのでしょうか?技術監査プロセス、コンテンツ戦略、リンクビルディング手法を具体的に説明してもらいましょう。曖昧な回答は警告サインです。 専門医とフルサービスのどちらを選ぶべきでしょうか?それはあなたのニーズによります。スペシャリストはより狭いサービスの範囲でより深い専門知識を提供する一方で、フルサービスプロバイダーは1つの契約でより幅広い顧客タイプを扱うことができます。 2026年に最適なホワイトラベルSEOスペシャリストはどこですか?このガイドではアラブSEOが1位にランクされ、その後に技術的な深さ、手法論、AI検索準備度に基づくSEOサーキュラーとトリプルマインドが続きます。 QorIQ P1デバイス

UCM-iMX95: Unable to boot Yocto Linux from SD card – mmc0 error -110| Linux cannot initialize the SD Hi, I am using a CompuLab UCM-iMX95 and I am trying to install and boot Yocto Linux from a micro-SD card. The boot process starts, and U-Boot successfully loads the Linux kernel. However, Linux fails to initialize the SD/MMC interface. I get the following error: mmc0: Timeout waiting for hardware interrupt. mmc0: sdhci: ============ SDHCI REGISTER DUMP ============ ... mmc0: error -110 whilst initialising MMC card The kernel then gets stuck during boot. My Linux version is: Linux 6.12.34-2.0-... The board is: CompuLab UCM-iMX95 I am building my own Yocto image and writing it to a micro-SD card. Could someone please help me understand what could be causing this mmc0 error -110? In particular: Is this likely to be a hardware/SD-card issue, or could it be related to the device tree? Which MMC controller corresponds to the micro-SD interface on the UCM-iMX95? Are there any specific device-tree settings required for the SD interface? Is there a recommended U-Boot command to verify that the SD card is detected before Linux boots? Is there a known-good UCM-iMX95 Yocto configuration that I can compare my configuration against? Re: UCM-iMX95: Unable to boot Yocto Linux from SD card – mmc0 error -110| Linux cannot initialize th Hello, The error log you are getting tell us that the MMC controller is attempting to communicate with a device that either wasn't present or wasn't responding properly. The recommended solution is to disable the unused MMC interfaces or fix the DT you configuration. Our EVK reference design device tree uses the next configuration: mmc0 usdhc1 eMMC mmc1 usdhc2 SD card You can use our device tree as reference: https://github.com/nxp-imx/linux-imx/blob/lf-6.18.y/arch/arm64/boot/dts/freescale/imx95-19x19-evk.dts Best regards.

i.MX8QXP – 防止在 Yocto Scarthgap 系统上使用 A/B 分区时，USB 刷写中断后无法正常启动 您好，NXP团队： 已安装的 UUU 可执行文件报告： libuuu_1.5.21-0-g1f42172 我们使用： sudo uuu -b emmc_all ~/Downloads/flash.bin *.wic 内置的 emmc_all 脚本使用以下命令写入完整的 .wic 镜像： FB：flash -raw2sparse 所有_image 然后写入引导加载程序，配置 eMMC 引导选择，最后显示 FB: done。 该脚本不包含显式的持久性闪存进行中完成元数据处理或回读哈希验证步骤。 如果在 .wic 期间闪光灯闪烁中断写入后，集群即可启动并显示更新后的 HMI。我们怀疑现有的可用引导加载程序和足够的已写入启动、根文件系统内容允许这样做，但所选插槽及其内容的完整性尚未得到确认。 请问如何添加一个断电容错完成检查，在工厂刷机中断后阻止从两个插槽正常启动，同时保留 USB 恢复功能？元数据必须独立于完整的 .wic 文件保持有效。写入和引导加载程序更新。 Re: i.MX8QXP – Prevent normal boot after interrupted USB flashing on Yocto Scarthgap with A/B partit 你好， 虽然没有官方的解决方案，但您可以自定义 uuu 脚本，内置的 emmc_all 流程只是一个基于 Fastboot 和 U-Boot 命令的 UUU 脚本，它可以被修改或替换为自定义的 uuu.auto 文件。U-Boot 命令也可以通过 FB:ucmd 执行。这意味着您应该添加自定义步骤，例如在编程前设置“闪存正在进行中”标志，并在验证成功后才清除该标志。 U-Boot 启动次数/启动限制 U-Boot 库包含对以下功能的支持： 配置启动次数限制 启动计数 启动限制 altbootcmd 配置启动计数_FS 当启动次数超过启动限制时，U-Boot 会执行 altbootcmd 而不是正常的 bootcmd。此机制可用于将系统重定向到恢复模式，例如 Fastboot 模式。 启动次数限制 — Das U-Boot 未知版本文档

Eureka on PIC CLB Certain PIC MCUs (e.g., pic16f13145 family) have FPGA-like programmable logic called Configurable Logic Block. The pic16f13115 I'm using has 32 cells each with a 4-input lookup table and a D flip-flop. To learn to use the tools, today I implemented and simulated support for Charlieplexing of 6 LEDs with PWM brightness control. I used Verilog to define the circuit instead of using the logic CAD canvas. I was pounding my head on the wall for about half my time. Slowly, I got the Verilog right, got it to synthesize (build), then got it simulating. It is cool that the CLB programmed logic works even when the CPU is sleeping. It's perfect for safety-critical applications. Can be used, for example, to implement complex interrupt trigger logic. There is great flexibility in hooking up CLB logic to peripheral inputs and outputs. It's much more flexible than the clunkier CLC programmable logic that's been a fixture of PICs. General Re: Eureka on PIC CLB That’s a really interesting use of the PIC16F13115’s CLB! Using Verilog for a 6-LED Charlieplexing setup with PWM sounds like a great way to learn the workflow, and having the logic continue operating while the CPU sleeps opens up some impressive possibilities for low-power and safety-critical designs. Re: Eureka on PIC CLB Hello, It appears that the device in question belong to a different manufacturer. Could you help us contacting your manufacturer, please If you are interested in changing to an NXP device with a Programmable Logic Unit you can consult the LPC804 The LPC804 Programmable Logic Unit (PLU) Best Regards

i.MX8QXP – A/BパーティションでYocto ScarthgapのUSBフラッシュが中断された後の通常起動を防ぐ こんにちは、NXP チームの皆様、 インストールされたUUU実行ファイルは以下を報告します。 libuuu_1.5.21-0-g1f42172 私たちは以下を使用しています： sudo uuu -b emmc_all ~/Downloads/flash.bin *.wic 組み込みのemmc_allスクリプトは、以下の方法で完全な.wicイメージを書き込みます。 FB: flash -raw2sparse all _image その後、ブートローダーを書き込み、eMMCブート選択を設定し、FB: doneで終了します。 このスクリプトには、進行中のフラッシュ処理完了メタデータの明示的な処理や、読み戻しハッシュの検証手順は含まれていません。 .wic の実行中にフラッシュが中断された場合writeすると、クラスタはその後起動し、更新されたHMIを表示できます。既存の使用可能なブートローダーと、十分な量のboot、rootfsの内容が書き込まれていればこれが可能になると思われますが、選択されたスロットとその内容の完全性はまだ確認されていません。 工場出荷時フラッシュが中断された後、両方のスロットからの通常起動をブロックしつつ、USBリカバリ機能を維持するための、電源喪失耐性のある完了チェックを追加する方法について教えてください。メタデータは、完全な.wicファイルとは独立して有効でなければならない。書き込みとブートローダーのアップデート。 Re: i.MX8QXP – Prevent normal boot after interrupted USB flashing on Yocto Scarthgap with A/B partit こんにちは、 公式の解決策は実装されていませんが、uuuスクリプトをカスタマイズでき、組み込みのemmc_allフローはFastbootやU-Bootコマンドに基づくUUUスクリプトで、カスタムのuuu.autoファイルで修正または置き換えが可能です。U-BootコマンドはFB: ucmdを通じても実行可能です。つまり、プログラミング前に「フラッシュ処理中」フラグを設定し、検証が成功した後にのみそのフラグを解除するなど、カスタム手順を追加する必要があるということです。 U-Bootの起動回数／起動制限 U-Bootツリーには以下のサポートが含まれています: CONFIG_BOOTCOUNT_LIMIT ブートカウント ブート制限 altbootcmd CONFIG_BOOTCOUNT_FS ブート回数がブート制限を超えると、U-Bootは通常のbootcmdの代わりにaltbootcmdを実行します。この仕組みは、システムをFastbootのようなリリバリモードにリダイレクトするために使用できます ブートカウント制限 — Das U-Boot 不明バージョンドキュメント

imx-firmwareからW8997ファームウェアを削除することに関する質問 NXPチームの皆様、こんにちは。 imx-firmwareリポジトリにおける以下のコミットに関してご連絡差し上げております。 「26Q1以降、BSPからSD/PCIE W8997サポートを解除」 W8997のファームウェアは標準のimx-firmwareパッケージからのみ削除されたのか、それともこれらのデバイスのサポートが完全に終了したのか、教えていただけますか? Git履歴から最後のW8997ファームウェアファイルは取得できるので、主な質問は最新のimxファームウェアを使い続けながらW8997のサポートを維持する推奨方法についてです。 最新のimx-firmwareパッケージをインストールして、それらを含む最後のリリースのW8997ファームウェアファイルを追加することはサポートされていますか? もしそうなら、これをきれいに処理し、将来のimxファームウェアアップデートとの競合を避けるための推奨される手順やパッケージング方法はありますか? 私たちの目標は、88W8997をベースにした古い展開ハードウェアのサポートを維持しつつ、システムを最新の i.MX ファームウェアパッケージに維持することです。 よろしくお願いいたします。 アントワーヌ・ジェナール Re: Question regarding removal of W8997 firmware from imx-firmware こんにちは、 @agennart さん。お元気でお過ごしでしょうか。 社内チームに確認中です。返信があり次第、ご連絡いたします。 Re: Question regarding removal of W8997 firmware from imx-firmware こんにちは、 @agennart さん。 プロジェクトの詳細を教えていただけますか?あなたが使っているW8997モジュールや、実装したインターフェース(PCIeまたはSDIO)も含めて。 Re: Question regarding removal of W8997 firmware from imx-firmware 私はW8997を使用するプロジェクトを持っていません。Buildrootプロジェクトで`imx-firmware`のバージョンを上げようとしています。Buildrootは、旧型のハードウェアとの互換性を維持しつつ、新型ハードウェアもサポートすることを目指しており、今回のアップデートはそのためのものです。 問題は、このアップデートが古いハードウェアとの互換性を壊してしまうため、その互換性を維持する方法が必要なことです。 私は二つの可能なシナリオを考えています。 1. NXPは単純に古いハードウェアのサポートを廃止しました。その場合、Buildrootプロジェクトは古いハードウェアとの互換性を維持するために適切なバージョンの「imx-firmware」を選択する方法が必要です。 2. NXPは旧ハードウェアのサポートを別のパッケージ/プロジェクトに移しました。その場合、Buildrootプロジェクトは互換性を維持するためにそのパッケージやプロジェクトを更新または統合する必要があります。 Re: Question regarding removal of W8997 firmware from imx-firmware こんにちは、 @agennart さん。 88W8997のサポートは、Github上の専用ホットフィックスブランチを通じて、W8997ドライバーとLF 6.12.49_2.2.0リリースベースラインに基づくファームウェアの両方で提供されます。これらのブランチには、今後のW8997を対象としたオフサイクルリリースがすべて含まれます。したがって、以下のホットフィックスブランチを参照するように環境を更新してください。 ドライバーブランチ - GitHub - https://github.com/nxp-imx/mwifiex/tree/hotfix/lf-6.12.49_2.2.0_hotfix_w8997 ファームウェアブランチ - GitHub - https://github.com/nxp-imx/imx-firmware/tree/hotfix/lf-6.12.49_2.2.0_hotfix_w8997 W8997との互換性を確保するために、メインブランチはこのデバイスへのさらなるサポートを受けないため、共有ホットフィックスブランチを指すのが推奨されています。 この情報がご要望に合致するかどうかお知らせください。

AFM907N PAについて もしあれば、915MHz帯のチューニングレイアウトを共有してもらえますか? Re: Regarding AFM907N PA こんにちは、lavanyaemsecさん 良い一日！ 残念ながら、915 MHz 用のリファレンスレイアウトはご用意しておりません。最も近いものとしては、... AFM907N 760-870 MHz リファレンス回路設計ファイル 公式 AFM907N ページのデザインリソースセクションでご覧いただけます。 ご迷惑をおかけして申し訳ありません。 良い一日をお過ごしください。幸運を祈ります。

S32DS v3.5のライセンスが期限切れです。権利は有効ですが、延長ボタンが表示されず、返品もできません。 Hello NXP support, My NXP account holds valid entitlement for S32DS v3.5, but the generated license expired. Fulfillment ID: 113445398 IDE: S32 Design Studio for S32 Platform v3.5 License Expiry: Aug 8, 2026 Entitlement Expiry: Sep 16, 2030 Machine ID: A5883F5CCBF60C6BECC55C5A0CC9D1C68DA192AD Current situation: 1. The license management page has no EXTEND button. 2. Return license is disabled, cannot release this fulfillment. 3. The entitlement is still valid until Sep 16, 2030. Could you help refresh this fulfillment license to entitlement expiry date Sep 16,2030? I have attached the screenshot of license list for your reference. Thanks. LicenseNotAllow.png Re: S32DS v3.5 license expired, entitlement valid, no EXTEND button and Return not allowed ご協力いただき、誠にありがとうございました。S32DSの再アクティベーションに成功しました。 Re: S32DS v3.5 license expired, entitlement valid, no EXTEND button and Return not allowed こんにちは、 古いライセンスを返却しましたので、以前のコードでS32DSを再度アクティベートできるはずです。

TEA1716 сalculation file Hello, I am looking for an Excel calculation file for the TEA1716 IC, similar to those provided in the development tools for other chips in the TEA series. I am using the TEA1716DB1255 development board and following the relevant documentation, but I would also like to access the calculation file if one exists. Thank you for your reply, and have a great day! Power solution Re: TEA1716 сalculation file Hello, An Excel-based calculation sheet for the TEA1716 exists ("Calculation sheet TEA1716 draft V1_4") and serves as the replacement for the original online design tool, which is no longer operational. Please find it attached. For reference alongside the calculation sheet, the key documents for your TEA1716DB1255 work are: AN11179 — detailed design guidance including worked calculation examples UM10557 — TEA1716DB1255 demo board documentation BRs, Tomas

On-chip secure NVM (S32K314) The Secure NVM mapping(FULL_MEM) described in HSE FW install for S32K3xx.pdf is as follows: HSE data flash is 160KB，APP data flash is 88KB，total ： 160KB+88KB=248KB luojing_0-1789619650388.png luojing_1-1789619740147.png However, the dflash allocation described in S32K3XXRM.pdf is as follows: The total size of dflash is 128KB luojing_2-1789619854070.png Why are the Dflash sizes mentioned in the two documents different? Note: I am using the HSE firmware version HSE_FW_S32K344_0_2_55_0_S2502.exe luojing_3-1789620886731.png Re: sRe: On-chip secure NVM (S32K314) All these information you will find in HSE-B Firmware Reference Manual. It is a secure file, so following procedure is needed to follow unless you have already done it before: https://www.nxp.com/docs/en/user-guide/nxp-secure-access-rights-registration.pdf For better understanding you may also see following link: https://www.nxp.com/support/support/secure-access-rights:SEC-ACCESS Re: sRe: On-chip secure NVM (S32K314) The HSE FW install for S32K3xx.pdf only specifies the range of HSE Pflash and dflash, without specifying the RAM range. What is the RAM range used by HSE? What are the starting address and size? Is there a specific document describing it? Re: sRe: On-chip secure NVM (S32K314) Secure data flash starts at 0x10016000 (for FULL_MEM) having 168KB. It is the same on all derivatives. The appnote is not up to date. Re: sRe: On-chip secure NVM (S32K314) luojing_0-1789654909700.png Is it incorrect for HSE (FULL UMEM) Dflash size to be 160KB? Should it be 128KB-88KB=40KB? sRe: On-chip secure NVM (S32K314) It is described here: davidtosenovjan_0-1789654479428.png

片上安全型非易失性存储器（S32K314） HSE FW install for S32K3xx.pdf 中描述的 Secure NVM 映射（FULL_MEM）如下： HSE 数据闪存为 160KB，APP 数据闪存为 88KB，总计：160KB+88KB=248KB 罗静_0-1789619650388.png 罗静_1-1789619740147.png 然而，S32K3XXRM.pdf 中描述的 dflash 分配如下： dflash的总大小为128KB 罗晶_2-1789619854070.png 为什么两份文件中提到的Dflash容量大小不同？ 注意：我使用的是 HSE 固件版本 HSE_FW_S32K344_0_2_55_0_S2502.exe 罗静_3-1789620886731.png Re: sRe: On-chip secure NVM (S32K314) 所有这些信息都可以在 HSE-B 固件参考手册中找到。 这是一个安全文件，因此除非您之前已经操作过，否则需要按照以下步骤操作： https://www.nxp.com/docs/en/user-guide/nxp-secure-access-rights-registration.pdf 为了更好地理解，您还可以参考以下链接： https://www.nxp.com/support/support/secure-access-rights:SEC-ACCESS Re: sRe: On-chip secure NVM (S32K314) S32K3xx 的 HSE FW 安装说明.pdf 仅指定了 HSE Pflash 和 dflash 的范围，而没有指定 RAM 的范围。HSE使用的内存范围是多少？ 起始地址和大小是多少？ 是否有相关文件进行描述？ Re: sRe: On-chip secure NVM (S32K314) 安全数据闪存从 0x10016000 开始（对于 FULL_MEM），大小为 168KB。所有衍生品都一样。 该应用说明已过时。 Re: sRe: On-chip secure NVM (S32K314) 罗晶_0-1789654909700.png HSE（完整 UMEM）Dflash 大小为 160KB 是否不正确？应该是 128KB-88KB=40KB 吗？ sRe: On-chip secure NVM (S32K314) 具体描述如下： davidtosenovjan_0-1789654479428.png

Regarding AFM907N PA Can you share tuned layout for 915MHz frequency range if available Re: Regarding AFM907N PA Hello lavanyaemsec Good day! We regret to inform you that we do not have a reference layout for 915 MHz; the closest one would be the... AFM907N 760-870 MHz Reference Circuit Design Files Which can be found on the official AFM907N page in the design resources section. We apologize for any inconvenience this may cause. Have a great day and best of luck.

TEA1716計算ファイル こんにちは、TEA1716 IC用のExcel計算ファイルを探しています。これはTEAシリーズの他のチップの開発ツールに付属しているものに似ています。 TEA1716DB1255の開発ボードを使い、関連するドキュメントに従っていますが、もし存在すれば計算ファイルにもアクセスしたいです。 ご返信ありがとうございます。良い一日をお過ごしください! 電源ソリューション Re: TEA1716 сalculation file こんにちは、 TEA1716用のExcelベースの計算シート(「計算シートTEA1716ドラフトV1_4」)が存在し、元のオンライン設計ツールの代替として機能しています。元のオンライン設計ツールは現在は運用されていません。添付ファイルをご確認ください。 計算シートと並べて参照するために、TEA1716DB1255作業の主要な文書は以下の通りです: AN11179 — 計算例を含む詳細な設計ガイダンス UM10557 — TEA1716DB1255デモボードのドキュメント BRs、トーマス

MCXW23x — BLE connection drops repeatedly when using FRO32K MCXW235B BLE connection drops repeatedly, `disconnect reason=0x08` (LL supervision timeout), consistently a few seconds after connect  Hardware constraint (fixed, not changeable on this design):** the custom board does **not** populate a 32.768kHz crystal on `XI32K`/`XO32K` — both pins are left open. The board only has a 32MHz crystal on `XI32M`/`XO32M` Board Design Re: MCXW23x — BLE connection drops repeatedly when using FRO32K Hello, hope you are doing well. How are you selecting the clock source in your application?  FRO32K is supported as an option for the BLE sleep clock, as part of the two low-frequency sources available for MCXW23xB: external crystal oscillator XO_32K, and 32.768 kHz freely running oscillator FRO_32K. The command "HCI_CMD_OCF_LE_SELECT_SLEEP_CLOCK_SOURCE" is used to select the sleep clock source that is used for the sleep timer, where FRO32K is a sleep clock source (slp_clk_src=0x01).  In a case where the 32.768 kHz crystal (XO_32K) is absent, the free running oscillator (FRO_32K) can also act as a backup of the 32.768 kHz clocking. In MCXW23, the frequency of an on-chip or off-chip clock signal can be measured accurately with a selectable reference clock. For example, the frequency measurement function can be used to determine the frequency of the 32.768 kHz free running oscillator (FRO32K) accurately, using the frequency measure function control register (FREQ_ME_CTRL). To start a frequency measurement cycle and read the result, see MCXW23 Reference Manual Section 11.4.1. The FRO32K trim registers are available in RM section 45.4.11.2.13 FRO32K control (FRO32K) Best regards, Sofia. Re: MCXW23x — BLE connection drops repeatedly when using FRO32K Dear  sofiaurueta,  Thanks for your reply.  We also tested ll_intf_curb_sleep_state(1) to disable sleep, which returned 0. After reviewing the code, we couldn't find any explicit sleep commands. Furthermore, ll_intf_le_select_slp_clk_src(RTC_SLPTMR) was configured with value 0x02, corresponding to the RTC clock source. Additionally, we integrated FSCI into the Wireless UART sample and tested Peripheral mode, where we observed the following RX data when connecting via phone. Best Regards,

MCXW23x — FRO32K使用時にBLE接続が繰り返し切断される MCXW235B BLE接続が繰り返し切断される。`切断理由=0x08`（LL監視タイムアウト）、接続後数秒で必ず切断される。 ハードウェア制約(この設計では固定、変更不可):** カスタムボードは**XI32K/'XO32K'の32.768kHzクリスタルを**埋めていません** — 両方のピンが開いたままです。このボードには、`XI32M`/`XO32M`にのみ32MHzの水晶発振子が搭載されています。 ボード設計 Re: MCXW23x — BLE connection drops repeatedly when using FRO32K こんにちは、お元気でお過ごしでしょうか。 アプリケーションでクロックソースをどのように選んでいますか? FRO32Kは、BLEスリープクロックのオプションとしてサポートされており、MCXW23xBで使用可能な2つの低周波ソース（外部水晶発振器XO_32Kと、32.768kHzの自由発振器FRO_32K）の1つです。 コマンド「HCI_CMD_OCF_LE_SELECT_SLEEP_CLOCK_SOURCE」は、スリープタイマーに使用するスリープクロックソースを選択するために使用されます。ここで、FRO32Kはスリープクロックソースです（slp_clk_src=0x01）。32.768 kHzのクリスタル(XO_32K)がない場合、自由走行する発振器(FRO_32K)は32.768 kHzのクロックのバックアップとしても機能します。 MCXW23では、オンチップまたはオフチップのクロック信号の周波数を選択可能な参照クロックで正確に測定できます。例えば、周波数測定関数は周波数測定関数制御レジスタ(FREQ_ME_CTRL)を用いて、32.768 kHzの自由走行発振器(FRO32K)の周波数を正確に測定するために使えます。周波数測定サイクルを開始し結果を読みたい場合は、MCXW23リファレンス・マニュアルセクション11.4.1を参照してください。FRO32Kトリムレジスタは、RMセクション45.4.11.2.13 FRO32K制御（FRO32K）に記載されています。 よろしくお願いします、 ソフィア。 Re: MCXW23x — BLE connection drops repeatedly when using FRO32K 親愛なる ソフィアウレタ、 ご返信ありがとうございます。 また、スリープを無効にするために ll_intf_curb_sleep_state(1) をテストしたところ、 0が返されました。コードを調べたところ、明示的なスリープコマンドは見つかりませんでした。さらに、ll_intf_le_select_slp_clk_src(RTC_SLPTMR) は、RTC クロックソースに対応する値 0x02 に設定されました。 さらに、FSCIをワイヤレスUARTサンプルに統合し、ペリフェラルモードで電話接続時に以下のRXデータを観察しました。 よろしくお願いいたします。

MCXW23x — 使用 FRO32K 时 BLE 连接反复断开 MCXW235B BLE 连接反复断开，断开原因为 `0x08`（LL 监控超时），每次连接后几秒钟都会断开。 硬件限制（此设计中固定且不可更改）：** 定制板** 未** 在 `XI32K`/`XO32K` 上安装 32.768kHz 晶振 — 两个引脚均未连接。该电路板仅在 `XI32M`/`XO32M` 上配备了 32MHz 晶振。 电路板设计 Re: MCXW23x — BLE connection drops repeatedly when using FRO32K 你好，希望你一切都好。 你的应用程序中是如何选择时钟源的？ FRO32K 可作为 BLE 睡眠时钟的一个选项，是 MCXW23xB 可用的两个低频源之一：外部晶体振荡器 XO_32K 和 32.768 kHz 自由运行振荡器 FRO_32K。 命令“HCI_CMD_OCF_LE_SELECT_SLEEP_CLOCK_SOURCE”用于选择睡眠定时器使用的睡眠时钟源，其中FRO32K是一个睡眠时钟源（slp_clk_src=0x01）。如果缺少 32.768 kHz 晶体 (XO_32K)，则自由运行振荡器 (FRO_32K) 也可以作为 32.768 kHz 时钟的备用。 在 MCXW23 中，可以使用可选的参考时钟精确测量片上或片外时钟信号的频率。例如，可以使用频率测量功能控制寄存器（FREQ_ME_CTRL）精确地确定 32.768 kHz 自由运转振荡器（FRO32K）的频率。要启动频率测量周期并读取结果，请参阅 MCXW23 参考手册第 11.4.1 节。FRO32K 微调寄存器可在 RM 45.4.11.2.13 节 FRO32K 控制 (FRO32K) 中找到。 此致， 索菲亚。 Re: MCXW23x — BLE connection drops repeatedly when using FRO32K 亲爱的 sofiaurueta ， 谢谢你的回复。 我们还测试了 ll_intf_curb_sleep_state(1) 来禁用睡眠，结果返回0。检查代码后，我们没有找到任何显式的睡眠命令。此外，ll_intf_le_select_slp_clk_src(RTC_SLPTMR) 配置值为 0x02，对应于 RTC 时钟源。 此外，我们将 FSCI 集成到无线 UART 示例中，并测试了外围模式，在通过手机连接时观察到以下 RX 数据。 顺祝商祺！

TEA1716 计算文件 您好，我正在寻找TEA1716 IC的Excel计算文件，类似于TEA系列其他芯片开发工具中提供的计算文件。我使用的是TEA1716DB1255开发板，并按照相关文档进行操作，但我也想获取该计算文件（如果存在的话）。谢谢您的回复，祝您一切顺利！ 电源解决方案 Re: TEA1716 сalculation file 你好， TEA1716 有一个基于 Excel 的计算表（“TEA1716 计算表草案 V1_4”），它取代了不再运行的原始在线设计工具。请查收附件。 除计算表外，您完成 TEA1716DB1255 工作所需的关键文件如下： AN11179 — 详细设计指南，包括计算示例 UM10557 — TEA1716DB1255 演示板文档 BRs，托马斯

オンチップセキュアNVM（S32K314） HSE FW install for S32K3xx.pdfに記載されているセキュアNVMマッピング（FULL_MEM）は以下のとおりです。 HSEデータフラッシュは160KB、APPデータフラッシュは88KB、合計：160KB+88KB=248KB 羅京_0-1789619650388.png luojing_1-1789619740147.png ただし、S32K3XXRM.pdfに記載されているdflashの割り当ては以下のとおりです。 dflashの合計サイズは128KBです。 luojing_2-1789619854070.png なぜ2つの文書に記載されているDflashのサイズが異なるのですか？ 注：私はHSEファームウェアバージョンHSE_FW_S32K344_0_2_55_0_S2502.exeを使用しています。 luojing_3-1789620886731.png Re: sRe: On-chip secure NVM (S32K314) これらの情報はすべてHSE-Bファームウェアリファレンスマニュアルに記載されています。 これは安全なファイルなので、すでに行ったことがない限り、以下の手順に従う必要があります。 https://www.nxp.com/docs/en/user-guide/nxp-secure-access-rights-registration.pdf より理解を深めるために、以下のリンクもご参照ください。 https://www.nxp.com/support/support/secure-access-rights:SEC-ACCESS Re: sRe: On-chip secure NVM (S32K314) S32K3xx 用の HSE FW インストールに関する PDF ファイルでは、HSE Pflash と dflash の範囲のみが指定されており、RAM の範囲は指定されていません。HSEが使用するRAMの範囲は？ 開始地点の住所とサイズを教えてください。 それについて説明した特定の文書はありますか？ Re: sRe: On-chip secure NVM (S32K314) セキュアデータフラッシュは、0x10016000 (FULL_MEMの場合) から始まり、168KB の容量を持ちます。これは全てのデリバティブ商品に共通する。 アプリケーションノートは最新ではありません。 Re: sRe: On-chip secure NVM (S32K314) 羅京_0-1789654909700.png HSE（FULL UMEM）のDflashサイズが160KBというのは間違いでしょうか？128KB-88KB=40KBになるべきでしょうか？ sRe: On-chip secure NVM (S32K314) 以下に説明します。 davidtosenovjan_0-1789654479428.png