S32K3 HSE Hi，NXP专家们，想问下S32K3 HSE是否支持ED448算法 Re: S32K3 HSE 你好@Chenxu1 HSE-B 支持 ED448。来自 HSE 服务 API 参考手册： lukaszadrapa_0-1752824170040.png 此致， Lukas Re: S32K3 HSE 嗨@lukaszadrapa 感谢您的反馈， 您提到 HSE-B 支持 ED448，但根据 HSE 服务 API 参考手册和版本说明，ED448 似乎不受支持。请您帮我们再核实一下好吗？ kay3_0-1786418040733.png kay3_1-1786418087077.png Re: S32K3 HSE 嗨@KaiKim 看来我错了。我查阅了几份 API 手册，有些包含这些信息，有些则没有。我可能看的是一个没有显示这些信息的版本。但是，查看不同版本接口文件中的 hse_b_config.h 文件，发现它们都包含以下内容： lukaszadrapa_0-1786607577525.png 所以，它实际上不受支持。 谢谢指出这一点。 问候， 卢卡斯

MFS2633的FCCU功能如何使用？ 请问MFS2633的PIN.17 FCCU1与PIN.18 FCCU2是如何使用的？两个Pin脚的输入值会构成真值表，引发芯片的不同保护措施？ Re: MFS2633的FCCU功能如何使用？ 你好，里约！ MFS2633 上的 FCCU1（引脚 17）和 FCCU2（引脚 18）是用于接收来自连接的 MCU 的故障信号的数字输入。它们是 FS26 故障保护状态机的 MCU 监控接口的一部分。 它们直接连接到 MCU 的 FCCU 错误输出引脚（例如，S32K3xx MCU 的 FCCU_EOUT[0:1] 或 FSP 输出）。FS26 监控这些输入，当检测到故障情况时，会发出配置的功能安全输出（FS0B 和/或 RSTB）。 在 FS26 初始化阶段，通过 FS_I_SAFE_INPUTS 寄存器中的 FCCU_CFG[2:0] 位选择监视模式。 可用的模式有： Screenshot 2026-08-13 092241.jpg 在最常见的汽车应用中——双稳态（配对）模式——这两个引脚作为互补对工作，而不是作为产生不同反应的独立输入。FS26 预期： 正常/安全状态：FCCU1 = 高电平 (1)，FCCU2 = 低电平 (0) 故障状态：FCCU1 = 低电平 (0) 或 FCCU2 = 高电平 (1) 任何偏离预期正常状态的情况都会触发预设的故障响应。默认故障极性为： FCCU1 = 0 or FCCU2 = 1 is a fault 。该极性可通过 FCCU12_FLT_POL 进行配置。 Screenshot 2026-08-13 092736.jpg 功能安全反应（其钳位）不会因 FCCU1/FCCU2 等级的具体组合而有所不同。对于检测到的任何故障，反应都是相同的，但可以使用 FCCU12_FS_REACTION 、 FCCU1_FS_REACTION 和 FCCU2_FS_REACTION 位对每个引脚进行独立配置。 Screenshot 2026-08-13 093010.jpg 检测到故障时，默认反应是将 RSTB 和 FS0B 都置低。如果您希望启用故障恢复策略（MCU 在不复位的情况下处理故障），则必须将响应更改为仅 FS0B。 BRs，托马斯

U-Boot USB ID とメインラインにおける回帰/バグ こんにちは、 U-Bootのlf-6.18.20-2.0.0ブランチで「コミットa5c91319731f(「MLK-25803-2: Update VID/PID」)は、USBユーザー全員に回帰を導入します。 設定から値を取得するのではなく、USB製品IDを強制的に入力します。これは、0x0151以外の値を使用しているすべてのボードを破損させます。 この問題は、NXP製以外のボード（NXP製SoCを使用しているボード）でこのU-Bootブランチを使用した場合に発生します。 この値は設定ファイルから取得する必要があり、ハードコーディングしてはいけません。 次のパッチで問題が解決しますが、あなたの支店にも適用できますか? 「`」 diff --git a/arch/arm/mach-imx/spl.c b/arch/arm/mach-imx/spl.c インデックス 165cc82d9c72..46e26d138cf9 100644 --- a/arch/arm/mac-imx/spl.c +++ b/arch/arm/mach-imx/spl.c @@ -199,7 +199,7 @@ int g_dnl_bind_fixup(struct usb_device_descriptor *dev, const char *name) snprintf(serial_string, sizeof(serial_string), "%08x%08x", serialnr.high,シリアル番号.low); g_dnl_set_serialnumber(serial_string); #endif - put_unaligned(0x0151, &dev->idProduct); + put_unaligned(CONFIG_USB_GADGET_PRODUCT_NUM + 0xfff, &dev->idProduct); 0を返す。 } 「`」 Re: Regression/bug in U-Boot USB ID vs mainline 問題は、あなたが先ほど説明したNXP製品に関する具体的なニーズではありません。問題は、コードに数字をハードコーディングすることで、ユーザーがkconfigから設定できず、実質的に回帰を生み出せないことです。 その変更は、異なるニーズを持つ既存ユーザーを無視し、動作するユースケースを積極的に壊すことです。コードの中のgrepでgrep CONFIG_USB_GADGET_PRODUCT_NUMすれば、この問題が壊れている複数のユースケースがわかります。 回帰バグを引き起こさない、別の解決策が必要です。 Re: Regression/bug in U-Boot USB ID vs mainline こんにちは、 この変更は意図的なものであった。 VID 0x525とPID 0xa4a5すでにPLX Technology, Inc.として登録されています。 Linux-USBファイルバックアップストレージガジェット しかし、fastboot デバイスはマスストレージデバイスではありません。Windows 10 の最新アップデートは既に上記の vid/pid をキャッシュしています。 Freescale VID 0x1fc9を使用するように変更します。 PID 0x151、SPL SDP HIDダウンロード用 PID 0x152、Fastboot用 PID 0x153、カーネル高速起動用 uuuを1.4.182以上にアップデートする必要があります

GuierV1.7.2はどうやってダウンロードできますか? GuierV1.7.2はどうやってダウンロードできますか? Re: How can I download GuierV1.7.2? こんにちは、@smile168さん お問い合わせいただきありがとうございます。 現在、ダウンロード可能なのはGUI Guider v2.0.0とv1.10.1のみです。残念ながら、v1.7.2はダウンロードチャネルからはもう利用できません。 現代的な組み込みGUIファストを作成 |NXPセミコンダクターズ BR ハリー

[i.MX95 FRDM] AR0144/AP1302 Pink Tint Issue & Bypassing AP1302 for NXP NEO ISP Environment & Hardware Setup Processor / Platform: NXP i.MX95 FRDM Board Camera Module: RPI-CAM-MIPI (AR0144 Sensor + AP1302 Onboard ISP) Firmware Used: ap1302_60fps_ar0144_27M_2Lane_awb_tuning.bin (renamed to ap1302_ar0144_single_fw.bin and placed in /lib/firmware/) Issue 1: Pink / Magenta Color Tint from AP1302 ISP I am experiencing a persistent pink / magenta color cast in the decoded images/video streams coming from the AR0144 camera module via the AP1302 ISP. Despite using this tuned firmware file, the decoded frames still exhibit a noticeable pink cast (sample image attached). Is this a known issue with the AR0144 + AP1302 setup? Is there an updated AP1302 firmware binary available to fix this color balance issue? Issue 2: Bypassing AP1302 to Use the i.MX95 Internal NEO ISP The NXP documentation for the RPI-CAM-MIPI camera module states: "The bypassable onboard ISP chip allows it to be used with a wide range of SoCs." Since the i.MX95 features an integrated hardware NEO ISP, we would like to bypass the AP1302 onboard processing and route the RAW Bayer stream from the AR0144 directly into the i.MX95 internal NEO ISP using libcamera and the neo-ipa-uguzzi pipeline handler. Questions for NXP: Is RAW passthrough (bypassing AP1302 hardware processing to feed RAW Bayer directly to the i.MX95 NEO ISP) officially supported on the i.MX95 FRDM board? If yes, could NXP provide the step-by-step configuration required to enable RAW passthrough? How can we acquire or generate the required DTP / YAML tuning files for the AR0144 sensor under the NEO ISP? Does NXP have a pre-calibrated YAML/DTP file available for AR0144 that can be shared? face_detection_input_image.png face_detection_input_image.png Re: [i.MX95 FRDM] AR0144/AP1302 Pink Tint Issue & Bypassing AP1302 for NXP NEO ISP I reproduce this on my imx95 frdm board, doesn't have any color issue, you should set the correctly since you can bring up the camera, just check if your display has any issue or not 1) set the dtb file as imx95-15x15-frdm-ap1302.dtb   2) your firmware is correct 3) use the command gst-launch-1.0 libcamerasrc ! autovideosink joanxie_0-1786086912147.jpeg Re: [i.MX95 FRDM] AR0144/AP1302 Pink Tint Issue & Bypassing AP1302 for NXP NEO ISP Hi, Thank you for testing and providing the feedback on Question 1.  Re: Question 2 — Bypassing AP1302 for the i.MX95 Internal NEO ISP Could you please also address my second question regarding bypassing the onboard AP1302 ISP to utilize the i.MX95's internal NEO ISP? Since the RPI-CAM-MIPI board documentation states that the onboard ISP is bypassable, we want to route the RAW Bayer stream from the AR0144 sensor directly into the i.MX95's internal NEO ISP. Could you please clarify: Is RAW passthrough (bypassing AP1302 hardware ISP processing) supported for the AR0144 on the i.MX95 FRDM board in the Linux 6.12.49_2.2.0 BSP release? Device Tree Changes: What exact Device Tree configuration or overlay is needed to bypass the AP1302 ISP block and capture RAW Bayer frames directly on the MIPI-CSI interface? Tuning & YAML Configuration: Does NXP provide the tuning/DTP configuration files for the AR0144 under the NEO ISP pipeline handler? If available, could you share these files or guide us on how to properly set up libcamera and LIBCAMERA_IPA_MODULE_PATH for this workflow? Thank you for your assistance! Re: [i.MX95 FRDM] AR0144/AP1302 Pink Tint Issue & Bypassing AP1302 for NXP NEO ISP Is RAW passthrough (bypassing AP1302 hardware ISP processing) supported for the AR0144 on the i.MX95 FRDM board in the Linux 6.12.49_2.2.0 BSP release?>couldn't support it as default bsp, you can find the dtb file named ap1302 only Device Tree Changes: What exact Device Tree configuration or overlay is needed to bypass the AP1302 ISP block and capture RAW Bayer frames directly on the MIPI-CSI interface?> refer to the ap1302 dtso file https://github.com/nxp-imx/linux-imx/blob/lf-6.18.y/arch/arm64/boot/dts/freescale/imx95-15x15-frdm-ap1302.dtso isp_en-gpios = <&adp5585_isp 2 GPIO_ACTIVE_HIGH>; this pin is enable ap1302, you can bypass ap1302 by control this pin, hi is for enable, low is for bypass 3.Tuning & YAML Configuration: Does NXP provide the tuning/DTP configuration files for the AR0144 under the NEO ISP pipeline handler? If available, could you share these files or guide us on how to properly set up libcamera and LIBCAMERA_IPA_MODULE_PATH for this workflow? >you can find all of the SW pacakge here https://github.com/nxp-imx-support/imx-camera-sw-pack Re: [i.MX95 FRDM] AR0144/AP1302 Pink Tint Issue & Bypassing AP1302 for NXP NEO ISP Hi, Thank you for the detailed clarification regarding bypass mechanism. Regarding the color issue, I want to clarify that this is not a display or monitor artifact. To be certain, we did not take a photo of the screen; rather, we dumped the raw image/video file directly from the GStreamer pipeline and inspected the saved file on a separate host machine, where the light reddish/magenta pink tint is clearly present in the pixel data. Since we are using the correct DTB (imx95-15x15-frdm-ap1302.dtb) and the official AWB-tuned firmware (ap1302_60fps_ar0144_27M_2Lane_awb_tuning.bin), could you please help us isolate the root cause? Question: Is there a specific test we can run from user space to verify whether this pink tint is caused by a hardware defect in the specific AR0144 camera module unit we have, or if it is a configuration/software issue? Thank you for your continued support! Re: [i.MX95 FRDM] AR0144/AP1302 Pink Tint Issue & Bypassing AP1302 for NXP NEO ISP Hi @joanxie ,  1) As I mentioned earlier we have confirmed this is NOT a display issue. Because the images are dumped to a file and pulled to a host PC (Not a capture from the Display) 2) We have checked the same camera on IMX 95 EVK and IMX 95 FRDM baord, just to confirm that the problem is with the camera module or not. Both the places we are able to see the red tint. 3) We are using this firmware for ap1302: https://github.com/ONSemiconductor/ap1302_binaries/blob/main/NXP_i.MX93/ap1302_60fps_ar0144_27M_2Lane_awb_tuning.bin And placing this in /lib/firmware with a name "ap1302_ar0144_single_fw.bin" (as we saw this is file name from dmesg logs).  Can you confirm whether you are using the same firmware. If not could you please let us know from where we can get the proper firmware 4) Is there any way to identify whether it's a tuning, firmware problem . Or some hardware issue with the specific module we are having? If it is hardware issue we want to consider buying another fresh unit

FS2613チップの選定 FS2613シリーズのチップは非常に高性能で、各電源レールの値とタイミングを編集できます。しかし、ソフトウェア開発にあまり時間をかけられないため、OTPを自社で実装することは避けたいと考えています。S32K358と互換性を持つように工場出荷時に設定されているモデルはありますか？例えば、下の画像に示されているようなモデルです。 Rio_Lee_0-1786090969347.png Re: 关于FS2613芯片的选型 添付ファイルを参照してください Re: 关于FS2613芯片的选型 さて、 MFS2633AMDB2ADモデルの場合、電源投入後の各チャンネルの出力電圧はデフォルトでどのくらいですか？ VCORE、LDO1、LDO2、VREF、VBST、TRK1、TRK2はどこから発生するのですか？ Re: 关于FS2613芯片的选型 MFS2633AMDB2AD 検索 | NXPセミコンダクターズ あなたはこれを選ぶことができます！ Re: 关于FS2613芯片的选型 MFS2633AMDB2ADは製造中止になりました。同じ仕様であれば、MFS2633HMDB2ADに交換すれば良いですよね？ Re: 关于FS2613芯片的选型 はい！ Re: 关于FS2613芯片的选型 このチップでは、PIN.17 FCCU1とPIN.18 FCCU2はどのように使用されますか？これらの2つのピンの入力値はどのような真理値表を形成し、チップのさまざまな保護メカニズムをトリガーしますか？ Re: 关于FS2613芯片的选型 新しいご質問については、新しいチケットを送信してください。よろしくお願いいたします。

关于安装IDE和RTD遇到的问题 你好，我安装了S32DSIDE 3.6.6软件 3859b5427f61973af225339173048fd.png 然后我又安装了RTD包 YangLuYao_0-1786007576122.png 但是我在新建application project时找不到SDK，如下图 YangLuYao_1-1786007624669.png YangLuYao_2-1786007639499.png 这个问题困扰我很久了，期待回复，谢谢，我的电脑配置如下 YangLuYao_3-1786007691107.png 电脑上装了JDK 8和JDK17, Python 13 14 15   Re: 关于安装IDE和RTD遇到的问题 谢谢，我发现了这个问题，然后我就想装gcc-10.2，我找到了关于编译器的网页 YangLuYao_0-1786064846455.png 我不知道使用哪一个，所以我下载了这两个EXE文件进行安装 YangLuYao_1-1786064901733.png 但是安装完成之后，在S32DS软件中新建工程发现还是没有gcc-10.2 YangLuYao_2-1786065074605.png 然后我就想在扩展包管理器中下载，但是我试了很多次下载过程中总是报错，无法下载成功，请指导我下一步该怎么做，谢谢~~~ YangLuYao_3-1786065134265.png Re: 关于安装IDE和RTD遇到的问题 抱歉，过去两天是周末，这是我今天早上又试着装了一次报的错 YangLuYao_0-1786325441496.png Re: 关于安装IDE和RTD遇到的问题 你好@YangLuYao ， 抱歉回复晚了。从图片来看，您似乎正在尝试安装 NXP GCC 6.3.1（版本 1620），但实际上您应该安装 v10.2（版本 1728）： Julin_AragnM_0-1786577752319.png Julin_AragnM_1-1786577760152.png 如果这仍然不起作用，我想你可以尝试从外部安装它：在 S32 设计工作室中安装软件。 我会检查以下几点： 安装过程中网络不稳定。 工作场所的代理/防火墙。 防病毒/网络安全检查。 磁盘空间。 除此之外，我就不确定根本原因是什么了。您可以尝试重新安装 S32DS，然后再次尝试安装 NXP GCC 10.2。 此致， 朱利安 Re: 关于安装IDE和RTD遇到的问题 嗨@YangLuYao ， 无需下载独立组网 (SA) 工具链。S32DS 已提供 NXP GCC 10.2： Julin_AragnM_0-1786119575796.png 选择工具链后，点击“安装/更新 1 个项目”，点击“下一步”，S32DS 将提示您重新启动。重启后，您应该可以看到它已安装： Julin_AragnM_1-1786119784429.png 如果发现任何错误，能否告知一下？ 此致， 朱利安 Re: 关于安装IDE和RTD遇到的问题 我已经解决了这个问题，谢谢~~

MFS2633のFCCU機能の使い方は？ MFS2633のPIN.17 FCCU1とPIN.18 FCCU2はどのように使用されますか？これらの2つのピンの入力値はどのような真理値表を形成し、チップのさまざまな保護機能をトリガーしますか？ Re: MFS2633的FCCU功能如何使用？ こんにちはリオ、 MFS2633上のFCCU1(PIN 17)とFCCU2(PIN 18)は、接続されたMCUからの故障信号を受信するためのデジタル入力です。これらはFS26フェイルセーフステートマシンのMCU監視インターフェースの一部です。 これらはMCUのFCCUエラー出力ピン(例:S32K3xxのFCCU_EOUT[0:1]やFSP出力)に直接接続されます。FS26はこれらの入力を監視し、故障状態が検出されると、設定されたセーフティ出力(FS0Bおよび/またはRSTB)を主張します。 監視モードは、FS26の初期化フェーズ中に FS_I_SAFE_INPUTS レジスタの FCCU_CFG[2:0] ビットによって選択されます。 利用可能なモードは以下のとおりです。 Screenshot 2026-08-13 092241.jpg 最も一般的なオートモーティブ実装であるバイスタッフル(ペアモード)では、2つのピンは相補的なペアとして動作し、異なる反応を生み出す独立した入力としてはなりません。FS26は以下を期待しています。 正常／安全状態：FCCU1 = HIGH（1）、FCCU2 = LOW（0） 故障状態：FCCU1 = LOW (0) または FCCU2 = HIGH (1) 想定される正常状態からの逸脱はすべて、設定された障害反応を引き起こします。デフォルトの障害極性は、 FCCU1 = 0 or FCCU2 = 1 is a fault 。この極性は FCCU12_FLT_POL で設定可能です。 Screenshot 2026-08-13 092736.jpg セーフティ反応(どの出力が主張されるか)は、FCCU1/FCCU2レベルの特定の組み合わせによって違いはありません。反応は検出された故障に対して同じですが、 FCCU12_FS_REACTION ビット、 FCCU1_FS_REACTION ビット、 FCCU2_FS_REACTION ビットを使ってピンごとに独立して設定できます。 Screenshot 2026-08-13 093010.jpg デフォルトの動作は、障害が検出された場合、RSTBとFS0Bの両方をローレベルにすることです。故障回復戦略(MCUがリセットせずに故障を処理する方法)を有効にしたい場合は、リアクションをFS0Bのみに変更する必要があります。 BRs、トーマス

S32K3 HSE NXP の専門家の皆さん、S32K3 HSE が ED448 アルゴリズムをサポートしているかどうかお尋ねしたいのですが。 Re: S32K3 HSE こんにちは@Chenxu1 HSE-BはED448をサポートします。HSE サービス API リファレンス マニュアルより: lukaszadrapa_0-1752824170040.png よろしくお願いいたします。 ルーカス Re: S32K3 HSE こんにちは、 @lukaszadrapa ご返信ありがとうございます。 ED448はHSE-Bでサポートされているとおっしゃいましたが、HSEサービスAPIリファレンスマニュアルやリリースノートによると、ED448はサポート されていない ようです。もう一度確認してもらえますか? kay3_0-1786418040733.png kay3_1-1786418087077.png Re: S32K3 HSE こんにちは、 @KaiKim さん。 どうやら私の間違いだったようだ。いくつかのAPIマニュアルに目を通したところ、この情報が記載されているものもあれば、記載されていないものもあった。おそらく、私が見ていたのは、この情報が表示されていないものだったのでしょう。しかし、異なるバージョンのインターフェースファイルで hse_b_config.h を見ると、すべて以下が含まれています: lukaszadrapa_0-1786607577525.png つまり、実際にはサポートされていません。 ご指摘ありがとうございます。 よろしくお願いいたします。 ルーカス

NXP S32K312 CAN0 – FIRC vs. FXOSC Clock Source Causing CAN Errors Hi everyone, I am using CAN0 on the S32K312 at 500 kbps with an 87.5% sampling point. Initially, I set up CAN0 to use the internal FIRC_CLK as the clock source. When I connected the S32K312 to a network with multiple CAN nodes, I noticed a lot of CAN error frames. I then switched the CAN clock source from FIRC_CLK to the external FXOSC_CLK while keeping the CAN bitrate and sampling point the same. After this change, the communication became stable, and I stopped seeing the error frames. Could anyone help me understand why switching the clock source from FIRC_CLK to FXOSC_CLK would fix the CAN errors? Re: NXP S32K312 CAN0 – FIRC vs. FXOSC Clock Source Causing CAN Errors Hello @Karthik_R, Usually, FIRC clock is not recommended for FlexCAN communication, as accuracy is over the ~1% requirement according to CAN protocol (ISO 11898-1). You can see from S32K3's Data Sheet that FIRC's deviation is +- 5%. Recommendation is to use either FXOSC or PLL running from XOSC. You can refer to FlexCAN Bit Timing Calculation document, and MPC5xxx/S32Kxx/LPCxxxx: CAN / CAN FD bit timing calculation tool for clock and timing calculations. Hope this is clear. Best regards, Julián

如何通过喷嘴拾取 MPXM2053GS 在 SMT 过程中，空气可能会从取放喷嘴吹入压力端口。内部传感器有可能损坏吗？ Re: how to pick up MPXM2053GS by nozzle 你好，大卫， 从取放喷嘴到侧面压力端口的短暂低压空气脉冲不太可能造成损坏，只要施加的压力不超过设备的最大额定过压。然而，反复或高压气流原则上可能会使隔膜承受压力，或者在极端情况下，使其受损。 为完全避免任何风险，建议将取放喷嘴放置在 M-PAK 封装的平坦顶部表面上，远离侧面的压力端口。这样可以确保喷嘴永远不会接触或引导气流进入感应端口开口。应用笔记AN1984 – 飞思卡尔压力传感器的处理，针对该设备系列的喷嘴设计和放置提供了具体指导，是 MPX 系列传感器 SMT 处理的主要参考。应用笔记AN936 – MPX 系列压力传感器的安装技术、引脚成型和测试也是一份有用的补充资料。 请注意，截至 2026 年 2 月 2 日，NXP MEMS 传感器产品（包括 MPXM2053GS）已过渡到 STMicroelectronics。如需后续产品支持和文档处理方面的帮助，我建议您直接咨询STM。 BRs，托马斯

how to pick up MPXM2053GS by nozzle During the SMT process, air may get blown into the pressure port from the pick-and-place nozzle. Is it possible to damage the sensor inside? Re: how to pick up MPXM2053GS by nozzle Hello David, A brief, low-pressure air pulse from the pick-and-place nozzle into the side pressure port is unlikely to cause damage, provided the applied pressure does not exceed the device's maximum rated overpressure. However, repeated or high-pressure air blasts could in principle stress the diaphragm or, under extreme conditions, compromise it. To avoid any risk entirely, the recommended approach is to position the pick-and-place nozzle on the flat top body surface of the M-PAK package, away from the side pressure port. This ensures the nozzle never contacts or directs airflow into the sensing port opening. Application Note AN1984 – Handling Freescale Pressure Sensors provides specific guidance on nozzle design and placement for this device family and is the primary reference for SMT handling of MPX-series sensors. Application Note AN936 – Mounting Techniques, Lead Forming, and Testing of the MPX Series Pressure Sensors is also a useful complement. Please note that as of February 2, 2026, NXP MEMS sensor products (including the MPXM2053GS) have been transitioned to STMicroelectronics. For ongoing product support and handling documentation going forward, I recommend also consulting STM directly. BRs, Tomas

NXP S32K312 CAN0 – FIRC 与 FXOSC 时钟源导致 CAN 错误 大家好， 我正在使用 S32K312 上的 CAN0，速率为 500 kbps，采样点为 87.5%。 最初，我将 CAN0 设置为使用内部 FIRC_CLK 作为时钟源。当我将 S32K312 连接到具有多个 CAN 节点的网络时，我注意到出现了很多 CAN 错误帧。 然后，我将 CAN 时钟源从 FIRC_CLK 切换到外部 FXOSC_CLK，同时保持 CAN 比特率和采样点不变。做出这一改变后，通信变得稳定，我不再看到错误帧。 请问有人能帮我理解一下为什么将时钟源从 FIRC_CLK 切换到 FXOSC_CLK 就能解决 CAN 错误吗？ Re: NXP S32K312 CAN0 – FIRC vs. FXOSC Clock Source Causing CAN Errors 你好@Karthik_R ， 通常不建议将 FIRC 时钟用于 FlexCAN 通信，因为根据 CAN 协议 (ISO 11898-1)，其精度超过了 ~1% 的要求。从 S32K3 的数据表中可以看出，FIRC 的偏差为 +/- 5%。 建议使用 FXOSC 或由 XOSC 运行的 PLL。您可以参考FlexCAN 位时序计算文档和MPC5xxx/S32Kxx/LPCxxxx：CAN / CAN FD 位时序计算工具进行时钟和时序计算。 希望这能说清楚。 此致， 朱利安

NXP S32K312 CAN0 – FIRC vs. FXOSC クロックソースによる CAN エラーの発生 こんにちは、皆さん 私はS32K312でCAN0を使用し、500kbpsの速度で87.5%のサンプリングポイントを設定しています。 最初は、CAN0を内部のFIRC_CLKをクロックソースとして使用するように設定しました。S32K312を複数のCANノードがあるネットワークに接続したところ、多くのCANエラーフレームに気付きました。 その後、CANのクロックソースをFIRC_CLKから外部FXOSC_CLKに切り替え、CANのビットレートとサンプリングポイントは同じにしました。この変更後、通信は安定し、エラーフレームが表示されなくなりました。 なぜクロックソースをFIRC_CLKからFXOSC_CLKに切り替えるとCANエラーが直るのか、どなたか教えてもらえますか? Re: NXP S32K312 CAN0 – FIRC vs. FXOSC Clock Source Causing CAN Errors こんにちは、 @Karthik_R さん。 通常、FIRCクロックはFlexCAN通信には推奨されません。なぜなら、精度がCANプロトコル(ISO 11898-1)の~1%要件を超えているためです。S32K3のデータシートを見ると、FIRCの偏差は+-5%です。 FXOSCを使用するか、XOSCから実行されるPLLを使用することを推奨します。FlexCANビットタイミング計算のドキュメントや、MPC5xxx/S32Kxx/LPCxxxx: CAN / CAN FDビットタイミング計算ツールをご参照ください。 これで分かりやすくなったでしょうか。 よろしくお願いします、 ジュリアン

FS23 V1 output abnormal V1 output is abnormal as below waveform: C1 was VSUP,C2 was VBOS,C3 was V2;C4 was V1(power to MCU)C1 was VSUP,C2 was VBOS,C3 was V2;C4 was V1(power to MCU) 微信图片_20260813093846_286_23.jpg V1 without npnV1 without npn 微信图片_2026-08-13_095130_111.png How can I thoroughly solve the problems I am currently facing? if you want to get more information,please let me know. Re: FS23 V1 output abnormal guoweisun_0-1786680381549.png guoweisun_1-1786680552393.png This diagram explains the softstart conditions highlighted above. If all conditions are met, V1 starts powering on and enters the M5 timing sequence, which takes 150-500µs. If the startup fails within this time, it enters the FS state and restarts after 100ms. This is roughly the process. Re: FS23 V1 output abnormal Could you please explain the softstart process? This section, " 19.4.6 V1UVLP monitoring chapter shows 'V1 is also monitored for V1UVLP when the device powers up after a wake-up from LPON, and during a cold start after TSOFT_START_V1. If, at the end of the softstart, V1 is still under the V1UVLP threshold, then the device goes into Fail-Safe state.'" What exactly is required for the V1 startup waveform? Thanks Re: FS23 V1 output abnormal This problem is most likely caused by V1 experiencing a startup failure during the soft boot process of OC, followed by a recovery. The solution is to add an external tube to the V1 port and enable this function when using FS23 OTP, or you can choose our HVBUCK version. Alternatively, you could remove some output capacitors to make the softstart smoother. I recommend choosing either of these two solutions for greater stability. Re: FS23 V1 output abnormal 1: If PIN37 in the schematic is not used, ground it. 2: V1's load current is not large, only a maximum of 100mA. Please confirm the load at your location. 3: The decoupling capacitor of V1_IN is 1uF. guoweisun_0-1786671133675.png 4: In the case above, if the first startup fails and the second startup occurs, can the register M_GEN_FLAG be read to see what happened? Let's change these things first and see the results. Re: FS23 V1 output abnormal We measured a new waveform and found that V1 sometimes fails to start on the first try when the input is 12V. af12f0f0-afa6-40e3-881d-890516697b5a.png This is the waveform of the first startup failure. V1第一次启动未成功图V1 failed to start on the first attempt (image) This is the waveform of the second successful startup. V1第二次启动成功图V1 successfully started for the second time (image) Is this related to the undervoltage detection in V1 after a soft boot? The typical soft boot time is 300µs, and the maximum is 500µs. Why does it seem like it won't boot if it exceeds 500µs, but it seems to work if it's below 500µs? Could you please describe the soft boot process? The manual doesn't provide much information about it. Re: FS23 V1 output abnormal guoweisun_0-1786608712650.png With 8V Vin, could you reduce the time axis of the waveform circled above? I want to see how long V1 has been running. Can we also test the same waveform with 12V VIN? I don't have a high and low temperature test chamber here, so I can't do too many tests. I can only rely on your results. Re: FS23 V1 output abnormal You can see below circled part. guoweisun_0-1786601658488.png Re: FS23 V1 output abnormal Channel 1 was VSUP,C2 was VBOS,C3 was V2;C4 was V1(power to MCU) Re: FS23 V1 output abnormal which one indicate V1 follow up VBAT from 0? current test results show VBOS>3.06V TO V1 UPing used 13.2ms, please check Re: FS23 V1 output abnormal guoweisun_0-1786601048119.png guoweisun_1-1786601077374.png A lots of confuse for your test result ,you can see when Vbat< Vsup_uv,the V1 should be stay 0,why your V1 follow up VBAT from 0? I suppose your test waveform yellow is VBAT,Green is V1,am I right? Re: FS23 V1 output abnormal This is testing. by the way, we check the manual and found 19.4.6 V1UVLP monitoring chapter shows "V1 is also monitored for V1UVLP when the device powers up after a wake up from LPON, and during a cold start after TSOFT_START_V1. If, at the end of the softstart, V1 is still under V1UVLP threshold, then the device goes into Fail-Safe state." does it mean V1 should beyond V1UVLP threshold after TSOFT_START_V1(type,300us)? in addition ,this V1 abnormal issue happened in low temperature (-30℃ ） and low Vsup power(8v)。in this condition, we increased VSUP to 12V，V1 output OK。 Re: FS23 V1 output abnormal VBOS>3.06V TO V1 UPing used 13.2msVBOS>3.06V TO V1 UPing used 13.2ms Re: FS23 V1 output abnormal You can try to disconnect  MCU with V1 and test it again for example add some loading 50mA. 

FS23 V1 输出异常 V1 输出异常，波形如下： C1 was VSUP,C2 was VBOS,C3 was V2;C4 was V1(power to MCU)C1 为 VSUP，C2 为 VBOS，C3 为 V2；C4 为 V1（MCU 电源） 微信图片_20260813093846_286_23.jpg V1 without npnV1 无 npn 微信图片_2026-08-13_095130_111.png 我该如何彻底解决目前面临的问题？ 如果您想了解更多信息，请告诉我。 Re: FS23 V1 output abnormal guoweisun_0-1786680381549.png guoweisun_1-1786680552393.png 这个图可以解释框出来的上面的是softstart的条件，假如都满足了V1开始上电了进入M5的时序，他的时间是150-500us，假如超过了这个时间还没有启动成功就会进入FS状态然后100ms以后重启这样一个大概的过程 Re: FS23 V1 output abnormal 能否帮忙在解释下softstart过程？ 包括这一段“19.4.6 V1UVLP monitoring chapter shows "V1 is also monitored for V1UVLP when the device powers up after a wake up from LPON, and during a cold start after TSOFT_START_V1. If, at the end of the softstart, V1 is still under V1UVLP threshold, then the device goes into Fail-Safe state."”到底是要求什么样的V1启动波形？ 谢谢 Re: FS23 V1 output abnormal 这个问题大概率是V1 发生了OC在软启动的过程中导致启动失败然后又恢复的这个过程。 解决方案可以外加管子阔流在V1端口然后FS23 OTP的时候把这个功能打开，也可以选择我们的HVBUCK的版本。 要么就是适当的去掉一些输出电容让softstart更顺畅，我建议选择上面两个方案更稳妥 Re: FS23 V1 output abnormal 1：原理图PIN37不用的话接地。 2：V1的负载电流不大的最大才100mA确认下您那里的负载 3：V1_IN的decouple 电容是1uF. guoweisun_0-1786671133675.png 4: 就像上面这个情况第一次启动不成功第二次起来了能否读取寄存器 M_GEN_FLAG register 看看发生了什么？ 先改上面这些看看结果。 Re: FS23 V1 output abnormal 我们新测了个波形，在输入12V时也发现V1有时第一次启动是失败的。 af12f0f0-afa6-40e3-881d-890516697b5a.png 这是第一次启动失败的波形 V1第一次启动未成功图V1第一次启动未成功图 这是第二次启动成功的波形 V1第二次启动成功图V1第二次启动成功图 这个是不是和那个V1 在软启动之后的欠压检测有关联，但是软启动的时间是典型值300，最大值500us。现在为啥感觉是超过500us就启动不起来，低于500us好像就行。 能否帮忙描述下软启动的内容，看手册没有太多描述 Re: FS23 V1 output abnormal guoweisun_0-1786608712650.png 在8V Vin的情况下能否把这个上面圈出来的波形的时间轴放小些，我想看V1启动了多久？ 另外12V VIN的情况下也测试下相同的波形可以嘛？ 我这里没有高低温试验箱无法做太多的测试只能看你们的结果了。 Re: FS23 V1 output abnormal 您可以看到下面圈出的部分。 guoweisun_0-1786601658488.png Re: FS23 V1 output abnormal 通道 1 为 VSUP，C2 为 VBOS，C3 为 V2；C4 为 V1（MCU 电源） Re: FS23 V1 output abnormal 哪个指标表示 V1 后续 VBAT 从 0 开始？ 当前测试结果显示 VBOS>3.06VV1 更新耗时 13.2 毫秒，请检查 Re: FS23 V1 output abnormal guoweisun_0-1786601048119.png guoweisun_1-1786601077374.png 你的测试结果有很多令人困惑的地方。你可以看到，当 Vbat < Vsup_uv 时，V1 应该保持为 0，为什么你的 V1 会跟随 VBAT 从 0 开始变化呢？我猜你的测试波形中，黄色代表 VBAT，绿色代表 V1，对吗？ Re: FS23 V1 output abnormal 这是测试。 顺便说一下，我们查阅了手册，发现 19.4.6 V1UVLP 监测章节显示“当设备从 LPON 唤醒后上电，以及在 TSOFT_START_V1 之后冷启动时，也会监测 V1UVLP。如果在软启动结束时，V1 仍然低于 V1UVLP 阈值，则设备进入故障保护状态。 这是否意味着在 TSOFT_START_V1(type,300us) 之后，V1 应该超过 V1UVLP 阈值？ 此外，V1的异常问题发生在低温（-30℃）和低Vsup功率（8V）下。在这种情况下，我们将VSUP提高到12V，V1输出正常。 Re: FS23 V1 output abnormal VBOS>3.06V TO V1 UPing used 13.2msVBOS>3.06V 至 V1 UPing 耗时 13.2ms Re: FS23 V1 output abnormal 您可以尝试断开MCU与V1的连接，然后再次进行测试，例如增加50mA的负载。

ノズルでMPXM2053GSをピックアップする方法 SMTプロセス中、ピックアンドプレースノズルから圧力ポートに空気が吹き込まれる可能性があります。内部のセンサを壊すことはあり得ますか? Re: how to pick up MPXM2053GS by nozzle こんにちは、デイビッドさん。 ピックアンドプレースノズルから側面の圧力ポートへ短時間で低圧の空気パルスが噴射されても、印加される圧力がデバイスの最大定格過圧を超えない限り、損傷を引き起こす可能性は低い。しかし、繰り返しまたは高圧の空気吹きは原理的にダイアフラムにストレスを与えたり、極端な条件下では損傷を与える可能性があります。 リスクを完全に回避するために推奨される方法は、ピックアンドプレースノズルをM-PAKパッケージの平らな上部表面、側面圧力ポートから離れた位置に配置することです。これにより、ノズルがセンサーポートの開口部に空気の流れを接触したり、導いたりすることがなくなります。アプリケーションノート AN1984 – フリースケール圧力センサの取り扱い は、このデバイスファミリのノズル設計と配置に関する具体的な指針を提供し、MPXシリーズセンサのSMT取り扱いに関する主要な参考資料です。応用ノート AN936 – MPXシリーズ圧力センサの取り付け技術、リード成形および試験 も有用な補完資料です。 なお、2026年2月2日現在、NXP MEMSセンサー製品(MPXM2053GSを含む)はSTMicroelectronicsに移行されました。今後の継続的な製品サポートやドキュメント管理については、STMに直接相談することをお勧めします。 BRs、トーマス

FS23 V1 出力異常 V1出力は、以下の波形のように異常です。 C1 was VSUP,C2 was VBOS,C3 was V2;C4 was V1(power to MCU)C1はVSUP、C2はVBOS、C3はV2、C4はV1(power to MCU) 微信图片_20260813093846_286_23.jpg V1 without npnV1で、NPNなしで 微信图片_2026-08-13_095130_111.png 現在直面している問題をどうすれば徹底的に解決できるでしょうか? さらに詳しい情報が必要な場合は、お知らせください。 Re: FS23 V1 output abnormal guoweisun_0-1786680381549.png guoweisun_1-1786680552393.png この図は、上記で説明したソフトスタート条件を示しています。すべての条件が満たされると、V1は電源投入を開始し、150～500µsかかるM5タイミングシーケンスに入ります。この時間内に起動に失敗した場合、FS状態に入り、100ms後に再起動します。これが大まかなプロセスです。 Re: FS23 V1 output abnormal ソフトスタートのプロセスについて説明していただけますか？ このセクション「 19.4.6 V1UVLP モニタリングの章」には、「LPON からのウェイクアップ後、および TSOFT_START_V1 後のコールドスタート中に、デバイスの電源投入時にも V1 は V1UVLP について監視されます。ソフトスタートの終了時に V1 がまだ V1UVLP しきい値を下回っている場合、デバイスはフェイルセーフ状態になります。」と記載されています。V1の起動波形には具体的に何が必要ですか？ ありがとう Re: FS23 V1 output abnormal この問題は、OCのソフトブートプロセス中にV1が起動に失敗し、その後復旧したことが原因である可能性が最も高い。 解決策としては、V1ポートに外部チューブを追加し、FS23 OTP使用時にこの機能を有効にするか、弊社のHVBUCKバージョンを選択することです。 あるいは、出力コンデンサをいくつか取り外すことで、ソフトスタートをよりスムーズにすることもできます。安定性を高めるためには、これら2つの方法のいずれかを選択することをお勧めします。 Re: FS23 V1 output abnormal 1: 回路図のPIN37が使用されていない場合は、接地してください。 2：V1の負荷電流は大きくなく、最大でも100mAです。設置場所の負荷をご確認ください。 3：V1_INのデカップリングコンデンサは1μFです。 guoweisun_0-1786671133675.png 4：上記の場合、最初の起動が失敗し、2回目の起動が行われた場合、レジスタM_GEN_FLAGを読み取って何が起こったかを確認できますか？ まずはこれらの点を変えてみて、結果を見てみましょう。 Re: FS23 V1 output abnormal 新しい波形を測定したところ、入力電圧が12Vの場合、V1が初回起動時に失敗することがあることがわかりました。 af12f0f0-afa6-40e3-881d-890516697b5a.png これは最初の起動失敗時の波形です。 V1第一次启动未成功图V1は最初の試行で起動に失敗しました（画像）。 これは、2回目の起動が成功した際の波形です。 V1第二次启动成功图V1は2回目の起動に成功しました（画像）。 これはソフトブート後のV1における低電圧検出と関係があるのでしょうか？ 通常のソフトブート時間は300µs、最大は500µsです。500µsを超えると起動しないように見えるのに、500µs未満だと正常に動作するように見えるのはなぜでしょうか？ ソフトブートの手順について説明していただけますか？マニュアルにはあまり詳しい説明がありません。 Re: FS23 V1 output abnormal guoweisun_0-1786608712650.png 入力電圧が8Vの場合、上記の丸で囲んだ波形の時間軸を短くできますか？V1がどれくらいの時間動作しているかを確認したいのです。 12Vの入力電圧で同じ波形をテストすることもできますか？ ここに高温・低温試験室がないので、あまり多くの試験はできません。あなたの結果を頼りにするしかありません。 Re: FS23 V1 output abnormal 下記に丸で囲まれた部分が見えます。 guoweisun_0-1786601658488.png Re: FS23 V1 output abnormal チャネル1はVSUP、C2はVBOS、C3はV2でした。C4はV1(MCUへの電源)でした。 Re: FS23 V1 output abnormal どちらがV1が0からVBATに追随することを示していますか？ 現在のテスト結果では、VBOS>3.06Vとなっています。TO V1 UPing は 13.2ms 使用しました。ご確認ください。 Re: FS23 V1 output abnormal guoweisun_0-1786601048119.png guoweisun_1-1786601077374.png テスト結果が混乱します。Vbat< Vsup_uvが0のままでいるべきなのに、なぜV1は0から続くのでしょうか?テストの波形の黄色はVBAT、緑はV1、合っていますか? Re: FS23 V1 output abnormal これはテストです。 ちなみに、マニュアルを確認したところ、19.4.6 V1UVLP モニタリングの章に「LPON からのウェイクアップ後にデバイスの電源がオンになったとき、および TSOFT_START_V1 後のコールドスタート中に、V1 も V1UVLP 用に監視されます」と記載されていました。ソフトスタートの終了時にV1がV1UVLPしきい値を下回っている場合、デバイスはフェイルセーフ状態に移行します。 これは、TSOFT_START_V1(type,300us)の後、V1がV1UVLPのしきい値を超える必要があるという意味ですか？ さらに、このV1異常は低温（-30℃）および低Vsup電源（8V）の条件下で発生しました。この状況下でVsupを12Vに上げたところ、V1出力は正常になりました。 Re: FS23 V1 output abnormal VBOS>3.06V TO V1 UPing used 13.2msVBOS>3.06VからV1へのアップイングには13.2msかかりました。 Re: FS23 V1 output abnormal 例えば、V1のMCUを切断して再度テストしてみてください。例えば、50mAの負荷を追加してみてはどうでしょうか。

MCUXpresso 配置工具：引脚工具的使用方法（日语博客） 目录 介绍 在哪些情况下可以使用图钉工具？ 安装配置工具 引脚工具屏幕配置 引脚工具基础知识——信号从哪里流向哪里？ 演示：更改引脚设置并更改 LED 的闪烁颜色。 额外福利 - 在文档（Excel 文件）中查看密码列表   介绍 本文介绍 MCUXpresso 配置工具中包含的“引脚工具” ，该工具用于配置引脚。有关“时钟工具”的使用说明，请参阅以下文章。 MCUXpresso 配置工具：如何使用时钟工具（日语博客） 近年来，微控制器（MCU）集成了许多外围功能，导致一些MCU拥有超过200个引脚。MCU的引脚配置设计灵活，允许将多个功能（信号）分配给单个引脚。此外，同一功能还可以有多个引脚选项。虽然这种高度灵活性也使得配置变得相当复杂。 因此，决定将哪个功能分配给哪个引脚（引脚复用配置）是设计早期阶段一项重要且具有挑战性的任务。这时，MCUXpresso 配置工具中的“引脚工具”就派上了用场。 Pins Tool 允许您通过 GUI 直观地执行引脚分配和电气设置，并自动将结果生成为代码，从而避免手动配置错误和冲突。 我们将首先解释如何在 VS Code 环境中的配置工具中使用引脚工具。然后，我们将演示如何更改引脚设置和更改 LED 闪烁颜色。 您还可以观看视频。点击此链接观看： 如何 使用 MCUXpresso Pins Tool（VS Code 环境）   在哪些情况下可以使用图钉工具？ 当您想要检查现有引脚设置时 当你想在设计中避免引脚冲突时 （*如果您不小心进行了冲突的设置，错误信息将以清晰易懂的方式显示。） 当您想使用 GUI 调整上拉/下拉和驱动强度等电气设置时。 当您需要自动生成引脚配置代码时   安装配置工具 本指南解释了如何在 VS Code 环境中安装 Config Tools。 *如果您尚未为 VS Code 安装 MCUXpresso，请参阅此博客文章。 安装适用于 VSC 和 SDK 的 MCUXpresso（日文博客） 启动 VS Code 后，从左侧面板中选择 MCUXpresso，然后从快速启动面板中单击“打开 MCUXpresso 安装程序”。 Kogiso_0-1780554901225.png 安装程序将启动。选择 MCUXpresso 配置工具，然后单击右上角的“安装”。 （这篇博文介绍了 MCUXpresso 配置工具 v26.03 的安装过程。） Kogiso_1-1780554932958.png 安装开始后，系统会提示您登录 MyNXP。 Kogiso_2-1780554952803.png 登录后，将显示许可协议。请阅读并同意其内容。 *安装完成后请重启VS Code。 问：如果安装失败怎么办？ A. 请从以下网站下载适合您电脑操作系统环境的安装程序并进行尝试。 MCUXpresso 配置工具 | NXP 微控制器 (MCU) 软件开发 | NXP 半导体 安装过程中，初始屏幕上会出现以下界面。如果您没有看到任何相关信息，可以将其关闭。 Kogiso_3-1780554991836.png 要从 VS Code 访问配置工具，请安装 SDK，导入示例，然后右键单击您的项目。“使用 MCUXpresso 配置工具打开”将出现；单击它。 *整个过程将在最终演示中详细解释，因此我们在此省略。 配置工具将在短时间内启动。 Kogiso_4-1780555023748.png 如果您使用的是 MCUXpresso IDE，则配置工具默认已集成，可以直接从顶部选项卡启动。 Kogiso_5-1780555059845.png   引脚工具屏幕配置 启动配置工具后，您可以使用屏幕右侧的面板在工具之间切换。 这次，我们将选择“别针”。 Kogiso_6-1780555122082.png 本节介绍图钉工具中的主要视图。 引脚：逐个引脚分配外设。 外设信号：按外设分配引脚。 封装：显示芯片的引脚配置。 路由详情：配置每个引脚与外设之间的连接，以及输入/输出设置。 问题：显示与设置相关的错误或警告。 Kogiso_7-1780555327080.png 接下来，我们将仔细研究路由细节，这是设置中最重要的方面。 #：表示MCU封装上的实际引脚编号（位置）。 外设：指示分配给该引脚的外设。 信号：指示外设信号。对于 UART，将显示 TX/RX；对于 SPI，将显示 SCK 或 MOSI。 箭头：指示连接方向。<->：双向连接 <- ：ペリフェラルへの入力 ->：输出到外围设备 布线引脚/信号：指示连接外围信号或内部信号的引脚。 标签：可以任意设置的标签。 标识符：代码生成过程中使用的标识符。此标识符会自动生成为 #define 宏，并在应用程序代码中引用。 方向：指定引脚用作 GPIO 时的输入/输出方向。对于 UART 和 SPI 等信号，输入/输出方向是预先确定的，因此“方向”仅供参考。 Kogiso_8-1780555440199.png 如果由于引脚设置错误而导致故障，问题视图将显示错误的位置和原因。其他区域也会以红色突出显示，方便您直观地识别问题区域。 在下图所示的电路中，多个外设配置在引脚 B12 上，这意味着发生了冲突。 Kogiso_9-1780555489529.png   引脚工具基础知识——信号从哪里流向哪里？ 在实际使用该工具之前，让我们先明确一下 Pins Tool 是用来配置什么的。 在 PinsTool 中 “交通信号灯从哪里来，又到哪里去？” 我们将从这个角度配置引脚设置。 这种“流程”主要有三种模式。 ① 将外部信号输入到MCU（引脚⇀外设） 首先，我们来看一下输入。这涉及到通过引脚将来自外部传感器、开关或其他集成电路的信号输入到微控制器内部的外围设备中。 在“路线详情”中点击“+”按钮将添加一行，允许您直接输入数据。 下图中的示例显示，“复位按钮 SW1 的信号输入通过 F3 引脚 (RESET_B) 进入 MCU”。 Kogiso_0-1780902810271.png Kogiso_0-1781753425379.png ② 将MCU内部信号输出到外部（外设⇀引脚） 接下来是输出。在这种情况下，信号会通过引脚从MCU内部的外设发送到外部。 下图中的示例展示了如何“将来自内部外设 (FlexSPI) 的信号 (FLEXSPI_B_DATA0) 分配给 K3 引脚，并将该信号向外输出”。 Kogiso_11-1780555643049.png Kogiso_1-1781753450620.png ③ 内部自包含连接（外围设备⇀外围设备） 最后，还有一种情况，即一个内部外设的输出连接到另一个内部外设的输入。 在下图所示的示例中，PWM 触发信号 (PWM0_A0_TRIG0) 通过内部路由连接到 ADC0 触发输入 (TRG)。　这表明它将被用作 CH0。 在这种情况下，由于它不通过外部引脚，因此表示最左侧引脚分配的“#”为 n/a。 Kogiso_12-1780555739542.png Kogiso_4-1780993159237.png 在大多数实际设计中，涉及与外部系统进行输入和输出的情况①和②占绝大多数。内部连接（③）则用于更高级的控制和优化。   演示：更改引脚设置并更改 LED 的闪烁颜色。 接下来，我们将实际更改引脚工具中的引脚设置，看看评估板上的 LED 闪烁颜色是否会发生变化。 硬件准备 本文使用的评估板是 FRDM-MCXN947 安装 SDK 在VS Code 的左侧面板中选择MCUXpresso ，然后单击“导入存储库”。 Kogiso_13-1780556224474.png 接下来，点击左侧第二个选项“远程存档”，然后在“软件包”部分搜索“ FRDM-MCXN947 ”。输入“ 947 ”后，它应该会立即出现。 Kogiso_14-1780556250581.png 您可以根据需要设置名称、位置和“创建 Git”复选框。 *对于名称和位置名称，最好只使用小写字母数字字符和下划线(_)或连字符(-) ，并避免使用符号（ \、/、:、*、?、"、、| ）和空格（这可能会导致程序故障）。 最后，勾选“我同意”复选框，然后点击“导入”开始安装SDK 。请稍候片刻。当屏幕右下角显示“存储库导入成功”时，安装即完成。 Kogiso_15-1780556320281.png 导入示例代码 SDK安装完成后，即可导入示例代码。 点击左侧面板中的“从存储库导入示例”。 Kogiso_16-1780556391584.png 在右侧显示的每个选项卡中，“存储库”下，选择您刚刚导入的SDK 。 请为“主板”选择FRDM-MCXN947 。 在本“模板”演示中，我们将展示如何更改LED的闪烁颜色。 尝试输入“ led ”，然后选择出现的“ driver_examples/gpio/gpio_led_output_cm33_core0 ”。 Kogiso_17-1780556445876.png 接下来，选择工具链并点击“导入” 。 Kogiso_18-1780556477536.png 打开配置工具 右键单击导入的示例，然后选择“使用 MCUXpresso 配置工具打开”。稍等片刻，配置工具将启动。 Kogiso_19-1780556524007.png 配置工具打开后，首先查看右侧面板中的概览。在本例中， “时钟”和“引脚”均显示为绿色（开启） ，表示这两个工具均已启用。 Kogiso_21-1780556565520.png 选择引脚以查看当前引脚设置。 查看“布线详情”，可以看到三个引脚（A1、B1、B12）已启用。 但是，当我们查看LED的B12 引脚组的方向时，它显示“未指定”，这意味着LED未在引脚工具中设置为输出。 Kogiso_23-1780556630970.png 那么，为什么即使没有进行配置， LED也会闪烁呢？让我们回到 VS Code，查看C源文件 (gpio_led_output.c)。 Kogiso_24-1780556672951.png 查看C源文件，引脚功能由BOARD_InitHardware()反映出来，但正如我们之前确认的那样，此时引脚 B12 并未在Pins Tool中设置为 GPIO 输出。 因此，在该示例的初始状态下， GPIO输入/输出方向取决于源代码，而不是引脚工具。 具体来说， GPIO_PinInit() 函数将引脚 B12 初始化为“GPIO 输出”，使其可以控制 LED 。 此处的目的是使用引脚工具更改引脚设置，并将这些更改反映到代码中。因此，我们将删除与GPIO初始化和控制相关的源代码部分（如下红色部分所示） 。 删除它将从任何地方移除 GPIO 输出设置，因此在构建和调试时LED将不再闪烁。 Kogiso_25-1780556727764.png 接下来，使用引脚工具配置引脚。在引脚工具中，将引脚 # B12 的GPIO0_10方向更改为输出。 这是上面 ② 的情况，其中内部MCU信号被发送到外部（外设 ⇀ 引脚）。 这样就改变了配置，使得“引脚B12 ( PIO0_10 ) 被设置为GPIO输出，并且由MCU的内部 GPIO 控制（软件控制）控制的信号通过该引脚输出到外部 ( LED_RED )。 Kogiso_26-1780556782627.png Kogiso_0-1780992952475.png 您可以在右侧的代码预览面板中看到代码更改。 将“未指定”更改为“输出”会在pin_mux.c的底部添加GPIO初始化代码。 Kogiso_27-1780556823305.png 现在，我们将重写示例代码。首先，点击“配置工具”屏幕左上角的“更新代码” 。 Kogiso_29-1780556862972.png 此时会弹出一个窗口。在这里，您可以像在代码预览中一样看到代码更改。 Kogiso_0-1781755356712.png 返回VS Code后，您会在屏幕顶部看到三个复选框。请确保选中它们，然后单击“确定” 。稍等片刻，时钟工具中所做的更改将应用到VS Code中的示例代码。 *如果您使用的是其他 SDK 版本，则可能不会显示此内容。 Kogiso_30-1780556951613.png 完成后，在组装之前将电路板（FRDM-MCXN947）连接到您的电脑。 Kogiso_31-1780556974535.png 连接建立后，调试导入的示例（构建、编写和运行应用程序） 。 Kogiso_32-1780557011825.png 调试过程完成后，程序将在断点处停止，因此请点击屏幕顶部的“|▶”图标。 Kogiso_33-1780557034309.png 如图所示，红色LED灯将开始闪烁。 (function() { var wrapper = document.getElementById('lia-vid-6397512171112w304h540r564'); 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'); }); }); }); } }})(); （显示我的视频） 要退出程序，请点击方形图标（只要连接到电脑， LED 指示灯就会继续闪烁，但请暂时忽略这一点） 。 Kogiso_34-1780557121251.png 为什么红色LED灯会闪烁？ 以下是关于红色LED 指示灯闪烁原因的一些补充信息。 在这种情况下，红色LED的闪烁由两个主要设置决定： app.h：定义要控制的LED（引脚） 。 pin_mux.c：定义如何使用该引脚。 这两个元件使LED能够闪烁。 哪个LED正在被控制？（app.h） 在C源文件“ gpio_led_output.c ”的底部，有一个名为GPIO_PortToggle的函数：它可以反转指定GPIO引脚的输出。 在这个函数中， BOARD_LED_GPIO（GPIO 端口） BOARD_LED_GPIO_PIN（引脚编号） 这将反转指定 GPIO 引脚的输出，使 LED 闪烁。 但是，目前还不清楚哪个颜色的LED对应于这个GPIO端口和引脚。 然后，右键单击BOARD_LED_GPIO ，选择“转到定义”（或“fn + F12” ）打开“ app.h ”。 Kogiso_35-1780557314641.png 如果您查看app.h中的Definitions部分，您会发现这些定义被分配给了红色LED的GPIO 引脚。这证实了操作的目标是红色LED 。然而，即使在app.h中已为红色LED指定了引脚，除非将该引脚配置为GPIO输出，否则LED 也不会亮起。 Kogiso_36-1780557354117.png 如何使用引脚（pin_mux.c） 接下来，我们将查看pin_mux.c的内容以检查引脚设置。在gpio_led_output.c文件中，您会找到 Pin、Clock 和 Debug 参数。每个控制台都有一个 BOARD_InitHardware()函数用于初始化，因此请在此处右键单击并选择“转到定义”（或“fn + F12” ）以查看更多详细信息。 下一个位置是BOARD_InitPins();，其中描述了引脚设置。再次右键单击BOARD_InitPins();并选择“转到定义（或“fn + F12” ）”以打开“ pin_mux.c ”。 Kogiso_37-1780557449769.png pin_mux.c文件反映了Pins Tool中的配置，与您之前在代码预览中将红色LED设置为输出时看到的内容相同。文件底部有如下描述，表示连接到红色LED 的引脚B12被初始化为GPIO输出，初始值为0 。 Kogiso_38-1780557510294.png 这样， app.h确定“要控制哪个LED （红色LED ）”，而pin_mux.c使“该引脚可用作GPIO输出”，以便可以通过GPIO_PortToggle()控制红色LED 。 更改引脚设置，将 LED 的闪烁颜色更改为蓝色。 接下来，我们将通过改变引脚设置，把LED的闪烁颜色从红色改为蓝色。 返回配置工具，如果您在引脚中搜索“ LED ”，您会发现引脚C4对应于蓝色LED (LED_BLUE) 。 Kogiso_39-1780557596823.png 检查C4引脚时，会出现如下所示的窗口。选中GPIO1:GPIO,2 (PIO1_2)并单击“完成” 。 Kogiso_40-1780557619256.png 完成这些步骤后，您添加的C4引脚将出现在“布线详情”中。 C4引脚配置为GPIO功能（ PIO1_2 ），并被赋予标签“LED_BLUE ” 。这使得软件能够将此引脚视为蓝色LED 。 Kogiso_41-1780557655257.png 接下来，我们将配置引脚的输入/输出设置。在“方向”面板中，将红色LED 的设置从“输出”更改为“未指定”，将蓝色 LED 的设置从“未指定”更改为“输出”。这样，蓝色 LED 就被配置为 GPIO 输出。 Kogiso_42-1780557690076.png 您可以在代码预览中看到pin_mux.c的变化。 Kogiso_43-1780557712959.png 现在，重写示例代码。和之前一样，在配置工具中运行“更新代码” ，并在VS Code中确认更改。更改后的引脚设置将会生效。 目前， pin_mux.c已更新。 最后，更新app.h。 按照前面描述的步骤打开app.h ，并将LED_RED更改为LED_BLUE 。 通过更改此定义，您可以将GPIO控制目标从红色LED切换到蓝色LED 。 Kogiso_44-1780557756352.png 完成这些步骤后，再次进行调试（构建、刷写并运行应用程序） 。 调试过程完成后，点击屏幕顶部的“|▶”图标。 如图所示，蓝色LED灯将开始闪烁。 (function() { var wrapper = document.getElementById('lia-vid-6397512593112w304h540r266'); 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'); }); }); }); } }})(); （显示我的视频） 顺便一提，之所以一个LED可以闪烁不同的颜色，是因为本项目中使用的FRDM-MCXN947开发板配备了RGB LED。查看FRDM-MCXN947的电路图，可以看到每个引脚都分别对应了R/G/B三种颜色。 因此，通过在引脚工具中同时设置两个彩色引脚的输出并适当格式化源代码，可以表示各种颜色（例如，红色+蓝色=紫色）。 Kogiso_1-1781668629459.png   额外福利 - 在文档（Excel 文件）中查看密码列表 打开MCX N 参考手册后，你会发现一个名为MCXNP184M150F70_Pinout.xlsx的附件。该文件包含引脚列表以及每个引脚对应的外设功能列表。 如今，随着引脚工具的不断发展，参考此类列表手动配置引脚设置的需求可能会减少。 另一方面，它仍然可以作为系统设计早期阶段的有用参考文档，例如用于器件选择、封装比较和检查可用外围设备。 要下载 MCX N 参考手册，您需要注册一个 MyNXP 帐户。 Kogiso_0-1782189821835.png *使用 Acrobat Reader 打开 这个解释使用了一个简单的例子，但实际设计中的引脚配置要复杂得多。这时Pins Tool就派上用场了；它可以帮助避免错误，并实现高效的配置。请试用一下！ =========================​ 我们目前无法 回复 此帖子“ 评论”部分留下的评论。 对于由此造成的不便，我们深表歉意，但 在进行咨询时， 请 参考“ NXP 技术问题 - 如何联系我们 （ 日语博客 ） ” 。 （如果您已经是 恩智浦的 分销商或 与 恩智浦 有合作关系 ，您可以直接咨询您的代表。） 本指南重点介绍 MCUXpresso 配置工具中的“引脚工具”，解释设置引脚的基本原理和方法。 本指南将涵盖从在 VS Code 环境中安装到通过更改引脚设置来演示 LED 闪烁的所有内容。 （预计耗时：10 分钟 *假设已安装 MCUXpresso for VSC（Visual Studio Code）SDK） MCUXpresso MCX SW | 下载 日本博客

MCUXpresso Config Tools : Pins Toolの使い方 (日本語ブログ) 目次 はじめに Pins Toolはどのような場面で活用するのか Config Toolsのインストール Pins Toolの画面構成 Pins Toolの基本 ~信号はどこからどこへ流れるのか？~ デモンストレーション：ピン設定を変更し、LEDの点滅色を変更する おまけ - ピン一覧をドキュメント(Excelファイル)で確認する   はじめに 　本記事では、MCUXpresso Config Toolsに含まれ、ピンの設定をおこなう「Pins Tool」について解説します。「Clocks Tool」の使い方については、以下の記事をご参考ください。 MCUXpresso Config Tools : Clocks Toolの使い方 (日本語ブログ) 最近のMCUには多くのペリフェラル機能が集約・統合されており、それに伴いピンの数も200ピンを超えるようなMCUも出ています。MCUのピン設定は柔軟に使えるように設計されており、1つのピンで複数の機能(信号)を切り替えて使うことができます。また、同じ機能でも複数のピン候補から選べるようになっています。柔軟性が高い分、設定は非常に複雑です。 そのため、どの機能をどのピンに割り当てるか（ピン・マルチプレックス設定）は、設計初期の重要かつ大変な作業の一つです。そこで活躍するのが、MCUXpresso Config Toolsの「Pins Tool」です。 Pins Toolを使うことで、ピン割り当てや電気的設定をGUI上で直感的に行い、その結果をコードとして自動生成することができ、手作業による設定ミスや競合(コンフリクト)を避けることができます。 VS Code環境からConfig Tools内のPins Toolを開き、はじめにツールの使い方を解説します。その後、ピン設定を変更し、LED点滅色を変更するデモンストレーションを紹介いたします。 動画でもご覧いただきます。視聴はこちらのリンク MCUXpresso   Pins Toolの使い方(VS Code環境)から   Pins Toolはどのような場面で活用するのか？ 既存のピン設定を確認したいとき ピンの競合(コンフリクト)を避けて設計したいとき (＊誤って競合した設定をすると視覚的に分かりやすくエラー箇所が表示されます) プルアップ／プルダウンやドライブ強度などの電気的設定をGUIで調整したいとき ピン設定コードを自動生成したいとき   Config Toolsのインストール VS Code環境におけるConfig Toolsのインストール方法について解説します。 ※MCUXpresso for VS Codeのインストールがお済みでない方はこちらのブログをご参照ください。 MCUXpresso for VSCとSDKのインストール (日本語ブログ) VS Codeを起動後、左側のパネルからMCUXpressoを選択し、Quick Start PanelよりOpen MCUXpresso Installerをクリックしてください。 Kogiso_0-1780554901225.png Installerが立ち上がりますので、MCUXpresso Configuration Toolsを選択し、右上のInstallをクリックしてください。 （今回のブログではMCUXpresso Config Tools v26.03 をInstallしています） Kogiso_1-1780554932958.png インストールの開始と同時にMyNXPへのログインを求められます。 Kogiso_2-1780554952803.png ログインの後、License Agreementが表示されますので内容をご確認のうえ同意してください。 ※インストール後は、VS Codeを再起動してください。 Q. もしインストールに失敗した場合は？ A. 以下ウェブサイトからのご自身のPC OS環境に応じたインストーラーをダウンロードして、お試しください。 MCUXpresso Config Tools | NXPマイクロコントローラ (MCU) 向けソフトウェア開発 | NXP Semiconductors） インストールを進めると初期画面で以下のような画面が表示されますが、該当がなければ閉じて問題ありません。 Kogiso_3-1780554991836.png VS CodeからConfig Toolsを呼び出すにはSDKをインストールし、サンプルをインポート後、プロジェクトを右クリックすると Open with MCUXpresso Config Toolsが現れますので、こちらをクリックしてください。 ※この一連のプロセスは最後のデモンストレーションで詳細に説明するので、ここでは割愛します。 　しばらくするとConfig Toolsが起動します。 Kogiso_4-1780555023748.png なおMCUXpresso IDEを使用している場合、Config Toolsは標準で統合されており、上部タブから直接起動できます。 Kogiso_5-1780555059845.png   Pins Toolの画面構成 Config Tools起動後、画面右側のパネルでツールの切り替えが可能です。 今回は「Pins」を選択します。 Kogiso_6-1780555122082.png Pin Tool内の主要なビューについて説明します。 Pins : ピン単位でペリフェラルの割り当てを行う Peripheral Signals：ペリフェラル単位でピンの割り当てを行う Package：チップのピン配置を可視化 Routing Details：各ピンとペリフェラルの接続関係や入力/出力設定を行う Problems：設定内容に関するエラーや警告が表示される Kogiso_7-1780555327080.png 続いて、設定において最も重要となるRouting Detailsについて深堀りして見ていきます。 # : MCUパッケージ上の実際のピン番号(位置)を示す。 Peripheral : ピンに割り当てられているペリフェラルを示す。 Signal : ペリフェラルの信号を示す。UARTであればTX/RX、SPIであればSCKやMOSIが表示される。 Arrow: 接続方向を示す。　<->：双方向　<- ：ペリフェラルへの入力 -> ：ペリフェラルからの出力 Routed pin/signal：ペリフェラルの信号が接続されるピンもしくは内部信号を示す。 Label : 任意に設定可能なラベル。 Identifier：コード生成時に使用される識別名。この識別名が #define マクロとして自動生成され、アプリケーションコードから参照される。 Direction：ピンをGPIOとして使用する場合の入出力方向(Input or Output)を指定。UARTやSPIなどの信号は、あらかじめ入出力方向が決まっているため、Directionは参考表示となる場合がある。 Kogiso_8-1780555440199.png ピン設定に誤りがあり、エラーが発生するとProblemsビューにはエラーの発生箇所と原因が表示されます。またその他の箇所にも赤色でハイライト表示されるため、問題箇所を視覚的に特定できます。 下記図では、B12ピンに対して複数のペリフェラルが設定された状態、つまり競合(コンフリクト)が起きています。 Kogiso_9-1780555489529.png   Pins Toolの基本 ~信号はどこからどこへ流れるのか？~ 実際にツールを操作する前に、Pins Toolが何を設定しているツールなのかを整理しておきましょう。 Pins Toolでは 「信号がどこから来て、どこへ流れるか」 という観点でピン設定を行います。 この“流れ”には、大きく3つのパターンがあります。 ①　外部の信号をMCUに取り込む(ピン⇀ペリフェラル) まずは入力です。外部のセンサやスイッチ、他のICからの信号をピン経由でMCU内のペリフェラルに取り込むケースです。  Routing Details上の”＋”をクリックすると行を追加し、直接入力できます。  下記図の例では、「リセットボタンSW1からの入力された信号をF3ピン(RESET_B)経由でMCUに取り込むこと」を示しています。 Kogiso_0-1780902810271.png Kogiso_0-1781753425379.png ②　MCU内部の信号を外部に出す（ペリフェラル⇀ピン） 続いて出力です。MCU内部のペリフェラルからピンを介して外部に信号を出すケースです。 下記図の例では、「内部ペリフェラル(FlexSPI）の信号(FLEXSPI_B_DATA0)をK3ピンに割り当て、その信号を外部へ出力すること」を示しています。 Kogiso_11-1780555643049.png Kogiso_1-1781753450620.png ③　内部で完結する接続 (ペリフェラル⇀ペリフェラル) 最後に内部ペリフェラルの出力を別の内部ペリフェラルの入力に接続するケースです。 下記図の例では、「PWMのトリガ信号(PWM0_A0_TRIG0)を、内部ルーディングによりADC0のトリガ入力(TRG　CH0)として使う」ことを示しています。 この場合は外部ピンを経由しないため、左端のピン割り当てを示す”# “はn/aとなっています。 Kogiso_12-1780555739542.png Kogiso_4-1780993159237.png 実際の多くの設計では、外部との入出力となる①・②のケースが大半を占めます。 ③の内部接続は、より高度な制御や最適化を行う際に使用されます。   デモンストレーション：ピン設定を変更し、LEDの点滅色を変更する ここからは実際にPins Tool上でピン設定を変更し、評価ボード上のLEDの点滅色が変更されるかを見ていきます。 ハードウェアの準備 本稿で使用する評価ボード ・FRDM-MCXN947 SDKのインストール VS Code内の左側のパネルからMCUXpressoを選択した状態で「Import Repository」をクリックしてください。 Kogiso_13-1780556224474.png その後、左から2番目の「REMOTE ARCHIVE」をクリックし、Packageにて「FRDM-MCXN947」を検索してください。「947」と打ち込むとすぐに出てきます。 Kogiso_14-1780556250581.png Name名、Location名、Create Gitへのチェックは任意に設定して下さい。 ※NameおよびLocation名については、「小文字の英数字」「アンダースコア(_)またはハイフン(-)」のみを使用し、（\, /, :, *, ?, ", <, >, |）などの記号やスペース（プログラムの動作不良の原因になりうる）を避けるのが無難です。 最後に「I agree」にチェックを入れた後、「Import」をクリックするとSDKのインストールが開始しますので、しばらくお待ちください。画面右下に"Repository successfully imported"が表示されたら完了です。 Kogiso_15-1780556320281.png サンプルコードのインポート SDKのインストールが完了したら、サンプルコードのインポートへと進みます。 左側のパネルから「Import Example From Repository」をクリックしてください。 Kogiso_16-1780556391584.png 右側に表示された各タブ内で、「Repository」では先ほどインポートしたSDKを選択、 「Board」はFRDM-MCXN947を選択してください。 「Template」では、今回はLEDの点滅色を変えるデモンストレーションですので、 「led」と打ち込んで表示される「driver_examples/gpio/gpio_led_output_cm33_core0」で試してみます。 Kogiso_17-1780556445876.png その後、Toolchainを選択して「Import」をクリックしてください。 Kogiso_18-1780556477536.png ConfigToolsを開く インポートしたサンプル上で右クリックして、「Open with MCUXpresso Config Tools」を選択してください。少し待つとConfig Toolsが立ち上がります。 Kogiso_19-1780556524007.png Config Toolsが開いたらまずは右側のパネルにあるOverviewを確認します。このサンプルにおいては、ClocksとPinsの2つが緑色(ONの状態)になっており、2つのツールが有効であることを示しています。 Kogiso_21-1780556565520.png Pinsを選択し、現在のピン設定の状況を見てみます。 「Routing Details」を見ると3つのピン(A1,B1,B12)が有効になっています。 しかしながら、LEDに対して設定されているB12ピンのDirectionを見ると“Not Specified”となっており、つまりPins Tool上ではLEDに対してOutput（出力）設定がされていない状態となっています。 Kogiso_23-1780556630970.png では、なぜ設定がされていないのにLEDが点滅するのかというと、VS Codeに戻りCソースファイル(gpio_led_output.c)を見てみます。 Kogiso_24-1780556672951.png Cソースファイルを見ると、BOARD_InitHardware()によってピンの機能は反映されますが、先ほど確認したように、この時点ではPins Tool上でB12ピンはGPIO出力として設定はされていません。 したがって、このサンプルの初期状態では、GPIOの入出力方向はPins Toolではなく、ソースコード側に依存しています。 具体的には、GPIO_PinInit()関数によってB12ピンが「GPIO出力」として初期化され、LEDを制御できる状態になっています。 今回の目的はPins Tool上でピン設定を変更し、その結果をコードとして反映させることですので、ソースコード側からGPIOの初期化および制御に関する部分(下記赤枠)を削除します。 削除するとGPIOの出力設定がどこにも存在しなくなるため、ビルド・デバッグを行うとLEDは点滅しなくなります。 Kogiso_25-1780556727764.png 続いて、Pins Toolsでピン設定を行います。Pins Toolより#B12ピンのGPIO0_10のDirectionをOutputに変更します。 これは先ほどの②MCU内部の信号を外部に出す（ペリフェラル⇀ピン）のケースです。 これにより「B12ピン（PIO0_10）をGPIO出力として設定し、MCU内部のGPIO制御(ソフトウェア制御)による信号をピン経由で外部（LED_RED）へ出力する状態」へと変わりました。 Kogiso_26-1780556782627.png Kogiso_0-1780992952475.png コードの変更点は右側のパネルのCode Previewより確認できます。 Not SpecifiedからOutputに変更することでpin_mux.cの最下部にGPIOの初期化コードが追加されます。 Kogiso_27-1780556823305.png この状態でサンプルコードを書き換えます。まずはConfig Toolsの画面左上にあるUpdate Codeをクリックしてください。 Kogiso_29-1780556862972.png その後Windowが表示されます。ここでもCode Previewと同様にコードの変更を確認することができます。 Kogiso_0-1781755356712.png VS Codeに戻ると、画面上部にチェックボックスが3つ並んで表示されますので、チェックが入った状態でOKをクリックしてください。少し時間が経つと、Clocks Toolでの変更がVS Code上のサンプルコードに適応されます。 ※SDKのバージョンが異なる場合は表示されない場合もあります。 Kogiso_30-1780556951613.png 完了したら、ビルドの前にボード(FRDM-MCXN947)とPCを接続します。 Kogiso_31-1780556974535.png 接続が完了したらインポートしたサンプルをデバッグ(ビルド＆書き込み＆アプリケーションの実行)します。 Kogiso_32-1780557011825.png デバッグのプロセスが完了したら、プログラムがブレイクポイントで止まっているので、画面上部のアイコン内の"|▶"をクリックします。 Kogiso_33-1780557034309.png 動画のように赤色のLEDが点滅を開始します。 (function() { var wrapper = document.getElementById('lia-vid-6397512171112w304h540r564'); 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'); }); }); }); } }})(); （マイビデオを表示） プログラムの終了は、アイコンの□をクリックします(PCと接続している限りLEDは点滅を続けますが一旦無視してください)。 Kogiso_34-1780557121251.png なぜ赤色LEDが点滅したのか？ ここで、なぜ赤色LEDが点滅したのかについて補足します。 今回の赤色LEDの点滅は、大きく次の2つの設定によって決まっています。 app.h：どのLED(ピン)を操作するかを定義 pin_mux.c：そのピンをどのように使うかを定義 この2つによりLEDの点滅が実現されています どのLEDを操作しているか？(app.h) Cソースファイル「gpio_led_output.c」の最下部には、GPIO_PortToggle ：指定したGPIOピンの出力を反転するための関数が存在します。 この関数では、 BOARD_LED_GPIO (GPIOポート) BOARD_LED_GPIO_PIN(ピン番号) で指定されたGPIOの出力を反転し、LEDを点滅させています。 ただしこの時点では、このGPIOポートとピンがどの色のLEDに対応しているかはわかりません。 そこで、BOARD_LED_GPIO で右クリックし「Go to Definition（もしくは"fn + F12"）」を選択すると、「app.h」が開きます Kogiso_35-1780557314641.png app.hでDefinitionsの部分を確認すると、これらの定義は赤色LED用のGPIOに割り当てられていることがわかります。つまり、この時点で操作対象が赤色LEDであることが確定します。しかし、app.hで赤色LEDが割り当てられていてもピン設定がGPIO出力になっていなければ、LEDは光りません。 Kogiso_36-1780557354117.png ピンをどのように使うか(pin_mux.c) 続いて、ピン設定を確認するためにpin_mux.cの中身を見ていきます。「gpio_led_output.c」内にPin、Clock、Debug consolのそれぞれ初期化を実行するためのBOARD_InitHardware(); があるので、ここで右クリックし「Go to Definition（もしくは"fn + F12"）」を選択し、さらに詳細を見てみます。 遷移先にBOARD_InitPins();があり、ここにピン設定が記述されています。BOARD_InitPins(); 上でもう一度右クリックし、「Go to Definition（もしくは"fn + F12"）」を選択すると「pin_mux.c」が開きます。 Kogiso_37-1780557449769.png pin_mux.c はPins Tool上で設定した内容が反映されたファイルで、先ほど赤色LEDをOutputへ変更した際にCode Previewで確認したものと同じです。最下部に以下の記述があり、赤色LEDに接続されたB12ピンを、初期値0のGPIO出力として初期化することを意味しています。 Kogiso_38-1780557510294.png このように、app.hで「どのLEDを操作するか（赤色LED）」が決まり、pin_mux.cで「そのピンをGPIO出力として使えるようにする」ことで、GPIO_PortToggle()によって赤色LEDを制御できる状態になっています。 ピン設定を変更し、LEDの点滅を青色に変更する 次にピン設定を変更することでLEDの点滅色を赤色から青色に変更します。 Config Toolに戻り、Pinsから「LED」検索するとC4ピンが青色LED(LED_BLUE)に対応していることがわかります。 Kogiso_39-1780557596823.png C4ピンにチェックを入れると下図のようなウィンドウが表示されるので、GPIO1:GPIO,2(PIO1_2)にチェックを入れてDoneをクリックします。 Kogiso_40-1780557619256.png ここまで完了すると、Routing Detailsに追加したC4ピンが表示されます。 C4ピンをGPIO機能（PIO1_2）として設定し、このピンに青色LED（LED_BLUE）というラベルを割り当てています。これにより、ソフトウェアからこのピンを青色LEDとして扱うことができます。 Kogiso_41-1780557655257.png 続いて、ピンの入出力設定を行います。Directionの赤色LEDをOutput⇀Not Specifiedに、青色LEDをNot Specified ⇀Outputに変更します。この設定により青色LEDをGPIO出力として設定できました。 Kogiso_42-1780557690076.png Code Previewで、pin_mux.cの変更点は確認できます。 Kogiso_43-1780557712959.png この状態でサンプルコードを書き換えます。先ほど実施したようにConfig Tools上でUpdate Codeを実行し、VS Code上でも変更を承認してください。変更したピン設定が反映されます。 ここまでで、まずはpin_mux.cが更新されました。 最後に、app.hを更新します。 先ほどの手順でapp.hを開き、LED_REDからLED_BLUEに変更します。 この定義を変更することで、GPIOの制御対象を赤色LEDから青色LEDへ切り替えることができます。 Kogiso_44-1780557756352.png ここまで完了したら再度デバッグ(ビルド＆書き込み＆アプリケーションの実行)します。 デバッグのプロセスが完了したら、画面上部のアイコン内の"|▶"をクリックします。 動画のように青色のLEDが点滅を開始します。 (function() { var wrapper = document.getElementById('lia-vid-6397512593112w304h540r266'); 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'); }); }); }); } }})(); （マイビデオを表示） ちなみに、なぜ1つのLEDで異なる色の点滅ができたかについて、今回使用したボードFRDM-MCXN947にはRGB LEDが搭載されています。FRDM-MCXN947の回路図を見るとピンごとにR/G/Bが割り当てられていることがわかります。 このため、2色のピンを同時にPins Tool内で出力設定し、ソースコードを適切な形に整えれば様々な色を表現することも可能です (例 : 赤 + 青 = 紫)。 Kogiso_1-1781668629459.png   おまけ - ピン一覧をドキュメント(Excelファイル)で確認する MCX Nのリファレンス・マニュアルを開くと、添付ファイルにMCXNP184M150F70_Pinout.xlsx というファイルがあります。ここにはピンの一覧と各ピンに対するペリフェラル機能の一覧が載っています。 最近では、Pins Toolの進化により、このような一覧表を参照しながら手作業でピン設定を行う機会は少なくなってきているかもしれません。 一方で、デバイス選定やパッケージ比較、利用可能なペリフェラルの確認など、システム設計の初期段階では今でも有用なリファレンス資料として活用できます。 MCX Nのリファレンス・マニュアルをダウンロードするには、MyNXPアカウントの登録が必要です。 Kogiso_0-1782189821835.png ※Acrobat Readerで開いています 今回はシンプルな例で説明しましたが、実際の設計ではピン設定はさらに複雑になります。そんなときこそPins Toolを活用することで、ミスを防ぎながら効率的に設定を進めることができます。是非ご活用ください。 =========================​ 本投稿の「Comment」欄にコメントをいただいても、現在返信に対応しておりません。​ お手数をおかけしますが、お問い合わせの際には「NXPへの技術質問 - 問い合わせ方法 (日本語ブログ)」をご参照ください。​ （既に弊社NXP代理店、もしくはNXPとお付き合いのある方は、直接担当者へご質問いただいてもかまいません。) MCUXpresso Config Toolsの中から「Pins Tool」にフォーカスし、ピン設定の基本および設定方法を解説します。 VS Code環境での導入方法から、ピン設定の変更によるLED点滅デモまで紹介します。 (作業時間：10分　＊MCUXpresso for VSC (Visual Studio Code), SDKをインストールしている前提) MCUXpresso MCX SW | Downloads 日本語ブログ