Linuxカーネル6.1.85用のIW416 Wi-Fi/BTドライバーのソースコードおよびビルドガイドの要請 こんにちは、NXPコミュニティの皆さん、 現在、 NXP IW416(8997ベース) Wi-Fi/BluetoothモジュールをカスタムSBCに統合する作業を進めています。私のシステムは Linuxカーネル6.1.85を搭載したYoctoベースのディストリビューションを使っています。 Wi-FiとBluetoothのドライバーを独立したカーネルモジュールとして構築したいのですが、正しくて最も安定したソースを使っているか確認したいです。 以下の点について教えていただけませんか? ドライバーソースコード: カーネル6.1.85では、どのリポジトリとブランチ(またはコミット)を使うべきでしょうか? 組み立て手順: これらのドライバーや必要なファームウェアを正しく構築・統合する方法についての公式ドキュメントやアプリケーションノート、ガイドはありますか? 何かご助言や適切な情報源を教えていただければ大変ありがたいです。 お手数ですが、よろしくお願いいたします。   Re: Request for IW416 Wi-Fi/BT driver source code and build guide for Linux Kernel 6.1.85 私の環境設定は以下のとおりです。 $ ls -al /lib/firmware/nxp/ drwxr-xr-x 2 root root 4096 2月 28 02:44 ./ drwxr-xr-x 3 root root 4096 2月 28 2024 ../ -rw-r--r-- 1 root root 415996 2月 28 2024 sdioiw416_wlan_v0.bin -rw-r--r-- 1 root root 570976 2月 28 2024 sdiouartiw416_combo_v0.bin -rw-r--r-- 1 root root 154920 2月 28 2024 uartiw416_bt_v0.bin -rw-r--r-- 1 root root 58 2月 28 02:28 wifi_mod_para.conf   $ cat /lib/firmware/nxp/wifi_mod_para.conf fw_name= "nxp/sdiouartiw416_combo_v0.bin" cal_data_cfg=なし   $ lsmod モジュールサイズ使用 モアル 745472 0 mlan 585728 1 moal   DMESGログの関連部分は提供できます。どのキーワードやパーツにgrepをすべきか教えてもらえますか?また、正常に動作した場合の期待される結果／出力についても知りたいです。   よろしくお願いします。 +起動時には、以下のようにMLANドライバからのログがあります。 [ 1.312336] wlan: MWLANドライバの読み込み中 [ 1.316381] wlan: バスドライバへの登録... [ 1.321331] wlan: バスドライバへの登録完了 [ 1.326355] wlan: ドライバのロードが正常に完了   Re: Request for IW416 Wi-Fi/BT driver source code and build guide for Linux Kernel 6.1.85 こんにちは、 @sunam ファームウェアは /lib/firmware/nxp/ に配置する必要があります。 Wi-FiとBluetoothのコンボファームウェアを使用している場合は、以下のように設定してください。 root@imx8mnevk: /lib/firmware/nxp # ls -l sduartiw416_combo.bin -rw-r--r-- 1 root root 406996 2011年4月5日sduartiw416_combo.bin 入力した後は、/lib/firmware/nxp/wifi_mod_para.confのWi-Fiドライバーの読み込みパラメータを再度確認し、ファームウェア名が一致しているか再度確認してください。 それでも起動しない場合は、デバイスの起動時に取得したdmesgログを提供してください。 よろしくお願いいたします。 Christine。 Re: Request for IW416 Wi-Fi/BT driver source code and build guide for Linux Kernel 6.1.85 こんにちは、 私は現在、IW416チップを使用しています。6.1.55-2.2.2ブランチを使ってドライバを無事に構築でき、ドライバが正しく生成されていることも確認しました。 しかし、どうやら動作していないようで、最新のファームウェアがインストールされていないことが原因ではないかと疑っています。ファームウェアファイルをどのディレクトリに入れるべきか教えていただけますか? よろしくお願いします。 Re: Request for IW416 Wi-Fi/BT driver source code and build guide for Linux Kernel 6.1.85 こんにちは、 @sunam 1. ご使用のチップセットがIW416か88W8997のどちらであるかを再度ご確認ください。これらは異なるチップセットです。 IW416の場合、 最新のファームウェアをダウンロードするには： imx-firmware/FwImage_IW416_SD (lf-6.18.20_2.0.0) · nxp-imx/imx-firmware · GitHub 最新のドライバーをダウンロードするには: GitHub - nxp-imx/mwifiex at lf-6.18.20_2.0.0 · GitHub また、ドライバーのソースコードはLinuxカーネルバージョン 2.6.32から6.19.0まで運行しているホストとも互換性があるので、あなたのL6.1.85には問題ありません。 2. ビルド手順: これらのドライバや必要なファームウェアを正しく構築・統合する方法についての公式ドキュメント、アプリケーションノート、ガイドはありますか? ==> 参照先: NXP Wi-Fiドライバーのダウンロードと構築方法 また、以下のドキュメントもあなたにとって役立つと思います。 Linux OSを実行する8M Quad EVK上でNXPベースのワイヤレスモジュール i.MX 始める 他に何かご心配な点がございましたら、お知らせください。 もし違うなら、私の回答を解決策としてマークして、閉じるのを手伝ってください。 当社の製品使用中に問題が発生した場合は、新たなCASEの作成を歓迎します。 よろしくお願いいたします。 Christine。 Re: Request for IW416 Wi-Fi/BT driver source code and build guide for Linux Kernel 6.1.85 こんにちは、 @sunam 通常は以下のようなdmesgログが出力されるはずです。 ========= root@imx8mnevk:~# dmesg |グレップ・ウラン [ 5.127546] wlan: MWLANドライバーの読み込み [ 5.141006] WLAN: バス運転手への登録... [ 5.213728] wlan: TX SGモードを有効にする [ 5.217262] WLAN: mpa_tx.BUF_Size=65280 [ 5.221136] wlan: RX SG モードを有効にする [ 5.224679] wlan: mpa_rx.buf_size=65280 [ 6.505940] wlan: RX SG モードを有効にする [ 6.585864] wlan: version = SD8987----16.92.21.p155.1-MM6X16540.p33-GPL-(FP92)//これは、当社の88W8987の例です。 [ 6.624373] wlan: バス運転手への登録完了 [ 6.637582] wlan: ドライバのロードが正常に完了 ======== wifi_mod_para.confを以下のように変更できます: ====== SDIW416 = { fw_name=nxp/sdiouartiw416_combo_v0.bin cal_data_cfg=なし cfg80211_wext=0xf max_sta_bss=1 drv_mode=7 } ======= それでも解決しない場合は、デバイスの起動時に取得したdmesgログをすべて提供してください。 DMESGログは添付ファイルとしてアップロードできます。 よろしくお願いいたします。 Christine。

Using S32K3X8EVB-Q289 On-Board Debugger to Program a Custom S32K358 Target I am currently using the S32K3X8EVB-Q289 evaluation board and have developed a custom hardware design based on the S32K358 MCU. Could you please clarify: Is programming/debugging an external S32K358 target using the EVB's on-board debugger officially supported? If supported, what jumper settings or hardware modifications are required on the EVB? Which debug connector should be used for this purpose? Are there any limitations compared to using an S32 Debug Probe ? Is there any documentation or application note describing this configuration? Thank you for your support. Regards, Yash Gupta Re: Using S32K3X8EVB-Q289 On-Board Debugger to Program a Custom S32K358 Target Hello @Yash2530 , 1. Yes, using the S32K3X8EVB-Q289 on-board debugger to program/debug an external S32K358 target is supported. Actually, the EVB’s on-board OpenSDA debugger uses a P&E Micro-developed bootloader/debug application - https://community.nxp.com/t5/S32-Design-Studio/Which-debugging-interface-is-better/m-p/1715877 2. No soldering rework or jumper setting is required on the EVB for this use case. 3. J55 USB host connector. 4. In practice, for standard flashing and source-level debug of an external S32K358 target, the EVB’s on-board debugger should be sufficient. Since I don't know what feature is important to you, please compare features by yourself: https://www.nxp.com/design/design-center/software/automotive-software-and-tools/s32-design-studio-ide/s32-debugger-for-s32-platform:S32DBG-S32PLATFORM https://www.pemicro.com/products/product_viewDetails.cfm?product_id=15320180&productTab=5045 5. Yes, https://www.nxp.com/webapp/Download?colCode=S32K3X8EVB-Q289HWUM Best regards, Pavel

DESFire EV3 Transaction MAC Input (TMI) construction — backend verification with TapLinx Hi, I'm verifying DESFire EV3 Transaction MAC (TMV/TMC) values on a backend. The card produces the Transaction MAC via TapLinx (CommitTransaction). I have the Transaction MAC key, the card UID, the TMC (pre and post), and the returned TMV, and I've implemented the EV2 session-key derivation from public references — but I cannot reproduce the TMV because I do not have the exact Transaction MAC Input (TMI) byte construction for EV3. Could you please help with: 1. The exact TMI accumulation for DESFire EV3 (which command bytes/fields are included, their order, and padding). 2. Whether Backup Data File writes committed in the same transaction are covered by the TMI. 3. Whether a known-key Transaction MAC reference vector is available (key + TMI + TMC + TMV) to validate an implementation. 4. If this is NDA-only, the correct way to obtain DS4870 / AN12757 as a small company. Thank you! Re: DESFire EV3 Transaction MAC Input (TMI) construction — backend verification with TapLinx Hello sir, Thank you so much for your interest in our products. Unfortunately, it is required to sign an NDA to gain access to the Secured Documentation of MIFARE DESFire EV3. Please check our FAQ and fill out the NDA Form. You will need to create a new ticket from our site. I hope this information may be helpful.

IMX95LPD5EVK測定時の温度条件 こんにちは、 AN14449ドキュメントを確認しても、測定値の温度条件が見つかりません。ヒートシンクは取り付けられていましたか？ファンは取り付けられていて、作動していましたか？使用された周囲温度は何度でしたか？ Re: Temperature condition for IMX95LPD5EVK measurements こんにちは、 基板は現状のままテストされました。 Oswalag_0-1782841642133.png 注記: 使用されているBCUソフトウェアツールでは、測定は搭載の測定回路を使用して行われます これらの測定は熱強制装置を使わず、室温で行われます。これは、周囲温度でテストされたという意味であり、試験室ではテストされていませんが、ボードにはヒートシンクとファンが残っています。

BCTU 控制模式和触发模式下 ADC 噪声的差异 你好， 我正在开发一个使用[S32k322]的应用程序，其中我使用eMIOS 定时器每 100 µs 触发一次BCTU来读取模拟数据。 我发现两种 BCTU 模式之间存在一种奇怪的现象： 控制模式：当 ADC CTU 模式设置为控制模式时，ADC 转换完全稳定。通过 FreeMASTER 读取的数据干净，没有噪声或故障。 触发模式：当我将 ADC CTU 模式切换到触发模式（保持 100 µs eMIOS 触发不变）时，采样模拟数据变得嘈杂，并在 FreeMASTER 中出现明显的毛刺。 触发模式是否需要特定的架构配置、时序约束或寄存器设置（例如触发延迟、FIFO 配置或时钟同步）来防止出现这种噪声？ 感谢您的帮助。 ADC CTU 模式输出：触发模式 Stark__2-1782126491792.png Stark__0-1782125656766.png ADC CTU 模式输出：控制模式 Stark__3-1782126564933.png Stark__1-1782125738057.png Re: Difference in ADC noise between BCTU Control Mode and Trigger Mode 嗨@Stark_ 请您分享一下测试项目，我这边会进行测试。 Re: Difference in ADC noise between BCTU Control Mode and Trigger Mode 嗨@Senlent ， 谢谢你的回复。我的ADC时钟频率为160MHz，我的ADC配置和寄存器值附在下面。 钟 Stark__1-1782196451195.png ADC配置 Stark__2-1782196500638.png Stark__4-1782196672188.png ADC CTU 模式输出：触发模式 Stark__3-1782196552394.png ADC CTU 模式输出：控制模式 Stark__5-1782196875804.png Re: Difference in ADC noise between BCTU Control Mode and Trigger Mode 嗨@Stark_ 根据您提供的配置截图，存在一些配置问题，特别是模块时钟和校准时钟的分频比。 ADC时钟配置必须严格按照下表执行。 Senlent_0-1782179202962.png 请修改后再测试一次。 Re: Difference in ADC noise between BCTU Control Mode and Trigger Mode 嗨@Senlent 我已附上测试代码。 是否可以对某些选定的通道（ADC_Instance0 和 ADC_Instance1）进行 BCTU 和正常转换？ Re: Difference in ADC noise between BCTU Control Mode and Trigger Mode 嗨@Senlent “是的，可以进行BCTU和常规转换。” 是否有可供参考的示例代码？ 此外，您的程序仍然没有修改ADC模块时钟和校准时钟分频器。 以下是我的测试结果； 我把端口外部连接到了地线（GND）。你可以看到，效果并没有明显不同。“ 请您分享一下修改后的测试项目，我这边会进行测试。 Re: Difference in ADC noise between BCTU Control Mode and Trigger Mode 嗨@Stark_ 是的，可以进行 BCTU 和常规转换。 我测试了您提供的程序并做了一些修改。你的外部时钟频率是 25MHz，而我的外部时钟频率是 16MHz。 此外，您的程序仍然没有修改ADC模块时钟和校准时钟分频器。 以下是我的测试结果； 我将端口外部连接到了VDD（我的打字错误） 。你可以看出两者之间没有显著差异。 Senlent_0-1782359793819.png Senlent_1-1782359802334.png Re: Difference in ADC noise between BCTU Control Mode and Trigger Mode 嗨@Stark_ 我没有那样的演示；附件是一个修改后的项目。 Re: Difference in ADC noise between BCTU Control Mode and Trigger Mode 嗨@Senlent 感谢您附上修改后的项目文件。我已经测试过了，但目前在我的设置中，它对正常的ADC转换不起作用。 但是，我的实际应用需要25 MHz的系统时钟。我对你的项目所做的唯一更改就是将时钟频率从 16 MHz 更新到 25 MHz。 将时钟频率改为 25 MHz 后，将 ADC CTU 模式设置为控制模式，正常转换不起作用，而 BCTU 转换继续工作。 当 ADC CTU 模式处于触发信号模式时，正常转换和BCTU 转换继续运行。 您提供的这个项目是否旨在同时支持25 MHz 的BCTU 触发信号模式和正常转换？如果是这样，我还需要调整哪些额外的时钟分频器、预分频器或采样时间配置才能使其在更高的频率下工作？ Re: Difference in ADC noise between BCTU Control Mode and Trigger Mode 嗨@Senlent 我将 ADC 配置为使用触发模式，因为转换需要由 BCTU 模式和正常模式共同驱动。但是，在使用触发模式时，我注意到通过 BCTU 测量的 ADC 数据中存在噪声，正如之前提到的那样。 Re: Difference in ADC noise between BCTU Control Mode and Trigger Mode 嗨@Stark_ 如果您的 ADC 转换是通过 BCTU 驱动的，请使用 BCTU 控制模式。 如果您希望 ADC 接受正常/注入转换或其他触发信号，请使用触发模式。 BCTU 控制模式将 ADC 启动控制锁定为仅 BCTU；触发模式使 ADC 对正常/注入和其他支持的转换触发信号开放。 所以你的测试结果符合预期。 Re: Difference in ADC noise between BCTU Control Mode and Trigger Mode 嗨@Stark_ 我已经向你展示了我的测试结果，你应该已经注意到，我的采样结果的波动是完全正常的。 Senlent_1-1782892390979.png Senlent_2-1782892398124.png 我的建议是，您可以尝试增加采样时间，就像我之前建议的那样。 Senlent_0-1782892370211.png

LPC55S28 VBAT_PMU Current Draw I have a PCB with the schematic below. I have a coin cell battery for backup when the PCB main power is removed. From my understanding, the VBAT_PMU (Pin 51) on the MCU is dedicated for the Always‑On (PD_AON) domain.  When I measure the current draw of the battery, with no main power (only the battery), I get around 102uA. Which is far more than expected for the RTC to consume. Event if D12 is removed. Vbat only is connected to the VBAT_PMU pin and nothing else.  What is the expected behavior here? I would expect the VBAT_PMU to only draw enough current for the RTC to keep time while power is down.  102uA would drain a CR1632 coin cell battery pretty quickly.  How do I power the MCU so the battery only powers the RTC and draws less than 1uA when main power is removed?  guitardenver_0-1781801068417.png Re: LPC55S28 VBAT_PMU Current Draw Hi @guitardenver  On LPC55S28, VBAT_PMU is the supply for the always-on domain , which includes the PMC, RTC, and OS Event Timer, and that domain remains powered as long as a valid VBAT supply is present. The RTC can continue running in deep power-down from that domain. VBAT_PMU by itself does not guarantee “RTC-only current.” To get sub-µA backup current, the device must be in deep power-down mode. So your measured ~102 µA with main power removed is not consistent with RTC-only deep-power-down operation . For LPC55S2x/LPC552x, the datasheet shows typical total supply current of 110 µA in deep-sleep mode at 25 °C and 3.0 V, while deep power-down with RTC oscillator disabled is 590 nA  , and with the RTC running from an external crystal is 790 nA . Harry_Zhang_0-1782184915287.png To get less than 1 µA from the coin cell on LPC55S28, power only VBAT_PMU from the battery and make firmware enter Deep Power-Down before main power is removed. Harry_Zhang_1-1782185057154.png BR Harry Re: LPC55S28 VBAT_PMU Current Draw Thank you for your reply! I have code that will trigger the Deep power down on a brownout interrupt, which works great. But there is a huge problem with this method. If the ROM Bootloader is executing, and power is removed, the brownout interrupt is not setup and does not have code to put it into power down. Is there a good way to guarantee that I can get into the deep power down mode? If there is any state that leaves the MCU in normal mode, the battery will get drained. Maybe there is something I am missing. If not, I may have to put an external RTC chip on the board.  Re: LPC55S28 VBAT_PMU Current Draw Hi @guitardenver  No — on LPC55S28 you cannot guarantee entry into Deep Power-down purely in firmware if the device might be executing the ROM bootloader when main power is removed. Deep power-down is a software-entered mode via the power API. BR Harry

IMX8MP 辅助映像启动 IMG_CNTN_SET1_OFFSET 辅助映像启动（RM 6.1.6.2）是否适用于 i.MX8MP 上的 ECSPI（“SPI”）或非 启动，还是仅适用于 FlexSPI 或非（和 SD/eMMC）？表 6-28 将“SPI”和“FlexSPI NOR”列为单独的引导设备，并且仅针对“FlexSPI NOR 启动”说明了辅助偏移有效值。 Re: IMX8MP secondary image boot 你好， 你的理解有误， IMG_CNTN_SET1_OFFSET 辅助镜像启动也适用于 SPI 设备，只是偏移量不同： FlexSPI 的有效值为：0、1、2、3、4、5、6 和 7 对于 SPI 模式，如果熔丝位大于 10，则禁用辅助启动；n = 熔丝位大于 10. • n == 0：偏移量 = 4MB • 当 n == 2 时：偏移量 = 1MB • 其他情况且 n <= 10：偏移量 = 1MB*2^n Oswalag_0-1782750547759.png Re: IMX8MP secondary image boot 谢谢——这下偏移映射的问题就清楚了。我们需要进行两项后续操作，以便在我们的 i.MX8MP 板上重现该问题（在 ECSPI2 上启动或非，开放/非 HAB 配置，熔丝读取 2 1 = 0 → n=0 → 4 MB）： 是什么触发信号 ROM 在 SPI 或非接口上切换到辅助映像？是无效的主启动头/镜像解析失败，还是具体的 HAB 认证失败？换句话说，辅助映像启动在开放（非安全）配置下是否有效，还是仅在设备 HAB 关闭时才有效？ 它会恢复到之前的RESET状态，还是需要断电重启/第二次RESET（持久启动方式）？ 4 MB 偏移处的辅助映像必须是单独版本的可启动映像（具有该偏移处的独立虚拟映像/启动数据），还是主映像的字节相同副本就足够了？ Re: IMX8MP secondary image boot 在 OPEN (SEC_CONFIG=open, non-HAB) 配置下，i.MX8MP 从 ECSPI (SPI) NOR 启动时，IMG_CNTN_SET1_OFFSET 辅助映像启动的确切触发条件是什么？ROM 是否会在主容器头无效/被擦除时切换到辅助镜像，还是仅在 HAB 身份验证失败时才会切换到辅助镜像（例如，当主容器头无效/被擦除时）？仅在封闭/安全配置下？我们有一个 4MB 的有效辅助副本（熔丝 n=0），擦除了主头，并且 ROM 不会回退到开放配置。

BCTU制御モードとトリガーモードにおけるADCノイズの差 こんにちは、 私は [S32k322] を使って、 eMIOSタイマー を使って100μsごとに BCTU をトリガーし、アナログデータを読み取るアプリケーションを開発しています。 2つのBCTUモード間で奇妙な挙動が見られます。 制御モード： ADC CTUモードを制御モードに設定すると、ADC変換は完全に安定します。FreeMASTERで読み取られたデータは、ノイズや不具合がなく、クリーンなデータです。 トリガーモード: ADC CTUモードをトリガーモードに切り替え(100μsのeMIOSトリガーは同じに)、サンプリングされたアナログデータがノイズが発生し、FreeMASTERで目立つグリッチが現れます。 トリガーモードでこのノイズを防ぐために必要な特定のアーキテクチャ構成、タイミング制約、またはレジスタ設定（トリガー遅延、FIFO構成、クロック同期など）はありますか？ 助けてくれてありがとう。 ADC ctuモードでの出力：トリガーモード Stark__2-1782126491792.png Stark__0-1782125656766.png ADC ctuモードでの出力：制御モード Stark__3-1782126564933.png Stark__1-1782125738057.png Re: Difference in ADC noise between BCTU Control Mode and Trigger Mode こんにちは@Stark_ テストプロジェクトを教えていただければ、私が自分の側でテストします。 Re: Difference in ADC noise between BCTU Control Mode and Trigger Mode こんにちは、 @Senlent さん。 ご回答ありがとうございます。私のADCクロックは160MHzです。以下にADCの設定とレジスタ値を添付しました。 クロック Stark__1-1782196451195.png ADCの設定 Stark__2-1782196500638.png Stark__4-1782196672188.png ADC ctuモードでの出力：トリガーモード Stark__3-1782196552394.png ADC ctuモードでの出力：制御モード Stark__5-1782196875804.png Re: Difference in ADC noise between BCTU Control Mode and Trigger Mode こんにちは@Stark_ ご提供いただいた設定画面のスクリーンショットに基づくと、いくつかの設定上の問題、特にモジュールクロックとキャリブレーションクロックの分周比に問題があるようです。 ADCクロックの設定は、下記の表に厳密に従う必要があります。 Senlent_0-1782179202962.png 変更して再度テストしてください。 Re: Difference in ADC noise between BCTU Control Mode and Trigger Mode こんにちは@Senlent  テストコードを添付しました。 BCTUの作業と、選ばれた一部のチャンネル(ADC_Instance0とADC_Instance1)の通常の変換は可能でしょうか? Re: Difference in ADC noise between BCTU Control Mode and Trigger Mode こんにちは、 @Senlentさん 「はい、BCTUと通常の変換の両方で作業することは可能です。」 参考になるサンプルコードはありますか？ また、あなたのプログラムは依然としてADCモジュールのクロックとキャリブレーションクロックの分周器を変更していません。 以下は私のテスト結果です。 ポートを外部からGNDに接続しました。大きな違いは見て取れません。" 修正されたテストプロジェクトを教えていただけますか?私がMysideでテストします。 Re: Difference in ADC noise between BCTU Control Mode and Trigger Mode こんにちは@Stark_ そのようなデモは持っていません。添付ファイルは修正済みのプロジェクトです。 Re: Difference in ADC noise between BCTU Control Mode and Trigger Mode こんにちは@Stark_ はい、BCTUと通常の変換の両方で作業することは可能です。 ご提供いただいたプログラムをテストし、いくつか修正を加えました。あなたの外部クロックは25MHzですが、私の外部クロックは16MHzです。 また、あなたのプログラムは依然としてADCモジュールのクロックとキャリブレーションクロック分周器を変更していません。 以下は私のテスト結果です。 ポートを外部からVDDに接続しました(タイプミスでした)。大きな違いは見て取れません。 Senlent_0-1782359793819.png Senlent_1-1782359802334.png Re: Difference in ADC noise between BCTU Control Mode and Trigger Mode こんにちは、 @Senlentさん 修正済みのプロジェクトファイルを添付していただきありがとうございます。テストしてみましたが、私の環境では現在のところ通常のADC変換では動作しません。 しかし、実際のアプリケーションではシステムクロックが 25MHzです。私があなたのプロジェクトに加えた変更は、クロック周波数を16MHzから25MHzに更新したことだけです。 クロックを25MHzに変更し、Adc CTUモードを制御モードに設定した後、通常変換は機能しなくなりましたが、BCTU変換は引き続き機能します。 Adc CTUモードがトリガーモードの場合、通常変換とBCTU変換は引き続き機能します。 添付されたプロジェクトは、 25MHzでBCTUトリガーモードとノーマル変換の両方を同時にサポートする設計ですか?SO、この高い周波数で動作させるために、どんな追加のクロック分割器やプリスケーラー、またはサンプリング時間の設定を調整すればよいでしょうか? Re: Difference in ADC noise between BCTU Control Mode and Trigger Mode こんにちは@Stark_ 既にテスト結果をお見せしましたが、サンプリング結果の変動は全く正常な範囲内であることに気づかれたはずです。 Senlent_1-1782892390979.png Senlent_2-1782892398124.png 私の提案は、以前提案したようにサンプリング時間を延ばしてみるのも良いことです。 Senlent_0-1782892370211.png Re: Difference in ADC noise between BCTU Control Mode and Trigger Mode こんにちは、 @Senlentさん 変換はBCTUモードとノーマルモードの両方で駆動する必要があるため、ADCをトリガーモードを使用するように設定しました。しかし、トリガーモードを使用した場合、前述のようにBCTUを介して測定したADCデータにノイズが見られることに気づきました。 Re: Difference in ADC noise between BCTU Control Mode and Trigger Mode こんにちは@Stark_ ADC変換がBCTUを介して行われる場合は、BCTU制御モードを使用してください。 ADCが通常/注入変換またはその他のトリガーパスを受け入れるようにするには、トリガーモードを使用します。 BCTU制御モードでは、ADCの開始制御がBCTUのみに制限されます。トリガーモードでは、ADCは通常/注入およびその他のサポートされている変換トリガーに対して開放されます。 つまり、検査結果は期待通りです。

S32K3X8EVB-Q289搭載デバッガを使ってカスタムS32K358ターゲットをプログラムする方法 現在はS32K3X8EVB-Q289評価ボードを使用しており、S32K358 MCUを基にカスタムハードウェア設計を開発しました。 もう少し詳しく教えていただけますか: EVBの搭載デバッガを使って外部S32K358ターゲットのプログラミングやデバッグは公式にサポートされていますか? サポートされている場合、EVB上でどのようなジャンパー設定またはハードウェアの変更が必要ですか？ この目的にはどのデバッグコネクタを使用すべきですか？ S32デバッグプローブを使用する場合と比較して、何か制限事項はありますか？ この構成について説明したドキュメントやアプリケーションノートはありますか? ご支援ありがとうございます。 よろしくお願いいたします。 ヤシュ・グプタ Re: Using S32K3X8EVB-Q289 On-Board Debugger to Program a Custom S32K358 Target こんにちは、 @Yash2530 さん。 1. はい、S32K3X8EVB-Q289搭載デバッガを使って外部S32K358ターゲットのプログラミング/デバッグが可能です。実際、EVBの搭載OpenSDAデバッガはP&E Microが開発したブートローダー/デバッグアプリケーションを使用しています - https://community.nxp.com/t5/S32-Design-Studio/Which-debugging-interface-is-better/m-p/1715877 2. この用途ではEVBのはんだ付けの再作業やジャンパー設定は不要です。 3. J55 USBホストコネクタ。 4. 実際には、標準的なフラッシュおよび外部S32K358ターゲットのソースレベルのデバッグには、EVBの搭載デバッガで十分であるべきです。あなたにとってどの機能が重要なのか分からないので、ご自身で機能を比較してみてください。 https://www.nxp.com/design/design-center/software/automotive-software-and-tools/s32-design-studio-ide/s32-debugger-for-s32-platform:S32DBG-S32PLATFORM https://www.pemicro.com/products/product_viewDetails.cfm?product_id=15320180&productTab=5045 5. はい、 https://www.nxp.com/webapp/Download? colCode=S32K3X8EVB-Q289HWUM よろしくお願いいたします。 パベル

M7コアのSGMIIでPFE_MACを設定する方法 こんにちは、NXPさん。 イーサネット・スイッチのPFE_MACとポート間でSGMIIリンクを確立したいと考えています。 M7コア用のSGMIIにおけるPFE_MACの設定例はありますか？ ご協力ありがとうございます。 Re: How to configure PFE_MAC in SGMII for the M7 core こんにちは、 @77373 投稿ありがとうございます。 はい、PFE MCALパッケージには存在します。対応する例を確認し、NXPアカウントからダウンロードするか、以下のリンクからアクセスできます。 https://www.nxp.com/app-autopackagemgr/automotive-software-package-manager:AUTO-SW-PACKAGE-MANAGER chenyin_h_0-1782125278279.png BR チェイン

FS26 Amuxのセンシング問題 BATセンス電圧をAMUXピンに送った後、 AMUXピンの電圧を測定しようとしています。関連するレジスタ値をすべて確認したところ、 FS_STATESレジスタはデバイスがノーマルモードであることを示しています。しかし、AMUXピンは引き続き0Vを出力し、12ビットADCは常に0の値を読み取っています。添付したコードでは、 S32K3xxのリファレンスサンプルを参考にしましたが、AMUXの測定が期待どおりに機能していません。どうか、こちらをご確認ください。 Re: FS26 Amux sensing issue こんにちは、 コードと詳細情報を共有していただきありがとうございます。以下の点をご確認いただけますか: - 書き込み後にM_AMUX_CTRLレジスタを読み戻し、AMUX_EN = 1およびAMUX[4:0] = 0x16（BATSENSEが選択されている）であることを確認します。 - また、SPI応答がM_AVAL = 1を示していることを確認してください。これは、メインステートマシンが通常モードであることを意味します。 ハードウェア面では、BATSENSEピンに期待される電圧が供給されていること、およびAMUXピンがADC入力に正しく接続されていることを確認してください。   BRs、トーマス Re: FS26 Amux sensing issue こんにちは、 読み戻し結果から、AMUXは正しく設定されていることが確認されましたが、デバイスはINIT_FSで停止しています。 この問題を解決するには、 AN13850 （NDAを必要とするセキュアファイル）のセクション6.1および6.2に記載されている初期化およびウォッチドッグシーケンスに従ってください。 電源投入後またはリセット後、セクション6.1で説明されているように、必要なFS_I_xxxレジスタとFS_I_NOT_xxxレジスタをすべて設定します。 初期化フェーズを終了するために、256msのINIT_FSウィンドウ内で適切なウォッチドッグ更新を実行してください。 セーフティ出力が解除されると、デバイスはノーマルモードに入り、AMUX測定は期待通りに動作するはずです。 BRs、トーマス Re: FS26 Amux sensing issue M_AMUX_CTRLレジスタはM_AMUX_EN | M_AMUX_BATSENSE | M_AMUX_DIV_0に設定され、読み出しによって0x56であることが確認されました。これにより、アナログ多重化器がアクティブで、12V BATSENSE入力を正しくルーティングしていることが確認されます。   しかし、SPIデバイスの状態（u8DeviceStatus）は0xCAとして読み取られます。最上位ビットがセットされているため (sbc_fs26_RxFrameType.u8DeviceStatus & 0x80 == 1)、グローバルなフェイルセーフ障害がアクティブになっています。さらに、FS_STATESレジスタが11を返すことから、デバイスがINIT_FS（初期化フェイルセーフ）状態から抜け出せないことが証明されます。 Re: FS26 Amux sensing issue ごサポートありがとうございます。 私のAMUXは正しく有効になっていなかったため、選択した電圧がAMUXピンにルーティングされませんでした。ご提供いただいたINITシーケンスのおかげで問題が解決しました。感謝いたします。ウォッチドッグ周期を256に設定したところ、デバイスは期待どおり正常状態を維持するようになりました。

KW47 NBUのプログラミングとアップグレード こんにちは： KW47 NBUのプログラミングやアップグレード方法を知りたいです。手順がもっと詳しく説明できることを願っています。 ご回答をお待ちしています。 Re: KW47 NBU programming and upgrade こんにちは： サポートありがとうございます。ご提供いただいた方法でNBUのファームウェアを更新できるようになりました。 ご提供の方法には、ファームウェア経由でNBUをアップデートする方法が含まれていないようですね? 例えば、私のデバイスがマーケットに出てNBUバージョンをアップデートする必要がある場合、どうすればよいでしょうか? ご回答をお待ちしています。 Re: KW47 NBU programming and upgrade こんにちは、お元気でお過ごしでしょうか。 KW45からKW47への移行ガイドAN14796 6.2節「KW47にNBUファームウェアをロードする」を参照してください。 このドキュメントでは、KB47のNBUを更新するためのいくつかの方法(手順はKW47-EVKを用いて示されています)を紹介しており、blhost、Secure Provisioning Tool、LinkServerなど、開発に最適な方法を自由に選択できます。各方法の詳細手順も含まれています。 お役に立てば幸いです！他に質問があれば、遠慮なくお尋ねください。 よろしくお願いします、 アナ・ソフィア。 Re: KW47 NBU programming and upgrade こんにちは、 ROMブートローダーには、メインフラッシュおよびラジオフラッシュのファームウェアの更新に使用できるファームウェア更新機能があります。 現場でのNBUアップデートのワークフローは通常次の順序に従います。アプリケーションはアップデートイメージを保存し、対応するメタデータをUser IFR0 OTACFG領域に書き込み、その後システムリセットをトリガーしてROMブートローダーが引き継ぎ、無線ファームウェアの更新を行います。 詳細は KW47セキュリティリファレンスマニュアル の4.2.6「ファームウェア更新機能」および4.2.2.3のオーバーエア(OTA)アップデート構成のセクションで確認できます。 よろしくお願いします、 アナ・ソフィア。

ARM 2018R1 IDE用のS32DSライセンスは期限切れです 私のArm 2018R1 IDEs 用のS32DSライセンス が 期限切れです。チェックや延長を手伝ってもらえますか? ソフトウェアのライセンスを確認しましたが、このバージョンは自分で拡張できません(ARM2.2は拡張可能です)。 hornik7_0-1782126764353.png 事前に感謝いたします。 アクティベーション | インストール | ライセンス | インストーラーのダウンロード Re: License of S32DS for ARM 2018R1 IDE has expired Ahoj Matúši、 お客様のS32DSライセンスが延長されました。以前使用していたコードを使って、S32DSを再度有効化してください。

关于 RDBESS774A3EVB 的咨询 - 由于连接器（J1_1 和 J1_3）互换导致的板损坏 您好， 我目前正在评估RDBESS774A3EVB电池监控单元 (CMU) 板（采用 MC33774A 电池单元控制器），该板连接到 50 节电池组设置。 最近，我们在测试过程中发生了一起意外的连接错误。我们错误地将J1_1 （上部）和J1_3 （下部）之间的电池连接器组互换了。 事件发生期间观察到以下行为： 初始事件：连接器互换后，第 36 单元立即发生严重短路，导致外部电线/线路烧毁断裂。 后续措施：发现错误后，我们使用正确的连接器位置将电池组重新连接到同一块电路板上。 次要行为：一旦建立了正确的连接，板上的多个平衡电阻器（R_balance）就开始过热并烧毁。 基于以上情况，我们非常希望您能就以下问题提供工程方面的见解： Q1：在第一次事件中，J1_1 和 J1_3 之间的初始连接器互换是否对 MC33774A IC 或相关电路造成了灾难性的内部损坏？ Q2：假设在第二次（正确的）连接期间多个平衡电阻烧毁是由于第一次事故造成的 MC33774A IC 内部损坏（例如，内部 FET 击穿或栅极驱动器卡在导通状态）的直接结果，这种假设是否正确？ Q3：如果我们更换损坏的MC33774A IC和所有烧毁的平衡电阻，RDBESS774A3EVB板能否恢复到完全功能和安全的工作状态？除了主集成电路之外，是否还有其他重要的配套组件（例如静电放电/齐纳保护二极管或隔离电路元件）需要检查或更换？ Re: Inquiry regarding RDBESS774A3EVB - Board Damage due to Swapped Connectors (J1_1 and J1_3) 嗨@guoweisun ， 我们没有将整个 50 节电池组连接到一个连接器上。相反，我们的 50 单元系统分为三个独立的部分，并配有三个不同的单元连接器。 1 Initial Event ERROR: CONNECTOR SWAP1 Initial Event ERROR: CONNECTOR SWAP1 Initial Event ERROR: CONNECTOR SWAP1 Initial Event ERROR: CONNECTOR SWAP1 Initial Event ERROR: CONNECTOR SWAP1 初始事件错误：连接器交换 2 Subsequent Action: NORMAL CONNECTION2 Subsequent Action: NORMAL CONNECTION2 Subsequent Action: NORMAL CONNECTION2 Subsequent Action: NORMAL CONNECTION2 Subsequent Action: NORMAL CONNECTION2 后续操作：正常连接 Re: Inquiry regarding RDBESS774A3EVB - Board Damage due to Swapped Connectors (J1_1 and J1_3) guoweisun_0-1782106495796.png 你是说你把50*3.6V加错了吗？MC33774 第一部分中 C17 到地之间的电压是多少？ Re: Inquiry regarding RDBESS774A3EVB - Board Damage due to Swapped Connectors (J1_1 and J1_3) 嗨@guoweisun ， 为了确保硬件的功能安全并防止任何潜在的接线问题，我们设计了一个中间“CSU 桥接板” ，将我们的 50S 电池组连接到 RDBESS774A3EVB（采用菊花链连接三个 MC33774A AFE）。 请您查看我们附上的原理图（ CSUBridge_Connector.png和CSUBridge_Block Diagram.png ），并确认我们的引脚映射和连接方式是否正确？ CSUBridge_Block Diagram.png CSUBridge_Connector.png   Re: Inquiry regarding RDBESS774A3EVB - Board Damage due to Swapped Connectors (J1_1 and J1_3) 似乎没有发现其他问题，但请注意 GDN1 GND2 GND3 的位置。 Re: Inquiry regarding RDBESS774A3EVB - Board Damage due to Swapped Connectors (J1_1 and J1_3) 感谢您一直以来的支持。首先，我们想澄清一下我们实际硬件配置中的 AFE 堆叠顺序，以确保我们保持一致： AFE1 (J1_1)指定用于高压级（单元 37–50）。 AFE3 (J1_3)指定用于低电压级（单元 1–18）。 我们附上了一张图片，其中记录了我们最近的发现以及我们目前面临的关键问题。 我们希望您能就之前提出的关于第一次事件的问题，以及新董事会提出的新问题，给出明确的答复： 【第一部分：对第一次板的回顾性问题】 Q1：在第一次事件中，J1_1 和 J1_3 之间的初始连接器互换是否对 MC33774A IC 或相关电路造成了灾难性的内部损坏？ Q2：假设在第二次（更正后的）连接过程中多个平衡电阻烧毁是由于第一次事故造成的 MC33774A IC 内部损坏（例如，内部 FET 击穿或栅极驱动器卡在导通状态）的直接结果，这种假设是否正确？ Q3：如果我们更换损坏的MC33774A IC和所有烧毁的平衡电阻，RDBESS774A3EVB板能否恢复到完全功能和安全的工作状态？除了主集成电路之外，是否还有其他重要的配套组件（例如静电放电/齐纳保护二极管或隔离电路元件）需要检查或更换？ 【第二部分：新董事会带来的新问题】 按照上述正确的堆叠顺序（高压端接 AFE1/J1_1，低压端接 AFE3/J1_3），我们尝试使用全新的 RDBESS774A3EVB 板来测试我们的系统。 然而，一接上电源，就立即冒烟，高压段（37-50 节电池/AFE1）上的平衡 IC（MC33774A）再次损坏。 鉴于连接映射完全按照预期进行（高对高，低对低），请问您能否帮助我们分析一下为什么新板在 AFE1 阶段立即失效？ cmu_connection_normal.png Re: Inquiry regarding RDBESS774A3EVB - Board Damage due to Swapped Connectors (J1_1 and J1_3) 嗨@guoweisun ， 我们目前遇到一个严重的问题，即在多个电池组依次连接时，均衡IC会损坏。 根据当地 NXP 技术建议，对于我们第 1 组部分（监控 14 个电池单元）上未使用的通道，我们已将未使用的引脚直接连接到平衡 IC 输入端，具体如下： CB15-18 与 CB14 短路 CT15-18 与 CT14 连接短路 以下是我们的测试流程详情及相应结果： 测试 1：单组连接（仅限组 1） 步骤：我们只连接了第 1 组，该组对应于最高电位段：电池 37 至电池 50（共 14 个电池，总电压约为 100 伏）。50V）。 结果：板运行正常。我们能够准确读取所有电池的电压。VBAT_1 相对于 GND_1 的测量电压稳定在约 50V。未发现异常情况。 测试 2：完整的 3 组连接（顺序上电） 步骤：我们将所有 3 个细胞组同时连接起来，但严格按照从下到上的插入顺序，从第 3 组（底部细胞）开始，一直到第 1 组（顶部细胞）。 结果：连接完成后，电阻 R1_1（10 欧姆）附近出现烟雾和可见的烧焦痕迹。我们立即切断电源以防止进一步损坏，并检查了电路板。 事后分析及损害分析： VBAT_1 至 GND_1 短路：电气测试显示 VBAT_1 和 GND_1 之间存在短路。由于这条电源线直接连接到平衡集成电路，我们怀疑是内部硅芯片故障。 电阻器 R1_1：发现 10 欧姆电阻器已烧毁开路（开路）。 CT 和 CB 引脚：检查了 CT 和 CB 引脚；未发现这些引脚有任何物理或电气损坏。 平衡电阻：检查了所有外部电池平衡电阻；所有电阻均完好无损。 IC 根本原因验证：我们从 PCB 上拆焊了平衡 IC，以隔离问题。对未安装的集成电路进行测试，证实 VBAT 和 GND 引脚之间存在永久性内部短路。 向恩智浦技术支持提出的问题： 鉴于单独给第 1 组供电时配置工作完美，当所有三组依次（从下到上）插入时，什么会触发平衡 IC 内部的 VBAT 到 GND 故障？ 将未使用的引脚短接（CB15-18 到 CB14，以及 CT15-18 到 CT14）的终端方法是否会在多芯片菊花链热插拔过程中引起意外的瞬态或闩锁情况？ 为了缓解这种故障模式，我们需要实施哪些具体的热插拔保护、TVS 调整或上电顺序限制？ 请帮助我们分析并提出解决此问题的建议。 CMU_1st_group_damage.jpg

批量打印NFC卡的建议 大家好，NFC社区！ 我想批量订购[10-200张，以后可能会更多] 4A型NFC卡[标准信用卡大小]，卡片上需要定制印刷。卡片和印刷质量都必须很高。我还需要快速运送到加拿大。 请问大家有没有可以推荐的做这类业务的公司/供应商？我希望与一个优秀的团队建立长期的合作关系。 非常感谢您！ Re: Advice for bulk printing NFC cards 你好@isenki ， 希望你一切都好。 如需标签/卡片供应信息，请参阅NTAG 424 DNA产品页面，点击“设计资源 > 工程服务”部分。您可以在这里找到标签和读卡器制造商、解决方案提供商和系统集成商的联系方式。如需查找支持此产品的其他合作伙伴，请访问我们的合作伙伴市场。 问候， 爱德华多。

FRDM-A-S32K344で一括消去を無効にする方法 FRDM-A-S32K344向けに2つのアプリケーションを作成しました。1つのアプリケーションはアドレス0x00400000に、もう1つはアドレス0x00500000にあります。 オンボードデバッガで1つのアプリケーションをフラッシュすると、一括消去が行われ、もう1つのアプリケーションも削除されます。 大量消去を無効にして、デバッガーをプログラミング中に特定のフラッシュ領域やセクションだけ消去するように設定するにはどうすればいいですか? ganavi1_0-1782105971120.png Re: How to Disable Mass Erase on the FRDM-A-S32K344 こんにちは、 なるほど、両方のバイナリを同時に正常に読み込めるということですね。 しかし、ブートローダーを使用する予定だとはおっしゃっていませんでしたね。 あなたが本当に欲しいもの リセット → ブートローダー実行 → SW2を待機 → アプリへジャンプ   S32DSでLaunch Groupを使うと、各デバッグ構成はELFを読み込み、最後の設定が現在のPCを決定します。したがって、アプリケーションのエントリポイントがブートローダーを上書きし、スキップします。 ブートローダーが正しく実行されるようにするには、両方のイメージをロードするものの、ブートローダーのリセットベクタから実行を開始する単一のデバッグ構成を使用してください。また、起動コードのスキップを避けるため、「メイン関数へ実行」を無効にしてください。 実際のリセット後、S32K3は必ず事前に定義されたブートアドレス(内部フラッシュ0x00400000)から実行を開始し、最初の有効なイメージ(通常はブートローダー)が実行されます。 しかし、S32DSでのデバッグ時には、この動作がデバッガによって上書きされ、ELFファイルを読み込んだ後にプログラムカウンターをアプリケーションのエントリポイントに設定することで、ブートローダーを実質的にバイパスできます。 よろしくお願いいたします。 ピーター Re: How to Disable Mass Erase on the FRDM-A-S32K344 こんにちは、 ご提案ありがとうございます。 Launch グループを作成し、Bootloaderとアプリケーション ELFのデバッグ設定の両方を追加しました。しかし、デバッグセッションを始めると、アプリケーションコードだけが実行され、ブートローダーの実行がバイパスされているように見えます。私の要件は、ブートローダーがリセット後に最初に実行され、その後SW2が押されたときにのみアプリケーションにジャンプすることです。 ブートローダーがアプリケーションより先に動作するようにするために、追加のLaunch Group設定やデバッガ設定が必要かどうか教えていただけますか? 私はFRDM-A-S32K344の搭載デバッガを使っています ganavi1_0-1782121473794.png Re: How to Disable Mass Erase on the FRDM-A-S32K344 こんにちは、 Debug Configurationsでは、Launch Groupを作成し、読み込みたいすべてのELFファイルを追加するだけです。これにより、複数の画像を読み込むことができます（例：ブートローダー+アプリケーション)を一気に使うことができます。 よろしくお願いいたします。 ピーター Re: How to Disable Mass Erase on the FRDM-A-S32K344 Hello S32DSを両方のELFファイルが読み込まれているけれど、PCがアプリケーションのエントリポイントではなくブートローダー Reset_Handler 0x00400000に設定されるように設定する方法を説明してもらえますか? Re: How to Disable Mass Erase on the FRDM-A-S32K344 こんにちは、 デバッグセッション中にメモリブラウザで、0x00400000のメモリ空間が空(PE Microによって消去されている)か、それとも書き込み済みのエントリポイントだけがあるか確認してもらえますか? 複数の.elfこれらのファイルは通常、マルチコアMCUで使用されます。シングルコアだと少し難しいかもしれません。有効な方法の1つは、2つのデバッグセッションを用意することです。最初のセッションでは、ブートローダーの.elfファイルを使用します。ファイルとアプリ用の2つ目のファイルがありますが、どちらのメモリ領域を保持するかを定義する必要があります。PE Microは常に一括消去を実行します。保存メモリは、保存メモリ領域からデータを読み取り、一括消去を実行し、保存データを書き戻し、2番目の.elfからデータを書き込みます。ファイル。 別の方法としては、s-record ツール ( https://srecord.sourceforge.net/ ) を使用する方法もあります。) 、両方の .elf からこのツールでファイルを作成し、両方のsレコードをマージして、マージされた.srecを使用します。.elf の代わりに。.elfは使えますデバッグ用ファイルとシンボル。

关于 i.MX8Mplus 的有限状态机 (FSM) 我们公司使用的是 Toradex 的 Veridin i.MX8Mplus。 此时，输入 SOM_PW_ON 信号以控制 SoM 的电源。（直接连接到 i.mx8MPlusSoC 的 ON/OFF 信号）。*请参考所附示波器上的波形。 V1-1B_tool0_OFF.pngV1-1B_tool0_OFF.pngV1-1B_tool0_OFF.pngV1-1B_tool0_OFF.pngV1-1B_tool0_OFF.png   由于 SoM 侧的电路配置，电压应为高电压 (1.8V)，但在启动后约 800 毫秒内，电压保持在约 0.3-0.4V 的中间电位。 我想知道 SoC 端是如何处理 0.3 至 0.4V 电压作为 ON/OFF 信号的。 该信息未包含在数据表或参考手册中。 我认为，在极短的开/关操作（<5秒）的情况下，系统可能会关机。操作检测标准是否应该是从高电平到低电平的转换以及低电平状态的持续时间？ 我还想知道这些时间段的具体最短/最长时间。 i.MX 8M | i.MX 8M Mini | i.MX 8M Nano Re: i.MX8MplusのFinite-State Machine (FSM)について 对于 i.MX8M Plus，ONOFF 被处理成一个按住按钮输入，可配置 0/50/100/500 毫秒的延迟和 5/10/15 秒的强制关机时间，并且观察到 0.3–0.4根据现有的输入阈值文档，1.8V ONOFF 网络上的 V 最常被解释为逻辑低电平。 Re: i.MX8MplusのFinite-State Machine (FSM)について 感谢你的回复。 根据现有的输入阈值文档，观察到的 ONOFF 网络上的 V 值在 0.3–0.41.8V 范围内最一致地被解释为逻辑上的低值。 顺便问一下，您能否也告诉我一下逻辑上被解释为低电压的阈值是多少？ 此外，如果解释为逻辑低，则 ON/OFF 状态在启动后将保持逻辑低约 800 毫秒，然后变为逻辑高。 在这种情况下，是否可以认为发生了按钮输入？ 我担心按下按钮是否会导致系统在启动后立即自动关机。 Re: i.MX8MplusのFinite-State Machine (FSM)について 顺便问一下，您能否也告诉我一下逻辑上被解释为低电压的阈值是多少？ 抱歉。我想知道逻辑值被解读时的电压阈值。 Re: i.MX8MplusのFinite-State Machine (FSM)について 感谢你的回复。 根据现有的输入阈值文档，观察到的 ONOFF 网络上的 V 值在 0.3–0.41.8V 范围内最一致地被解释为逻辑上的低值。 顺便问一下，您能否也告诉我一下被解释为逻辑高电平的电压阈值是多少？ 此外，如果解释为逻辑低，则 ON/OFF 状态在启动后将保持逻辑低约 800 毫秒，然后变为逻辑高。 在这种情况下，是否可以认为发生了按钮输入？ 我担心按下按钮是否会导致系统在启动后立即自动关机。 致恩智浦技术支持代表 你对此事有何看法？ 我还有一个问题： ON/OFF 被处理为电平保持按钮输入，条件为 0/50/100/500 毫秒。 关于这一点，我认为默认值是 0。在这种情况下，如果由于噪声或其他因素导致电平瞬间超过逻辑高电平或逻辑低电平阈值，电平是否会被保持？ 我担心，在这种默认设置下，如果接收到噪声，即使只是一瞬间，如果引入了导致逻辑判断与当前保持的逻辑电平相反的因素，也可能导致故障。 Re: i.MX8MplusのFinite-State Machine (FSM)について @Rita_Wang 我又补充了一些问题。 给您带来的不便，我们深表歉意，请您尽快回复。 Re: i.MX8MplusのFinite-State Machine (FSM)について @Rita_Wang 确认流程进展如何？ 请提供答案。 Re: i.MX8MplusのFinite-State Machine (FSM)について 很抱歉错过了您的消息，我可以帮忙查看，下周会回复您。 祝你今天过得愉快 Re: i.MX8MplusのFinite-State Machine (FSM)について @Rita_Wang 谢谢你的帮助。 这是Pal Giken的Mori。 已经过去快一周了，反响如何？ 感谢您的合作。 Re: i.MX8MplusのFinite-State Machine (FSM)について @毛利修二 对于 i.MX8MP，ONOFF 引脚属于 NVCC_SNVS 电源组，并被列为复位状态为“带 PU 的输入”的 GPIO 类型输入。适用的 GPIO 直流输入低电平规格为： VIL(最大值)=0.3× VDD V I L( 最大值) = 0.3 × V D D 表格中将低电平输入电压的最小值设定为 -0.3V,max = 0.3 × VDD。 因此，如果 ONOFF 由 1.8 V SNVS I/O 功能域供电，则保证的逻辑低电平阈值为： 0.3×1.8 V=0.54 V 0.3 × 1.8 V = 0.54 V 因此，观察到的ONOFF电压约为0.3–0.4V 将被解释为逻辑低。 关于这是否会被视为按钮输入：是的，如果设备处于 ON 模式后 ONOFF 引脚保持低电平足够长的时间，则可以将其视为有效的 ONOFF 按钮事件。 持续 800 毫秒的低电平信号可被识别为正常的 ONOFF 按钮事件。 因为它超过了配置的正常按钮防抖持续时间。 它不应直接触发硬件紧急强制关机。 因为那需要大约 5秒 。 系统启动后是否立即关闭取决于软件/PMIC对正常ONOFF事件的处理。在 ON 模式下，短暂连接到 GND 会产生一个中断，旨在启动软件可控的断电。如果启动软件或操作系统电源键处理程序将该中断视为关机请求，则启动后可能会发生意外关机。 Re: i.MX8MplusのFinite-State Machine (FSM)について @Rita_Wang 感谢你的回复。 我提出这个问题想问的是： 问题是，在启动过程中，当ONOFF 引脚处于逻辑低状态时，按钮输入是否能被识别。 我们的验证 观察到的一种现象是，当 ONOFF 引脚以逻辑高电平开始，然后在 10 毫秒到 20 毫秒后变为逻辑低电平时，系统会在启动后立即关闭。 当系统以逻辑低电平启动时，尚未观察到系统启动后立即关机的情况。 Re: i.MX8MplusのFinite-State Machine (FSM)について @Rita_Wang 请回答我提出的问题。 Re: i.MX8MplusのFinite-State Machine (FSM)について @Rita_Wang 给您带来不便，敬请谅解，请问您能否也回答一下这个问题？ Re: i.MX8MplusのFinite-State Machine (FSM)について @Rita_Wang 问题是，在启动过程中，当ONOFF 引脚处于逻辑低状态时，按钮输入是否能被识别。 你对此有何看法？

如何在 Kinetis 系列产品上使用 HCI_bb 并访问 DTM 模式 本文分为两部分： 第 1 部分：如何将 HCI_bb 二进制文件刷入 Kinetis 产品（这里以 KW38 为例）。 第二部分：使用 R&S CMW270 进行射频测量 附件共 2 个文件： - bci_black_box.bin（zip 文件） - mbed_WinSerial.exe（zip 文件） 第 1 部分：如何将 HCI_bb 二进制文件刷入 Kinetis 产品（这里以 KW38 为例）。 HCI_bb 应用程序示例位于以下 SDK 文件夹中： christophe_menard_0-1620204656370.png 使用 USB 线缆将 FRDM-KW38 板连接到您的 PC。 FRDM-KW38 板将被识别为硬盘。磁盘 😧 在这个例子中。 选择 hci_black_box_frdmkw38.bin 文件，然后将此文件拖放到 FRDM-KW38 (D:) 目录下。 christophe_menard_1-1620204656478.png 当电量达到 100% 时，KW38 会闪烁。 christophe_menard_2-1620204656494.png FRDM-KW38 板已准备好与 DTM 模式一起使用。 第二部分：使用 R&S CMW270 进行射频测量 FRDM-KW38 板可以通过 USB 电缆连接到 R&S CMW270。 hci_bb 将 KW38 设置为 DTM 模式。 CMW270 可以通过发送 DTM 命令进行通信。 注意：您需要在 CMW270 中安装 mbedWinSerial 驱动程序（本文附件中），才能检测到 FRDM-KW38 板。 Re: How to use the HCI_bb on Kinetis family products and get access to the DTM mode 我正在尝试在 KW36（专用应用硬件，而非开发板）上进行 DTM 测试，您能否帮忙或分享整个流程以及执行此测试所需的固件和工具列表？

EdgeLock SE051:OpenSSL プロバイダを読み込んだ後にSCP03エラーでse05x_Minimal失敗 こんにちは、 Linux上でEdgeLock SE051とSCP03を使ってOpenSSL プロバイダを使おうとしています。se05x_Minimal例が最初は完璧に動作するのに、OpenSSL プロバイダの共有ライブラリをインストールし た後に SCP03認証エラーで失敗するという問題に直面しました。 この対立の原因についてアドバイスをいただけますか? 環境: 基板： MCIMX8M-WEVKおよびOM-SE051ARD SoC: i.MX 8M Linuxバージョン: 6.1.151-cip46 OpenSSLバージョン： 3.0.20 Plug & Trust MW バージョン: 04.07.01 講じた措置： 以下のCMake構成を使用して、Plug & Trust MWをビルドしました。 cmake ../simw-top \ -DPTMW_Applet=SE05X_C \ -DPTMW_SE05X_Ver=07_02 \ -DPTMW_Host=iMXLinux \ -DPTMW_SMCOM=T1oI2C \ -DPTMW_HostCrypto=OPENSSL \ -DPTMW_RTOS=Default \ -DPTMW_mbedTLS_ALT=None \ -DPTMW_SCP=SCP03_SSS \ -DPTMW_FIPS=None \ -DPTMW_SBL=None \ -DPTMW_SE05X_Auth=PlatfSCP03 \ -DPTMW_Log=Default \ -DCMAKE_BUILD_TYPE=Release \ -DPTMW_SE_RESET_LOGIC=1 Plug & Trust MWディレクトリから i.MX 8Mの/rootにsimw-top/demos/linux/common/openssl30_sss_se050.cnfをコピーしました。 設定環境変数をエクスポートしました。 export OPENSSL_CONF=/root/openssl30_sss_se050.cnf SE051とSCP03が正しく動作することを確認するため、se05x_Minimalを実行しました。それは成功した。 App :INFO :Running bin/se05x_Minimal App :INFO :If you want to over-ride the selection, use ENV=EX_SSS_BOOT_SSS_PORT or pass in command line arguments. App :INFO :PlugAndTrust_v04.07.01_20250519 App :INFO :Using default PlatfSCP03 keys. You can use keys from file using ENV=EX_SSS_BOOT_SCP03_PATH sss :INFO :atr (Len=35) (snip) App :INFO :mem=17196 App :INFO :se05x_Minimal Example Success !!!... App :INFO :ex_sss Finished libsssapisw.so 写した。libsss_pkcs11.so、そして/usr/local/lib/に libsssProvider.so。（注：/usr/local/lib/ は、/root/openssl30_sss_se050.cnf の [nxp_prov_sec] セクションで指定されているパスです。） se05x_Minimalを再度実行しました。今回は、以下のエラーが発生して失敗しました。 エラー出力: App :INFO :Running bin/se05x_Minimal App :INFO :If you want to over-ride the selection, use ENV=EX_SSS_BOOT_SSS_PORT or pass in command line arguments. App :INFO :PlugAndTrust_v04.07.01_20250519 App :INFO :Using default PlatfSCP03 keys. You can use keys from file using ENV=EX_SSS_BOOT_SCP03_PATH sss :INFO :atr (Len=35) (snip) App :INFO :If you want to over-ride the selection, use ENV=EX_SSS_BOOT_SSS_PORT or pass in command line arguments. App :INFO :Using default PlatfSCP03 keys. You can use keys from file using ENV=EX_SSS_BOOT_SCP03_PATH sss :INFO :atr (Len=35) (snip) sss :ERROR:Error in RAND_pseudo_bytes scp :WARN :nxEnsure:'status == kStatus_SSS_Success' failed. At Line:121 Function:nxScp03_AuthenticateChannel sss :ERROR:Could not set SCP03 Secure Channel App :ERROR:sss_session_open failed App :WARN :nxEnsure:'kStatus_SSS_Success == status' failed. At Line:240 Function:OSSL_provider_init smCom :ERROR:phNxpEseProto7816_DecodeFrame Max retry count reached!!! smCom :ERROR:phNxpEseProto7816_Transceive Transceive failed, hard reset to proceed smCom :ERROR: phNxpEse_Transceive phNxpEseProto7816_Transceive- Failed smCom :ERROR: Transcive Failed sss :WARN :nxEnsure:'retStatus == SM_OK' failed. At Line:7977 Function:sss_se05x_channel_txn sss :WARN :nxEnsure:'ret == SM_OK' failed. At Line:7839 Function:sss_se05x_TXn sss :WARN :APDU Transaction Error: Error (0xFFFF) scp :ERROR:GP_InitializeUpdate Failure on communication Link FFFF scp :ERROR:nxScp03_GP_InitializeUpdate fails with Status 3C3C0000 sss :ERROR:Could not set SCP03 Secure Channel App :ERROR:sss_session_open failed App :ERROR:ex_sss_session_open Failed App :ERROR:!ERROR! ret != 0. OpenSSLプロバイダーが設定によって正常にロードされると、(おそらくRAND_pseudo_bytesに関連する)何かがSCP03チャネルの確立を壊すようです。 同様の現象に遭遇した方、または他にどのような設定が不足しているかご存知の方はいらっしゃいますか？ ご協力ありがとうございます。 Re: EdgeLock SE051: se05x_Minimal fails with SCP03 errors after loading OpenSSL Provider こんにちは、 @Uc_S さん。 適切なバージョンのopensslを設定しましたか？以下のオプションをご利用ください。 -DPTMW_OpenSSL=3_0 ちなみに、テスト目的で、より詳細なデバッグ情報を取得するために、詳細ログを有効にしてください。 -DPTMW_Log=詳細 すてきな一日を、 カン ------------------------------------------------------------------------------- 注記： この投稿があなたの質問への回答になっている場合は、「正解としてマーク」ボタンをクリックしてください。ありがとうございます! - 前回の投稿から7週間Threadをフォローしており、その後の返信は無視しています もし後で関連する質問があれば、新しいThreadを開き、閉じたThreadを参照してください。 ------------------------------------------------------------------------------- Re: EdgeLock SE051: se05x_Minimal fails with SCP03 errors after loading OpenSSL Provider アドバイスをいただき、本当にありがとうございました。あなたの言う通りでした。 問題の根本原因は、CMakeの設定ファイルに「-DPTMW_OpenSSL=3_0」オプションが欠落していたことでした。 「-DPTMW_OpenSSL=3_0 -DPTMW_Log=Verbose 」を追加してMWを再構築したところ、問題は完全に解決しました。結果は以下のとおりです。 ステップ6を実行しても、エラーは発生しなくなりました。期待どおりに「App :INFO :mem=17196」が出力されます。 また、ログレベルを元の設定(「-DPTMW_Log=Default」に設定しても、アプリケーションは完璧に動作し、「App :INFO :mem=17196」を出力することも確認しました。 このトピックは解決したとマークします。

MU経由でHSEファームウェアをインストールする際にS32K3の復旧に問題が発生する 現在、`S32K3_HSE_DemoExamples`に含まれる`S32K344_Advanced_SecureBoot`デモを基に、HSEを使用してS32K344/S32K314上でセキュアブート機能を開発しています。機能開発のほとんどは完了しており、デバッグも無事に進めています。私たちの設定プログラムでは、ED25519を使ってBM、FBL、APPの署名を計算し、指定されたアドレスにフラッシュで書き込み、これら3つのアプリケーション(BMは起動前のSMR、FBLとAPPは起動後のSMR)ごとにSMRとCRを設定しています。しかしながら、いくつか不明瞭な点があり、皆様のご協力をいただければ幸いです。現在、HSEのFULL_MEM形式を使用しています。 すべてのアプリケーションバイナリの署名を計算するためにED25519アルゴリズムを使用しているため、設定プログラムの実行に時間がかかります。プログラムが終了する前に予期せず停電が発生した場合、HSEは回復不能なエラー状態に陥ることがわかっています。電源の再投入やファームウェアの再フラッシュを行っても、HSEはホストからの要求に一切応答しなくなった。レジスタ `0x4039C028` (HSE_CONFIG_GPR3) を確認すると、値が `0xC0` であることがわかります。ビット 0 が `0` になっていることから、HSE ファームウェアが SBAF によって消去された可能性があることがわかります。電源投入後、MU0 FSRレジスタも「0」になります。そこで、HSEファームウェアの再インストールを試みました。通常のIVTベースのインストール方法はもはや機能しないため、MUインターフェース経由で設置を試みました。 ドキュメントで説明された手順をシミュレートしましたが、ピンクイメージのSRAMアドレスをMU Txレジスタに書き込む(ステップ5)すると、HSE_CONFIG_GPR3の値がすぐに「0xC2」から「0xC0」へと変化し、ビット1が「1」から「0」に変わり、期待される成功応答「0xDACACADA」は一切受け取れないことがわかりました。 また、フォーラムでも同様の問題について言及しました： S32K3_HSEのMUインストールAB_SWAPプロセスが正しくありません。ステップ5の直後に機能的なリセットを試みましたが、リセット後も新しいHSEファームウェアはインストールできませんでした。 このような腐敗したHSE状態をどのように扱い、回復すればよいかアドバイスいただけますか? 何か調整が必要な場合はお知らせください。 Re: S32K3 recovery issue when install HSE fw via MU こんにちは@chengjinwang あなたが共有してくれたプロジェクトのソースファイルは暗号化されているため、読み取ることができません。暗号化されていないプレーンファイルを含むバージョンを提供してください。 数日前に、MUインターフェース経由でHSE AB_SWAPファームウェアを復元するTrace32スクリプトを作成し、すぐにFULL_MEMバージョン用に修正しました。私の環境では正常に動作しており、0xDACACADAという応答を受信しています。 ピンク色の画像の位置を書き込んだ後、次の操作を行うまでに約1.5秒待ちますか？この遅延はFULL_MEMのインストール手順には明示的に記載されていませんが、AB_SWAPバージョンでは必須です。これが問題かもしれません。 もしTrace32を使っているなら教えてください。スクリプトを共有します。 よろしくお願いいたします。 ルーカス Re: S32K3 recovery issue when install HSE fw via MU こちらが私がMU経由でHSE FWをインストールするために使っているリカバリープログラムです。何が問題か見てくれないか? Re: S32K3 recovery issue when install HSE fw via MU 添付ファイルは、私が現在使用しているプロジェクトの暗号化されていないバージョンです。テストには、S32K344チップ、PEデバッガ、および添付ファイルにあるS32DSプロジェクトを使用しています。ピンク色の画像を書き込んだ後、SBAFから正常な応答が得られるまで数秒待ってみましたが、それでもうまくいきませんでした。機能リセットを直接実行しても効果はありませんでした。添付プロジェクトのMUインストールルーチンに問題がないか確認していただけますか? Re: S32K3 recovery issue when install HSE fw via MU 私は自分のボードでそのプロジェクトをテストしました。まず、起動ファイル内のRAM初期化を修正する必要がありました。ピンク色のファイルをRAMにコピーする際にハードフォルトが発生したためです。これらのHSEデモの例ではRAMの初期化があまり良くないので、私は次のような簡単な修正を行いました: lukaszadrapa_0-1782288292132.png PemicroデバッガはRAMを自動的に初期化し、機能リセット時でもRAM内容が保持されるため、おそらくこの問題は見られなかったでしょう。しかし、電源を入れても動作しなかった。デバッグにはTrace32を使っていたので、最初から気づきました。 次にIVTを修正しました。ピンクのファイルへのポインタを削除し、最初のリセット後に自動的にインストールされず、Muでインストールを確認できるようにしました。 そして結果として、0xDACACADAという値が得られ、ファームウェアはMU経由でインストールされました。つまり、手順は明らかに正しいのです。 問題は、なぜあなたの側ではうまくいかないのかということです。 お使いのデバイスのSBAFのバージョンは何ですか？0x4039_C020 のダブルワードを読み取ってください。 よろしくお願いいたします。 ルーカス Re: S32K3 recovery issue when install HSE fw via MU これが私が読んだ結果です。 捕获.PNG Re: S32K3 recovery issue when install HSE fw via MU さらに、現在弊社ではHSE FWバージョン0.2.55.0を使用しています。 Re: S32K3 recovery issue when install HSE fw via MU こんにちは、 @lukaszadrapa さん。この問題はまだ解決していません。そちらで何か進展がありましたら、お知らせください。ありがとう。 Re: S32K3 recovery issue when install HSE fw via MU 返信が遅くなり申し訳ありません。 お使いのSBAFバージョンは0.15.0で、HSEファームウェア0.2.55.0と完全に互換性があります。これには何の問題もありません。 私のテストでは、サービスHSE_SRV_ID_ERASE_FWを使ってファームウェアを完全に消去したので、パッシブパーティションには有効なバックアップがありません。 あなたの場合、バックアップは利用可能なように見えるので、フローが異なるかもしれません(なぜうまくいかないのかはわかりません)。あなたのコードを見ると、スワップのみが実装されていないことがわかります。コードを追加してみてはどうですか?これで問題が解決するかもしれない。 lukaszadrapa_0-1782893943072.png よろしくお願いいたします。 ルーカス Re: S32K3 recovery issue when install HSE fw via MU ありがとう！SWAP要求を直接実行することで、HSEファームウェアの復元に成功しました。しかし、ずっとFULL_MEMファームウェアを使っていたのに、なぜ最終的にAB_SWAPで復元されたのか疑問です。 Re: S32K3 recovery issue when install HSE fw via MU それは面白い。正直に言うと、私は間違いを犯しました。多くのお客様を行き来していて、なぜかあなたがAB_SWAPを使っていて、FULL_MEMを使っていると思っていたのです。そうでなければ、お勧めしません。2つの可能な説明が考えられます。ファームウェアの有効なバックアップがまだ残っているなら、MUの手順に記載されていなくても「swap」コマンドがFULL_MEMバージョンでも動作する可能性があるFULL_MEM。2つ目は、リカバリーアプリケーションによる機能リセットによりSBAFがファームウェアを完全に消去し、インストールが成功したというものです。よく分かりません。再現して確認するのはかなり難しいです。