Multi Source Translation Content

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

Multi Source Translation Content

Discussions

Sort by:
spi example code Hello, I am studying the spi example code provided by NXP in a project called 'Spi_Transfer_S32K312'. I want to know what each function means in the code, can I know the location of the header file? Re: spi example code Hi @mingimin  The header files are located under RTD → include within the project directory. Additionally, I recommend reviewing the S32K3/S32M27x SPI Driver Integration Manual and the User Manual included with the RTDs. These documents provide detailed information about the driver, including its limitations, hardware and software requirements, usage guidelines, and configuration instructions. They are helpful for a deeper understanding of the driver's behavior and capabilities. You can find these resources, for example, at the following path: C:\NXP\S32DS.3.5\S32DS\software\PlatformSDK_S32K3\RTD\Spi_TS_T40D34M50I0R0\doc Please note that the exact path may vary depending on the S32DS version and your installation directory. BR, VaneB
View full article
Drivers configuration for the S32K3XX Hello, I would like to ask, S32K3XX series chip new construction projects, in the use of drivers, each driver (1 corresponding to the position of each driver type) corresponding to the configuration interface in each configuration (3 shown in the position), there is no documentation or tutorials to explain? In the actual engineering application, I can rely on what information to configure, I set up each time is to look at the name of the setup item to guess its function, and decided to be configured into what, I feel the lack of official basis, so I feel that each of my settings is very no certainty and basis. Re: S32K3XX的drivers配置 Hi@Aaron_LL The following sections of AN13435 have some descriptions of the components And you can find a lot of training tutorials for configuring these peripherals in the official website. https://www.nxp.com/products/S32K3
View full article
i.MX93: J-Link と SYSRESETREQ を使用した Cortex-M33 リセットが機能しない こんにちは、 Segger J-Link と gdb を使用して、i.MX93 上の Cortex-M33 のファームウェアをデバッグしようとしています。NXP の J-Link ソフトウェアのパッチを使用して SWD 接続を確立し、プロセッサを停止したり、レジスタやメモリを読み取ったりできるようになりました。 問題は、プロセッサをリセットしても機能しないことです。レジスタの内容は変更されないので、リセットは無視されるものと想定します。 (gdb) レジスタを監視する R0 = 40D000C0、R1 = 2001EFE3、R2 = 40D000C0、R3 = 00000000 R4 = 00000000、R5 = 00000000、R6 = FFFFFFFF、R7 = 2001EEE8 R8 = FFFFFFFF、R9 = FFFFFFFF、R10 = 2000F000、R11 = 00000000 R12= FFFFFFFF、R13= 2001EEE8、MSP= 2001EEE8、PSP= 00000000 R14(LR) = 0FFE219D、R15(PC) = 0FFE2248 XPSR 49000003、APSR 48000000、EPSR 01000000、IPSR 00000003 CFBP 00000000、コントロール 00、フォールトマスク 00、ベースプライ 00、プライマスク 00 セキュリティ拡張規則: MSP_S = 2001EEE8、MSPLIM_S = 00000000 PSP_S = 00000000、PSPLIM_S = 00000000 MSP_NS = 00000000、MSPLIM_NS = 00000000 PSP_NS = FFFFFFFC、PSPLIM_NS = 00000000 CONTROL_S 00、FAULTMASK_S 00、BASEPRI_S 00、PRIMASK_S 00 CONTROL_NS 00、FAULTMASK_NS 00、BASEPRI_NS 00、PRIMASK_NS 00 (gdb) モニターのリセット ターゲットをリセットする (gdb) レジスタを監視する R0 = 40D000C0、R1 = 2001EFE3、R2 = 40D000C0、R3 = 00000000 R4 = 00000000、R5 = 00000000、R6 = FFFFFFFF、R7 = 2001EEE8 R8 = FFFFFFFF、R9 = FFFFFFFF、R10 = 2000F000、R11 = 00000000 R12= FFFFFFFF、R13= 2001EEE8、MSP= 2001EEE8、PSP= 00000000 R14(LR) = 0FFE219D、R15(PC) = 0FFE2248 XPSR 49000003、APSR 48000000、EPSR 01000000、IPSR 00000003 CFBP 00000000、コントロール 00、フォールトマスク 00、ベースプライ 00、プライマスク 00 セキュリティ拡張規則: MSP_S = 2001EEE8、MSPLIM_S = 00000000 PSP_S = 00000000、PSPLIM_S = 00000000 MSP_NS = 00000000、MSPLIM_NS = 00000000 PSP_NS = FFFFFFFC、PSPLIM_NS = 00000000 CONTROL_S 00、FAULTMASK_S 00、BASEPRI_S 00、PRIMASK_S 00 CONTROL_NS 00、FAULTMASK_NS 00、BASEPRI_NS 00、PRIMASK_NS 00 J-Link からのリセット戦略では、Cortex-M33 コアのみがリセットされることになっているため、リセット信号ではなく SYSRESETREQ を使用します。デバッグ コントローラに SYSRESETREQ ビットを書き込むために必要なセキュリティ権限がない可能性はありますか? J-Link を使用して Cortex-M33 のリセットを実行する正しい方法は何ですか? よろしくお願いいたします。 マルテ Re: i.MX93: Cortex-M33 Reset using J-Link and SYSRESETREQ not working こんにちは、 [email protected] でも詳細を共有していただけますか? このトピックからすでに 1 年以上経過していますが、まだ同じ問題が残っています。 ありがとう。 Re: i.MX93: Cortex-M33 Reset using J-Link and SYSRESETREQ not working プロセッサが再び失われることはなかったという意味ではうまくいきましたが、実行時間には大きな影響がありました。その理由はわかりません。 それぞれの操作には10倍の時間がかかりました。 コールド リセットを実行しますが、デフォルトで ROM にいくつかのコード (NXP が SD カードがないことを示唆していることとは反対) を残し、実行中のものにデバッガーを接続して RAM を上書きすることは意味がありますか? Re: i.MX93: Cortex-M33 Reset using J-Link and SYSRESETREQ not working こんにちは、 この JLink スクリプトを使用することは可能ですか? https://kb.segger.com/images/8/86/Example_Reset_CortexM_Normal.JLinkScript これはCortexMの標準的な戦略です。 敬具 Re: i.MX93: Cortex-M33 Reset using J-Link and SYSRESETREQ not working こんにちは、 解決策を共有していただけますか?私も現在同じ状況に直面しています。 Re: i.MX93: Cortex-M33 Reset using J-Link and SYSRESETREQ not working こんにちは、クリストフさん。 上で述べたように、私は J-Link を使用して i.MX93 の Cortex-M33 をリセットする方法を見つけました。もしそれがあなたが探しているものであれば、喜んで詳細をお伝えします。電子メールアドレスまたは直接連絡できる他の方法を教えてください。 よろしくお願いいたします。 マルテ Re: i.MX93: Cortex-M33 Reset using J-Link and SYSRESETREQ not working こんにちは。このトピックを見つけたばかりですが、M33 を A55 から分離して操作するための信頼できる解決策を誰かがようやく見つけることができたかどうか知りたいと思いました。最近、今後のプロジェクトのために開発環境の作成を開始しましたが、すぐにソフトウェア リセットのトリガーに関する同じ問題に遭遇しました。Threadが開かれてからしばらく経ちましたが、SEGGERは現在 (v8.10) IMXターゲットを組み込んだソフトウェアを提供していますが、まだシングルコアリセットを実行できないようです。SCB (SYSRESETREQ) と SCR レジスターでいくつか実験してみましたが、安定した結果は得られませんでした。また、VSCode 用の MCUXpresso プラグインも簡単にテストしましたが、カスタムの動作するリセット戦略の実装は見つかりませんでした。 よろしくお願いいたします。 クリストフ Re: i.MX93: Cortex-M33 Reset using J-Link and SYSRESETREQ not working こんにちは、マルカイさん。私もまったく同じ問題を抱えているので、解決策にとても興味があります。解決策やアドバイスを送っていただくことは可能でしょうか?どうもありがとう。[email protected] よろしくお願いいたします。 順州 Re: i.MX93: Cortex-M33 Reset using J-Link and SYSRESETREQ not working こんにちは、マルテ 大変助かります。私のメールアドレスは[email protected]です。 よろしくお願いいたします。 ニールス Re: i.MX93: Cortex-M33 Reset using J-Link and SYSRESETREQ not working こんにちは、ニールス。 あまり役に立たない NXP サポートのおかげで、私はこの問題の解決策を見つけました。 メールアドレスまたは直接連絡できる他の方法を教えていただければ、喜んでお手伝いさせていただきます。 敬具、 マルテ・カイザー Re: i.MX93: Cortex-M33 Reset using J-Link and SYSRESETREQ not working こんにちは@Sanket_Parekh 私も原作者と全く同じ状況です。NXP が提供する JLink スクリプトは、実際には M33 コアをリセットするのではなく、停止するだけのようです。これにより、レジスタとプロセッサの状態は変更されず、障害が発生した場合、最初に Linux 経由でコアをリセットしないとデバッグを適切に続行できなくなります。 JLink デバッガーを使用して、M33 コアのこのようなリセットをトリガーする方法はありますか? よろしくお願いいたします。 ニールス Re: i.MX93: Cortex-M33 Reset using J-Link and SYSRESETREQ not working こんにちは、 Sanket_Parekhさん (1) i.MX93 Cortex-M33用のNXP J-Linkスクリプトパッチはどこで入手できますか? (2)Segger氏によると、J-Linkでi.MX93をサポートするためのロードマップはまだ存在しない。しかし、それはQ1またはQ2に発生する可能性があります。Cortex-M33 をデバッグする他の方法はありますか? BR Re: i.MX93: Cortex-M33 Reset using J-Link and SYSRESETREQ not working こんにちは@malkai 、 お元気でお過ごしでしょうか。 「NXP が i.MX93 の Cortex-M33 コアをリセットするために意図した手順は何ですか?」 -> システム リセット コントローラ (SRC) は、すべてのシステム リセット信号の生成とブート引数のラッチを担当します。 ->主な機能は次のとおりです。 • 他のモジュールからのすべてのグローバル システム リセット ソースを処理し、グローバル システム リセットを生成します。 • MIX (スライス) の電力ゲーティングとメモリの低電力制御を担当します。 ->SRCはPADとヒューズビットからPOR_Bを取得してブートシーケンスを完了し、GPCの低電力要求を 電源のダウン/アップシーケンスを完了します。 第33章「システム リセット コントローラ (SRC)」を参照してください。 https://www.nxp.com/webapp/Download?colCode=IMX93RM ありがとう、よろしく。 サンケト・パレック Re: i.MX93: Cortex-M33 Reset using J-Link and SYSRESETREQ not working こんにちは@Sanket_Parekh m、 お返事ありがとうございます。しかし、その情報は問題の解決には役立ちません。ご存知のとおり、i.MX93 の Cortex-M33 コアには Armv8-M アーキテクチャがあり、AIRCR レジスタに VECTRESET ビットがありません ( https://developer.arm.com/documentation/ddi0553/latest/の D1.2.3 を参照)。SO、唯一利用可能なリセット要求は SYSRESETREQ であり、これには Cortex-M33 コアもシステム全体も反応しません。何故ですか? 私はすでに J-Link で使用されるリセット戦略を調べました。問題は、私が言ったように、NXP からのパッチは、CPU を停止するだけでこれらを置き換えるということです。また、リセット ラインは SoC 全体をリセットするため、ここでは使用できません。 SO、問題はまだ残っています。NXP が i.MX93 の Cortex-M33 コアをリセットするために意図した手順は何でしょうか? ありがとうございます。 マルテ・カイザー Re: i.MX93: Cortex-M33 Reset using J-Link and SYSRESETREQ not working こんにちは@malkai 、 お元気でお過ごしでしょうか。 ->リセット選択は、ターゲット デバイスのリセット操作を制御します。すべてのリセット オプションは Cortex-M プロセッサ ベースのデバイスに適用され、JTAG および SWD モードで使用でき、リセット後に CPU を停止します。 ->Core - VECTRESET ビットを設定することによってのみ Cortex-M コアのリセットを実行します。オンチップペリフェラルはリセットされません。一部の Cortex-M デバイスでは、このリセット方法がリセットできる唯一の方法です。ただし、ほとんどの場合、この方法は推奨されません。これは、ほとんどのアプリケーションが一部のペリフェラル(PLL、外部メモリ インターフェイスなど)のリセット状態に依存しており、起動時にペリフェラルがすでに構成されていると混乱が生じる可能性があるためです。 ->ResetPin - J-Link は RESET ピンを低くして、コアとペリフェラルをリセットします。通常、これによりデバイスの CPU RESET ピンも低くなり、CPU とペリフェラルがリセットされます。ターゲット デバイスの RESET ピンがローにプルされていない場合、このリセット方法は失敗します。 以下のリンクのセクションのリセット戦略を参照してください。 https://community.nxp.com/ pwmxy87654/attachments/ pwmxy87654/kinetis/28743/1/ UM08001_JLink.pdf ありがとう、よろしく。 サンケト・パレック Re: i.MX93: Cortex-M33 Reset using J-Link and SYSRESETREQ not working こんにちは@Sanket_Parekhさん、 お返事ありがとうございます。残念ながら、その情報は私の問題の解決に役立ちません。その間に、私はいくつかのことを知りました: 1.i.MX93 のパッチで NXP が提供する J-Link スクリプトではリセットが実装されません。CPU をリセットするのではなく、単に停止するだけです。 2. デバッガを介して AICR.SYSRESETREQ に手動で 1 を書き込んでリセットを要求しても、Cortex-M33 コアはリセットされません。 SO、私の最初の質問は残っています: デバッガーを介して Cortex-M33 をリセットする可能性はありますか? 感謝と敬意を込めて、 マルテ Re: i.MX93: Cortex-M33 Reset using J-Link and SYSRESETREQ not working こんにちは@malkai 、 お元気でお過ごしでしょうか。 こちらのリンクを参考にしてください。役に立つと思います。 https://community.nxp.com/t5/i-MX-プロセッサ-Knowledge-Base/すべてのボード-JTAG/ta-p/1106822 ------------------------------ ------------------------------ ------------------------------ ----------------------------- 注: この投稿で質問が解決した場合は、「正解」ボタンをクリックしてください。 ------------------------------ -------------------------------- -------------------------------- ----------------------------- ありがとう、よろしく。 サンケト・パレック
View full article
Failed to load static DPL with 8x DPDMUX Hi Community, Using dynamic creation of DPDMUXs and DPNIs successfully, and generate the DPL by following commands: 8x ls-addni --fs-entries=8 --num-queues=8 -n source /usr/local/dpdk/dpaa2/dynamic_dpl.sh ... 8x restool dpdmux create 8x restool dprc connect dprc.1 --endpoint1= .n.0/1/2 --endpoint2= / /dpni.k> restool dprc generate-dpl dprc.1 > dpl-8-dpdmux.dts Update the static DPL with dpl-8-dpdmux.dtb (generate by dtc tool) for uboot to initiate MC layout. The error shows as blow: [E, mem_mng_get_phys_mem:655] MAJOR mem. manager memory allocation failed [E, mem_mng_get_phys_mem:658] Required size 0x000040000 alignment 0x000000100 exceeds available memory for partition ID 7 [E, init_bman_bp:399, DPDMUX] ID[6] - dpbp_allocate_buffers(), failed to allocate dpbp buffers [E, init_infrastructure:3750, DPDMUX] swlib_init_bman_bp : -12 [E, dpdmux_init:4487, DPDMUX] init_infrastructure : -12 [E, mem_mng_get_phys_mem:655] MAJOR mem. manager memory allocation failed [E, mem_mng_get_phys_mem:658] Required size 0x000040000 alignment 0x000000100 exceeds available memory for partition ID 7 [E, init_bman_bp:399, DPDMUX] ID[7] - dpbp_allocate_buffers(), failed to allocate dpbp buffers [E, init_infrastructure:3750, DPDMUX] swlib_init_bman_bp : -12 [E, dpdmux_init:4487, DPDMUX] init_infrastructure : -12 [E, resman_is_link_permitted:6375, RESMAN] Object wasn't found [E, linkman_probe_cb:205] No common ancestor - Failed to connect dpdmux@6 and dpmac@9 [E, subnode_process:155] Probing module 'connection' return error code -1. Continue dpl processing... [E, resman_is_link_permitted:6375, RESMAN] Object wasn't found [E, linkman_probe_cb:205] No common ancestor - Failed to connect dpdmux@6 and dpni@15 [E, subnode_process:155] Probing module 'connection' return error code -1. Continue dpl processing... [E, resman_is_link_permitted:6375, RESMAN] Object wasn't found [E, linkman_probe_cb:205] No common ancestor - Failed to connect dpdmux@6 and dpni@7 [E, subnode_process:155] Probing module 'connection' return error code -1. Continue dpl processing... [E, resman_is_link_permitted:6375, RESMAN] Object wasn't found [E, linkman_probe_cb:205] No common ancestor - Failed to connect dpdmux@7 and dpmac@10 [E, subnode_process:155] Probing module 'connection' return error code -1. Continue dpl processing... [E, resman_is_link_permitted:6375, RESMAN] Object wasn't found [E, linkman_probe_cb:205] No common ancestor - Failed to connect dpdmux@7 and dpni@16 [E, subnode_process:155] Probing module 'connection' return error code -1. Continue dpl processing... [E, resman_is_link_permitted:6375, RESMAN] Object wasn't found [E, linkman_probe_cb:205] No common ancestor - Failed to connect dpdmux@7 and dpni@8 [E, subnode_process:155] Probing module 'connection' return error code -1. Continue dpl processing... [E, dpl_process:527] Error while parsing 'connections'. Skip processing the rest of DPL. [E, main:198] DPL processing failed; continuing...  Is there any limitation on the static DPL to support same layout as dynamic way? QorIQ LS2 Device Re: Failed to load static DPL with 8x DPDMUX Hi yipingwang, Using '--max-dmat-entries' in dynamic creating layout don't change the final dts by 'restool dprc generate-dpl dprc.1'. So, I just give it a try by adding following elements 'mem-size' and 'max-dmat-entries' in .dts. manually: dpdmux@0 {     compatible = "fsl,dpdmux";     options = "DPDMUX_OPT_CLS_MASK_SUPPORT", "DPDMUX_OPT_AUTO_MAX_FRAME_LEN";     method = "DPDMUX_METHOD_CUSTOM";     manip = "DPDMUX_MANIP_NONE";     num_ifs = <0x2>;     mem-size = <0x100>;  // this is manually added by me     max-dmat-entries = <0x8>; // this is manually added by me }; Unfornately this doesn't fix it, the same error message showing from MC debug. Please also check my dpl as enclosed. Re: Failed to load static DPL with 8x DPDMUX Please try whether the following method is possible. When you create DPDMUX, please specify "--max-dmat-entries=8" to reduce the resource allocation. --max-dmat-entries= max entries in DPDMUX address table. Default is 64. If your problem persists, please share your whole console log to create DPDMUX and generate DPL file. In addition, which processor are you using? Re: Failed to load static DPL with 8x DPDMUX Hi, I've managed to fix this issue by correcting the DPL parameter names.
View full article
使用 8x DPDMUX 加载静态 DPL 失败 嗨,社区、 成功使用动态创建 DPDMUX 和 DPNI,并通过以下命令生成 DPL: 8x ls-addni --fs-entries=8 --num-queues=8 -n source /usr/local/dpdk/dpaa2/dynamic_dpl.sh ... 8x restool dpdmux create 8x restool dprc connect dprc.1 --endpoint1= .n.0/1/2 --endpoint2= / /dpni.k> restool dprc generate-dpl dprc.1> dpl-8-dpdmux.dts 使用 dpl-8-dpdmux.dtb(由 dtc 工具生成)更新静态 DPL,以便 uboot 启动 MC 布局。 错误显示为 "吹": [E, mem_mng_get_phys_mem:655] 主内存。管理器内存分配失败 [E, mem_mng_get_phys_mem:658] Required size 0x000040000 alignment 0x000000100 exceeds available memory for partition ID 7 [E, init_bman_bp:399, DPDMUX] ID[6] - dpbp_allocate_buffers(),分配 dpbp 缓冲区失败 [E, init_infrastructure:3750, DPDMUX] swlib_init_bman_bp :-12 [E, dpdmux_init:4487, DPDMUX] init_infrastructure : -12 [E, mem_mng_get_phys_mem:655] MAJOR mem.管理器内存分配失败 [E, mem_mng_get_phys_mem:658] Required size 0x000040000 alignment 0x000000100 exceeds available memory for partition ID 7 [E, init_bman_bp:399, DPDMUX] ID[7] - dpbp_allocate_buffers(), 分配 dpbp 缓冲区失败 [E, init_infrastructure:3750, DPDMUX] swlib_init_bman_bp :-12 [E, dpdmux_init:4487, DPDMUX] init_infrastructure : -12 [E, resman_is_link_permitted:6375, RESMAN] Object wasn't found [E, linkman_probe_cb:205] No common ancestor - Failed to connect dpdmux@6 and dpmac@9 [E, subnode_process:155] Probing module 'connection' return error code -1.继续 dpl 处理... [E, resman_is_link_permitted:6375, RESMAN] 对象未找到 [E, linkman_probe_cb:205] 没有共同祖先 - 连接 dpdmux@6 和 dpni@15 失败 [E, subnode_process:155] 探测模块 'connection' 返回错误代码 -1.继续 dpl 处理... [E, resman_is_link_permitted:6375, RESMAN] Object wasn't found [E, linkman_probe_cb:205] No common ancestor - Failed to connect dpdmux@6 and dpni@7 [E, subnode_process:155] Probing module 'connection' return error code -1.继续 dpl 处理... [E, resman_is_link_permitted:6375, RESMAN] 对象未找到 [E, linkman_probe_cb:205] 没有共同祖先 - 连接 dpdmux@7 和 dpmac@10 失败 [E, subnode_process:155] 探测模块 'connection' 返回错误代码 -1.继续 dpl 处理... [E, resman_is_link_permitted:6375, RESMAN] 对象未找到 [E, linkman_probe_cb:205] 没有共同祖先 - 连接 dpdmux@7 和 dpni@16 失败 [E, subnode_process:155] 探测模块 'connection' 返回错误代码 -1.继续 dpl 处理... [E, resman_is_link_permitted:6375, RESMAN] 对象未找到 [E, linkman_probe_cb:205] 没有共同祖先 - 连接 dpdmux@7 和 dpni@8 失败 [E, subnode_process:155] 探测模块 'connection' 返回错误代码 -1.继续 dpl 处理... [E, dpl_process:527] 解析 "连接 "时出错。跳过处理 DPL 的其余部分。 [E, main:198] DPL 处理失败;继续... 静态 DPL 在支持与动态方式相同的布局方面是否有任何限制? QorIQ LS2 设备 Re: Failed to load static DPL with 8x DPDMUX 你好 yipingwang, 在动态创建布局时使用"--max-dmat-entries "不会改变 "restool dprc generate-dpl dprc.1 "的最终 dts。 因此,我尝试在 .dts 中添加以下元素 "mem-size "和"max-dmat-entries" 。手动 dpdmux@0 { 兼容 ="FSL,DPDMUX" ; options ="DPDMUX_OPT_CLS_MASK_SUPPORT","DPDMUX_OPT_AUTO_MAX_FRAME_LEN" ; method ="DPDMUX_METHOD_CUSTOM" ; manip ="DPDMUX_MANIP_NONE" ; num_ifs =<0x2> ; mem-size =<0x100>; // 这是我手动添加的 max-dmat-entries =<0x8>; // 这是我手动添加的 }; 遗憾的是,这并没有解决问题,MC 调试器中显示的错误信息还是一样。 还请检查随附的我的 dpl。 Re: Failed to load static DPL with 8x DPDMUX 请尝试以下方法是否可行。 创建 DPDMUX 时,请指定"--max-dmat-entries=8" 以减少资源分配。 -max-dmat-entries= DPDMUX 地址表的最大条目数。默认为 64。 如果问题仍然存在,请共享创建 DPDMUX 和生成 DPL 文件的整个控制台日志。 此外,您使用的是哪种处理器? Re: Failed to load static DPL with 8x DPDMUX 您好, 通过更正 DPL 参数名称,我设法解决了这个问题。
View full article
当前的 FSS 版本"S32N_FSS_FW_R21-11_1.8.1" 是否支持 S32N53? 你好,团队、 客户 HKMC 将从 S32N55 移至 S32N53。 所以我的问题是 当前的 FSS 版本"S32N_FSS_FW_R21-11_1.8.1" 是否支持 S32N53? 如果不是,什么时候会版本支持 S32N53 的 FSS? 顺祝商祺! 谢谢您! HSE_FW 优先级:高 Re: Does current FSS version "S32N_FSS_FW_R21-11_1.8.1" support S32N53? 你好,谭生、 我们计划在本月(7月底)发布的版本中提供支持; 谢谢! 辛杜
View full article
串行线调试的乐趣与游戏 <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> 我为我的 LPC1517 项目重新铺设了电路板,以移动 SWD 插座。数据和时钟直接传输,但 0V 电压则绕到一个小型(1 瓦)降压稳压器的后面。如果我想从麦克风前置放大器中获得 -130dBV/√Hz 的信号,我不会使用这种 PCB 跟踪技术,但对于具有 1V 抗噪能力的数字信号来说,速度并不快,我想应该没问题--但是没有--出现了大量 ACK、Flash 写入失败之类的错误。 我剪断了轨道,换上了一条沿着数据和时钟轨道走向的导线,然后就成功了。 因此,SWD 就像是 SPI 的半双工版本,MOSI 和 MISO 复用到一个引脚上,运行频率为 1MHz;所以重要的时间是时钟转换。其他都不重要。因此,可能有三种情况会妨碍它的工作:边沿过快导致接地反弹,边沿过慢导致抖动,或者目标阻抗过高导致干扰进入。因此,我尝试了几种方法--220pF 跨时钟到地、1k 下拉和 10k 串联阻抗--1k 似乎最有希望,但没有真正成功。 LPCXpresso 崩溃了 - 我强行退出,然后重新启动。 然后一切正常 所以,我比以往任何时候都更加困惑。 同一批的另一块板容易出错,但是如果我的示波器接地夹连接到电路 0V,则可以正常工作。 我听您说过,这意味着电路应正确接地,但电路 0V 与电源接地相连,而示波器却没有。 另一个令人困惑的问题是,从提交闪存写入" 时出现的"目标错误显示"system rejected access at location x"; 但我遇到的所有错误中,位置 x 都在 RAM 中。 不同的电路在机柜中与开关电源相邻时不会连接。把它从柜子里拿出来,就可以正常使用了。 我觉得这一切都很令人费解,因为我一直使用 SPI,速度是它的十倍,而且没有过多考虑 PCB 跟踪问题。如果效果这么差,我的 LED 显示器就会像启动器失灵的荧光灯管一样闪烁。 有人有什么想法吗? LPC13XX lpc15xx LPC800 Re: Fun and games with Serial Wire Debug 我花了三天时间确信这是硬件故障,直到我意识到我在初始化代码中翻转了两个引脚。突然之间,传感器数据变得有感知了,但是在我玩 Slope Game 时为了放松而发生迷你崩溃之前,情况并非如此。 Re: Fun and games with Serial Wire Debug 有趣的是,即使是微小的 PCB 布线选择也会导致重大问题,尤其是像 SWD 这样的敏感信号。这让我想起了大米纯度分数的不可预测性--有时,看似简单的事情会呈现出意想不到的复杂性! Re: Fun and games with Serial Wire Debug > 有人有什么想法吗? 我会尝试降低 SWD 时钟频率,看看效果如何。 我建议是一个数量级,即 100 千赫或更低。 这样调试并不有趣,但可以证明一点。 Re: Fun and games with Serial Wire Debug 我创建了一个名为 Debug 的单例和一个始终位于顶部的基本文本框。我现在可以不打印,而是 Debug.output(text) 因此,在我测试时,它就会出现在游戏中。当你只有一台监测时,有时,几乎每时每刻都会让事情变得容易得多。 模拟人生 4》满意度积分作弊器最近派上了大用场,当时调试任何东西的唯一方法就是实时更新我的视网膜所观察到的确切坐标,而使用 print() 会很麻烦,而且会激怒戈多。"减少文字印刷量" 此外,它还能实时捕捉仅出现的问题,而无需密切关注 Godot 输出日志。 Re: Fun and games with Serial Wire Debug <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> 不太确定你期望我在参考手册中找到什么,而我在帖子中还没有提到过。在 LPC15xx 手册的三页中,除了连接图和两个引脚都有上拉功能外,几乎没有其他内容。它甚至没有说明 SWCLK 只是输入,而 SWDIO 是双向的。我的大部分信息来自ARM关于该主题的白皮书。 至少我很高兴恩智浦不再建议在 SWCLK 上使用下拉电阻(pullDOWN)了--那会严重破坏抗噪能力,尤其是在您碰巧获得与内部上拉电阻相同的电阻时。 无论如何,我进一步进行了实验,并在SWCLK输入中添加了施密特触发信号。我尝试了 74LVC1G17 和一对 74HC14 的栅极。结果令人震惊。在我追踪不太好的板上,错误率从65%下降到零。100 次尝试中没有一次编程失败(1G17 和 HC14 没有区别) 然后,我将导线延长到标准的 150 毫米以外。在 LPC-LINK 和 targert 之间的 1 米引线上没有出现过任何故障。3 米处仍未出现故障。除此之外,无缓冲 SWDIO 线路上电缆的体电容也成了问题,误差逐渐增大。 下一步是在使用高噪声开关电源的电路上进行试验! 磁滞似乎可以解决问题,PIO0_18 引脚也有一个磁滞选项,但我敢打赌,在 SWD 操作期间,它不会打开。但我想知道,如果我在软件中设置了 IOCON 寄存器的第 5 位,那么在下一次编程时,迟滞功能是否仍会开启? 想尝试的人请注意:您的 SWCLK 输入(74LVC1G17 的输入)现在需要一个下拉电阻。我用的是 3.3kΩ。这个值并不重要,因为连接太短,不能被视为传输线,所以从技术上讲,它不是"终端" 。 Re: Fun and games with Serial Wire Debug <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> 你好 IanBenton、 为了提供尽可能快的支持,我想请你参考参考手册中的串行线调试章节 查看详情。 祝你愉快 TIC   ----------------------------------------------------------------------------------------------------------------------- 注:如果本帖回答了您的问题,请点击正确答案按钮。Thank you! -----------------------------------------------------------------------------------------------------------------------
View full article
如何在定制 MIMXRT1176AVM8A 板 上运行恩智浦 SDK 示例 我有一块带有 MIMXRT1176AVM8A 处理器的定制板(与 MIMXRT1170-EVK 不同)。我想运行 SDK 示例,但在必要的修改方面需要指导。 我的硬件设置 微控制器:MIMXRT1176AVM8A(与 EVK 不同)。 外部闪存:S25FL128L(QSPI,16 MB)(与 EVK 的 W25Q512NWEIQ 不同)。 同步动态随机存取存储器(SDRAM):W9812G6KB-6J (32 MB) *(与 EVK 的 W9825G6KH-5I 不同)。 其他更改:用于 LED 和 UART 引脚等的不同 GPIO 我需要什么帮助? Flex-SPI NOR 闪存设置: 既然我使用的是 S25FL128L(不是华邦),我该如何更新 flex SPI 或配置 C 文件才能正常启动? 同步动态随机存取存储器(SDRAM) 初始化: EVK 使用不同的同步动态随机存取存储器(SDRAM) 芯片。我应该如何调整 DCD 设置? 调试技巧 将 SDK 示例移植到自定义板时常见的陷阱有哪些? 请求: 谁能分享一下: 改编 SDK 示例的分步说明? 自定义 Flex SPI/同步动态随机存取存储器(SDRAM) 设置的示例配置? 提前感谢! Re: How to Run NXP SDK Examples on Custom MIMXRT1176AVM8A Board 只要频率不超过 800MHz,就没有问题。 BR, Omar Re: How to Run NXP SDK Examples on Custom MIMXRT1176AVM8A Board MIMXRT1176AVM8A 的 Cortex-M7 内核工作频率为 800 MHz。MIMXRT1176DVMAA(EVK 的处理器)的主频为 1 GHz。 Re: How to Run NXP SDK Examples on Custom MIMXRT1176AVM8A Board 不,它是相同的元器件,但包装不同。 BR, Omar Re: How to Run NXP SDK Examples on Custom MIMXRT1176AVM8A Board 由于 EVK 使用的是 MIMXRT1176DVMAA 处理器,如果我使用 MIMXRT1176AVM8A 处理器的 EVK 示例,会有问题吗? Re: How to Run NXP SDK Examples on Custom MIMXRT1176AVM8A Board 请参阅此文档:如何为 FLEXSPI 或非 闪存启用调试\ 本文件包含使用其他闪存时可进行调试的指南。 更详细的文档可能对您有所帮助:i.MX RT FLEXSPI 启动指南-恩智浦社区 关于同步动态随机存取存储器(SDRAM),建议参考 SDK 示例来配置内存,DCD 使用相同的同步动态随机存取存储器(SDRAM)配置,因此它是在启动时加载的。这里有一些关于如何配置同步动态随机存取存储器(SDRAM) 参数的示例:已解决:双 16 位同步动态随机存取存储器(SDRAM) (W9812G6KH) 的 MIMXRT1176 SEMC 配置-恩智浦社区 致以最崇高的敬意, Omar
View full article
imx8mmシングルコアのdtsiについて少し混乱しています 私も同様のプロジェクトに取り組んでいます。SO、この質問を完全に明確にする必要があります。NXP エンジニアの回答は完全に間違っているように見えますが、正解としてマークされているのは NXP エンジニアの回答ではないため、誰が正しいのか少し混乱しています。SO、誰の答えが正しいのでしょうか?私たちは、NXP のエンジニアの方がコードに精通しているだろうと信頼する傾向があります。 https://community.nxp.com/t5/i-MX-Processors/dtsi-for-imx8mm-single-core/td-p/2165973 i.MX 8M | i.MX 8M ミニ | i.MX 8M ナノ Re: A little confused about dtsi for imx8mm single core また、説明も知りたいです。 Re: A little confused about dtsi for imx8mm single core 推奨される方法は、Linux デバイス ツリーから対応するノードを削除することです。 U-Boot はチップ モデルとその利用可能な機能を検出できますが、デバイス ツリー内のノードを無効にすると、Linux カーネルがサポートされていないコンポーネントにアクセスしないようにすることができます。投稿で言及されているソースはカーネルではなく U-Boot に関連しているため、これが特に重要です。 Re: A little confused about dtsi for imx8mm single core @Chaviraあなたが言ったことを説明してください。 I have provided the appropriate recommendations tailored to your specific case. Regarding the BSP, it is functioning as expected. 1>> U-Boot does not modify the Linux Device Tree at runtime. Once the Linux kernel is loaded, U-Boot no longer has control over the Device Tree. It seems there's some confusion here. The Linux device tree and the U-Boot device tree are two distinct entities, each serving different purposes in the boot process. The document you're referring to specifically modifies the U-Boot device tree, not the one used by the Linux kernel. Please double check your references, the U-Boot device tree is not the same as the Linux device tree, and changes made to one do not automatically apply to the other. Re: A little confused about dtsi for imx8mm single core こんにちは@hogole 、 あなたの具体的なCASEに合わせた適切な推奨事項を提供しました。 BSPに関しては期待通りに機能しています。 コミュニティは、経験に基づいたすべてのメンバーからの貢献を歓迎します。コミュニティで開発されたソリューションを、ニーズに合わせて変更および適応していただけます。 BSP に関して問題が発生した場合は、お気軽にフォーラムで新しいThreadを開いてください。弊社がさらにサポートさせていただきます。 よろしくお願いします、 チャビラ Re: A little confused about dtsi for imx8mm single core @チャビラ 当社ではすでに多くの 8MM 製品が導入されており、このコードは長期間存在し、最新の BSP リリースを一貫してサポートしています。8MM ヒューズに基づいて実行時にデバイス ツリーを自動的に変更することに問題がある場合は、現在の製品のアップグレードを検討する必要があります。これは非常に難しい決断であり、時間と費用がかかります。 したがって、明確な答えが必要です。NXP BSP リリースの BSP コードのこの部分には潜在的な問題があるのでしょうか?ヒューズに基づいて Linux デバイス ツリー コア数がこのように自動的に構成される場合でも、コンパイル時に Linux デバイス ツリーを変更する必要があるのはなぜですか? https://github.com/nxp-imx/uboot-imx/blob/lf-5.10.72-2.2.3/arch/arm/mach-imx/imx8m/soc.c static int disable_cpu_nodes(void *blob, u32 disabled_cores) { static const char * const nodes_path[] = { "/cpus/cpu@1", "/cpus/cpu@2", "/cpus/cpu@3", }; u32 i = 0; int rc; int nodeoff; if (disabled_cores > 3) return -EINVAL; i = 3 - disabled_cores; for (; i < 3; i++) { nodeoff = fdt_path_offset(blob, nodes_path[i]); if (nodeoff < 0) continue; /* Not found, skip it */ debug("Found %s node\n", nodes_path[i]); rc = fdt_del_node(blob, nodeoff); if (rc < 0) { printf("Unable to delete node %s, err=%s\n", nodes_path[i], fdt_strerror(rc)); } else { printf("Delete node %s\n", nodes_path[i]); } } Re: A little confused about dtsi for imx8mm single core @チャビラ これがあなたの提案です: 参照を再確認してください。U-Boot デバイス ツリーは Linux デバイス ツリーと同じではなく、一方に加えた変更が他方に自動的に適用されるわけではありません。 ここで、参照を二重に確認し、別の色を使用して強調表示します。 u-bootランタイムによるLinuxデバイス ツリーの変更 (dtb) u-boot ランタイムによる Linux デバイス ツリーの変更 (dtb) https://community.nxp.com/t5/i-MX-Processors-Knowledge-Base/u-boot-runtime-modify-Linux-device-tree-dtb/ta-p/1347212 Re: A little confused about dtsi for imx8mm single core @チャビラ 最初から今まで、u-boot が Linux デバイス ツリーをどのように変更するかについて説明してきましたが、u-boot 自体のデバイス ツリーについてはまったく説明していませんでした。 次のコードでも、u-boot を使用して Linux デバイス ツリーを変更します。 https://github.com/nxp-imx/uboot-imx/blob/lf-5.10.72-2.2.3/arch/arm/mach-imx/imx8m/soc.c static int disable_cpu_nodes(void *blob, u32 disabled_cores) { static const char * const nodes_path[] = { "/cpus/cpu@1", "/cpus/cpu@2", "/cpus/cpu@3", }; u32 i = 0; int rc; int nodeoff; if (disabled_cores > 3) return -EINVAL; i = 3 - disabled_cores; for (; i < 3; i++) { nodeoff = fdt_path_offset(blob, nodes_path[i]); if (nodeoff < 0) continue; /* Not found, skip it */ debug("Found %s node\n", nodes_path[i]); rc = fdt_del_node(blob, nodeoff); if (rc < 0) { printf("Unable to delete node %s, err=%s\n", nodes_path[i], fdt_strerror(rc)); } else { printf("Delete node %s\n", nodes_path[i]); } } もう一度強調しますが、私は u-boot のデバイス ツリーについて一度も説明していません。 Re: A little confused about dtsi for imx8mm single core @チャビラ ここでは、u-boot デバイス ツリーの変更ではなく、u-boot による Linux デバイス ツリーの変更について説明します。 また、コードhttps://github.com/nxp-imx/uboot-imx/blob/lf-5.10.72-2.2.3/arch/arm/mach-imx/imx8m/soc.cは、u-boot fdt コマンドと同じことを行います。 u-boot ランタイムでは、Linux デバイス ツリー (dtb) を変更するために u-boot コマンドを使用して Linux デバイス ツリーを変更します。 https://community.nxp.com/t5/i-MX-Processors-Knowledge-Base/u-boot-runtime-modify-Linux-device-tree-dtb/ta-p/1347212 8 ページから 11 ページにかけて、u-boot が Linux デバイス ツリーを変更し、Linux を起動することが明確に示されています。 Re: A little confused about dtsi for imx8mm single core こんにちは@hogole 、 ここで混乱が生じているようです。 Linux デバイス ツリーと U-Boot デバイス ツリーは 2 つの異なるエンティティであり、それぞれブート プロセスで異なる目的を果たします。あなたが参照しているドキュメントは、Linux カーネルで使用されるものではなく、U-Boot デバイス ツリーを具体的に変更するものです。 参照を再確認してください。U-Boot デバイス ツリーは Linux デバイス ツリーと同じではなく、一方に加えた変更が他方に自動的に適用されるわけではありません。 Re: A little confused about dtsi for imx8mm single core まだ混乱している点がいくつかあります。 チャビラさん、これがあなたの返事です: 1>> U-Boot は実行時に Linux デバイス ツリーを変更しません。 Linux カーネルがロードされると、U-Boot はデバイス ツリーを制御できなくなります。 u-boot が Linux デバイス ツリーを変更できないのは確かですか? a. u-boot には、Linux デバイス ツリーを変更できる fdt コマンドがあります。 あなたの同僚もこれに関するドキュメントを持っています。 ここにその文書があります: u-boot ランタイムによる Linux デバイス ツリーの変更 (dtb) https://community.nxp.com/t5/i-MX-Processors-Knowledge-Base/u-boot-runtime-modify-Linux-device-tree-dtb/ta-p/1347212 b. arch/arm/mach-imx/imx8m/soc.c は、u-boot fdt コマンドと同じ API を使用します。 c. u-boot は Linux ランタイム環境を準備するものですよね? Linux デバイスツリーの変更を含むすべての操作は、Linux が起動する前に実行する必要があります。 u-boot が Linux デバイスをロードした後、Linux がまだ起動していない場合、Linux デバイス ツリーを変更することはできませんか? 最も簡単な質問は、「disable_cpu_nodes」API 関数は Linux の起動前ですか、それとも起動後ですか? これらの問題は私たちが実際に実行しているプロジェクトに関係するため、NXP からの説明が本当に必要です。 ソースコードを確認していただけますか? https://github.com/nxp-imx/uboot-imx/blob/lf-5.10.72-2.2.3/arch/arm/mach-imx/imx8m/soc.c ここでのconst nodes_pathは Linux デバイス ツリー ノードですか? static int disable_cpu_nodes(void *blob, u32 disabled_cores) { static const char * const nodes_path[] = { "/cpus/cpu@1", "/cpus/cpu@2", "/cpus/cpu@3", }; u32 i = 0; int rc; int nodeoff; if (disabled_cores > 3) return -EINVAL; i = 3 - disabled_cores; for (; i < 3; i++) { nodeoff = fdt_path_offset(blob, nodes_path[i]); if (nodeoff < 0) continue; /* Not found, skip it */ debug("Found %s node\n", nodes_path[i]); rc = fdt_del_node(blob, nodeoff); if (rc < 0) { printf("Unable to delete node %s, err=%s\n", nodes_path[i], fdt_strerror(rc)); } else { printf("Delete node %s\n", nodes_path[i]); } } Re: A little confused about dtsi for imx8mm single core こんにちは@hogole 、 1>> U-Boot は実行時に Linux デバイス ツリーを変更しません。 Linux カーネルがロードされると、U-Boot はデバイス ツリーを制御できなくなります。 2>> U-Boot は SoC モデルを検出し、不足している CPU コア、GPU、NPU などの使用できないリソースの使用を回避します。この検出は、起動時のシステムの不安定性を防ぐのに役立ちます。 3>> Linux デバイス ツリーは、U-Boot のソース コードや動作に影響を与えません。 各環境は独自のデバイス ツリーを独立して使用します。 4>> Linux が使用するコアの数を調整するために、U-Boot のソースコードを変更する必要はありません。 U-Boot はシステムのブートローダーとして機能し、使用できないペリフェラルの使用を回避するための自動検出メカニズムを備えているため、ブート中の SoC の誤動作を防ぐのに役立ちます。ただし、Linux カーネルがロードされると、利用可能なハードウェア リソースを把握するためにデバイス ツリーに完全に依存します。 デバイス ツリーで 4 つの CPU コアが宣言されているが、ハードウェアには 1 つまたは 2 つしかない場合、Linux は存在しないコアでタスクを初期化してスケジュールしようとします。この不一致は、カーネル パニックやシステム クラッシュなどの深刻な問題を引き起こすCANがあります。したがって、Linux を起動する前に、デバイス ツリーが実際のハードウェア構成を正確に反映していることを確認することが重要です。 コア構成は、Linux カーネルに渡されるデバイス ツリーで直接処理する必要があります。 Re: A little confused about dtsi for imx8mm single core 以前のように応答が予期せず消えてしまうことを防ぐために、このページのスナップショットを保存しました。 Re: A little confused about dtsi for imx8mm single core @チャビラ 1.この問題は、U-Boot が実行時に Linux デバイス ツリーを変更することに関係しています。あなたが言及したブートプロセスは、現在議論しているトピックとは直接関係していないようですね。 2. U-Boot コードが、ヒューズによって示されたコアの数に基づいて実行時に Linux デバイス ツリーを既に自動的に更新している場合、コンパイル時にデバイス ツリーを変更する必要があるのはなぜですか? 3.コンパイル時に Linux デバイス ツリーを変更すると、U-Boot によるヒューズ設定に基づくコア数のランタイム調整が妨げられる可能性がありますか? 4. NXP がリリースした BSP の U-Boot コードには、ヒューズによって示されたコア数に応じて実行時に Linux デバイス ツリーを自動的に更新するロジックがすでに含まれているのに、なぜ NXP のサポート エンジニアは最初からこのことを私たちに伝えなかったのでしょうか。 これは、U-Boot コードのその部分に問題がある可能性があることを意味していますか? Re: A little confused about dtsi for imx8mm single core 今日は何かアップデートはありますか?問題の原因は見つかりましたか?私の返信が消えたのはなぜですか?CAN復元できますか? Re: A little confused about dtsi for imx8mm single core 私の投稿が消えたのはなぜですか?コミュニティ管理者は問題が何であるか確認していただけますか? Re: A little confused about dtsi for imx8mm single core ありがとう Re: A little confused about dtsi for imx8mm single core こんにちは@hogole 、 チップ モデルの検出を担当する U-Boot コードは正常に機能しており、エラーは発生しません。したがって、U-Boot に変更を加えることは不要であるため、お勧めしません。 ただし、Linux カーネルは独立して動作するため、適切な構成を確保するために、機能していないことがわかっている CPU ノードを削除することをお勧めします。これにより、システムの潜在的な誤動作や不安定性を防ぐことができます。 このCASE、両方のアプローチが有効です。 ブートプロセスを理解するには、次のブロック図を参照してください。 よろしくお願いいたします。 チャビラ Re: A little confused about dtsi for imx8mm single core あなたの答えは私をさらに混乱させました。コアの数を自動検出する BSP のコードが間違っているということでしょうか?コアノードを削除するには、DTS ファイルを変更する必要があるということですか? コアの数を自動的に検出する BSP のコードが正しいのなら、なぜ NXP のエンジニアは DTS ファイルを変更してコア ノードを削除することを推奨するのでしょうか? どちらが正しいでしょうか? Re: A little confused about dtsi for imx8mm single core こんにちは@hogole 、 推奨される方法は、デバイス ツリーから対応するノードを削除することです。 U-Boot はチップ モデルとその利用可能な機能を検出できますが、デバイス ツリー内のノードを無効にすると、Linux カーネルがサポートされていないコンポーネントにアクセスしないようにすることができます。投稿で言及されているソースはカーネルではなく U-Boot に関連しているため、これが特に重要です。 これは誰でも自分の経験を共有できる公開コミュニティであることをご留意ください。ただし、安定性と互換性を確保するために、公式の推奨事項に従うことを強くお勧めします。 よろしくお願いします、 チャビラ Re: A little confused about dtsi for imx8mm single core 一週間が経ちました。現在取り組んでいる iMX8MM プロジェクトに自信を持てるよう、NXP は私の疑問に答えることを検討していただけますか?NXP の専門的なサポートが必要です。 Re: A little confused about dtsi for imx8mm single core このコミュニティの多くの人が私に同意してくれると信じています。私たちは皆、NXP エンジニアの回答を信じています。投票するなら、大多数の人は間違いなく NXP エンジニアの回答を考慮するでしょう。 Re: A little confused about dtsi for imx8mm single core また、説明も知りたいです。 Re: A little confused about dtsi for imx8mm single core また、説明も知りたいです。 Re: A little confused about dtsi for imx8mm single core また、説明も知りたいです。 Re: A little confused about dtsi for imx8mm single core また、説明も知りたいです。 Re: A little confused about dtsi for imx8mm single core また、説明も知りたいです。 Re: A little confused about dtsi for imx8mm single core また、説明も知りたいです。 Re: A little confused about dtsi for imx8mm single core また、説明も知りたいです。 Re: A little confused about dtsi for imx8mm single core また、説明も知りたいです。 Re: A little confused about dtsi for imx8mm single core また、説明も知りたいです。 Re: A little confused about dtsi for imx8mm single core また、説明も知りたいです。 Re: A little confused about dtsi for imx8mm single core また、説明も知りたいです。 Re: A little confused about dtsi for imx8mm single core また、説明も知りたいです。 Re: A little confused about dtsi for imx8mm single core また、説明も知りたいです。 Re: A little confused about dtsi for imx8mm single core また、説明も知りたいです。 Re: A little confused about dtsi for imx8mm single core また、説明も知りたいです。 Re: A little confused about dtsi for imx8mm single core また、説明も知りたいです。 Re: A little confused about dtsi for imx8mm single core また、説明も知りたいです。 Re: A little confused about dtsi for imx8mm single core また、説明も知りたいです。 Re: A little confused about dtsi for imx8mm single core また、説明も知りたいです。 Re: A little confused about dtsi for imx8mm single core また、説明も知りたいです。 Re: A little confused about dtsi for imx8mm single core また、説明も知りたいです。 Re: A little confused about dtsi for imx8mm single core また、説明も知りたいです。 Re: A little confused about dtsi for imx8mm single core また、説明も知りたいです。 Re: A little confused about dtsi for imx8mm single core また、説明も知りたいです。 Re: A little confused about dtsi for imx8mm single core また、説明も知りたいです。 Re: A little confused about dtsi for imx8mm single core また、説明も知りたいです。 Re: A little confused about dtsi for imx8mm single core また、説明も知りたいです。 Re: A little confused about dtsi for imx8mm single core また、説明も知りたいです。 Re: A little confused about dtsi for imx8mm single core また、説明も知りたいです。 Re: A little confused about dtsi for imx8mm single core また、説明も知りたいです。 Re: A little confused about dtsi for imx8mm single core また、説明も知りたいです。 Re: A little confused about dtsi for imx8mm single core また、説明も知りたいです。 Re: A little confused about dtsi for imx8mm single core また、説明も知りたいです。 Re: A little confused about dtsi for imx8mm single core また、説明も知りたいです。 Re: A little confused about dtsi for imx8mm single core また、説明も知りたいです。 Re: A little confused about dtsi for imx8mm single core また、説明も知りたいです。 Re: A little confused about dtsi for imx8mm single core 最終的な説明は何ですか? Re: A little confused about dtsi for imx8mm single core 最終的な説明は何ですか? Re: A little confused about dtsi for imx8mm single core 最終的な説明は何ですか? Re: A little confused about dtsi for imx8mm single core 最終的な結論は何ですか?
View full article
The best way to build a PCB first time right with KW47 (Automotive) or MCX W72 (IoT/Industrial) Please, find the important link to build a PCB using a KW4x or MCX W7x and all concerning the radio performances, low power and radio certification (CE/FCC/IC). matthieu_baudry_0-1768238081772.png “As RF behavior are dependent of PCB layout & manufacturing; PCB prototypes (based on NXP recommendations) will have to be fine-tuned to insure the expected qualified in RF is reached on the final productized platform.” KW47 product NXP web page:  https://www.nxp.com/products/KW47 MCXW72 product NXP web page: https://www.nxp.com/products/MCX-W72 Board pages:  KW47-EVK Evaluation Kit with Bluetooth® Low Energy 6.0 KW47-LOC Localization Reference Design using KW47 MCXW72-LOC Localization Board for MCX W72 Bluetooth Channel Sounding MCU FRDM-MCXW72 Development Board for MCX W72 Wireless MCU   in addition of the product webpages please refer to KW47 Knowledge Hub Do not use pre-production or production board prior to April 2026 KW47-LOC or MCXW72-LOC platform for Channel Sounding certification - contact NXP for further note NXP Channel Sounding PAGE        (Bluetooth ®  SiG Channel Sounding Technical Overview ) More Channel Sounding enablement Available on request to NXP  Channel Sounding Fundamentals for the KW47 and MCX W72[AN14865] Fundamental Steps to Design a Channel Sounding Board - Creating a Simple PCB without Diversity[AN14832] Fundamental Steps to Design a Complex Channel Sounding Board[AN14869]        Printed Channel Sounding Antennas for the KW47 and MCX W72[AN14779] HARDWARE KW47-MCXW72-EVK HW guideline: KW47 Hardware Design Guide[UG10127] MCX W72 Hardware Design Guide[UG10273] HVQFN48 package specification: SOT619-17(D)   pending release of SOT619-17(DD)   KW47-MCXW72-EVK User Manual  KW47-LOC Board User Manual[UM12114] KW47-EVK Board User Manual[UM12094] MCXW72-LOC Board User Manual[UM12113] FRDM-MCXW72 User Manual[UM12222] Minimum BoM (attached file)  DCDC management guide (AN13831) :  Power Management Hardware (nxp.com) - KW45 applicable for KW47 waiting release of KW47/MCXW72  Design-In check list: see attached file at the bottom of this article RF matching: S parameters (attached file) Available on request    How to handle coincell application on PCB:  Coin Cell Hardware Recommendations for Kinetis Bluetooth LE Applications[AN14664] KW47-MCXW72 module can also be handled in standalone:  How to run KW47-M2 standalone RF output power level: Please note it is expected that each final PCB platform, is refine with the right RF matching and filtering, to fit your market and region mandatory certification. For instance the +10dBm at pin level can be exceeded in some configuration. It is final PCB owner responsibility to build a system (incl. all Rf path loss) with the expected target power level fitting with Bluetooth SiG Core spec and European radio certification target. Then the Tx power has to be adjusted at application level.   UFL SMA CABLE: On EVK, to connect M10 module for RF trials a µFL to SMA cable is recommended:  CSH-SGFB-200-UFFR TE Connectivity / Linx Technologies | Mouser France On KW47-LOC or MCXW72-LOC to connect SMA specific connector has to be populated: TE Connectivity Ltd CONSMA021.062-G. Warning to solder SMA connector:  please insure the PCB edge is well cut and right smooth; if not please mill a bit with a sand paper. (risk is to get SMA core line not well soldered on PCB line) Also for higher Harmonics the µFL is not convenient as connector is limited above 6GHz (an SMA has to be soldered to control RF losses ) RF matching component tolerance: Please note, on NXP EVK, FRDM and LOCalization platform the RF matching components (Inductors, Capacitors) are using the HIGH tolerance Muratasets. During your RF board tuning you may need to use low tolerance Murata set to insure all RF limits are passing. Eg: GJM1555C1H3R3CB01D is +/-0.25pF tolerance where GJM1555C1H3R3BB01 with +/-0.1pF tolerance may be preferred Eg2: LQG15HS1N3S02D  is +/-0.3nH tolerance where LQG15HS1N3B02D   with +/-0.1nH tolerance may be preferred KW47 from KW45 hardware porting :  KW47 is pin to pin compatible with KW45. However from HW point of view, some components values will have to be adjusted like RF matching components values. Other components around KW4x are not foreseen as to change based on current silicon validation.  Please also note some new muxing is in place to get new features of KW47 on pins. For instance on KW47 a second Flex CAN is available. See attached file RADIO RF report:         AN14461: KW47-EVK RF System Evaluation Report for Bluetooth Low Energy Applications | NXP Semiconductors KW47-LOC RF System Evaluation Report for Bluetooth Low Energy Applications        AN14580: MCX W72 RF System Evaluation Report for Bluetooth and IEEE.802.15.4 Applications | NXP Semiconductors Radio co-existence:  Kinetis Wireless Family Products Bluetooth Low Energy Coexistence with Wi-Fi Application (nxp.com) pending release of KW47/MCXW72  Antenna:  Compact Planar Antennas for 2.4 GHz Communication Designs and Applications within NXP EVK Boards Printed Channel Sounding Antennas for the KW47 and MCX W72[AN14779] Return loss (S11) measurement: How to measure the return loss of your RF matching (S11) part of the RF report (AN13728) Loadpull: Loadpull Test Report for KW47[AN14696] SW tools for RF trials:     IoT Tool box (mobile application)     Connectivity test tool for connectivity products (part of the IoT toolbox)     DTM: How to use the HCI_bb on Kinetis family products a... - NXP Community https://community.nxp.com/t5/Wireless-Connectivity-Knowledge/BLE-HCI-Application-to-set-transmitter-... CRYSTAL   Recommended Crystal attached   Articles: KW47/MCX W72 32MHz & 32kHz Oscillation margins - NXP Community  32 kHz Crystal-less Mode on KW47[AN14884]   Please note for Channel Sounding feature with higher 10dBm transmit output, some specific care have to be taken adding to pass all harmonics on all Bluetooth Channels: see "32 MHz crystal harmonics design recommendations" chapter in "AN14826: KW47-LOC RF System Evaluation Report" where an extra inline inductor on Xtal path may be needed. LowPower      All power profiling tools are available in this NXP community web page:              KW35, KW38, KW45, KW47 & MCX W71, MCX W72 & MCX W23 Power Profile Tools (including Localization)      Bluetooth LE power profile estimator Tool               KW45_WK47_MCXW71_MCXW72_BLE_power_profile_calculator vx.x.xls              AN14554 Kinetis KW47 & MCX W72 Bluetooth LE Power profile analysis release.pdf      802.15.4 Matter & Zigbee power profile estimator Tool               MCX W7x 802.15.4 Matter ICD SIT LIT & ZED Power profile vx.x.xls               AN MCX W72 802.15.4 Matter and Zigbee Power profile analysis.pdf      CCC Channel Sounding BLE power profile estimator Tool               KW47 Digital Key CCC CS Power Estimator tool vx.x.xls               AN14628_AN14628_KW47_CCC_CS_Power_Profile_estimator tool_release.pdf CERTIFICATION RF full certification of KW47/MCXW72  available on board product pages KW47 and MCXW72 are Bluetooth 6.x channel Sounding certified!
View full article
[S32K3 tool part]:How to use IAR compiler or IAR project to compile S32K3 MCAL project [S32K3 tool part]:How to use IAR compiler or IAR project to compile MCAL project 1.    Abstract      Through regular observation, it has been found that there are still many customers using platforms such as MCAL+IAR, including those using IAR compilers and those directly using IAR IDEs. In fact, when I was working on industrial MCUs in the past, I also particularly liked IAR IDE for its fast compilation speed, high compilation efficiency, and small code generation. However, when I came to auto MCU, I found that its popularity was not very high, and I also noticed that some customers encountered various problems when importing MCAL into IAR. Therefore, I will directly write a tool article on how to use IAR compiler or IAR IDE project to compile NXP S32K MCAL in combination with EB tresos MCAL. This article uses S32K344 combined with RTD600 to illustrate the compilation of MCAL projects using IAR compiler and the direct import of MCAL into IAR IDE projects 2. IAR Complier with S32K3 RTD MCAL project 2.1 S32K3 HW and SW SW32K3_S32M27x_RTD_R21-11_6.0.0 S32K3X4-EVB Based on Dio_TS_T40D34M60I0R0 IAR:IAR EW for Arm 9.70.1 EB tresos29.0.0 2.2 Compile MCAL project steps using IAR compiler CMD method 2.2.1 Copy one RTD MCAL new project Open path C:\NXP\SW32K3_S32M27x_RTD_R21-11_6.0.0\eclipse\plugins Copy Dio_TS_T40D34M60I0R0 , rename it as Dio_TS_T40D34M60I0R0_IAR Fig 1 2.2.2 Complie EB tresos project Use EB tresos tool open the following EB tresos project : C:\NXP\SW32K3_S32M27x_RTD_R21-11_6.0.0\eclipse\plugins\Dio_TS_T40D34M60I0R0_IAR\examples\EBT\S32K3XX\Dio_Example_S32K344\TresosProject Generate code: Fig 2 2.2.3 Vscode open Dio_TS_T40D34M60I0R0_IAR project Use VS code open the following path folder: C:\NXP\SW32K3_S32M27x_RTD_R21-11_6.0.0\eclipse\plugins\Dio_TS_T40D34M60I0R0_IAR\examples\EBT\S32K3XX\Dio_Example_S32K344 Of course, you can also directly open this folder path using the command line, as long as you ensure that it is in the same layer path as the. mk and makefile scr Fig 3 2.2.4   Project_parameters.mk modification Mainly modify the following points: TOOLCHAIN = iar IAR_DIR = C:/IAR/ewarm-9.70.1 TRESOS_DIR = C:/EB/tresos_29_0_0 PLUGINS_DIR = C:/NXP/SW32K3_S32M27x_RTD_R21-11_6.0.0/eclipse/plugins The path of IAR must be consistent with the version of IAR software used to ensure that the corresponding IAR compiler can be found. Fig 4 2.2.5   Check_build_params.mk modification Add the following content to check_build_params.mk: else ifeq ($(TOOLCHAIN),iar) ifeq ("$(wildcard $(IAR_DIR)/arm/bin/iccarm.exe)","") $(error Invalid path set to the IAR compiler. \ The provided path: from project_parameters.mk IAR_DIR=$(IAR_DIR) is invalid!) Endif Fig 5 2.2.6        Makefile modification   Makefile need the following 5 points modification: (1)Compilier change ifeq (${TOOLCHAIN},iar) CC := $(IAR_DIR)/arm/bin/iccarm.exe LD := $(IAR_DIR)/arm/bin/ilinkarm.exe AS := $(IAR_DIR)/arm/bin/iasmarm.exe # Intel Hexadecimal Flash image tool GENHEX := $(IAR_DIR)/arm/bin/ielftool.exe HEX_OPTS := --ihex OUT_OPTS := -o endif Fig 6 (2) SRC_DIRS  add TOOLCHAIN SRC_DIRS += $(foreach mod,$(MCAL_MODULE_LIST),$(PLUGINS_DIR)/$(mod)_$(AR_PKG_NAME)/src) \ $(foreach mod,$(MCAL_MODULE_LIST_ADDON),$(PLUGINS_DIR_ADDON)/$(mod)_$(AR_PKG_NAME_ADDON)/src) \ $(PLUGINS_DIR)/Platform_$(AR_PKG_NAME)/startup/src \ $(PLUGINS_DIR)/Platform_$(AR_PKG_NAME)/startup/src/m7 \ $(PLUGINS_DIR)/Platform_$(AR_PKG_NAME)/startup/src/m7/$(TOOLCHAIN) Fig 7 (3) Linker file  modification ifeq ($(LOAD_TO),flash) ifeq (${TOOLCHAIN},iar) LINKER_DEF:= $(PLUGINS_DIR)/Platform_$(AR_PKG_NAME)/build_files/${TOOLCHAIN}/linker_flash_$(DERIVATIVE_LOWER).icf else LINKER_DEF:= $(PLUGINS_DIR)/Platform_$(AR_PKG_NAME)/build_files/$(TOOLCHAIN)/linker_flash_$(DERIVATIVE_LOWER).ld endif else ifeq (${TOOLCHAIN},iar) LINKER_DEF:= $(PLUGINS_DIR)/Platform_$(AR_PKG_NAME)/build_files/$(TOOLCHAIN)/linker_ram_$(DERIVATIVE_LOWER).icf else LINKER_DEF:= $(PLUGINS_DIR)/Platform_$(AR_PKG_NAME)/build_files/$(TOOLCHAIN)/linker_ram_$(DERIVATIVE_LOWER).ld endif endif Fig 8 (4) Complier options change ifeq (${TOOLCHAIN},iar) ################################################################################ # iar Compiler options ################################################################################     clib        := $(IAR_DIR)/arm/lib     CCOPT           +=  --cpu=Cortex-M7 \                         -DAUTOSAR_OS_NOT_USED \                         -DUSE_MCAL_DRIVERS \                         --fpu=FPv5-SP \                         --cpu_mode=thumb \                         --endian=little \                         -e \                         -Ohz \                         --debug \                         --no_clustering \                         --no_mem_idioms \                         --do_explicit_zero_opt_in_named_sections \                         --require_prototypes \                         --no_wrap_diagnostics \                         --diag_suppress=Pa050 \                         $(MISRA) \                         -D$(PLATFORM) \                         -D$(DERIVATIVE) \                         -DIAR \                         -DUSE_SW_VECTOR_MODE  \                         -DENABLE_FPU \                         -DD_CACHE_ENABLE \                         -DI_CACHE_ENABLE                             LDOPT           :=  --entry _start \                         --enable_stack_usage \                         --skip_dynamic_initialization \                         --no_wrap_diagnostics \                         --cpu=Cortex-M7 \                         --fpu=FPv5-SP                             ASOPT           :=  $(ASOPT) \                         --cpu Cortex-M7 \                         --cpu_mode thumb \                         -g \                         -r \                         -DMULTIPLE_CORE endif Fig 9 Fig  10 So how did these IAR compilation options come about? You can refer to the release note of RTD600, which contains corresponding descriptions Fig 11 (5) Elf related change ifeq (${TOOLCHAIN},iar) %.elf: %.o $(LINKER_DEF)               @echo "Linking $@"               @$(LD) $(ODIR)/*.o $(LDOPT) --config $(LINKER_DEF) --map $(ODIR)/ -o $(ODIR)/$@@               @$(GENHEX) $(HEX_OPTS) "$(ODIR)/$(ELFNAME).elf" "$(ODIR)/$(ELFNAME).hex" else %.elf: %.o $(LINKER_DEF)               @echo "Linking $@"               @$(LD) -Wl,-Map,"$(MAPFILE)" $(LDOPT) -T $(LINKER_DEF) $(ODIR)/*.o -o $(ODIR)/$@@               @$(GENHEX) $(HEX_OPTS) "$(ODIR)/$(ELFNAME).elf" $(OUT_OPTS) "$(ODIR)/$(ELFNAME).hex" endif Fig 12 2.2.7   Build to generate elf Commander: make clean make build to generate the elf files: Fig 13 After generation, the elf can be burned onto the S32K344 EVB board for testing. The test results show that the onboard red light is flashing, indicating that the IAR compiler can work in command-line mode. 3. Import RTD MCAL to IAR IDE project This chapter explains how to create an IAR IDE project and import MCAL drivers to implement S32K3 MCAL combined with EB tresos for running. 3.1 MCAL IAR IDE project 2 methods Difference between two methods and how to import MCAL drivers: (1) Directly copy the RTD MCAL driver to the IAR IDE project directory (2) Connect the IAR IDE project driver to the original RTD driver path Fig 14 3.2 MCAL IAR IDE project import steps 3.2.1 create the new RTD MCAL IAR project folder    Create a new folder, named as:S32K344_DIO_MCAL_RTD600_IAR 3.2.2 create the sub folder for IAR project       Generate:EB tresos project code       Include:app related include file       Mcal: mcal driver copy from RTD       src: project main file       Tresos_Project:EB tresos project Fig 15 3.2.3 create EB tresos project (1) Create the EB tresos project in the followign path:  S32K344_DIO_MCAL_RTD600_IAR\Tresos_Project\Mcal_Dio_S32K344_RTD600_IAR (2)Add modules: BaseNXP, Dem, Dio, EcuC, Mcu, Platform, Port, Resource (3)Copy RTD xdm files in the following path: C:\NXP\SW32K3_S32M27x_RTD_R21-11_6.0.0\eclipse\plugins\Dio_TS_T40D34M60I0R0\examples\EBT\S32K3XX\Dio_Example_S32K344\TresosProject\Dio_Example_S32K344\config to: S32K344_DIO_MCAL_RTD600_IAR\Tresos_Project\Mcal_Dio_S32K344_RTD600_IAR\config (4)EB tresos Generate project EB tresos code will be generated to folder: S32K344_DIO_MCAL_RTD600_IAR\Generate Fig 16 3.2.4 Copy RTD related drivers to IAR project folder (1) BaseNXP: header, include, src (2)Det:  include, src (3)Dio:  include, src (4)Mcu:  include, src (5)Platform: build_files, include, src, startup (6)Port: include, src (7)Rte: include, src Copy RTD folder to IAR project is one method, if don’t want to copy the file, also can use the linker to add the RTD install path drivers directly. Fig 17 3.2.5 IAR IDE create IAR project   (1) Project->Create new project   (2) In the IAR project, add group   The related folder in project can be structured like the fig 18, which contains:   Generate: Include and src->EB tresos project generate code   Mcal:  Base, Det, Dio, Mcu, Platform, Port, Rte->Mcal driver   Src: Main.c->project main code    (3) Add RTD mcal related drivers to IAR project The RTD MCAL related driver files can be directly downloaded from the RTD installation path or copied to a folder in the IAR project, and both methods yield the same result. Fig 18 (4)IAR project platform folder added result: Fig 19 (5)main code add Main.c can copy from path: C:\NXP\SW32K3_S32M27x_RTD_R21-11_6.0.0\eclipse\plugins\Dio_TS_T40D34M60I0R0\examples\EBT\S32K3XX\Dio_Example_S32K344\src to S32K344_DIO_MCAL_RTD600_IAR\src Comment:  //#include "check_example.h"  // Exit_Example(TRUE); 3.2.6 IAR project options configuration (1)General options->Target->Device->NXP S32K344 (2)C/C++ Complier->Preprocessor Addional include directories: Use IAR project folder drivers which copied from RTD install path, the directories are: $PROJ_DIR$\Generate\include $PROJ_DIR$\mcal\BaseNXP_TS_T40D34M60I0R0\header $PROJ_DIR$\mcal\BaseNXP_TS_T40D34M60I0R0\include $PROJ_DIR$\mcal\Mcu_TS_T40D34M60I0R0\include $PROJ_DIR$\mcal\Platform_TS_T40D34M60I0R0\include $PROJ_DIR$\mcal\Rte_TS_T40D34M60I0R0\include $PROJ_DIR$\mcal\Platform_TS_T40D34M60I0R0\startup\include $PROJ_DIR$\mcal\Det_TS_T40D34M60I0R0\include $PROJ_DIR$\mcal\Dio_TS_T40D34M60I0R0\include $PROJ_DIR$\mcal\Port_TS_T40D34M60I0R0\include $PROJ_DIR$\include If use the RTD install path drivers, use the following directories: $PROJ_DIR$\Generate\include C:\NXP\SW32K3_S32M27x_RTD_R21-11_6.0.0\eclipse\plugins\BaseNXP_TS_T40D34M60I0R0\header C:\NXP\SW32K3_S32M27x_RTD_R21-11_6.0.0\eclipse\plugins\BaseNXP_TS_T40D34M60I0R0\include C:\NXP\SW32K3_S32M27x_RTD_R21-11_6.0.0\eclipse\plugins\Mcu_TS_T40D34M60I0R0\include C:\NXP\SW32K3_S32M27x_RTD_R21-11_6.0.0\eclipse\plugins\Platform_TS_T40D34M60I0R0\include C:\NXP\SW32K3_S32M27x_RTD_R21-11_6.0.0\eclipse\plugins\Rte_TS_T40D34M60I0R0\include C:\NXP\SW32K3_S32M27x_RTD_R21-11_6.0.0\eclipse\plugins\Platform_TS_T40D34M60I0R0\startup\include C:\NXP\SW32K3_S32M27x_RTD_R21-11_6.0.0\eclipse\plugins\Dio_TS_T40D34M60I0R0\include C:\NXP\SW32K3_S32M27x_RTD_R21-11_6.0.0\eclipse\plugins\Port_TS_T40D34M60I0R0\include C:\NXP\SW32K3_S32M27x_RTD_R21-11_6.0.0\eclipse\plugins\Det_TS_T40D34M60I0R0\include $PROJ_DIR$\include Defined symbols: S32K3XX S32K344 IAR USE_SW_VECTOR_MODE D_CACHE_ENABLE I_CACHE_ENABLE ENABLE_FPU Extra options: --no_clustering --no_mem_idioms --do_explicit_zero_opt_in_named_sections --require_prototypes --no_wrap_diagnostics Languate 1:   Check Require prototypes Diagnostics Suppress these disgnostics: Pa050 Fig 20 (3)Linker: Two points need to be added: $PROJ_DIR$\mcal\Platform_TS_T40D34M60I0R0\build_files\iar\linker_flash_s32k344.icf Library->Entry symbols: _start Fig 21 (4)Debugger Setup: PE micro, run to main Extra Options: Use command line options: --drv_vector_table_base=__ENTRY_VTABLE Fig 22 3.2.7  Build IAR project Project->Rebuild All Fig 23 3.2.8  Test result Download and debug result: Fig 24 After downloading and running, the red led is blinking on the board, indicating that the IAR IDE MCAL import method project has been successfully run.
View full article
eIQ Toolkit for MCU - Getting Started Labs The tools previously bundled as part of eIQ Toolkit are now released as standalone packages and eIQ Toolkit will no longer be updated after the eIQ Toolkit v1.17 in Q3 2025. Going forward the tools previously included in eIQ Toolkit can now be found at: eIQ Neutron SDK now contains the latest versions of the Neutron Compiler tool (previously called the Neutron Converter tool before Aug 2026) eIQ Time Series Studio can now be found in a standalone package eIQ Model Creator provides an option for vision based model creation eIQ AI Toolkit will provide model optimization functionality (Coming Soon) Netron provides TFLite model viewing functionality This article will remain up for existing users. --------- eIQ Toolkit enables machine learning development with an intuitive GUI (named eIQ Portal) and development workflow tools, along with command line host tool options as part of the eIQ ML software development environment. Developers can create, optimize, debug and export ML models, as well as import datasets and models, rapidly train and deploy neural network models and ML workloads. The eIQ Portal provides output TensorFlow Lite models that seamlessly feed into eIQ inference engines like TensorFlow Lite and TensorFlow Lite for Microcontrollers. Using a tool called Model Runner, eIQ Toolkit can also generate runtime insights to help optimize neural network architectures on i.MX RT and i.MX devices. These labs go over how to use eIQ Portal. It is recommended to do them in the following order: Data Import Lab Model Runner Lab The labs are written for using a FRDM-MCXN947 and i.MX RT1170-EVK, but other eIQ supported devices can be used as well.  MCX N i.MX RT1050 i.MX RT1060 i.MX RT1064 i.MX RT1160 i.MX RT1170 i.MX RT1180 i.MX RT500 i.MX RT600 For details on the Time Series Studio tool please see the Time Series Studio lab guides. For  i.MX RT
View full article
i.MX 93 Memory Compatibility Guide The purpose of this document is to provide extended guidance for the selection of compatible LPDDR4/4X memory devices that are supported by the i.MX 93 series of processors. In all cases, it is strongly recommended to follow the DRAM layout guidelines outlined in the NXP Hardware Developer's Guides for the specific SoCs. The i.MX 93 series of processors supports different packages, and each have their own maximum supported LPDDR4/4x data rates. Please refer to the respective datasheets. Memory devices with binary densities (e.g., 1 GB, 2 GB, 4 GB) are preferred because they simplify memory management by aligning with system addressing schemes and reducing software complexity. NOTE: Some of the LPDDR4/4X devices may not support operation at low speeds and in addition, DQ ODT may not be active, which can impact signal integrity at these speeds. If low-speed operation is planned in the use case, please consult with the memory vendor about the configuration aspects and possible customization of the memory device so correct functionality is ensured. LPDDR4/4X - Maximum Supported Densities SoC Max Data bus width Maximum density Assumed memory organization Notes i.MX 93 (i.MX 93xx) 16-bit 16 Gb / (2 GB) single rank, single channel device with 17-row addresses (R0 - R16) 1, 2, 3   LPDDR4/4X - List of Validated Memories The validation process is an ongoing effort - regular updates of the table are expected. SoC Density Memory Vendor Validated Memory Part# Notes i.MX 93 16 Gb/ (2 GB) Micron LPDDR4/4x: MT53E1G16D1FW-046 AAT:A  (Z32N) MT53E1G16D1ZW-046 AAT:C (Z42N) 7 4, 8 8 Gb/ (1 GB) Micron LPDDR4/4x: MT53D512M16D1DS-046 AAT (Z11M) 4, 10 16 Gb/ (2 GB) Micron LPDDR4/4x: MT53E1G32D2FW-046 AUT:B (Z42M) 4, 5, 10 8 Gb/ (1 GB) Nanya LPDDR4: NT6AN512M16AV-J1I LPDDR4x: NT6AP512M16BV-J1I 4, 8 4 Gb/ (512 MB) Nanya LPDDR4x: NT6AP256M16AV  4, 8 16 Gb/ (2 GB) Kingston LPDDR4: D1611PM3BDGUI-U 4, 8 16 Gb/ (2 GB) Kingston LPDDR4: C1612PC2WDGTKR-U  7, 9 4 Gb/ (512 MB) ISSI LPDDR4: IS43LQ16256B-062BLI 4, 8 2 Gb / (256 MB) ISSI LPDDR4: IS43LQ16128A-062BSLI 4, 6, 8   8 Gb/ (1 GB) CXMT LPDDR4/4x: CXDB4CBAM-EA-M 4, 9 16 Gb/ (2 GB) JSC LPDDR4x: JSL4BAG167ZAMF  4, 8 8 Gb/ (1 GB) JSC LPDDR4x: JSL4B8G168ZAMF-05x  4, 8 4 Gb/ (512 MB) JSC LPDDR4x: JSL4A4G168ZAMF-05 4, 8 2 Gb / (256 MB) Winbond  LPDDR4x: W66BQ6NBHAGJ 4, 6, 8 8 Gb / (1 GB) IM (Intelligent Memory) LPDDR4x: IM8G16L4JCB-046I 4, 11 16 Gb / (2 GB) IM (Intelligent Memory) LPDDR4/4x: IMAG16L4KBBG 4, 8 4 Gb / (512 MB) Samsung LPDDR4: K4F4E164HD-THCL 4, 8 8Gb / (1 GB) AM (Alliance Memory) LPDDR4X: AS4C512M16MD4V-053BIN 4, 8 4 Gb / (512 MB) ISSI LPDDR4/4X: IS43LQ16256B-053BLI 4, 8 8 Gb / (1 GB) ISSI LPDDR4/4X: IS46LQ16512B-046BLA2 4, 8 32Gb / (4GB) 16 Gb / (2Gb) usable by i.MX 93 ISSI LPDDR4/4X: IS46LQ32K01B-046BLI 4, 8   Note 1: The numbers are based purely on the IP documentation for the DDR Controller and the DDR PHY, on the settings of the implementation parameters chosen for their integration into the SoC, SoC reference manual and on the JEDEC standards JESD209-4B/JESD209-4-1 (LPDDR4/4X). Therefore, they are not backed by validation, unless said otherwise and there is no guarantee that an SoC with the specific density and/or desired internal organization is offered by the memory vendors. Should the customers choose to use the maximum density and assume it in the intended use case, they do it at their own risk. Note 2: Byte-mode LPDDR4/4X devices (x16 channel internally split between two dies, x8 each) of any density are not supported therefore, the numbers are applicable only to devices with x16 internal organization (referred to as "standard" in the JEDEC specification). Note 3: The SoC also supports dual rank single channel devices therefore, 16Gb/2GB density can be also achieved by using a dual rank single channel device with 16-row addresses (R0 - R15). Note 4: The memory part number did not undergo full JEDEC verification however, it passed all functional testing items. Note 5: This is a dual channel x32 device. Since i.MX93 only supports 16-bit LPDDR4/X data bus, it can only interface with one of the channels and therefore, utilize only half of the device's density. As indicated in the table - the device has 32Gb/4GB density however, only 16Gb/2GB can be used. There is no functional problem with using only one channel of a dual channel device as the channels are independent in LPDDR4/4X.  Note 6: This is a new JEDEC 100 ball package, half the size of the standard 200 ball package. This 100 ball package has the same performance and functionality as the 200 ball package, and has the added advantage of being smaller and cheaper than the standard package. Note 7: This device has been EoLed by the manufacturer and has been updated by a new memory part number  Note 8: Part is active. Reviewed Q3 2026 Note 9: Part is obsolete. Note 10: This device will be EoLed in Q2 24 by the manufacturer and will not be updated by a new memory part number Note 11: DQ eye marginalities were identified during TSA analysis. vTSA and stability testing did not identify any issues.
View full article
GD3160がSPI経由でレジスタに書き込み、ゲート出力が歪む おはようございます。NXPのGD3160をSPI経由で設定するのに苦労しています。データシートを長い間読み込んできましたが、GD3160のSPIと制御の動作をまだ理解できていません。私の主な問題は次の2つにまとめられます。1つ目は、2つのGDのデイジーチェーンから(少なくとも私が思うに)正常に読み取ることができるのですが、何も書き込むことができません。特にMODE2レジスタのCONFIG_ENビットに書き込むことができません。私はArduino Unoを使用しています。私は自分のコードに対して様々なアプローチとテストを試しましたが、最もシンプルでクリーンなテストコードでも失敗するものを添付します。何が間違っているのか教えていただけますか?計算を二重チェックしたのですが、CRCの問題でしょうか?それともSPIの設定の問題でしょうか?仕様通り、MSBが先です。2- また、ゲートのGD PWM信号は、MOSFETが接続されていないデフォルト構成で、デューティサイクルが約50%のときにのみクリーンです。デューティサイクルを上下に変更すると、オシロスコープで測定されるデューティサイクル信号が位相シフトし、はるかに小さくなります。どこから探し始めればいいか、何かアイデアはありますか? Hブリッジドライバ HS|LS 設定可能ドライバー 絶縁型ゲートドライバ Re: GD3160 writing registers through SPI and distorted Gate output マフムード様、 電圧レベルと部品値が記載された回路図を共有してください。 SPIが正しく設定されていることを確認するために、オシロスコープのプローブをCS、MISO、MOSI、SCLKピンに接続し、オシロスコープの波形を共有してください。SPIタイミング要件については、GD3160のフルデータシートの図35を参照してください。アイドル時はクロックはローレベル(CPOL=0)である必要があり、データはSCLKの立ち下がりエッジで切り替えられ、SCLKの立ち上がりエッジでサンプリングされる必要がある(CPHA=0)。その結果、SPIモード0になります。 AN13167もダウンロードしてご参照ください。そこには、GD3160のSPIインターフェースに関するヒントがいくつか掲載されています。 敬具、 ヨゼフ Re: GD3160 writing registers through SPI and distorted Gate output ご返信ありがとうございます。返信するのをすっかり忘れていました。ハードウェアチームに回路図を依頼する必要があるが、いずれにせよ、仕様通りに動作するようにすることはできた。問題は、書き込み時に高電圧側の電源が失われた場合やラッチ障害が発生した場合にロックされることを知らなかったことだ。私が今懸念しているのはCONFIG_ENビットについてです。単に書き込みや読み出しを行うだけでは設定モードをアクティブ化できません。いろいろ試してみましたが、唯一うまくいったのはconfig_bitとRESETビットに同時に書き込むことでした。なぜ私はこのような経験をしているのでしょうか?なぜconfig_bitとreset bitの両方を書き込む必要があるのですか?仕様によると、reset bitだけに書き込んでもINTBをローに駆動する効果はありませんが、両方のビットに書き込むと効果があります。SPI通信が正しく行われていること、および書き込む値がずれていないことを確認しました(ビットインデックスとオフセットについては間違いありません)。どう思いますか? Re: GD3160 writing registers through SPI and distorted Gate output マフムード様、 リセットビットは、障害をクリアし、レジスタをデフォルトの状態にリセットするだけです。設定モードへの移行を妨げる障害が発生しているようです。これは、GD3160をリセットすると、障害が解消され、設定モードに入ることができるようになることを示唆しています。 STATUSレジスタに異常がないか確認してください。STATUS1、STATUS2、STATUS3レジスタ。 敬具、 ヨゼフ
View full article
【NXPマイコン入門】【モータ制御】【基礎編③】永久磁石同期モータの仕組みと制御方法(日本語ブログ) 目次   【NXPマイコン入門】【モータ制御】【基礎編③】永久磁石同期モータの仕組みと制御方法 縁の下の力持ち!クラーク変換とパーク変換ってなんだろう? すべての始まり:三相交流という「複雑な波」 ステップ1:クラーク変換 - 3次元を2次元にシンプル化する ステップ2:パーク変換 - 動く世界を止めて見る「メリーゴーラウンドの魔法」 なぜこんな面倒な変換をするの? その絶大なメリットとは まとめ:複雑な波を、意のままに操るための数学の力 【NXPマイコン入門】【モータ制御】【基礎編③】永久磁石同期モータの仕組みと制御方法 縁の下の力持ち!クラーク変換とパーク変換ってなんだろう? こんにちは! 電気自動車(EV)がスーッと滑らかに発進したり、高性能なエアコンが驚くほど静かに運転したり。その裏側では、マイコンが超高速で複雑な計算を行い、モーターを巧みに操っています。 今回は、その制御技術の心臓部、「ベクトル制御」で活躍する二人の偉大な専門家(の名前がついた変換)、「クラーク変換」 と 「パーク変換」 の謎を、下のGIFアニメーションと共に解き明かしていきましょう! (function() { var wrapper = document.getElementById('lia-vid-6377224605112w540h540r855'); var videoEl = wrapper ? wrapper.querySelector('video-js') : null; if (videoEl) { if (window.videojs) { window.videojs(videoEl).ready(function() { this.on('loadedmetadata', function() { this.el().querySelectorAll('.vjs-load-progress div[data-start]').forEach(function(bar) { bar.setAttribute('role', 'presentation'); bar.setAttribute('aria-hidden', 'true'); }); }); }); } }})(); (マイビデオを表示) すべての始まり:三相交流という「複雑な波」 まず、一番上の段。これはモーターを動かすための基本エネルギー、「三相交流」の世界です。 右のグラフ(Three-Phase Sine Waves): A相, B相, C相という3つの波が、絶えず大きさと向きを変えながら流れています。この3つの波は互いに連携していますが、このままでは「今、モーターにどれくらいの力を加えるべきか」を直感的に判断するのは至難の業。まるで、3人の奏者がそれぞれ違う楽譜で演奏しているのを、同時に指揮するようなものです。 左のグラフ(Rotating Vector): しかし、この3つの波の力を合成すると、面白いことが起こります。大きさが一定のまま、クルクルと滑らかに回転する一つの力(回転ベクトル)が生まれるのです。物理的には、これがステータコイルが作り出す「回転磁界」そのもの。この回転する磁界こそが、ロータの磁石を引っ張ってモーターを回す力の源です。 課題: この「常に変化する3つの波」を、どうやってマイコンで簡単に、そして正確にコントロールすれば良いのでしょうか? ステップ1:クラーク変換 - 3次元を2次元にシンプル化する 最初の魔法が「クラーク変換」です。これは、複雑な3次元の世界を、もっと分かりやすい2次元の世界に描き直す作業です。 計算式は以下のようになります。 通常モーター制御では、振幅不変変換(K=2/3)、平衡三相(i_a+i_b+i_c=0)を前提とし、以下の簡略化された式が用いられます。   ​ 右のグラフ(Two-Phase Sine Waves α-β): 見てください!3本あった波が、α(アルファ)とβ(ベータ)という2本の波に集約されました。まだ波の形(交流)はしていますが、変数が一つ減って、だいぶ見通しが良くなりました。 左のグラフ(Clarke Transformation α-β): これは、3つの軸(A, B, C)で見ていた回転ベクトルを、直角に交わる2つの軸(α, β)で見た世界です。ちょうど、斜めから見ていた立体を、真上から見た平面図にしたようなイメージ。回転ベクトル自体は、何も変わらず同じように回転しています。 【クラーク変換のポイント】 情報を一切失うことなく、3相という少し扱いにくい座標系から、数学で馴染み深い直交座標(α-β静止座標系)に変換し、問題をシンプルにしました。 ステップ2:パーク変換 - 動く世界を止めて見る「メリーゴーラウンドの魔法」 αとβの値もまだ波のように変化しており、これを追いかけるのは大変です。そこで登場するのが、ベクトル制御の真髄、「パーク変換」です! 計算式は以下のようになります。 ​​ これは、「静止した地面(α-β座標)から回転ベクトルを眺めるのをやめて、いっそのこと回転ベクトルと同じ速度で回るメリーゴーラウンドに飛び乗ってしまおう!」 という、まさに発想の大転換です。この新しい回転する座標を「d-q回転座標系」と呼びます。 右のグラフ(Two-Phase Value d-q): 驚くべき結果です!あれほど激しく変化していた2つの波が、dとqという**ほぼ一定の値(直流)**に変わりました! 左のグラフ(Park Transformation d-q): d-q座標が、回転ベクトルと完全に同期して一緒に回転しているのが分かります。あなたがメリーゴーラウンドに乗っている馬の真横に立てば、その馬はあなたに対して静止して見えますよね?それと全く同じ原理です。回転している側から見れば、回転しているものは止まって見えるのです。 【パーク変換のポイント】 回転ベクトルと同じ速度で回転する座標系(d-q座標)から観測することで、交流の値を直流の値として扱うことができるようになります。 なぜこんな面倒な変換をするの? その絶大なメリットとは この二段階の変換を経て、私たちはとてつもないメリットを手にします。それは 「制御の圧倒的な単純化」 です。 常に変化する交流値を制御するのは難しいですが、直流値ならどうでしょう?目標値より高ければ下げる、低ければ上げる。小学生でも分かるこの単純な操作(PID制御)で、モーターを完璧にコントロールできるようになるのです。 そして、dとqの直流値には、それぞれ重要な物理的な意味が割り当てられています。 q軸の値 (Quadrature-axis): モーターの**トルク(回転する力)**を直接コントロールします。EVのアクセルを踏んだ時にグッと加速するのは、マイコンがこのq軸の目標値を上げているからです。まさに「力のダイヤル」です。 d軸の値 (Direct-axis): モーターの**磁束(磁石の強さ)**をコントロールします。永久磁石モータの場合、ロータの磁石の強さは一定なので、基本的にはこのd軸の電流はゼロになるように制御するのが最も効率的です。まさに「効率のダイヤル」です。 つまり、クラーク変換とパーク変換は、本来ごちゃ混ぜになっているモーターの「力」と「効率」の要素を、2つの独立した直流のダイヤル(dとq)に分離してくれる魔法なのです。 まとめ:複雑な波を、意のままに操るための数学の力 三相交流という複雑な波で、モーターの中に回転する力(回転ベクトル)を作る。 クラーク変換で、3次元の世界を2次元(α-β)に描き直し、問題をシンプルにする。 パーク変換で、回転するメリーゴーラウンド(d-q座標)に乗り込み、交流の値を直流の値に変換する。 直流になったトルク(q)と磁束(d)の値を、PIDコントローラーで簡単かつ正確に制御する! この一連の華麗な数学的処理こそが、現代の高性能モーターを支える「ベクトル制御」の根幹です。この魔法があるからこそ、私たちはパワフルで静かで、省エネなモーターの恩恵を存分に受けることができるのですね。 最後までお読みいただきありがとうございました! 次の基礎編を読みたい方はこちら↓ 【基礎編④】実践!ベクトル制御の仕組みをブロック図で見てみよう! 具体的なセットアップ方法やサンプルコードの動かし方についての解説はこちら↓ 【NXPマイコン入門】【モータ制御】【実践編①】永久磁石同期モータの仕組みと制御方法(日本語ブログ) NXPのモーター制御の記事をまとめたサイトはこちら↓ NXPのモーター制御 ~まとめページ~ (日本語ブログ) =========================​ 本投稿の「Comment」欄にコメントをいただいても、現在返信に対応しておりません。​ お手数をおかけしますが、お問い合わせの際には「NXPへの技術質問 - 問い合わせ方法 (日本語ブログ)」をご参照ください。​ (既に弊社NXP代理店、もしくはNXPとお付き合いのある方は、直接担当者へご質問いただいてもかまいません。)​ NXPのFRDMボード「FRDM-MCXA156」を使用して、モーター制御について分かりやすく解説していきます。基礎編と実践編に分かれていますので、興味のある内容から参考いただければ幸いです。 ・基礎編①~⑦、実践編①~③ 今回は基礎編③として、NXPマイコンで、永久磁石同期モータの仕組みと制御方法について解説します。 MCUXpresso MCUXpresso IDE MCUXpresso SDK MCX Motor Control Technology Focus 日本語ブログ
View full article
Physical connections for INT2 on MPL3115A2 and nRST on MPL115A2 Hi, I'd like to use interchangeably either a MPL115A2 or a MPL3115A2 in my circuit and I'm wondering if I can get away with not using a DNF/resistor on pin 5 and just connecting it to VDD. This is the RST line (active low) on the 115A2 but is INT2 on the 3115A2. What would the effect be if the INT2 line was internally pulling low and the pin is connected to VDD? Is the internal resistance enough that it wouldn't overheat/blow up? Would it be power hungry? Is this a CMOS type output? etc. etc. I'd be running them both from 3.3V on VDD/VDDIO. Any information appreciated - The only information I can find in the datasheets on this is VOH/VOL for INT1 and INT2 with a test condition I_o of 500uA. Pressure Sensors Re: Physical connections for INT2 on MPL3115A2 and nRST on MPL115A2 Thanks Tomas, your reply is very helpful. Re: Physical connections for INT2 on MPL3115A2 and nRST on MPL115A2 Timothy, By default all interrupts are disabled (CTRL_REG4 = 0x00), so the INT2 pin will be high all the time. If you want to use any of the internal interrupts (Data Ready, FIFO etc.), just set a corresponding bit in the CTRL_REG4 register and then route the interrupt to the INT1 pin by setting a corresponding bit in the CTRL_REG5 register. In both cases the INT2 pin can be connected directly to VDD without any problems. I hope it helps. Regards, Tomas
View full article
The benefits of choosing products with NXP security features (Japanese blog) Introduction NXP has long been developing products such as smart cards and secure elements for mobile devices. Based on these technologies, we offer a scalable range of embedded products, including MCUs/MPUs with built-in cryptographic accelerators, MCUs/MPUs with built-in EdgeLock ® secure enclaves, and dedicated security ICs (secure elements, secure authenticators), allowing for easy migration when products with different security strengths are required. We also offer a cloud service (EdgeLock 2GO) that securely writes confidential information to EdgeLock Secure Enclaves, Secure Elements, and Secure Authenticators. This article introduces the features and benefits of NXP's security-enabled products. NXP Hardware Security Product Features NXP offers products and services with the following security features, allowing users to select the optimal product based on the security level they require. Security features and services Feature Overview Cryptographic Accelerators Hardware-based encryption processing function implemented in MCU/MPU EdgeLock ® Secure Enclave A security block implemented within an MCU/MPU that integrates the above cryptographic accelerator as well as numerous other security functions. Secure Element/Authenticator An external IC specialized for security. EdgeLock 2GO A cloud service that supports key management and secure provisioning. In particular, products such as the EdgeLock ® Secure Enclave and Secure Element/Authenticator offer advanced security features not available in other companies' products. Even if you are not sure what level of security you need at the moment, by choosing NXP products, you can easily migrate to products with different security strengths if you need more advanced security features or if you no longer need them. NXP MCU/MPU without cryptographic accelerator or EdgeLock Secure Enclave MCU/MPU with built-in cryptographic accelerator or EdgeLock secure enclave External security IC (secure element/authenticator) The features when compared are shown below. Note: The actual features provided vary by product, so please check the product specifications for details.   1. MCU/MPU without cryptographic accelerator or EdgeLock Secure Enclave 2. MCU/MPU with built-in cryptographic accelerator or EdgeLock Secure Enclave 3. External security IC (secure element/authenticator) Product Examples MCX A(essential security), MCX C MCX A(advanced security), MCX L, MCX E, MCX N i.MX RT, i.MX 8, i.MX 9 SE05x, A5000, A30 Strong security ・Security software must run on the application CPU - Possibility of confidential information being leaked due to vulnerabilities in the application CPU and the software executed there. ・Application CPUs generally prioritize processing speed, and tamper resistance is a low priority (or is not considered at all) - Robust security with a dedicated security block that is physically independent from the application CPU ・Protection of confidential information from vulnerabilities in application CPU-side SW - Physical tamper resistance that also protects against some physical attacks ・In addition to 2., it also supports advanced physical attacks. Easier implementation of security software ・Security software (including key management and encryption algorithms) must be implemented and verified on the user software side. -Security processing has been implemented on the security function side In addition to 2., the following advantages are also provided: ・More advanced key management ・Product security can be strengthened without changing the MCU/MPU ・Security implementation can be standardized between systems using different host MCUs/MPUs Facilitating certification of final products ・If there is no security certification, it is necessary to extract information on compliance with cybersecurity standard requirements from product documentation or obtain it from customer support. -Third-party certification (SESIP/PSA) obtained - Evidence of conformance can be provided , and support is provided for obtaining cybersecurity standard certification for final products. - Meets the high-level hardware security requirements of various cybersecurity standards (depending on use cases) - In addition to 2, the more stringent Common Criteria (CC) certification has been obtained. Easier key writing (Provisioning) Customers must have PKI and manufacturing infrastructure for secure provisioning ・Initial investment and preparation period are required for new businesses ( EdgeLock Secure Enclave only) Flexible and secure key provisioning through the EdgeLock 2GO cloud service , enabling easy product launch. In addition to key provisioning with EdgeLock 2GO, factory-programmed credentials can be used for simple applications. While we've covered strong security and making security software easier to implement, we'll go into a bit more detail on third-party authentication and provisioning. Third-party certification Regardless of the security function used, the security processing behavior (output relative to input) will be the same, although there may be differences in processing speed. However, the security strength (tamper resistance, etc.) will differ depending on the security function implementation. Furthermore, even among products that are called the same secure element, the actual software/hardware implementation varies depending on the company. Security must also be considered in semiconductor suppliers' organizational structures and handling processes such as product development, manufacturing, and operation. The differences in security performance and processes of these semiconductor products from each company make it extremely difficult for users to compare them based on specifications or benchmarks. One way to solve these problems is to use third-party certification. Third-party certifications for ICs with security functions include SESIP, PSA, Common Criteria, and FIPS. A third-party organization evaluates the security implementation and operation of the security features declared by device manufacturers on a unified scale, verifying and certifying that they have been implemented correctly. In addition, we can provide documented evidence for products that have received third-party certification. This document allows customers to confirm how NXP products meet the requirements of cybersecurity standards, which is expected to reduce the effort required to ensure that end products incorporating NXP products comply with cybersecurity standards. NXP calls products that have received third-party certification under its EdgeLock ® Assurance program "Certified EdgeLock Assurance Products." A list of Certified EdgeLock Assurance products can be found here. You can also find product and certification evidence in the standards body's certified product lists. SESIP Certification List PSA Certification List Common Criteria (CC) Certified List The fact that components such as ICs/devices have already received third-party certification is expected to reduce the risk of non-compliance even when manufacturers obtain third-party certification for cybersecurity standards for their final products. For example, under the CRA (EU Cyber Resilience Act), products categorized as Default and Class 1 can be self-declared as well as third-party certified, but end users may still request third-party certification. About Secure Provisioning Service (EdgeLock 2GO) Products with security features require users to provision the confidential information they will use in their applications before they can actually be used. Provisioning must be done in a secure environment, and setting up a new secure environment on a user's production line requires a great deal of effort and expense. Additionally, if a user has multiple manufacturing bases, support will be required for each one. Furthermore, if manufacturing is outsourced, problems may arise such as it being difficult to exercise such control, or there being only a limited number of outsourcees that can exercise such control. NXP's secure elements/authenticators come pre-programmed with some identifying information at the NXP factory, and for simple use cases can be used without any provisioning during manufacturing. For complex use cases that cannot be covered by the identity information pre-programmed into the secure element/authenticator, or for MCU/MPU products with an integrated EdgeLock secure enclave that does not have pre-programmed identity information, NXP offers a cloud service ( EdgeLock 2GO ) that can be used in combination with NXP ICs. EdgeLock 2GO provides a means for secure provisioning during manufacturing and in the field by providing the ability to generate unique identities (key pairs and certificates) for each device and end-to-end encryption between EdgeLock 2GO and the device. In addition, EdgeLock 2GO's certificate authority is approved as a certificate authority that can issue certificates required by standards such as Matter and Qi. You can use it with confidence as a certificate authority that meets the requirements of these standards, not only when compliance with these standards is required, but also when it is not. In a separate article, we will take a closer look at the potential threats faced when handling confidential information on your production line and how EdgeLock 2GO addresses them. Software support for working with EdgeLock Secure Enclaves/Secure Elements We have mentioned that security can be strengthened by using products with security features. However, there are no set standards for APIs for using hardware security features, and each company has its own unique specifications. Doesn't this make it difficult to develop applications using these APIs? NXP provides middleware for host applications that not only provide device-specific APIs but also plugins for popular cryptographic libraries such as OpenSSL, PKCS#11, and Mbed-TLS. For example, by using a plugin for OpenSSL, applications that rely on OpenSSL (e.g., Eclipse Mosquitto ™ ) can use key protection using secure elements without any modifications. We will introduce practical use cases in a separate article. =========================​ We are currently unable to respond to comments in the " Comment " section of this post . We apologize for the inconvenience, but when making inquiries, please refer to " How to contact NXP with technical questions ( Japanese blog ) " . (If you are already an NXP distributor or have a relationship with NXP , you may ask the person in charge directly.) NXP has long been developing products such as smart cards and secure elements for mobile devices. Based on these technologies, we offer a scalable range of embedded products, including MCUs/MPUs with built-in cryptographic accelerators, MCUs/MPUs with built-in EdgeLock ® secure enclaves, and dedicated security ICs (secure elements, secure authenticators), allowing for easy migration when products with different security strengths are required. We also offer a cloud service (EdgeLock 2GO) that securely writes sensitive information to EdgeLock ® Secure Enclaves, Secure Elements, and Secure Authenticators. This article introduces the features and benefits of NXP's security-enabled products. Security Japanese Blog
View full article
PCIe:i.MX 95:分配多个 MSI IRQ 向量 您好, 我们在基于 i.MX95 的系统上使用 ATH12K Wi-Fi 模块,通过 PCIe2 实例连接。 在基于 linux-imx lf-6.12.y 的内核上,这个设置失败了,而在基于 lf-6.6.y 的内核上,它却能正常工作。 内核驱动程序成功请求并接收了 16 个 MSI 中断。但是,它随后无法启动 Wi-Fi 模块: [ 5.888139] ath12k_pci 0001:01:00.0:添加到 iommu 组 5 [ 5.888506] ath12k_pci 0001:01:00.0:BAR 0 [mem 0xa10000000-0xa101fffff 64bit]: assigned [ 5.888553] ath12k_pci 0001:01:00.0:启用设备 (0000-> 0002) [5.889315] ath12k_pci 0001:01:00.0:MSI 向量:16 [ 5.889334] ath12k_pci 0001:01:00.0:硬件名称: wcn7850 hw2.0 [ 6.475718] ath12k_pci 0001:01:00.0:chip_id 0x2 chip_family 0x4 board_id 0xff soc_id 0x40170200 [ 6.475743] ath12k_pci 0001:01:00.0:fw_version 0x110cffff fw_build_timestamp 2025-06-25 09:26 fw_build_id QC_IMAGE_VERSION_STRING=WLAN.HMT.1.1.c5-00302-QCAHMTSWPL_V1.0_V2.0_SILICONZ-1.115823.3 [ 7.647106] ath12k_pci 0001:01:00.0:无法接收控制响应完成,轮询... [8.675241] ath12k_pci 0001:01:00.0:服务连接超时 [ 8.681002] ath12k_pci 0001:01:00.0:连接 HTT 失败: -110 [ 8.692180] ath12k_pci 0001:01:00.0:未能启动核心:-110 在使用不同的 PCIe 设备的内核邮件列表 [1] 上进行了相关讨论,但尚未确定我们系统的有效配置。 最好的办法是什么? 感谢您的支持。 最大值 [1]https://lore.kernel.org/all/1819305.VLH7GnMWUR@steina-w/ Re: PCIe: i.MX 95: Allocate Multiple MSI IRQ Vectors 你好 i,MX95 还处于早期阶段,某些配置还没有设计出来。然而,您的 i.MX95(带 ATH12K,通过 PCIe2)在下列情况下出现故障 lf-6.12.y 但可在 lf-6.6.y 上运行提示新内核的 PCIe 或 Wi-Fi 堆栈存在回归或驱动程序交互变化,可能涉及 ATH12K 的 PCIe 电源管理单元 (ASPM)、MSI 映射或 PCIe 特定 PCIe 端点异常,通常可通过内核补丁或在较新内核的启动参数中禁用 ASPM 来解决;检查 dmesg 中是否有 PCIe 错误,比较设备树,并在 NXP/Linux 内核邮件列表中查找相关提交。  以下是潜在原因和故障排除步骤的详细介绍: 1.检查内核日志 (dmesg) 查找 PCIe 错误: 在失败的 lf-6.12.y 内核的 dmesg 中搜索"PCI","MSI","ATH12K","Error","Firmware", 或"Timeout" 消息。 固件加载:验证是否正确加载了 ath12k 固件,以及初始化过程中是否出现任何错误。  2。PCIe 电源管理单元 (ASPM) 常见问题:较新的内核通常默认启用主动状态电源管理 (ASPM),这可能会导致嵌入式系统上的 ATH12K 等 PCIe 设备出现问题,尤其是较旧的固件/硬件。 尝试禁用 ASPM:将 p cie_aspm=off 添加到内核启动参数(例如,在 U-Boot 或 GRUB 中),然后再次测试。  3.Devicetree/DTB 的差异 比较 DTB: 生成并比较两个内核(.dtb 文件)中使用的设备树 Blob (DTB)。 查看 p ci2 的 PCIe 节点的变化,尤其是与中断、功率域或兼容性特性相关的变化。  4.内核驱动程序/固件回归 特定提交: lf-6.12.y 中的 ATH12K 驱动程序 ( ath12k)、 mac80211 或核心 PCIe/ARM 代码可能引入了一项破坏设置 的更改。 搜索邮件列表:查看 Linux 内核邮件列表 (LKML) 和恩智浦列表,了解相关补丁或有关 ath12k 、 i.MX95 和较新内核(6.12 以上)的讨论。  5.微星处理 中断重映射:在接收中断的同时,处理中断的方式(MSI-X 与 MSI、中断重映射)可能会发生微妙的变化。 检查 proc/interrupts 中的中断:查看不同内核的中断分布或计数是否不同。  6.固件 Blob 固件版本:确保为 ATH12K 使用正确的固件,并与较新内核的驱动程序兼容。有时,更新的驱动程序需要更新的固件。  总之,从 dmesg 开始,尝试禁用 ASPM;这些是导致嵌入式平台上较新内核出现 PCIe Wi-Fi 故障的最常见原因   此致 Re: PCIe: i.MX 95: Allocate Multiple MSI IRQ Vectors 虽然这些建议是调试问题的好指导,但我找不到解决方案,也就是说,并非所有的 MSI IRQ 向量都触发了驱动程序中的 IRQ 例程。 最后,我改变了 ath12k 驱动程序,只请求一个 MSI IRQ,从而解决了这个问题。 请注意,当前的 Linux 主版本不存在这个问题。 此致 最大值
View full article
Installing SDK for NHS3152 fails Hello, I am trying to develop the firmware for a NHS3152TEMOADK board. I have MCUXpresso 25.6.136. When trying to install the SDK (release_mra2_12_6_nhs3152.zip) I get the following error message shown in the attached picture. Please suggest a solution. Mo Re: Installing SDK for NHS3152 fails Hello @MoAbdol  Please select the below button and import the project should be working. Does not need install SDK.
View full article
首次成功设计 KW47(汽车级)或 MCX W72(物联网 / 工业级)PCB 的最佳方法 /*** 2025 年 4 月最新免责声明: - KW47、MCX W72 是 KW45 和 MCX W71 的直接衍生产品 —— 请将本页面加入书签以获取未来更新 - 本文基于 KW45、K32W148、MCX W71 进行早期启用说明,有待 2025 年 KW47 和 MCX W72 更广泛发布时更新 -- 大部分设计文档(包括数据手册、参考手册和硬件制造文件)可应要求提供--  ***/ 请参考以下重要链接,了解如何使用 KW47 或 MCX W72 设计 PCB,以及有关射频性能、低功耗和射频认证 (CE/FCC/IC) 的所有信息。 KW47 产品 NXP 官网页面:https://www.nxp.com/products/KW47 MCXW72 产品 NXP 官网页面:https://www.nxp.com/products/processors-and-microcontrollers/arm-microcontrollers/general-purpose-mcus/mcx-arm-cortex-m/mcx-w-series-microcontrollers/mcx-w72x-secure-and-ultra-low-power-mcus-for-matter-thread-zigbee-and-bluetooth-le:MCX-W72X KW-MCXW-EVK 入门指南 NXP 官网页面(待 KW47/MCXW72 发布) KW47-LOC 入门指南 NXP 官网页面(待 KW47/MCXW72 发布) MCXW72-LOC 入门指南 NXP 官网页面(待 KW47/MCXW72 发布) 硬件  KW47 和 MCX W72 EVK 开发板:初步附件  KW47 LOC 信道探测板 - 原理图:初步附件  KW47-MCXW72-EVK 硬件指南:可应要求提供    HVQFN48 封装规格:SOT619-17 (D)(待 SOT619-17 (DD) 发布)    KW47-MCXW72-EVK 用户手册(待 KW47/MCXW72 发布)    最小物料清单(附件)>> KW45 - MCX W71 - KW47 - MCX W72 Minimum BoM Presentation Customers July25.pdf   DC-DC 管理指南 (AN13831):KW45/K32W148 - 电源管理硬件 (nxp.com)(KW45 的内容适用于 KW47,待 KW47/MCXW72 版本发布)   Design-In 检查清单:请参阅本文底部附件   射频匹配:S 参数(附件)(待 KW47/MCXW72 发布)   PCB 上纽扣电池应用处理方法:AN14664_Coincell_Hardware_recommendation_Rev1.0.pdf 说明:“由于射频性能取决于 PCB 布局和制造工艺,基于 NXP 建议制作的 PCB 原型必须进行微调,以确保最终产品平台达到预期的射频合格标准。” 在 EVK 上,为连接 M10 模块进行射频测试,建议使用 μFL 转 SMA 电缆: CSH-SGFB-200-UFFR TE Connectivity / Linx Technologies | Mouser France 在 KW47-LOC 或 MCXW72-LOC 上,需安装特定的 SMA 连接器以实现连接:TE Connectivity Ltd CONSMA021.062-G 从 KW45 到 KW47 的硬件移植: KW47 与 KW45 引脚到引脚兼容。然而,从硬件的角度来看,某些组件的值需要进行调整,例如 RF 匹配组件的值。 根据当前的硅验证,预计KW4x周围的其他组件不会发生变化。 另请注意,为实现 KW47 的新功能,部分引脚采用了新的复用配置。例如,KW47 提供了第二个 Flex CAN。详见附件。 射频   射频报告:KW45 和 K32W148 的蓝牙低功耗射频系统评估报告,以及 K32W148 的 802.15.4 应用评估报告……(待 KW47/MCXW72 发布,可应要求提供)   射频共存:Kinetis 无线系列产品的蓝牙低功耗与 Wi-Fi 共存应用(nxp.com)(待 KW47/MCXW72 发布)   距离性能:参考附件(待 KW47/MCXW72 发布)   天线: 用于NXP EVK板的2.4 GHz通信设计和应用的紧凑型平面天线 用于信道探测应用的天线   BLE 连接性测试二进制文件:可按需在 SDK 中获取   回波损耗 (S11) 测量:如何测量射频匹配的回波损耗 (S11)(射频报告 AN13728 的一部分)   负载牵引:待 KW47/MCXW72 发布 用于 RF 试验的 SW 工具:   IoT 工具箱(移动应用)   连接性产品的连接测试工具(IoT 工具箱的一部分)   DTM:如何在 Kinetis 系列产品上使用 HCI_bb……- NXP 社区 https://community.nxp.com/t5/Wireless-Connectivity-Knowledge/BLE-HCI-Application-to-set-transmitter-... 晶体  文章:KW45/K32W1 的 32MHz 和 32kHz 振荡裕量 - NXP 社区(待 KW47/MCXW72 发布) 推荐的水晶已附上 低功耗 蓝牙 LE 功耗配置文件估算工具 KW45_WK47_BLE_power_profile_calculator_v1.32.xlsm   低功耗              AN14554 Kinetis KW47 & MCX W72 Bluetooth LE Power profile analysis release.pdf 802.15.4 Matter & Zigbee 功率配置文件估算工具               MCX W7x 802.15.4 Matter ICD SIT LIT & ZED Power profile v0.2.xlsx                 AN MCX W72 802.15.4 Matter and Zigbee Power profile analysis - proposal.pdf CCC 信道探测 BLE 功率配置文件估算工具               KW47 Digital Key CCC CS Power Estimator tool v0.8.xlsx               AN14628_AN14628_KW47_CCC_CS_Power_Profile_estimator tool_release.pdf Bluetooth ® 信道探测技术概述  认证 RF 预认证已完成 - 完整认证待 KW47/MCXW72发布 KW47 和 MCXW72 已通过蓝牙 6.0 信道探测认证!
View full article