[S32K3] [RTD 7.0.1]BCTUモジュールにおける3つの課題 RTDコードバージョンS32K3_RTD_7_0_1_D2602_ASR_REL_4_9_REV_0000_20260206のBCTUモジュールに3つの問題が見つかりました。詳細な問題点は以下のとおりです。   問題 1:ファイルAdc_TS_T40D34M70I1R0/src/Bctu_Ip.cの 1558 行目で、現在のコードではビットごとの OR 代入を使用しています: BctuBasePtr->FIFOERR |= FifoWatermarkMask;これを直接代入に変更する必要があります: BctuBasePtr->FIFOERR = FifoWatermarkMask;   問題2：ファイルAdc_TS_T40D34M70I1R0/src/Bctu_Ip.cの567行目と568行目に、既存のコードに誤ったビットシフト演算が含まれています。元のコードは以下のとおりです。 ClrMask |= ((u32Mask & (BCTU_IP_STATUS_FIFO1_OVR_ERR << (Index * 2u))) != 0U) ?(BCTU_FIFOERR_OVR_ERR_FIFO1_MASK << Index) : 0U; ClrMask |= ((u32Mask & (BCTU_IP_STATUS_FIFO1_UNDR_ERR << (Index * 2u))) != 0U) ?(BCTU_FIFOERR_UNDR_ERR_FIFO1_MASK << インデックス) : 0U; これらの2行は、以下のように正しいシフトロジックに修正する必要があります。 ClrMask |= ((u32Mask & (BCTU_IP_STATUS_FIFO1_OVR_ERR << Index)) != 0U) ?(BCTU_FIFOERR_OVR_ERR_FIFO1_MASK << (Index * 2u)) : 0U; ClrMask |= ((u32Mask & (BCTU_IP_STATUS_FIFO1_UNDR_ERR << Index)) != 0U) ?(BCTU_FIFOERR_UNDR_ERR_FIFO1_MASK << (インデックス * 2u)) : 0U;   問題3: MCAL/SDKコード生成ツールとBCTUモジュールの静的ソースコードの間に型の整合性の問題があります。MCAL で生成されたコード ( Adc_TS_T40D34M70I1R0/generate_PB/Adc_RegOperations.m 、2397行目）では、ヘッダーファイルとCファイルの両方で定義されている配列は、一律にuint32型を採用しています。SDK生成コードでは、ヘッダーファイルとCファイルの型定義が一貫していません。eclipse/mcu_data/components/PlatformSDK_S32K3/Bctu_Ip/Bctu_Ip_PBcfg.hの配列型は(249行目)は、BctuFifoDmaRawDataオプションが有効になっているかどうかに応じてuint16とuint32を切り替え、対応する配列はeclipse/mcu_data/components/PlatformSDK_S32K3/Bctu_Ip/Bctu_Ip_PBcfg.cの対応する配列です（317行目）はuint32型に固定されています。静的コード ( Adc_TS_T40D34M70I1R0/src/Bctu_Ip.c 、1629行目）では、送信長（2バイトまたは4バイト）はBctuFifoDmaRawData構成に基づいて動的に決定されます。BctuFifoDmaRawDataオプションのチェックを外すと、以下の異常な問題がすべて発生します。 1.SDKプロジェクトの場合:ヘッダーファイルとCファイルの配列型が不一致で、直接コン パイル失敗を引き起こします。 2. MCALプロジェクトの場合:コンパイルは成功しますが、固定されたuint32配列定義のため メモリ容量の半分が無駄になります。さらに、各uint32データユニットには2つのADC結果が含まれているため、データ解析時にuint16の高値と低値を手動で分割する必要があります。 上記の3つのバグは、公式バージョンS32K3_RTD_7_0_1_D2602_ASR_REL_4_9_REV_0000_20260206に存在します。NXPのソフトウェアエンジニアが次回RTDリリースでこれらのBCTUモジュールの欠陥を修正できることを期待しています。 Re: [S32K3] [RTD 7.0.1] Three Issues in the BCTU Module こんにちは、@ chenwilsoft あなたの質問は社内フォーラムにエスカレーションされており、設計チームからの確認を待っています。 Re: [S32K3] [RTD 7.0.1] Three Issues in the BCTU Module こんにちは、@ chenwilsoft ご意見ありがとうございます。 ソフトウェアチームと私はこれらの問題を確認しましたが、確かにバグです。 これらの問題は社内でエスカレーションしており、今後のアップデートで修正する予定です。

[S32K3] [RTD 7.0.1]BCTU模块中的三个问题 我在 RTD 代码版本S32K3_RTD_7_0_1_D2602_ASR_REL_4_9_REV_0000_20260206中发现了 BCTU 模块的三个问题。具体问题如下：   问题 1：在文件Adc_TS_T40D34M70I1R0/src/Bctu_Ip.c 的第 1558 行，当前代码使用按位或赋值： BctuBasePtr->FIFOERR |= FifoWatermarkMask;应修改为直接赋值： BctuBasePtr->FIFOERR = FifoWatermarkMask;   问题 2：在文件Adc_TS_T40D34M70I1R0/src/Bctu_Ip.c的第 567 行和第 568 行中，现有代码包含不正确的位移操作。原始代码如下所示： ClrMask |= ((u32Mask & (BCTU_IP_STATUS_FIFO1_OVR_ERR << (Index * 2u))) != 0U) ?（BCTU_FIFOERR_OVR_ERR_FIFO1_MASK << Index） : 0U; ClrMask |= ((u32Mask & (BCTU_IP_STATUS_FIFO1_UNDR_ERR << (Index * 2u))) != 0U) ?(BCTU_FIFOERR_UNDR_ERR_FIFO1_MASK << 索引) : 0U; 这两行代码应按如下方式修改为正确的换行逻辑： ClrMask |= ((u32Mask & (BCTU_IP_STATUS_FIFO1_OVR_ERR << Index)) != 0U) ?（BCTU_FIFOERR_OVR_ERR_FIFO1_MASK << （索引 * 2u）） : 0U; ClrMask |= ((u32Mask & (BCTU_IP_STATUS_FIFO1_UNDR_ERR << Index)) != 0U) ?(BCTU_FIFOERR_UNDR_ERR_FIFO1_MASK << (索引 * 2u)) : 0U;   问题 3： MCAL/SDK 代码生成工具与 BCTU 模块的静态源代码之间存在类型不一致对齐问题。在 MCAL 生成的代码（ Adc_TS_T40D34M70I1R0/generate_PB/Adc_RegOperations.m中，第 2397 行），头文件和 C 文件中定义的数组统一采用uint32类型。在 SDK 生成的代码中，头文件和 C 文件中的类型定义不一致： eclipse/mcu_data/components/PlatformSDK_S32K3/Bctu_Ip/Bctu_Ip_PBcfg.h中的数组类型（第 249 行）根据BctuFifoDmaRawData选项是否启用，在uint16和uint32之间切换，而eclipse/mcu_data/components/PlatformSDK_S32K3/Bctu_Ip/Bctu_Ip_PBcfg.c中的相应数组（第 317 行）固定为uint32类型。在静态代码（ Adc_TS_T40D34M70I1R0/src/Bctu_Ip.c中，第 1629 行），传输长度（2 字节或 4 字节）是根据BctuFifoDmaRawData配置动态确定的。当取消选中BctuFifoDmaRawData选项时，会出现以下所有异常问题： 1.对于 SDK 项目：头文件和 C 文件之间数组类型不匹配会导致直接编译失败。 2. 对于 MCAL 项目：虽然编译可以成功，但固定的 uint32 数组定义导致一半的内存空间被浪费。此外，每个 uint32 数据单元包含两个 ADC 结果，需要在数据解析期间手动拆分高 uint16 值和低 uint16 值。 以上三个错误存在于官方版本S32K3_RTD_7_0_1_D2602_ASR_REL_4_9_REV_0000_20260206中。我们希望恩智浦软件工程师能在下一个 RTD 版本中修复这些 BCTU 模块缺陷。 Re: [S32K3] [RTD 7.0.1] Three Issues in the BCTU Module 您好@chenwilsoft 您的问题已提交至内部论坛，正在等待设计团队的确认。 Re: [S32K3] [RTD 7.0.1] Three Issues in the BCTU Module 您好@chenwilsoft 感谢您的反馈。 软件团队和我已经确认了这些问题，它们确实是软件漏洞。 我们已将这些问题上报内部，并将在未来的更新中修复它们。

i.MX8M Plus - Dedicated I2C for Display and Camera Hi Team, Just wanted to confirm if there is any Dedicated I2C for Display and Camera. (like I2C2 for Display and I2C4 for Camera) or there is no restriction on configuring can i use any I2C for Display and camera interfaces? Re: i.MX8M Plus - Dedicated I2C for Display and Camera You can use any available I2C controller for display-related or camera-related devices on i.MX8M Plus. There is no dedicated "camera I2C" or "display I2C" inside the SoC. The choice is determined by your hardware design and device-tree configuration.

MFS2323BMBA5EP OTP構成の競合:SPIとI2Cモードの識別 NXPのエンジニアおよびコミュニティの専門家の皆様へ 現在、以下の方法で開発中です MFS2323BMBA5EP セーフティ SBCで、設定ファイルとデータシートレポートの間でOTPの工場出荷時設定に関する大きな矛盾に直面しました。この点についてご説明いただけると大変ありがたいです。 設定の競合： 1. 証拠 .cfg ファイル： 私の FS2320_BA5_CONFIG_Rev_A.cfg ファイルには、直接レジスタ値があります。 0x30 : 0x00 FS23データシート（表229）によると、 OTP_MAIN_SYS_I2C_CFG😞 ビット4（ SPI_EN_OTP ） ： 0 手段 I2Cは有効、SPIは無効です。 1 SPIが有効になっていることを意味します。 ビット3~0 ( I2CDEVADDR_OTP ) : 0000 意味する I2Cスレーブアドレスは 0x20 。 これは明らかに、このチップが工場出荷時に構成されていることを示唆しています。 I2Cモード。 2. 構成レポートPDFからの証拠： しかし、私の R_MFS2323BMBA5_Rev_A_test.pdf 文書、 表2. デバイスのOTP設定、レポートには明示的に記載されています。 SPI有効化：SPIピンが有効になっています。 これはハードウェアピンがロックされていることを示唆しています SPIモード。 私の実際のハードウェアテスト結果： MCU(S32K344)をSPIマスターとして設定し、このPMICと通信させたとき: MISOピンは一定のままです 0.3V （内部プルダウン抵抗が弱い高インピーダンス状態を示しており、スレーブ側がラインを駆動していないことを意味します。） PMIC側のSCKピンは、実際には独自にクロック信号を出力していた。 チップがOTPエミュレーションモードに固定されているか、I2Cスレーブとして設定されている可能性があり、それが原因でSPI通信が完全に失敗しているのではないかと考えています。 私の具体的な質問： 確認いただけますか MFS2323BMBA5EPの実際の工場出荷時OTP設定ですか?それはSPIですか、それともI2Cですか?  の間に対立が生じたとき。cfg registerファイル(0x30 : 0x00)とPDF設定レポート、どちらが絶対的なハードウェアの真実と考えられるべきでしょうか?PDFレポートにドキュメントの誤りが含まれている可能性はありますか? （添付しました） FS2320_BA5_CONFIG_Rev_A.cfg そして R_MFS2323BMBA5_Rev_A_test.pdf （参考としてこの投稿を参照してください）。 ご協力ありがとうございます！ Re: MFS2323BMBA5EP OTP Configuration Conflict: SPI vs I2C Mode Identification はい、ありがとうございます。 Re: MFS2323BMBA5EP OTP Configuration Conflict: SPI vs I2C Mode Identification どちらの会社にお勤めですか？現在、お客様はご自身のメールアドレスを使用されていますが、これは優先度の低い（経営幹部レベルの）顧客とみなされます。 これには、回路図とCRCドライバに関連する一連の事項を確認する必要があります。 会社のメールアドレスを使ってチケットを送信することをお勧めします。 家 Re: MFS2323BMBA5EP OTP Configuration Conflict: SPI vs I2C Mode Identification 現状では不可能です。デバッグモードで通信しています。344ピンのSCK波形とMOSI波形を個別にテストしたところ、書き込んだデータは送信できました。しかし、FS23のSCKピンも信号を送信しているため、この2つを接続すると、MCUから送信されたSCK信号がFS23によってローにプルダウンされてしまいます。FS23に送信する応答はすべて0です。CRCも設定済みです。 紫色の線は、上部の信号以降のSCK信号を表しています。 黄色はデータ信号を示します。 定格電圧は5Vです。 送信されたデータは {0x02, 0x00, 0x00, CRC} です SCK波形を通常の波形として無理やり解釈すると、データが正しいことがわかります。最初のビットは2で、その後に00とCRCが続きます。 Re: MFS2323BMBA5EP OTP Configuration Conflict: SPI vs I2C Mode Identification SPIを使用して正常に通信できますか？ Re: MFS2323BMBA5EP OTP Configuration Conflict: SPI vs I2C Mode Identification FS23とS32K344がSPIで通信している際に、FS23のSCK信号も送信されている可能性はありますか？というのも、FS23とのSPI通信を設定しない場合、FS23のSCKピンをキャプチャしようとしても波形が取得できないからです。S32K344と通信している場合にのみ、FS23とS32K344の両方のSCKピンから信号が送信され、SCKピンとCSピンの波形が全く同じになります。 Re: MFS2323BMBA5EP OTP Configuration Conflict: SPI vs I2C Mode Identification guoweisun_0-1784603079866.png GUI経由で.cfgファイルをMirrorにアップロードしました。このレジスタはSPIモードを示します。

システムマネージャーのドライバーコードPCAL6524 システムマネージャーのドライバーコードを教えていただけますかPCAL6524HEAZ fsl_pcal6524.c fsl_pcal6524.h Re: system manager driver code for PCAL6524 ビンソン様、 公式のMCUXpresso SDKsやSystem マネージャ ドライバは知りません。 fsl_pcal6524.cfsl_pcal6524.h fやPCAL6524HEAZ。NXP Linux BSPは、標準のLinux GPIOエクスパンダードライバーを通じて、PCA6524デバイスツリー互換文字列を使ってデバイスをサポートしています。i.MX95 19x19 EVK は、I²C GPIO エキスパンダーとして PCAL6524 を使用する公開サンプルです。https ://github.com/torvalds/linux/blob/master/arch/arm64/boot/dts/freescale/imx95-19x19-evk.dts   敬具、 ヨゼフ

i.MX8M Plus - ディスプレイとカメラ専用のI2Cポート チームの皆さん、こんにちは。 ディスプレイとカメラ専用のI2Cポートがあるかどうか確認したかっただけです。 (例えばディスプレイ用のI2C2やカメラ用のI2C4のような)設定に制限はありませんか?ディスプレイとカメラのインターフェースに任意のI2Cを使えますか? Re: i.MX8M Plus - Dedicated I2C for Display and Camera i.MX8M Plusでは、ディスプレイ関連やカメラ関連デバイス用に利用可能な任意のI2Cコントローラーを使用できます。SoC内部には、専用の「カメラI2C」や「ディスプレイI2C」は搭載されていません。選択はハードウェア設計とデバイスツリー構成によって決まります。

Debug authentication Response for MCXW72 I am trying to unlock the debug port on the MCXW72. Unlocking it with the MCUXpresso Secure Provisioning Tool works correctly, but I am attempting to unlock the port using my own application based on the Debug Credential (DC), the DCK private key, and the DAC received from the device. The documentation is very unclear in this area (and in some places even incorrect). As I understand it, the DAR consists of: DAR = DC + AB + UUID (from DAC) + Signature (Figure 50 in the Reference Manual shows the UUID and AB fields in the wrong order.) I would like to calculate the Signature using OpenSSL, however I cannot determine exactly what data should be signed: a) DC + CV (from DAC) b) DC + AB + CV (from DAC) c) DC + AB + UUID (from DAC) + CV (from DAC) or something else entirely? The documentation states that the signature binds the DAR to the challenge vector (CV), but it does not clearly specify the exact byte sequence that must be hashed and signed. Could you please clarify the precise data that is used to generate the DAR signature? MCXA Security(Edgelock | secure boot | OTP) Re: Debug authentication Response for MCXW72 Hi @Surdej  Secure Provisioning Tool is built on top of Secure Provisioning SDK, see https://spsdk.readthedocs.io/en/latest/ This is open source so you can find the answers there.

调试 MCXW72 的身份验证响应 我正在尝试解锁 MCXW72 上的调试端口。使用 MCUXpresso 安全配置工具解锁端口可以正常工作，但我正在尝试使用我自己的应用程序，该应用程序基于从设备接收的调试凭证 (DC)、DCK 私钥和 DAC 来解锁端口。 这方面的文档非常不清楚（有些地方甚至有错误）。 据我了解，DAR 由以下部分组成： DAR = DC + AB + UUID（来自 DAC）+ 签名 （参考手册中的图 50 显示 UUID 和 AB 字段顺序错误。） 我想使用 OpenSSL 计算签名，但我无法确定应该对哪些数据进行签名： a)直流 + 恒压（来自数模转换器） b) DC + AB + CV（来自 DAC） c) DC + AB + UUID（来自 DAC）+ CV（来自 DAC） 或者完全是其他原因？ 文档指出，签名将 DAR 与挑战向量 (CV) 绑定，但并未明确指定必须进行哈希和签名的确切字节序列。请问能否详细说明用于生成DAR特征的具体数据？ MCXA 安全（Edgelock | 安全启动 | OTP） Re: Debug authentication Response for MCXW72 嗨@Surdej 安全配置工具基于安全配置 SDK 构建，请参阅https://spsdk.readthedocs.io/en/latest/ 这是开源软件，所以你可以在那里找到答案。

system manager driver code for PCAL6524 could you please provide the system manager driver code for PCAL6524HEAZ fsl_pcal6524.c fsl_pcal6524.h Re: system manager driver code for PCAL6524 Dear Binson, I am not aware of an official MCUXpresso SDK/System Manager driver named fsl_pcal6524.cfsl_pcal6524.h for the PCAL6524HEAZ. NXP Linux BSPs support the device through the standard Linux GPIO-expander driver using the PCA6524 device-tree compatible string. The i.MX95 19x19 EVK is a public example that uses the PCAL6524 as an I²C GPIO expander: https://github.com/torvalds/linux/blob/master/arch/arm64/boot/dts/freescale/imx95-19x19-evk.dts   With Best Regards, Jozef

MFS2323BMBA5EP OTP Configuration Conflict: SPI vs I2C Mode Identification Dear NXP engineers and community experts, I am currently developing with the MFS2323BMBA5EP Safety SBC and have encountered a significant conflict between my configuration files and datasheet reports regarding the OTP factory configuration. I would greatly appreciate your expertise in clarifying this. The Configuration Conflict: 1. Evidence from the .cfg file: In my FS2320_BA5_CONFIG_Rev_A.cfg file, there is a direct register value: 0x30 : 0x00 According to the FS23 datasheet (Table 229, OTP_MAIN_SYS_I2C_CFG😞 Bit 4 (SPI_EN_OTP): 0 means I2C is enabled, SPI is disabled; 1 means SPI is enabled. Bit 3~0 (I2CDEVADDR_OTP): 0000 means the I2C slave address is 0x20. This clearly suggests the chip is factory-configured for I2C mode. 2. Evidence from the Configuration Report PDF: However, in my R_MFS2323BMBA5_Rev_A_test.pdf document, under Table 2. Device OTP configuration, the report explicitly states: SPI Enable: SPI pins are enabled. This suggests the hardware pins are locked to SPI mode. My Actual Hardware Test Results: When I configured my MCU (S32K344) as an SPI Master to communicate with this PMIC: The MISO pin stays at a constant 0.3V (indicating high-impedance with internal weak pull-down, meaning the slave is not driving the line). The SCK pin on the PMIC side was actually outputting clock signals on its own. I suspect the chip might be locked in OTP Emulation mode or configured as an I2C slave, which is causing the SPI communication to completely fail. My Specific Questions: Could you please confirm the actual factory OTP configuration for the MFS2323BMBA5EP? Is it SPI or I2C? When there is a conflict between the .cfg register file (0x30 : 0x00) and the PDF configuration report, which one should be considered the absolute hardware truth? Is there a possibility that the PDF report contains a documentation error? (I have attached the FS2320_BA5_CONFIG_Rev_A.cfg and the R_MFS2323BMBA5_Rev_A_test.pdf to this post for reference). Thank you in advance for your help! Re: MFS2323BMBA5EP OTP Configuration Conflict: SPI vs I2C Mode Identification Okay, thank you. Re: MFS2323BMBA5EP OTP Configuration Conflict: SPI vs I2C Mode Identification Which company are you from? Currently, you're using your own email address, which is considered a low-priority (C-level) customer. This requires checking your schematic and a series of things related to the CRC driver. I suggest you submit a ticket using your company email address. Home Re: MFS2323BMBA5EP OTP Configuration Conflict: SPI vs I2C Mode Identification Currently, it's not possible. I'm communicating in DEBUG mode. I've tested the SCK and MOSI waveforms on the 344 pin separately, and they can transmit the data I write. However, because the FS23's SCK pin is also sending a signal, when these two are connected together, the SCK signal sent by the MCU is pulled low by the FS23. The responses I send to the FS23 are all 0s. I've also configured CRC. The purple line represents the SCK signal after the top. Yellow indicates data signals. The scale is 5V. The data sent is {0x02, 0x00, 0x00, CRC} If you forcefully interpret the SCK waveform as a normal waveform, you can see that the data is correct; the first bit is 2, followed by 00 and CRC. Re: MFS2323BMBA5EP OTP Configuration Conflict: SPI vs I2C Mode Identification Can you successfully communicate using SPI? Re: MFS2323BMBA5EP OTP Configuration Conflict: SPI vs I2C Mode Identification Is it possible that the SCK signal of the FS23 is also being sent when communicating with the S32K344 via SPI? Because if I don't configure SPI communication with the FS23, there's no waveform when I try to capture the SCK pin of the FS23. Only when communicating with the S32K344 are both the SCK pins of the FS23 and the S32K344 sending signals, and the waveforms of the SCK and CS pins are exactly the same. Re: MFS2323BMBA5EP OTP Configuration Conflict: SPI vs I2C Mode Identification guoweisun_0-1784603079866.png I uploaded the .cfg file to Mirror via the GUI. The register indicates SPI mode.

PCAL6524 的系统管理器驱动程序代码 请问能否提供PCAL6524HEAZ的系统管理器驱动程序代码？ fsl_pcal6524.c fsl_pcal6524.h Re: system manager driver code for PCAL6524 亲爱的宾森： 我不知道有名为fsl_pcal6524.cfsl_pcal6524.hf或 PCAL6524HEAZ 的官方 MCUXpresso SDK/系统管理器驱动程序。NXP Linux BSP 通过标准的 Linux GPIO 扩展器驱动程序，使用 PCA6524 设备树兼容字符串来支持该设备。i.MX95 19x19 EVK 是一个公开示例，它使用 PCAL6524 作为 I²C GPIO 扩展器： https://github.com/torvalds/linux/blob/master/arch/arm64/boot/dts/freescale/imx95-19x19-evk.dts   最诚挚的问候， 约瑟夫

MFS2323BMBA5EP OTP 配置冲突：SPI 与 I2C 模式识别 尊敬的恩智浦工程师和社区专家们： 我目前正在使用以下技术进行开发 MFS2323BMBA5EP 功能安全单板计算机 (SBC) 的配置文件与数据手册中关于一次性密码 (OTP) 出厂配置的报告存在重大冲突。非常感谢您能凭借专业知识对此进行澄清。 配置冲突： 1. 来自以下方面的证据 .cfg 文件： 在我的 FS2320_BA5_CONFIG_Rev_A.cfg 文件中，有一个直接的寄存器值： 0x30 : 0x00 根据 FS23 数据表（表 229）， OTP_MAIN_SYS_I2C_CFG😞 位 4 ( SPI_EN_OTP ) : 0 方法 I2C 已启用，SPI 已禁用； 1 表示SPI已启用。 位 3~0 ( I2CDEVADDR_OTP ) : 0000 意思是 I2C 从机地址是 0x20 。 这清楚地表明该芯片是出厂时就已配置好的。 I2C模式。 2. 来自配置报告 PDF 的证据： 然而，在我的 R_MFS2323BMBA5_Rev_A_test.pdf 文件，在 表 2. 设备 OTP 配置，报告中明确指出： SPI 使能：SPI 引脚已启用。 这表明硬件引脚被锁定。 SPI模式。 我的实际硬件测试结果： 当我将我的MCU（S32K344）配置为SPI主设备以与该PMIC通信时： MISO引脚保持恒定 0.3伏 （表示高阻抗，内部下拉电阻较弱，意味着从设备无法驱动线路）。 PMIC 侧的 SCK 引脚实际上会自行输出时钟信号。 我怀疑该芯片可能被锁定在 OTP 仿真模式或配置为 I2C 从设备，这导致 SPI 通信完全失败。 我的具体问题： 请您确认一下。 MFS2323BMBA5EP的实际出厂OTP配置是什么？是SPI还是I2C？ 当两者之间发生冲突时 .cfg 寄存器文件（ 0x30:0x00 ）和PDF配置报告，哪个才是硬件配置的绝对权威？PDF报告是否存在文档错误的可能性？ （我已附上） FS2320_BA5_CONFIG_Rev_A.cfg 以及 R_MFS2323BMBA5_Rev_A_test.pdf （参见此帖）。 提前感谢您的帮助！ Re: MFS2323BMBA5EP OTP Configuration Conflict: SPI vs I2C Mode Identification 好的谢谢您 Re: MFS2323BMBA5EP OTP Configuration Conflict: SPI vs I2C Mode Identification 请问你们是哪个公司?目前您是用的自己的邮箱属于C客户优先级很低的 这个是需要检查您的原理图，驱动CRC一系列的东西。 我建议您用公司的邮箱提交一个ticket Home  Re: MFS2323BMBA5EP OTP Configuration Conflict: SPI vs I2C Mode Identification 目前不能，我现在是在DEBUG模式下去通讯，我单独测试344端的SCK和MOSI的波形是能发出我写的数据的，但是由于，FS23的SCK引脚也在发信号，这两个接在一块后，MCU发出来的SCK信号被FS23对顶后拉低了，我发送给FS23回复的都是0，我也配置了CRC了 紫色的线是对顶后的SCK信号 黄色是数据信号 刻度都是5V 发送的数据是 {0x02, 0x00, 0x00,CRC} 如果强行把SCK看成正常波形是能看出来数据是对的，第一位是2然后00和CRC Re: MFS2323BMBA5EP OTP Configuration Conflict: SPI vs I2C Mode Identification 你配置成SPI 能通信成功吗? Re: MFS2323BMBA5EP OTP Configuration Conflict: SPI vs I2C Mode Identification 会出现与S32K344SPI通讯时FS23的SCK信号也在发送吗，因为如果我不配置SPI与FS23通讯，我去抓FS23的SCK脚是没有波形的，只有344和他通讯的时候这两个的SCK引脚都在发信号，而且SCK和CS引脚的波形是一模一样的 Re: MFS2323BMBA5EP OTP Configuration Conflict: SPI vs I2C Mode Identification guoweisun_0-1784603079866.png 我在GUI upload .cfg文件到mirror register显示就是SPI 模式

IMX95EVK-19-REV-A1 flash problem Dear NXP, I'm trying to flash a linux image(6.18.20_2.0.0/ 6.18.2_1.0.0/6.12.49_2.2.0) to eMMC/SD Card on IMX95LP5-19 EVK REV A1 and none of them is successful. The command prompt shows [HID(W): LIBUSB_ERROR_PIPE (-9) ] SDPS: boot -f imx-boot-imx95-19x19-lpddr5-evk-sd.bin-flash_all. IMX95LPD5EVK-19CM: UUU eMMC flash of L6.18.2 fails (LIBUSB errors on Linux and Windows) The reference above mentioned that A1 silicon does not support current images on official site(6.12.34 does not have IMX95EVK patch). so I wonder if there is an unpublished official link that includes suitable images?  Looking forward to your reply, Thanks. BR/david Here is a reference IMX95LPD5EVK-19CM: UUU eMMC flash of L6.18.2 fails (LIBUSB errors on Linux and Windows) Re: IMX95EVK-19-REV-A1 flash problem A1 silicon: The recommended BSP is LF 6.6.52_2.2.x Please download demo image L6.6.52_2.2.2_MX95 And use image imx-boot-imx95-a1-19x19-lpddr5-evk-sd.bin-flash_all I just verified the following command, it worked. uuu.exe -b emmc imx-boot-imx95-a1-19x19-lpddr5-evk-sd.bin-flash_all

MTC40F2046S1RC64BD2 Are you able to confirm if this mpn: MTC40F2046S1RC64BD2 is X-ray sensitive?  Re: MTC40F2046S1RC64BD2 That's not true. X-ray exposure is a common testing procedure and will not cause damage. We suggest you find a seller with a Certificate of Conformity (COC) for safety assurance.

边缘人工智能 建议使用 imx93 的 EDGE AI 应用 Re: edge ai 对于 i.MX 93，我建议最适合应用于边缘人工智能工业视觉/非接触式人机界面应用。 它为何适用于 i.MX 93： i.MX 93 旨在为工业、汽车和物联网市场提供节能型边缘计算、机器学习加速和快速边缘推理功能。 它集成了Arm Ethos-U65 微型 NPU ，旨在加速嵌入式和物联网设备中的机器学习推理。 NXP 文档明确列出了工业人机界面、工业视觉、工业自动化、非接触式门禁控制和机器视觉作为 i.MX 93 的应用领域。 该平台支持人工智能应用场景，例如计算机视觉、语音识别、物体检测、面部识别和姿态检测。 一个实用的应用程序概念： 智能工业视觉 + 非接触式操作界面 示例功能： 基于摄像头的物体检测，用于零件存在性检查、标签检查或缺陷筛查。 用于非接触式机器控制的手势或姿态检测。 可选语音命令界面，实现免提操作。 在 i.MX 93 上进行本地推理，减少对云的依赖和延迟。 使用 i.MX 93 安全架构提供安全设备身份和生命周期支持，包括 i.MX 93 材料中提到的 EdgeLock 相关功能。 其他适合 i.MX 93 的边缘人工智能应用候选方案： 应用创意 为什么它合适 智能门铃/门禁系统 使用人脸/物体检测和本地推理；智能门铃和智能锁是 i.MX 93 智慧家居目标之一。 驾驶员监测系统 DMS 已明确列入 i.MX 93 适用于汽车应用零部件清单。 带异常检测功能的电能表 该电能表适用于工业/楼宇控制用途；机器学习可以检测本地使用异常情况。 智能健身/姿态检测演示 姿态检测和智能健身示例是已记录的边缘人工智能用例。 最佳建议：在 i.MX 93 上构建工业视觉或非接触式 HMI 边缘 AI 应用，因为它与已记录的 i.MX 93 NPU、工业视觉、HMI 和本地 ML 推理用例直接相关。

IPCFのバージョンに関する問題 私は以下のRTDバージョンを使用しています：SW32K3_S32M27x_RTD_R21-11_6.0.0_QLP01&04、IPCFバージョン：SW32K3_IPCF_4.2.1_D2504、EBバージョン：29.0。Excampleにインポートする際...プロジェクト「IPCF_AutosarOS_S32K358_M7_0」でエラーが発生しました。内容は以下のとおりです。 エラー (11061) モジュール OS TS T40D34M413R184 をインストールしていません - プロジェクト IPCF AutosarOS S32K358 M7 0 のモジュール構成を作成できません 0 (11061) モジュール「pc TS T40D34M4210R0」がインストールされていないため、プロジェクト「IPCF AutosarOS $32K358 M7 0」のモジュール構成を作成できません。 0 (11061) モジュールリソースTS T40D34M5010Roをインストールせずにプラグインします - プロジェクトIPCF AutosarOS $32K358 M7 0°のモジュール構成を作成できません @ (11061) モジュール「BaseNXP TS T40D34M50I0RO」がインストールされていません - プロジェクト IPCF AutosarOS $32K358 M7 0 のモジュール構成を作成できません @ (11061) モジュール「Mcu TS T40D34M5010R0」を含むプラグインがインストールされていません - プロジェクト「IPCF AutosarOS $32K358 M7 0」のモジュール構成を作成できません 適切なIPCFまたはEBバージョンを使用して、この問題を解決するにはどうすればよいでしょうか？ Re: IPCF版本问题 こんにちは@liyongfeng 現在EB Tresos環境にインストールされているプラグインのバージョンを教えていただけますか? また、RTDパッケージを再インストールして、その後も問題が続くか確認してみてはどうでしょうか? BR、VaneB

マーキングの詳細 マーキングの意味を教えてください。 MPN: PCA9553DP/01,118 用 04 01 616

NFCカードについて助けが必要です 最近、AmazonでMIFARE Classic 1Kに対応しているACR122U-A9と13.56MHzのRFID近接IDカードキータグを買いました。書き込み可能な再書き込み可能なCUIDフォブタグです。MWT V.1.6.8424.424.63をインストールして、4tagくらいは動作しましたが、今はカードを読み取れないか、64で63くらいで止まってしまいます。どなたか助けていただけますか?私は本当にテクノロジーにはあまり詳しくありません NFCリーダー・ライブラリ Re: I need help with my NFC card お世話になります。 弊社製品をご利用いただきありがとうございます。 ACR122U-A9の使用についてですが、公式ページでは新しいデザインにはこのリーダーは推奨されていないと記載されているのに気づきました。私の推奨は、推奨されサポートされているものに移行することです。 インストールされたミドルウェアについてですが、公式ページで見つけることができなかったので、どこで入手されたのか教えていただけますか？ MIFARE Classicに対応しているタグが4タグのように動作するというのはどういう意味か理解したいです。MIFARE ClassicカードはISO14443〜3コマンドしかサポートできません。正確なコマンドの説明については データシート をご覧ください。 もしプロジェクトについてもっと詳しく教えていただければ、 MIFARE Classic カードもセキュリティ上の理由で推奨されていないので、より良いおすすめができるかもしれません。

MTC40F2046S1RC64BD2 请问您能否确认一下这个产品型号： MTC40F2046S1RC64BD2是否对X射线敏感？ Re: MTC40F2046S1RC64BD2 那不是真的。X射线照射是一种常见的检测程序，不会造成损害。为了功能安全起见，我们建议您寻找拥有合格证书（COC）的卖家。

IPCF版本问题 我使用的RTD版本：SW32K3_S32M27x_RTD_R21-11_6.0.0_QLP01&04;IPCF版本：SW32K3_IPCF_4.2.1_D2504；EB版本：29.0，在导入excample project:IPCF_AutosarOS_S32K358_M7_0时报错，内容如下： Errors (11061) Plug in with a module Os TS T40D34M413R184" is not instald - cannot create module configurations for project IPCF AutosarOS S32K358 M7 0" 0 (11061) Plug in with a module "pc TS T40D34M4210R0 is not installed cannot create module configurations for project "IPCF AutosarOS $32K358 M7 0" 0 (11061) Plug in with a module Resource TS T40D34M5010Ro is notinstaled -cannet create module configurations for prcject IPCF AutosarOS $32K358 M7 0° @ (11061) Plug in with a module 'BaseNXP TS T40D34M50I0RO is notinstalled - cannot create module configurations for prgject IPCF AutosarOS $32K358 M7 0 @ (11061) Plug-in with a module "Mcu TS T40D34M5010R0 "is not instaled - cannot create module configurations for project 'IPCF AutosarOS $32K358 M7 0" 请问我该如何使用合适的IPCF或者EB版本解决这个问题？ Re: IPCF版本问题 嗨@liyongfeng 请问您能否告知我您的 EB tresos 环境中当前安装了哪些插件版本？ 另外，您能否尝试重新安装 RTD 软件包，并验证问题是否仍然存在？ BR，VaneB