FS2400の起動後の消費電流 こんにちは、専門家さん： 私のチップはS32K312で、SBCはFS2400です。 今度はチップを起動させる必要があるのですが、起動ソースはGPIOの立ち下がりエッジです。 S32K312をスタンバイ状態にする前に、FS2400をLPONモードに設定しました。 /* レジスタ M_WU1_EN : フィールド CAN_WUEN をウェイクアップおよび割り込み(03)に設定 */ Sbc_FS24_Ip_WriteRegister (0, SBC_FS24_IP_M_WU1_EN_ADDR, SBC_FS24_IP_M_CAN_WUEN_MASK ); /* レジスタ M_IOWU_EN : フィールド WAKE2、WAKE3、HVIO1 をウェイクアップおよび割り込みなし(00) に設定 */ Sbc_FS24_Ip_WriteRegister(0, SBC_FS24_IP_M_IOWU_EN_ADDR, 0x00); /* レジスタM_CAN : 送信されたCAN MODEはトランシーバ受信のみモードに設定されています */ Sbc_FS24_Ip_WriteRegister(0, SBC_FS24_IP_M_CAN_ADDR, SBC_FS24_IP_M_CAN_MODE_RX_ONLY); /* LPONモードに移行 */ Sbc_FS24_Ip_WriteRegister(0, SBC_FS24_IP_M_SYS_CFG_ADDR, SBC_FS24_IP_M_GO2LPON_MASK) 起動後、SBCを通常モードに設定しました。 Lpspi_Ip_Init(&Lpspi_Ip_PhyUnitConfig_SpiPhyUnit_SBC_Instance_0); Sbc_FS24_Ip_InitDriver(&Sbc_FS24_Ip_Config); Sbc_FS24_Ip_InitDevice(SBC_FS24_DEVICE_ID); eReturnValue = Sbc_FS24_Ip_CanTrcvSetState(SBC_FS24_DEVICE_ID, SBC_FS24_CANTRCV_STATE_ACTIVE ); Sbc_FS24_Ip_WriteRegister(0, SBC_FS24_IP_M_SYS_CFG_ADDR, SBC_FS24_IP_M_GO2NORMAL_MASK); 電流消費量は54mAでしたが、PORの電流消費量は72mAでした。 スタンバイ状態になる前にSBCに対して何も操作を行わない場合、ウェイクアップ後の消費電流はPORと同じです。 SOの状態が何か問題だと思いますが、なぜか教えてもらえますか? Re: FS2400 current consumption after wakeup こんにちは、ピンクマン 良い一日！ ご説明いただいた動作から判断すると、FS2400が必ずしも「フリーズ」しているわけではないと思いますが、LPONから復帰した後、SBCがPOR後と全く同じ構成/状態に戻っていない可能性が非常に高いです。 データシートによると、LPONからのウェイクアップは、ウェイクアップシーケンスを経てデバイスを直接ノーマルモードに戻すとのことです。LPONウェイクアップ後、デバイスは自動的にINIT状態に再移行しません。 また、 デバイスがINIT状態でLPON、LPOFF、またはフェイルセーフモードに入ると、デバイスはINIT状態のままになり、デバイスの誤構成につながる可能性があります。LPONまたはLPOFFモードに入る前に、M_STATUSレジスタのINIT_Sステータスビットを読み取ることが推奨され、デバイスがINIT状態でない場合のみ行うことが推奨されます 両方の場合、以下のレジスタ(PORパスとLPONウェイクアップパス)をキャプチャして比較します。 M_STATUS M_SYS_CFG M_CAN M_SYS1_CFG M_REG_CTRL M_IOWU_EN M_WU1_EN この情報がお役に立てば幸いです。他に何かご不明な点がありましたら、お気軽にお問い合わせください。 良い一日をお過ごしください。幸運を祈ります。 Re: FS2400 current consumption after wakeup こんにちは : RafaR ご提案に基づき、POR時とウェイクアップ時のFS2400レジスタを比較しました。POR実行中はレジスタM_REG_CTRLの値が0x04であるのに対し、ウェイクアップ後はレジスタM_REG_CTRLの値が0x1304になっていることが分かりました。この発見に基づき、原因を関数 Sbc_FS24_Ip_InitDevice → Sbc_FS24_Ip_OptionalInitSequence → Sbc_FS24_Ip_InitMain にたどったところ、そこで M_REG_CTRL に対する操作が行われていることがわかりました。ただし、この関数には、SBC_FS24_NORMAL == ePowState という前提条件があります。したがって、POR中はこの関数を実行できますが、ウェイクアップ時にはSbc_FS24_Ip_InitDevice後にGOTONORMALが実行されるため、この機能は実行できず、消費電力の差が生じます。 そこで、2つの質問があります。 1.Sbc_FS24_Ip_InitDeviceは必須ですか？初期化時に呼び出さなくても、CANメッセージの送信・受信や電源供給は問題なく動作することがわかりました。 2.この消費電力の差は主にどこから生じるのでしょうか？

GUI Guider 2.0 image storage type selected as Flash cannot be displayed. Re: GUI Guider 2.0 图片存储类型选择Flash,无法显示 Hi @sk-l  Could you please provide a more detailed description of the issue? It would be very helpful if you could also attach screenshots or relevant pictures for reference.   Thank you.   BR Harry Re: GUI Guider 2.0 图片存储类型选择Flash,无法显示 skl_2-1786613588252.png skl_0-1786612933574.png skl_1-1786612993765.png Image/animated image, Color format I4, storage type Flash, no display during simulation; Color format I4, storage type c array, image displays normally;

FS2400 current consumption after wakeup hello expert: my chip is S32K312 and SBC is FS2400 now i need to wake up the chip and the wakeup source is a GPIO falling edge before make S32K312 going to standby ,i set the FS2400 goto LPON mode  /* register M_WU1_EN : filed CAN_WUEN set to wakeup and interrupt(03) */ Sbc_FS24_Ip_WriteRegister(0, SBC_FS24_IP_M_WU1_EN_ADDR, SBC_FS24_IP_M_CAN_WUEN_MASK); /* register M_IOWU_EN : filed WAKE2,WAKE3,HVIO1 set to no wakeup and interrupt(00) */ Sbc_FS24_Ip_WriteRegister(0, SBC_FS24_IP_M_IOWU_EN_ADDR, 0x00); /* register M_CAN : filed CAN MODE set to Transceiver receive only mode */ Sbc_FS24_Ip_WriteRegister(0, SBC_FS24_IP_M_CAN_ADDR, SBC_FS24_IP_M_CAN_MODE_RX_ONLY); /* go to LPON mode */ Sbc_FS24_Ip_WriteRegister(0, SBC_FS24_IP_M_SYS_CFG_ADDR, SBC_FS24_IP_M_GO2LPON_MASK) after wakeup ,i set the SBC goto normal Lpspi_Ip_Init(&Lpspi_Ip_PhyUnitConfig_SpiPhyUnit_SBC_Instance_0); Sbc_FS24_Ip_InitDriver(&Sbc_FS24_Ip_Config); Sbc_FS24_Ip_InitDevice(SBC_FS24_DEVICE_ID); eReturnValue = Sbc_FS24_Ip_CanTrcvSetState(SBC_FS24_DEVICE_ID, SBC_FS24_CANTRCV_STATE_ACTIVE); Sbc_FS24_Ip_WriteRegister(0, SBC_FS24_IP_M_SYS_CFG_ADDR, SBC_FS24_IP_M_GO2NORMAL_MASK); i found the current consumption is 54mA but the POR current consumption is 72mA if i do nothing about the SBC before goto standby ,after wakeup ,the current consumption is same as POR, so i think the sbc status is something wrong ,can you tell me why? Re: FS2400 current consumption after wakeup Hello PINKMAN Good day! Based on the behavior you described, I do not think the FS2400 is necessarily "stuck", but it is very likely that after waking from LPON the SBC is not returning to exactly the same configuration/state as after a POR The datasheet states that waking from LPON returns the device directly to Normal mode through the wake-up sequence. The device does not re-enter INIT state automatically after an LPON wake-up Also, if the device goes in LPON or LPOFF or Fail-safe mode while in INIT state, the device stays in INIT state, which can lead to misconfiguration of the device. It is recommended to read the INIT_S status bit in M_STATUS register before going to LPON or LPOFF mode, and to go only if the device is no longer in INIT state I would capture and compare the following registers in both cases (POR path and LPON-wakeup path): M_STATUS M_SYS_CFG M_CAN M_SYS1_CFG M_REG_CTRL M_IOWU_EN M_WU1_EN I hope this information has helped you, please let me know if you need help with anything else. Have a great day and best of luck. Re: FS2400 current consumption after wakeup hi : RafaR Based on your suggestion, I compared the FS2400 registers during POR and wake-up. I found that during POR, the value of register M_REG_CTRL is 0x04, while after wake-up, the value of register M_REG_CTRL is 0x1304. Based on this finding, I traced it to the function Sbc_FS24_Ip_InitDevice → Sbc_FS24_Ip_OptionalInitSequence → Sbc_FS24_Ip_InitMain, where there is an operation on M_REG_CTRL. However, this function has a prerequisite that SBC_FS24_NORMAL == ePowState. Therefore, during POR, this function can be executed, but during wake-up, GOTONORMAL is executed after Sbc_FS24_Ip_InitDevice, so this function cannot be executed, resulting in a power consumption difference. So I have two questions: 1. Is Sbc_FS24_Ip_InitDevice mandatory? Because I found that even if I do not call it during initialization, CAN message transmission/reception and power supply still work fine. 2. Where does this power consumption difference mainly come from?

Inquiry: NXP EasyEVSE for ISO 15118-20 EVCC Simulation and SECC Testing Hi  We are developing a custom charger-side ISO 15118-20 SECC. We are considering the NXP EasyEVSE platform as an EV-side simulator to test our charger without requiring a real vehicle. We understand that the MIMXRT1064-EVK would run the EVCC software, while the EVSE-SIG-BRD2X and Green PHY hardware would provide the CP/PE and PLC connection to our charger. Could you please confirm: Whether this platform/hardware can operate in EV/EVCC mode and test a custom SECC. Whether it supports ISO 15118-20 AC and AC-BPT. Whether it can test CP states and 5% PWM, SLAC, SDP, TCP/TLS, authorization, service discovery, schedule exchange, charging loop and session stop. Whether simulated EV values such as Present SoC, Target SoC and charging/discharging power limits can be configured. The exact EV-side hardware BOM, including the correct signal board, Green PHY board, cables and part numbers. Whether the required SEVENSTAX software is included or requires a separate evaluation licence. Whether QA/test TLS certificates and a secure element are required for evaluation. Which EV parameters and message fields can be modified; Whether charge and discharge power can be changed dynamically during a session; This setup is intended only for laboratory development and interoperability testing. Best regards,

S32K3 HSE Hi, NXP experts, I would like to ask if the S32K3 HSE supports the ED448 algorithm Re: S32K3 HSE Hi @Chenxu1  HSE-B supports ED448. From HSE Service API reference manual: lukaszadrapa_0-1752824170040.png Regards, Lukas Re: S32K3 HSE Hi @lukaszadrapa  Thank you for your response. You mentioned that ED448 is supported on HSE-B, but based on the HSE Service API Reference Manual and the release notes, it appears that ED448 is not supported. Could you please double-check this for us? kay3_0-1786418040733.png kay3_1-1786418087077.png Re: S32K3 HSE Hi @KaiKim  It seems I was wrong. I went through a couple of API manuals and some contains this information, some not. I was probably looking at one which didn't show this information. But when looking at hse_b_config.h in interface files in different versions, all of them contain: lukaszadrapa_0-1786607577525.png So, it's really not supported. Thanks for pointing this out. Regards, Lukas

[i.MX95 FRDM] AR0144/AP1302 ピンク色問題と NXP NEO ISP の AP1302 バイパス 環境およびハードウェアのセットアップ プロセッサー/プラットフォーム: NXP i.MX95 FRDMボード カメラモジュール: RPI-CAM-MIPI(AR0144センサ+AP1302オンボードISP) 使用ファームウェア: ap1302_60fps_ar0144_27M_2Lane_awb_tuning.bin (ap1302_ar0144_single_fw.bin に名前変更され、/lib/firmware/ に配置されています) 問題1：AP1302 ISPからのピンク/マゼンタ色の色むら AP1302 ISPを介してAR0144カメラモジュールから送信されるデコードされた画像/ビデオストリームに、ピンク/マゼンタ色の色かぶりが継続的に発生しています。 この調整済みファームウェアファイルを使用しても、デコードされたフレームには依然として目立つピンク色の色合いが見られます（サンプル画像を添付） 。 これはAR0144とAP1302の組み合わせにおける既知の問題ですか？ このカラーバランスの問題を修正するための、最新のAP1302ファームウェアバイナリはありますか？ 問題2：AP1302をバイパスしてi.MX95内蔵NEO ISPを使用する NXPのRPI-CAM-MIPIカメラモジュールに関するドキュメントには次のように記載されています: 「バイパス可能なオンボードISPチップにより、幅広いSoCで使用できます。」 i.MX95は統合されたハードウェア NEO ISPを備えているため、AP1302のオンボード処理をバイパスし、libcameraとneo-ipa-uguzziパイプラインハンドラーを使ってAR0144から直接i.MX95内部NEO ISPにルーティングしたいと考えています。 NXPへの質問： RAWパススルー(AP1302のハードウェアプロセッシングをバイパスしてRAWバイエルを直接i.MX95 NEO ISPに送る)は、i.MX95 FRDMボード上で公式にサポートされているのでしょうか? もしそうなら、NXPはRAWパススルーを有効にするためのステップバイステップ設定を提供できるのでしょうか? NEO ISPの下でAR0144センサーに必要な DTP/YAMLチューニングファイルを取得または生成するにはどうすればよいのでしょうか?NXPはAR0144用の事前キャリブレーション済みのYAML/DTPファイルを持っていて、それを共有できますか? 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 私はIMX95のFRDMボードでこれを再現していますが、色の問題はありません。カメラを起動できるので正しく設定してください。ただしディスプレイに問題があるかどうかを確認してください 1) dtb ファイルを imx95-15x15-frdm-ap1302.dtb に設定します。 2) ファームウェアが正しい 3) コマンド gst-launch-1.0 libcamerasrc ! を使用します自動ビデオシンク joanxie_0-1786086912147.jpeg Re: [i.MX95 FRDM] AR0144/AP1302 Pink Tint Issue & Bypassing AP1302 for NXP NEO ISP こんにちは、 質問1のテストとフィードバックにご協力いただき、ありがとうございました。 Re: 質問2 — i.MX95内部NEO ISPのAP1302バイパスについて また、i.MX95の内蔵NEO ISPを利用するためにオンボードのAP1302 ISPをバイパスするという私の2つ目の質問にも答えていただけますか? RPI-CAM-MIPIボードのドキュメントにはオンボードISPがバイパス可能と記載されているため、AR0144センサから直接i.MX95の内部NEO ISPにRAWのBayerストリームをルーティングしたいと考えています。 もう少し詳しく教えていただけますか: Linux 6.12.49_2.2.0 BSPリリースのi.MX95 FRDMボード上のAR0144で、AP1302ハードウェアISPプロセッシングをバイパスするRAWパススルーはサポートされていますか? デバイスツリーの変更:AP1302 ISPブロックを回避し、MIPI-CSIインターフェース上で直接RAWのBayerフレームを取得するために、具体的にどのようなデバイスツリーの設定やオーバーレイが必要ですか? チューニングとYAML構成：NXPは、NEO ISPパイプラインハンドラ内のAR0144用のチューニング/DTP構成ファイルを提供していますか？もし可能であれば、これらのファイルを共有したり、このワークフローに合ったlibcameraやLIBCAMERA_IPA_MODULE_PATHの適切な設定方法について教えていただけませんか? ご協力ありがとうございました！ Re: [i.MX95 FRDM] AR0144/AP1302 Pink Tint Issue & Bypassing AP1302 for NXP NEO ISP Linux 6.12.49_2.2.0 BSPリリースのi.MX95 FRDMボード上のAR0144で、RAWパススルー(AP1302ハードウェアISP処理をバイパスする)はサポートされていますか?>デフォルトのBSPとしてはサポートできませんでした。dbファイル名はap1302のみで見つけることができます デバイスツリーの変更:AP1302 ISPブロックを回避し、MIPI-CSIインターフェース上でRAWのBayerフレームを直接キャプチャするには、具体的にどのようなデバイスツリー構成やオーバーレイが必要ですか>ap1302 dtso ファイルを参照してください 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>;このピンはAP1302を有効にします。AP1302をバイパスするにはこのピンをコントロールできます。HIは有効化用、lowはバイパス用です 3. チューニングとYAML構成：NXPは、NEO ISPパイプラインハンドラの下にあるAR0144用のチューニング/DTP構成ファイルを提供していますか？もし可能であれば、これらのファイルを共有したり、このワークフローに合ったlibcameraやLIBCAMERA_IPA_MODULE_PATHの適切な設定方法について教えていただけませんか? >SWのパカッゲはこちらでご覧いただけます 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 こんにちは、 バイパス機構に関する詳細なご説明をありがとうございました。 色の問題についてですが、これはディスプレイやモニターの不具合ではないことを明確にしておきたいと思います。念のため申し添えますが、画面の写真を撮影したわけではありません。GStreamerパイプラインから生の画像/動画ファイルを直接ダンプし、別のホストマシンで保存したファイルを検査したところ、ピクセルデータに薄い赤みがかった/マゼンタピンクの色合いがはっきりと確認できました。 正しいDTB(imx95-15x15-frdm-ap1302.dtb)と公式のAWBチューニングファームウェア(ap1302_60fps_ar0144_27M_2Lane_awb_tuning.bin)を使用しているので、根本原因を特定するのを手伝ってもらえますか? 質問: このピンク色が特定の AR0144カメラモジュールユニットのハードウェア欠陥 によるものか、それとも構成やソフトウェアの問題によるものかをユーザー空間から確認できる特定のテストはありますか? 引き続きサポートしてくださりありがとうございます! Re: [i.MX95 FRDM] AR0144/AP1302 Pink Tint Issue & Bypassing AP1302 for NXP NEO ISP こんにちは、 @joanxie さん。 1) 先ほど申し上げたように、これはディスプレイの問題ではないことを確認しました。画像はファイルに保存され、ホストPCに転送されるためです（ディスプレイからのキャプチャではありません）。 2) カメラモジュールに問題があるかどうかを確認するため、同じカメラをIMX 95 EVKとIMX 95 FRDMボードでチェックしました。どちらの場所でも、赤みがかった色合いが見られます。 3)弊社では、AP1302に以下のファームウェアを使用しています。 https://github.com/ONSemiconductor/ap1302_binaries/blob/main/NXP_i.MX93/ap1302_60fps_ar0144_27M_2Lane_awb_tuning.bin そして、これを「ap1302_ar0144_single_fw.bin」という名前で/lib/firmwareに配置します（これはdmesgログから確認したファイル名です）。 同じファームウェアを使っているか確認できますか?もしなければ、適切なファームウェアを入手できる場所を教えていただけると助かります 4) チューニングやファームウェアの問題かどうかを見分ける方法はありますか?あるいは、現在使用している特定のモジュールにハードウェア上の問題があるのでしょうか？ハードウェアの問題であれば、新しいユニットの購入を検討したいと思います。

如何下载 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 版本已不再通过我们的下载渠道提供。 快速创建现代化的嵌入式图形用户界面 | 恩智浦半导体 BR 哈里

[i.MX95 FRDM] AR0144/AP1302 粉色色调问题 & 绕过 AP1302 以适配 NXP NEO ISP 环境和硬件设置 处理器/平台： NXP i.MX95 FRDM 板 摄像头模块： RPI-CAM-MIPI（AR0144传感器+AP1302板载ISP） 使用的固件： ap1302_60fps_ar0144_27M_2Lane_awb_tuning.bin（已重命名为ap1302_ar0144_single_fw.bin并放置在/lib/firmware/中） 问题 1：AP1302 ISP 出现粉色/洋红色色调 我发现通过 AP1302 ISP 从 AR0144 摄像头模块解码出的图像/视频流中存在持续的粉红色/洋红色色调。 尽管使用了经过调整的固件文件，解码后的帧仍然呈现出明显的粉红色色调（附图示例） 。 这是AR0144 + AP1302组合的已知问题吗？ 是否有更新的AP1302固件二进制文件可以解决这个色彩平衡问题？ 问题 2：绕过 AP1302 使用 i.MX95 内置 NEO ISP NXP关于RPI-CAM-MIPI摄像头模块的文档中写道： “可旁路的板载ISP芯片使其能够与多种SoC配合使用。” 由于 i.MX95 具有集成的硬件NEO ISP ，我们希望绕过 AP1302 板载处理，并使用 libcamera 和 neo-ipa-uguzzi 管道处理程序将来自 AR0144 的 RAW Bayer 流直接路由到 i.MX95 内部 NEO ISP。 向恩智浦提出的问题： i.MX95 FRDM 板是否正式支持 RAW 直通（绕过 AP1302 硬件处理，将 RAW Bayer 直接馈送到 i.MX95 NEO ISP）？ 如果可以，NXP能否提供启用RAW直通所需的逐步配置说明？ 在 NEO ISP 下，我们如何获取或生成 AR0144 传感器所需的DTP / YAML 调优文件？NXP是否有可供共享的AR0144预校准YAML/DTP文件？ 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 我在我的imx95 frdm板上重现了这个问题，没有颜色问题。既然你能调出摄像头，说明你的设置应该正确，检查一下你的显示屏是否有任何问题。 1) 将 dtb 文件设置为 imx95-15x15-frdm-ap1302.dtb 2）您的固件正确 3) 使用命令 gst-launch-1.0 libcamerasrc ！自动视频接收器 joanxie_0-1786086912147.jpeg Re: [i.MX95 FRDM] AR0144/AP1302 Pink Tint Issue & Bypassing AP1302 for NXP NEO ISP 您好， 感谢你测试并对问题1提供反馈。 回复：问题 2 — 绕过 i.MX95 内置 NEO ISP 的 AP1302 请问您能否也回答我的第二个问题，即如何绕过板载 AP1302 ISP 而使用 i.MX95 的内部 NEO ISP？ 由于 RPI-CAM-MIPI 板文档指出板载 ISP 是可旁路的，我们希望将来自 AR0144 传感器的 RAW Bayer 流直接路由到 i.MX95 的内部 NEO ISP。 请问您能否澄清一下： Linux 6.12.49_2.2.0 电路板支持包 版本是否支持 i.MX95 FRDM 板上的 AR0144 进行 RAW 直通（绕过 AP1302 硬件 ISP 处理）？ 设备树更改：要绕过 AP1302 ISP 块并直接在 MIPI-CSI 接口上捕获 RAW Bayer 帧，需要什么样的设备树配置或覆盖？ 调优和 YAML 配置：NXP 是否为 NEO ISP 流水线处理程序下的 AR0144 提供调优/DTP 配置文件？如果可以的话，能否分享这些文件，或者指导我们如何为该工作流程正确设置 libcamera 和 LIBCAMERA_IPA_MODULE_PATH？ 谢谢你的帮助！ Re: [i.MX95 FRDM] AR0144/AP1302 Pink Tint Issue & Bypassing AP1302 for NXP NEO ISP Linux 6.12.49_2.2.0 BSP 版本是否支持 i.MX95 FRDM 板上的 AR0144 芯片的 RAW 直通（绕过 AP1302 硬件 ISP 处理）？> 默认 BSP 不支持此功能，您只能找到名为 ap1302 的 dtb 文件。 设备树更改：需要什么样的设备树配置或覆盖才能绕过 AP1302 ISP 块并直接在 MIPI-CSI 接口上捕获原始 Bayer 帧？请参考ap1302 dtso文件 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>; 此引脚使能 AP1302，您可以通过控制此引脚来旁路 AP1302，高电平表示使能，低电平表示旁路。 3.调优和YAML配置：NXP是否为NEO ISP管道处理程序下的AR0144提供调优/DTP配置文件？如果可以的话，能否分享这些文件，或者指导我们如何为该工作流程正确设置 libcamera 和 LIBCAMERA_IPA_MODULE_PATH？ 您可以在这里找到所有SW扩展包 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 您好， 感谢您对旁路机制的详细解释。 关于颜色问题，我想澄清一下，这不是显示器或监视器的问题。为了确认，我们没有拍摄屏幕照片；而是直接从 GStreamer 管道导出原始图像/视频文件，并在单独的主机上检查保存的文件，结果发现像素数据中明显存在淡红色/洋红色色调。 由于我们使用的是正确的 DTB 文件 (imx95-15x15-frdm-ap1302.dtb) 和官方的 AWB 调校固件 (ap1302_60fps_ar0144_27M_2Lane_awb_tuning.bin)，请问您能否帮助我们找出根本原因？ 问题：我们能否从用户空间运行特定的测试来验证这种粉红色色调是由我们所拥有的特定 AR0144 摄像头模块单元的硬件缺陷引起的，还是配置/软件问题引起的？ 感谢您一直以来的支持！ Re: [i.MX95 FRDM] AR0144/AP1302 Pink Tint Issue & Bypassing AP1302 for NXP NEO ISP 嗨@joanxie ， 1）正如我之前提到的，我们已经确认这不是显示问题。因为图像会被保存到文件中，然后传输到主机（而不是从显示器捕获）。 2) 我们已经在 IMX 95 EVK 和 IMX 95 FRDM 板上检查了同一台相机，以确认问题是否出在相机模块上。这两个地方都能看到红色色调。 3)我们正在将此固件用于 ap1302： https://github.com/ONSemiconductor/ap1302_binaries/blob/main/NXP_i.MX93/ap1302_60fps_ar0144_27M_2Lane_awb_tuning.bin 并将该文件放置在 /lib/firmware 目录下，文件名设为“ap1302_ar0144_single_fw.bin”（正如我们从 dmesg 日志中看到的，这是文件名）。 请确认您使用的固件版本是否相同。如果不行，请问您能否与我们联系从哪里可以获取正确的固件？ 4）有没有办法确定这是调校问题还是固件问题？或者说是我们遇到的这个特定模块存在硬件问题？如果是硬件问题，我们考虑购买一台新的设备。

How can I download GuierV1.7.2? How can I download GuierV1.7.2? Re: How can I download GuierV1.7.2? Hi @smile168  Thank you for your inquiry. Currently, only GUI Guider v2.0.0 and v1.10.1 are available for download. Unfortunately, v1.7.2 is no longer available through our download channels. Create Modern Embedded GUIs Fasts | NXP Semiconductors BR Harry

咨询：NXP EasyEVSE 用于 ISO 15118-20 EVCC 仿真与 SECC 测试 你好 我们正在开发定制的充电器侧 ISO 15118-20 SECC。 我们正在考虑使用 NXP EasyEVSE 平台作为电动汽车侧模拟器来测试我们的充电器，而无需使用真正的车辆。我们了解到，MIMXRT1064-EVK 将运行 EVCC 软件，而 EVSE-SIG-BRD2X 和 Green PHY 硬件将为我们的充电器提供 CP/PE 和 PLC 连接。 请您确认一下： 该平台/硬件是否能在EV/EVCC模式下运行并测试定制的SECC。 是否支持 ISO 15118-20 AC 和 AC-BPT。 是否可以测试 CP 状态和 5% PWM、SLAC、SDP、TCP/TLS、授权、服务发现、调度交换、充电循环和会话停止。 是否可以配置模拟电动汽车值，例如当前 SoC、目标 SoC 和充电/放电功率限制。 确切的电动车端硬件 BOM，包括正确的信号板、Green PHY 板、电缆和部件号。 是否包含所需的 SEVENSTAX 软件，或者是否需要单独的评估许可证。 评估是否需要 QA/测试 TLS 证书和安全元件。 哪些电动汽车参数和消息字段可以修改？ 充电和放电功率是否可以在会话中动态变化; 此设置仅用于实验室开发和互操作性测试。 顺祝商祺！

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，托马斯

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

关于安装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