PMIC PF8200 I2Cレジスタのデフォルト値/リセット値 私はOTP構成でPF8200を使用しています。 PMICの設定を変更するために、SCFWを使っていくつかのレジスタに新しい値をロードする必要があります。 OTP値によってロードされないレジスタビットには、データシートにデフォルト値が指定されていません。 これらの値を知ることで、OTPによって既にロードされていないすべてのレジスタをロードすることが有用かどうかを判断できます。 ありがとう; Re: PMIC PF8200 I2C register default/reset values 迅速なご回答ありがとうございます。 電源投入後のデフォルト値に関する情報は見つかりませんでした。 どうか、この情報をどこで見つけられるか教えさせてください! Re: PMIC PF8200 I2C register default/reset values こんにちは、 OTPからロードされないレジスタまたはビットは、電源投入後にデフォルト値に初期化されます。したがって、デフォルト設定とは異なる値が必要な場合を除き、すべての非OTPレジスタをSCFW経由で設定する必要はありません。 追加の初期化が必要かどうかを判断するには、希望する設定とデフォルトのレジスタ値を比較してください。 PF82ファミリのI2Cレジスタマップをご参照ください お役に立てば幸いです！ Re: PMIC PF8200 I2C register default/reset values どのレジスターに興味があるのか確認していただけますか? Re: PMIC PF8200 I2C register default/reset values 例えば、レジスタ05 INT_MASK_1。 しかし、すべてのレジスタはOFF_TOGGLEとして指定されています。 ありがとうございます。

i.MX95におけるUSXGMIIマルチレート こんにちは、 i.MX95に以下のイーサネット速度をサポートできるイーサネットポートを実装できるかどうかを評価しようとしています。 10GBASE-T 5GBASE-T 2.5GBASE-T 1000BASE-T 100BASE-TX 10BASE-Te 一般的に、デザイン上に10Gbit対応のイーサネットPHYを設置し、USXGMIIまたはXFIのいずれかのインターフェースを通じてi.MX95イーサネットコントローラに接続する必要があります 私たちの理解では、USXGMIIインターフェースは理論上マルチレートインターフェースであり、1リンクで10Gbitから10bitまでのあらゆる速度を実現できます。 これに対し、XFIインターフェースは単一レートのインターフェースで、10Gbitしか対応できません。 i.MX95のリファレンスマニュアル(例:)セクション104.2、表621)i.MX95はXFIおよび「10G-USXGMII」の両方をサポートしています。最初は、私たちが望むUSXGMIIインターフェースがサポートされているように見えます。 しかし、いくつか私たちを困惑させる点があります。 1.「10G-USXGMII」という宣言は、理論上はインターフェースがUSXGMIIリンクであることを意味するかもしれませんが、実際には10Gbitモードでしか動作しません。 2. NXP評価ボードIMX95LPD5EVK-19は、Marvell AQR113C PHYを使用して10GBase-Tポートを実装しています。 a) 図1のブロック図、セクション1.1では、PHYがUSXGMIIインターフェースに接続されているように見えます: b) 関連するセクション2.11.3「10 Gbitイーサネットインターフェース」では、AQR113Cイーサネットトランシーバーが10Gbitから10bitまでのすべてのデータレートをサポートするとされており、真のUSXGMIIを示唆しています: c) この節では、イーサネットPHYを接続するインターフェースがXFIであることも記載されています。 結論として、i.MX95がフルのマルチレートUSXGMIIに対応しているのか、それとも10Gbit専用バージョンのみ対応しているのか混乱しています。 NXPの評価ボードを参考にしてみましたが、そのボードの10GbEポートがUSXGMII(10Gbitから10bitまでのマルチレート対応)で接続されているのか、XFI(10Gbitのみ)で接続されているのかも分かりません。 教えていただけますか: i.MX95に10Gbitから10Gbitまでの速度をサポートする真のマルチレート10GbEポートを実装することは可能でしょうか? Re: USXGMII multi-rate on i.MX95 詳細なご回答をいただき、誠にありがとうございます。 これで私たちの側の混乱は解消されました！ Re: USXGMII multi-rate on i.MX95 1. 「10G-USXGMII」の意味 「10G-USXGMII」とは、10G専用モードではなく、標準的なマルチレートUSXGMIIプロトコルを指します。「10G」は固定されたSerDesレーン速度を示し、USXGMIIは10M、100M、1G、2.5G、5G、10Gイーサネットの帯内レート適応をサポートしています。 i.MX95では、このモードはPCS_PROT_10G_SXGMII設定で表されます。 2. i.MX95 EVKで使用されたインターフェース i.MX95 EVKは、USXGMIIではなくXFI（10GBASE-R）を使用します。imx95-19x19-evk.dtsでは、enetc_port2 は次のように設定されています。 phy-mode = "10gbase-r"; したがって、搭載されているAQR113CはXFIモードで動作します。 3. 真のマルチレートUSXGMIIはサポートされていますか？ はい。i.MX95 NETCハードウェアはUSXGMIIをサポートし、LinuxのENETC4ドライバはenetc4_set_port_speed()を通じて速度変更を処理します。Marvell AQR113CはUSXGMIIホストインターフェースモードもサポートしています。 4. カスタムボードに必要なものは何ですか？ マルチレート動作を完全に有効にするには： デバイスツリーの設定： phy-mode = "usxgmii"; managed = "in-band-status"; AQR113Cのファームウェアを、XFIではなくUSXGMIIホストモードに設定してください。 EVKは10GbEポートにXFIを使用していますが、カスタムi.MX95設計ではUSXGMIIをAQR113C(または類似のPHY)と組み合わせて、10M/100M/1G/2.5G/5G/10Gを単一のMACからPHYリンクまでサポートできます。 よろしくお願いします。 Re: USXGMII multi-rate on i.MX95 もう一つ追加で質問します:Marv AQR113C ellのドライバはNXP Linux BSPに含まれているのか、それとも自分たちで用意しなければならない外部モジュールですか? Re: USXGMII multi-rate on i.MX95 私は元の投稿者ではありませんが、私もusxgmiiを動作させようとしています。 NXPは、usxgmiiがBSPカーネル上で動作するかどうかを検証したことがありますか？mv-cux3610 PHYで使用しようとしていますが、以下のエラーが発生します。 [ 43.063202] nxp_enetc4 0002:00:10.0 (unnamed net_device) (uninitialized): MAC returned PCS which does not support usxgmii [ 43.074224] nxp_enetc4 0002:00:10.0 (unnamed net_device) (uninitialized): failed to validate link configuration for inband [ 43.085308] nxp_enetc4 0002:00:10.0: Failed to create phylink [ 43.091726] nxp_enetc4 0002:00:10.0: probe with driver nxp_enetc4 failed with error -22 これは、NetC PCSがUSXGMIIサポートを宣伝しておらず、10Gbase-R、2500-basex、SGMIIのみが原因のようです: (これはLF-6.18.YのLinux-IMXブランチでの話です) Re: USXGMII multi-rate on i.MX95 このドライバーはNXP Linux BSPに含まれています。リンク: https://github.com/nxp-real-time-edge-sw/real-time-edge-linux/blob/linux_6.18.20/drivers/net/phy/aquantia/aquantia_main.c Re: USXGMII multi-rate on i.MX95 お返事ありがとうございます！ 最後に質問です。i.MX95 EVKのenetc_port2とAQR113CをUSXGMIIモードに設定することは可能でしょうか？これにより、EVK上でUSXGMIIインターフェースのマルチレート機能をテストできるのでしょうか?

USXGMII multi-rate on i.MX95 Hi, we are trying to evaluate if we can implement an ethernet port on the i.MX95 that is able to support the following ethernet speeds: 10GBASE-T 5GBASE-T 2.5GBASE-T 1000BASE-T 100BASE-TX 10BASE-Te In general this requires us to place a 10Gbit capable ethernet PHY on our design and connect it to the i.MX95 ethernet controller via one of two interfaces: USXGMII or XFI From our understanding the USXGMII interface is a multi-rate interface in theory, meaning it can facilitate all speeds from 10Gbit to 10bit over one link. In contrast the XFI interface is a single-rate interface that can only facilitate 10Gbit. According to the i.MX95 reference manual (e.g. section 104.2, table 621) the i.MX95 supports both XFI and "10G-USXGMII". So initially it looks like our desired interface USXGMII seems to be supported. There are several points that confuse us however: 1. The declaration "10G-USXGMII" could be interpreted to mean that the interface is a USXGMII link in theory but it only really works in the 10Gbit mode. 2. The NXP eval board IMX95LPD5EVK-19 implements a 10GBase-T port using a Marvell AQR113C PHY. a) In the block diagram in figure 1, section 1.1 the PHY looks to be connected to the USXGMII interface: b) In the associated section 2.11.3 "10 Gbit Ethernet Interface" the AQR113C ethernet transceiver is said to support all data rates from 10Gbit to 10bit, hinting at true USXGMII: c) This section also mentions that the interface used to connect the ethernet PHY is XFI: So in conclusion we are confused wether or not the i.MX95 supports the full multi-rate USXGMII or only a 10Gbit-only version. We tried to look at the NXP eval board as a reference but we are not sure either if the 10GbE port on that board is connected via USXGMII (allowing multi-rate from 10Gbit to 10bit) or via XFI (10Gbit only). Could you please clarify for us: Is it possible to implement a true multi-rate 10GbE port on the i.MX95 that supports speeds from 10Gbit to 10bit? Re: USXGMII multi-rate on i.MX95 Thank you very much for this in-depth response. This clears up any confusion on our side! Re: USXGMII multi-rate on i.MX95 1. Meaning of "10G-USXGMII" "10G-USXGMII" refers to the standard multi-rate USXGMII protocol, not a 10G-only mode. The "10G" denotes the fixed SerDes lane speed, while USXGMII supports in-band rate adaptation for 10M, 100M, 1G, 2.5G, 5G, and 10G Ethernet. On i.MX95, this mode is represented by the PCS_PROT_10G_SXGMII setting. 2. Interface Used on the i.MX95 EVK The i.MX95 EVK uses XFI (10GBASE-R) rather than USXGMII. In imx95-19x19-evk.dts, enetc_port2 is configured as: phy-mode = "10gbase-r"; Therefore, the onboard AQR113C operates in XFI mode. 3. Is True Multi-Rate USXGMII Supported? Yes. The i.MX95 NETC hardware supports USXGMII, and the Linux ENETC4 driver handles speed changes through enetc4_set_port_speed(). The Marvell AQR113C also supports USXGMII host-interface mode. 4. What Is Needed on a Custom Board? To enable full multi-rate operation: Configure the device tree: phy-mode = "usxgmii"; managed = "in-band-status"; Configure the AQR113C firmware for USXGMII host mode instead of XFI. The EVK uses XFI for its 10GbE port, but a custom i.MX95 design can use USXGMII with the AQR113C (or a similar PHY) to support 10M/100M/1G/2.5G/5G/10G over a single MAC-to-PHY link. Thanks Re: USXGMII multi-rate on i.MX95 I am not the original poster but I am also trying to get usxgmii working. Has NXP ever validated if usxgmii works on the BSP kernel? I am trying to use it with a mv-cux3610 phy but I get these errors: [ 43.063202] nxp_enetc4 0002:00:10.0 (unnamed net_device) (uninitialized): MAC returned PCS which does not support usxgmii [ 43.074224] nxp_enetc4 0002:00:10.0 (unnamed net_device) (uninitialized): failed to validate link configuration for inband [ 43.085308] nxp_enetc4 0002:00:10.0: Failed to create phylink [ 43.091726] nxp_enetc4 0002:00:10.0: probe with driver nxp_enetc4 failed with error -22 it seems to be caused by the netc PCS not advertising usxgmii support, only 10gbase-r, 2500-basex and sgmii: (this is on the lf-6.18.y linux-imx branch) Re: USXGMII multi-rate on i.MX95 Just one more follow-up question: Is the driver for the Marvell AQR113C included in the NXP Linux BSP or is it an out-of-tree module we must supply ourselves? Re: USXGMII multi-rate on i.MX95 Thank you for your reply! Last question from my side: Is it possible to configure the enetc_port2 and the AQR113C on the i.MX95 EVK to USXGMII mode? Would this allow us to test the multi-rate functionality of the USXGMII interface on the EVK? Re: USXGMII multi-rate on i.MX95 the driver has been included in NXP Linux BSP, link: https://github.com/nxp-real-time-edge-sw/real-time-edge-linux/blob/linux_6.18.20/drivers/net/phy/aquantia/aquantia_main.c

FRDM-K64FでMCUxpresso 25.6を使用した場合、SDカードのシンボルが未定義になる 私のプロジェクトでは、双方向無線システム用の個別のパーソナライズデータを読み込むためにSDカードを使用したいと考えています。#include "tx_api.h" を取得していますまた、#include "tx_event_flags.h" が未定義として扱われます。 これは、SDKにAzure RTOSを含めていなかったためです。 私は「manage sdk components」を使ってAzureをSDKにインストールしてこれを克服しようとしましたが、どうやらAzure RTOSのサポートは2.11で終了しており、この問題に気づく前にプロジェクトに読み込んでいました。 SO I created a new SDK online, but it drops back to 2.10 to get Azureサポート.しかし、プロジェクトのSDKを変更しようとすると、持っているSDKを削除できず、別のSDKを追加しようとすると、SDK 2.x_FRDM-K64Fがすでに存在すると表示されます。 Azureのサポートはどうすればいいですか?SDカードへのアクセスだけに必要なんです!

VR5510: I2C ウォッチドッグ リフレッシュは、非同期モードが有効になっている場合でも ISR でブロックされます - 真の非ブロッキング サポート NXPチームの皆様、こんにちは。 現在VR5510 PMICのデバッグを行っているのですが、ウォッチドッグの更新に関連するリアルタイムスケジューリングの問題に遭遇しました。 MCAL I2C ウォッチドッグのリフレッシュ (I2C を介して VR5510 ウォッチドッグにフィードする) は、 同期 手術。同期待機は割り込みコンテキスト内から呼び出されるため、CPUをブロックし、他のタスクのリアルタイムスケジューリングを低下させます。 ドライバーの設定やコードに 非同期 オプションがあるのに気づきました。しかし実際には同期のビジー待機(I2C転送が完了するまでブロックとポーリングを行う)を実行しているため、実際には転送を呼び出し元から切り離すことはありません。 私の質問： VR5510のウォッチドッグリフレッシュを公式にサポートされた方法で実行することは可能ですか？ 真のノンブロッキング （例えば割り込み駆動かDMA駆動のI2C)で、他のタスクを停止させないために? 非同期オプションがノンブロッキングであることが想定されている場合、現在の同期ビジーウェイト動作は既知の制限事項でしょうか、それとも私の側の設定の問題でしょうか？ 何かご助言、設定例、またはサンプルコードをご提供いただければ大変ありがたいです。 よろしくお願いします。 Re: VR5510: I2C watchdog refresh blocks in ISR even with async mode enabled – is true non-blocking s こんにちは、 @Jerry_cao 投稿ありがとうございます。 あなたが言及しているのは、使用されている以下のAPIでしょうか？ Std_ReturnType I2c_AsyncTransmit(uint8 チャネル、 const I2c_RequestType ∗ RequestPtr ) 「？ どのバージョンのRTDが使用されていますか？ BR チェイン Re: VR5510: I2C watchdog refresh blocks in ISR even with async mode enabled – is true non-blocking s こんにちは： 私のバージョンは：   * プロジェクト:RTD AUTOSAR 4.4 * プラットフォーム:CORTEXM *   ペリフェラル           : VR5510 * 依存関係：なし * * Autosar バージョン:4.4.0 * Autosar リビジョン:ASR_REL_4_4_REV_0000 *   AUTOSAR Conf.Variant : * ソフトウェアバージョン：4.0.2 * ビルドバージョン：S32_RTD_4_0_2_HF02_D2311_ASR_REL_4_4_REV_0000_20231103 * * (c) 著作権 2020-2023 NXP セミコンダクターズ * 無断転載を禁じます。 * この関数を使用する Pmic_VR55XX_TriggerWatchdog Re: VR5510: I2C watchdog refresh blocks in ISR even with async mode enabled – is true non-blocking s こんにちは、 @Jerry_cao ご確認いただきありがとうございます。 対応するコードを確認すると、 I2C非同期通信用のVR5510ソリューションはRTD5.0.0QLP04に実装されていることがわかります。 詳細については、このバージョンのRTDに含まれる関連コードをご確認ください。 BR チェイン Re: VR5510: I2C watchdog refresh blocks in ISR even with async mode enabled – is true non-blocking s こんにちは： 私のバージョンは：   * プロジェクト:RTD AUTOSAR 4.4 * プラットフォーム:CORTEXM *   ペリフェラル           : VR5510 * 依存関係：なし * * Autosar バージョン:4.4.0 * Autosar リビジョン:ASR_REL_4_4_REV_0000 *   AUTOSAR Conf.Variant : * ソフトウェアバージョン：4.0.2 * ビルドバージョン：S32_RTD_4_0_2_HF02_D2311_ASR_REL_4_4_REV_0000_20231103 * * (c) 著作権 2020-2023 NXP セミコンダクターズ * 無断転載を禁じます。 * この関数を使用する Pmic_VR55XX_TriggerWatchdog

S32K312 temperature sensor inaccurate reading Hello NXP Team, I am working on the S32K312​ internal temperature sensor and need help with incorrect temperature readings. I have reviewed similar threads and confirmed the basic configurations, but the ADC results do not reflect the ambient temperature. What I have done so far： (1) TEMPSENSE clock enabled​-Screenshot attached  (2)ADC configuration ADC instance: ADC0 Channel: Temperature Sensor (TEMPSENSE) Trigger mode: Software trigger (3)Measurement routine Periodically start ADC conversion Wait for conversion complete flag Read ADC data register (4)Result However, the converted temperature value does not match the actual ambient temperature. Any guidance, clarification, or reference code for the S32K312 temperature sensor would be greatly appreciated.   Thanks in advance for your support!   Best regards, Re: S32K312 temperature sensor inaccurate reading Hi@SunLucas The temperature channel requires a relatively long sampling time, with a minimum of 1.2 microseconds. Therefore, please check the sampling time settings. Re: S32K312 temperature sensor inaccurate reading I further switched the ADC voltage reference to 0x50, but the issue persists: The temperature readings deviate significantly from the ambient temperature (28°C). Temperature data retrieved via the API exhibits severe fluctuations, as shown in the attached plot. Re: S32K312 temperature sensor inaccurate reading Hi@SunLucas Then you should set TempSense voltage supply to: 5V * 16 = 0x50 Re: S32K312 temperature sensor inaccurate reading The TempSense voltage supply is configured as 0x58, hardware's VDD_HV_A supply voltage is 5V Re: S32K312 temperature sensor inaccurate reading Hi@SunLucas Please check the "TempSense Voltage Supply" and tell me what your current hardware's VDD_HV_A supply voltage is.

VR5510: I2C watchdog refresh blocks in ISR even with async mode enabled – is true non-blocking suppo Hello NXP team, I'm currently debugging the VR5510 PMIC and have run into a real-time scheduling issue related to the watchdog refresh. The MCAL I2C watchdog refresh (feeding the VR5510 watchdog over I2C) is implemented as a synchronous operation. Because we call it from within an interrupt context, the synchronous wait blocks the CPU and degrades the real-time scheduling of other tasks. I noticed there is an asynchronous option in the driver configuration/code. However, in practice it still performs a synchronous busy-wait (it blocks and polls until the I2C transfer completes), so it does not actually decouple the transfer from the caller. My questions: Is there an officially supported way to make the VR5510 watchdog refresh truly non-blocking (e.g. interrupt-driven or DMA-driven I2C), so that it does not stall other tasks? If the asynchronous option is expected to be non-blocking, is the current synchronous busy-wait behavior a known limitation or a configuration issue on my side? Any guidance, reference configuration, or example code would be greatly appreciated. Thank you. Re: VR5510: I2C watchdog refresh blocks in ISR even with async mode enabled – is true non-blocking s Hello, @Jerry_cao  Thanks for the post. May I know if you are referring to the following API used " Std_ReturnType I2c_AsyncTransmit (uint8 Channel,  const I2c_RequestType ∗ RequestPtr ) "?  Which version RTD is used? BR Chenyin Re: VR5510: I2C watchdog refresh blocks in ISR even with async mode enabled – is true non-blocking s Hello： my version is：   *   Project              : RTD AUTOSAR 4.4 *   Platform             : CORTEXM *   Peripheral           : VR5510 *   Dependencies         : none * *   Autosar Version      : 4.4.0 *   Autosar Revision     : ASR_REL_4_4_REV_0000 *   Autosar Conf.Variant : *   SW Version           : 4.0.2 *   Build Version        : S32_RTD_4_0_2_HF02_D2311_ASR_REL_4_4_REV_0000_20231103 * *   (c) Copyright 2020-2023 NXP Semiconductors *   All Rights Reserved. * use this function  Pmic_VR55XX_TriggerWatchdog Re: VR5510: I2C watchdog refresh blocks in ISR even with async mode enabled – is true non-blocking s Hello, @Jerry_cao  Thanks for your confirmation. By checking with the corresponding code, the VR5510 Solution for I2C asynchronous communication is implemented in RTD5.0.0QLP04 You may check the related code in this version RTD for details. BR Chenyin Re: VR5510: I2C watchdog refresh blocks in ISR even with async mode enabled – is true non-blocking s Hello： my version is：   *   Project              : RTD AUTOSAR 4.4 *   Platform             : CORTEXM *   Peripheral           : VR5510 *   Dependencies         : none * *   Autosar Version      : 4.4.0 *   Autosar Revision     : ASR_REL_4_4_REV_0000 *   Autosar Conf.Variant : *   SW Version           : 4.0.2 *   Build Version        : S32_RTD_4_0_2_HF02_D2311_ASR_REL_4_4_REV_0000_20231103 * *   (c) Copyright 2020-2023 NXP Semiconductors *   All Rights Reserved. * use this function  Pmic_VR55XX_TriggerWatchdog

SW32K14-MCAL421-RTMC-1.0.1 ダウンロードへのアクセスを有効にするリクエスト こんにちは、NXPサポートチーム様 SW32K14-MCAL421-RTMC-1.0.1のダウンロード アクセスをリクエストします。 現在、NXP ソフトウェア ライセンス ページの [前へ] タブがグレー表示されており、このバージョンにアクセスできません。 私のアカウントのユーザー名はChefanqfです。 このバージョンは、 S32K14x MCAL 4.2に基づく既存のプロジェクトとの互換性を保つために必要です。 私のアカウントでこのソフトウェアの権限を有効にするのを手伝っていただけますか? サポートしていただき誠にありがとうございます！ よろしくお願いいたします。 Re: Request to enable access for SW32K14-MCAL421-RTMC-1.0.1 download こんにちは@Chefanqf 、 NXP.com (検索 | NXP Semiconductors) で「S32K1 MCAL」を検索し、次のように flexera と入力してみてはいかがでしょうか。 この後、「オートモーティブ SW - AUTOSAR MCAL / QM」を選択すると、以前のソフトウェアが利用できるようになります。 「前へ」タブがまだグレー表示されている場合、直接リンク： SW32K14-MCAL421-RTMC-1.0.1 から入力してみてください。直接リンクを使用する場合は、nxp.com にログインしていることを確認してください。 よろしくお願いします、 ジュリアン Re: Request to enable access for SW32K14-MCAL421-RTMC-1.0.1 download こんにちは、NXPサポートチーム様 SW32K14-MCAL421-RTMC-1.0.1 のダウンロードアクセスをお願いしたいです。 現在、NXPソフトウェアライセンスページの「前回」タブが グレーアウト 表示され このバージョンにアクセスできません。 私のアカウントのユーザー名はmianlongxuです。 このバージョンは、既存のプロジェクトとの互換性のために必要です。 S32K14x MCAL 4.2 。 私のアカウントでこのソフトウェアの権限を有効にするのを手伝っていただけますか? サポートしていただき誠にありがとうございます！ よろしくお願いいたします。

JTAGデバッガのサポートに関するお問い合わせLX2082A 親愛なるNXPサポートチームへ、 NXP LX2082Aプロセッサをベースにしたカスタムボードを開発しており、現在ハードウェアのブリングアップとデバッグセットアップを計画中です。 SEGGER J-LinkがLX2082Aで以下のタスクに対して正式にサポートされているかどうかを確認したいと思います。 初期ボードの立ち上げ JTAGデバッグ ベアメタルデバッグ TF-AとU-Bootのデバッグ Linuxカーネルデバッグ Flashプログラミング（サポートされている場合） 私の開発環境はLinuxで、すべてのソフトウェアをLinuxホスト上で開発・構築する予定です。 何かアドバイスをいただけますか: SEGGER J-LinkはLX2082Aで正式にサポートされていますか？ もし対応しているなら、どのJ-Linkモデルに対応していますか? NXPが推奨するデバッグソリューションと比較して、何か制限事項はありますか？ もしJ-Linkが推奨されていないなら、公式に対応しているハードウェアデバッガをLX2082Aで教えていただけますか? JTAGのデバッグや基板の導入に関するドキュメントやアプリケーションノートがあれば、ぜひ教えていただけるとありがたいLX2082A。 ご協力ありがとうございました。ご指導を心よりお待ちしております。 敬具。 Re: Inquiry Regarding JTAG Debugger Support for LX2082A NXPが公式にサポートしているデバッガはCWTAPです。 あなたのアプリケーションにはCodewarrior Developer Suite Levelを使えます。 また、以下のリンクから評価版(無料トライアル)をダウンロードすることもできますが、30日間の制限があります すべての顧客アカウント(メールアドレス)は、以下のリンクから評価版をダウンロードできます。 「評価版をダウンロード」を選択してください。 https://www.nxp.com/design/design-center/software/development-software/codewarrior-development-tools/codewarrior-network-applications/codewarrior-development-suites-for-networked-applications:CW-DS-NETAPPS 下記に役立つ資料を掲載していますので、ご参照ください。   ARMv8_Targeting_Manual.pdf   CodeWarrior TAP プローブユーザーガイド   Layerscape Linux SDK ユーザーガイド Clarification on CodeWarrior License After 30-Day Evaluation (CW TAP / QCVS / QCS) こんにちは、NXPサポートの皆さん、 CodeWarriorの30日間評価版について質問があります。 評価期間終了後： JTAG接続（CW TAPを使用）は引き続き機能しますか、それともCodeWarriorは完全に動作しなくなりますか？ 有料ライセンスがなくても、RCWの生成・プログラミングおよびフラッシュプログラミングは引き続き利用できますか？ QCVS(QorIQ Configuration and Validation Suite)はトライアル終了後も引き続き使用できますか?それとも有効なCodeWarriorライセンスも必要ですか? Linuxのコマンドラインツール(U-Boot、Yocto、OpenOCDなど)のみを使用しているお客様にとって、CodeWarriorの購入はJTAGデバッグのためだけに推奨されるのか、それとも基板の設置に必須ですか? 評価期間終了後も利用可能な機能について、ご説明いただけると幸いです。 よろしくお願いします。 Re: Inquiry Regarding JTAG Debugger Support for LX2082A 1. CodeWarriorの機能が停止します。 2. いいえ。 3. いいえ。有効な免許証が必要です。 4. LinuxのデバッグはJTAGデバッグなしで動作しますが、各ボードでのDDR検証や初回フラッシュはCodeWarrior IDEとJTAGデバッガ(CW TAP)を使うべきです。

S32K344 chip, failed to download using bootloader after adding eMCEM_1 module in spd Sort out the logic and rewrite: As the title suggests, when I enabled eMCEM_1 in the app code, downloading the app using the official bootloader failed. If I didn't erase the chip, I couldn't enter the boot again, and even after powering it back on, it wouldn't solve the problem. I suspect that after powering it back on, the boot jumped to the app, but the app didn't run. When I disable eMCEM_1, this issue does not occur. How can I use boot to flash the app when eMCEM_1 is enabled Re: S32K344 chip, failed to download using bootloader after adding eMCEM_1 module in spd Hi @XPW, The problem description is not entirely clear. If the application is being programmed through the bootloader, the eMCEM_1 configuration contained in the application should not affect the programming process itself, since the application is not executed during download, it is just a binary. Only after the bootloader transfers execution to the application would eMCEM/FCCU-related configuration become relevant, and at that point, it would be useful to check: FCCU status registers DCM flags, MC_RGM flags. Or whether the application actually reaches main() Based on the current description, it is unclear whether the programming operation fails, or whether programming succeeds and the issue occurs later when the application starts executing. Could you clarify the exact sequence of events? Regards, Daniel Re: S32K344 chip, failed to download using bootloader after adding eMCEM_1 module in spd After my investigation, I found that some global variables were not initialized as defined when was enabled 。 Select a portion for explanation： Firstly, when I haven't enabled the target Clock_ip. c under RTD file Power_ip. c under RTD file Can initialize correctly。 However, when I activated it： Clock_ip. c under RTD file Power_ip. c under RTD file Global variable initialization failed。 May I ask if there is a better solution? Re: S32K344 chip, failed to download using bootloader after adding eMCEM_1 module in spd Hi @XPW, Based on what I see in the screenshots, the variables are initialized correctly at first. However, after the eMCEM initialization, Clock_Ip_pfkNotificationsCallback contains an invalid pointer. eMCEM does not magically change the pointer value. This looks much more like one of the following issues: Startup initialization (.data copy / .bss initialization) is not completed correctly. RAM corruption occurs before main(). Linker sections overlap. Stack corruption. Can you test it with the linker file from the SPD demo project? BR, Daniel Re: S32K344 chip, failed to download using bootloader after adding eMCEM_1 module in spd The link file has been modified for the following. I have defined three global variables： I found that when is not enabled, after executing init_data-bss, It seems to be aligned with 4 bytes and assigned correctly. But when I enable , after executing init_data-bss It doesn't seem to be aligned. Re: S32K344 chip, failed to download using bootloader after adding eMCEM_1 module in spd What is the cause of this phenomenon and how should I investigate and solve it. Re: S32K344 chip, failed to download using bootloader after adding eMCEM_1 module in spd HI @XPW, Based on the screenshots, I am not convinced there is actually a problem with the variable initialization itself. variable_a is an 8-bit variable, and enabling eMCEM will introduce additional variables, which can change the layout of the .data section. Therefore, seeing the variables at different offsets is expected and does not by itself indicate corruption. I think the key question is whether the issue occurs when the application is run standalone, or only when it is programmed and started through the bootloader. Can you reproduce the issue when programming the application directly with the debugger and running it without the bootloader? If the problem only occurs after loading the application through the bootloader, then the investigation should focus on the bootloader programming process, image layout, or bootloader handover rather than the application itself. BR, Daniel

LS1046A 10GB SFP+ Configuration on kernel 6.12 Hello,  I have a custom board with the LS1046A, and I'm trying to use fm1-mac9 with a soldered SFP+ 10GB module.  My RCW in SERDES 1 is 0x1040:  So 10GB in fm1-mac9 is well covered from the RCW's perspective. Looking at the SFP power and laser everything seems healthy, but I can't seem to get it to talk/link with the sfp in front of it, so I suspect my DTB configuration is incorrect.  This is my current configuration for that MAC:  xfi10g: ethernet@f0000 {   status = "okay";   pcsphy-handle = <&pcsphy6>;   pcs-handle = <&pcsphy6>;   pcs-handle-names = "xfi";   phy-connection-type = "10gbase-r";   fixed-link {     speed = <10000>;     full-duplex;   }; }; mdio@f1000 {   status = "okay";   pcsphy6: ethernet-phy@0{     compatible = "fsl,lynx-pcs";     reg = <0x0>;   }; }; sfp_mac9: sfp {   compatible = "sff,sfp";   i2c-bus = <&i2c3>;   status = "okay"; }; For reference, I'm running linux-qoriq kernel 6.12, and the SFP probes correctly during boot reading its EEPROM. Do you have a proper example of running this type of connection in fm1-mac9? 

i.MX8MP_EVK: YOCTO Compilation Error do_package() (Issue: tar & *at()) Hi, These are my yocto build parameters: Release: imx-linux-walnascar BSP Version: imx-6.12.49-2.2.0 MACHINE: imx8mpevk DISTRO: fsl-imx-xwayland I have been using this build environment successfully for the past couple of months. However, I suddenly started encountering the attached error. To troubleshoot, I completely cleaned the build environment, reinitialized the repository (repo init), synced everything again, and performed a fresh build. Unfortunately, I am still facing the same issue. Please find the attached log file for your reference. I would appreciate your help in identifying the root cause and suggesting a solution. i.MX 8M | i.MX 8M Mini | i.MX 8M Nano Re: i.MX8MP_EVK: YOCTO Compilation Error do_package() (Issue: tar & *at()) bitbake imx-image-core Re: i.MX8MP_EVK: YOCTO Compilation Error do_package() (Issue: tar & *at()) What "bitbake command" are you using? I will do verification. Re: i.MX8MP_EVK: YOCTO Compilation Error do_package() (Issue: tar & *at()) Thank you for your response. I verified my build environment, and it already matches the configuration you recommended. Host OS: Ubuntu 22.04.5 LTS (Jammy) GNU tar version: GNU tar 1.34 $ cat /etc/os-release PRETTY_NAME="Ubuntu 22.04.5 LTS" ... $ tar --version tar (GNU tar) 1.34 However, I still encounter the same failure Re: i.MX8MP_EVK: YOCTO Compilation Error do_package() (Issue: tar & *at()) Please check the tar version, if the host is Ubuntu 24.04 and tar is 1.35 Build inside a container or VM with: Ubuntu 22.04 LTS GNU tar 1.34 Re: i.MX8MP_EVK: YOCTO Compilation Error do_package() (Issue: tar & *at()) Please find file below,  Here i am pasting the some lines of error  DEBUG: Executing python function extend_recipe_sysroot NOTE: Direct dependencies are ['/home/vvdn/LWT_Build/sources/poky/meta/recipes-devtools/binutils/binutils-cross_2.44.bb:do_populate_sysroot', '/home/vvdn/LWT_Build/sources/poky/meta/recipes-devtools/gcc/gcc-cross_14.3.bb:do_populate_sysroot', '/home/vvdn/LWT_Build/sources/poky/meta/recipes-devtools/quilt/quilt-native_0.68.bb:do_populate_sysroot', '/home/vvdn/LWT_Build/sources/poky/meta/recipes-kernel/kern-tools/kern-tools-native_git.bb:do_populate_sysroot', 'virtual:native:/home/vvdn/LWT_Build/sources/poky/meta/recipes-core/coreutils/coreutils_9.6.bb:do_populate_sysroot', 'virtual:native:/home/vvdn/LWT_Build/sources/poky/meta/recipes-devtools/bison/bison_3.8.2.bb:do_populate_sysroot', 'virtual:native:/home/vvdn/LWT_Build/sources/poky/meta/recipes-devtools/dwarfsrcfiles/dwarfsrcfiles.bb:do_populate_sysroot', 'virtual:native:/home/vvdn/LWT_Build/sources/poky/meta/recipes-devtools/flex/flex_2.6.4.bb:do_populate_sysroot', 'virtual:native:/home/vvdn/LWT_Build/sources/poky/meta/recipes-devtools/patch/patch_2.7.6.bb:do_populate_sysroot', 'virtual:native:/home/vvdn/LWT_Build/sources/poky/meta/recipes-devtools/pkgconfig/pkgconfig_git.bb:do_populate_sysroot', 'virtual:native:/home/vvdn/LWT_Build/sources/poky/meta/recipes-devtools/pseudo/pseudo_git.bb:do_populate_sysroot', 'virtual:native:/home/vvdn/LWT_Build/sources/poky/meta/recipes-devtools/rpm/rpm_4.20.0.bb:do_populate_sysroot', 'virtual:native:/home/vvdn/LWT_Build/sources/poky/meta/recipes-extended/bc/bc_1.08.1.bb:do_populate_sysroot', 'virtual:native:/home/vvdn/LWT_Build/sources/poky/meta/recipes-kernel/kmod/kmod_34.1.bb:do_populate_sysroot'] NOTE: Installed into sysroot: [] NOTE: Skipping as already exists in sysroot: ['gettext-minimal-native', 'binutils-cross-aarch64', 'cmake-native', 'gcc-cross-aarch64', 'libtool-native', 'm4-native', 'quilt-native', 'texinfo-dummy-native', 'kern-tools-native', 'linux-libc-headers', 'file-native', 'openssl-native', 'coreutils-native', 'expat-native', 'ncurses-native', 'readline-native', 'util-linux-libuuid-native', 'zlib-native', 'bison-native', 'dwarfsrcfiles-native', 'elfutils-native', 'flex-native', 'git-native', 'gnu-config-native', 'json-c-native', 'libedit-native', 'lua-native', 'make-native', 'patch-native', 'perl-native', 'pkgconfig-native', 'pseudo-native', 'python3-native', 'rpm-native', 'bc-native', 'bzip2-native', 'libarchive-native', 'libidn2-native', 'lzlib-native', 'xz-native', 'zstd-native', 'kmod-native', 'acl-native', 'attr-native', 'curl-native', 'gdbm-native', 'gmp-native', 'gnutls-native', 'libtasn1-native', 'libcap-native', 'libffi-native', 'libgcrypt-native', 'libgpg-error-native', 'libmicrohttpd-native', 'libmpc-native', 'libunistring-native', 'mpfr-native', 'nettle-native', 'p11-kit-native', 'popt-native', 'sqlite3-native'] DEBUG: Python function extend_recipe_sysroot finished DEBUG: Executing python function sstate_task_prefunc DEBUG: Python function sstate_task_prefunc finished DEBUG: Executing python function do_package DEBUG: Executing python function package_setup_pkgv DEBUG: Python function package_setup_pkgv finished DEBUG: Executing python function package_convert_pr_autoinc DEBUG: Python function package_convert_pr_autoinc finished DEBUG: Executing python function package_prepare_pkgdata NOTE: Installed into pkgdata-sysroot: [] DEBUG: Python function package_prepare_pkgdata finished DEBUG: Executing python function perform_packagecopy ERROR: Error executing a python function in exec_func_python() autogenerated: The stack trace of python calls that resulted in this exception/failure was: File: 'exec_func_python() autogenerated', lineno: 2, function: 0001: *** 0002:perform_packagecopy(d) 0003: File: '/home/vvdn/LWT_Build/sources/poky/meta/classes-global/package.bbclass', lineno: 363, function: perform_packagecopy 0359: rpath_replace (dvar, d) 0360:} 0361:perform_packagecopy[cleandirs] = "${PKGD}" 0362:perform_packagecopy[dirs] = "${PKGD}" *** 0363: 0364:python populate_packages () { 0365: oe.package.populate_packages(d) 0366:} 0367:populate_packages[dirs] = "${D}" File: '/usr/lib/python3.10/subprocess.py', lineno: 421, function: check_output 0417: else: 0418: empty = b'' 0419: kwargs['input'] = empty 0420: *** 0421: return run(*popenargs, stdout=PIPE, timeout=timeout, check=True, 0422: **kwargs).stdout 0423: 0424: 0425:class CompletedProcess(object): File: '/usr/lib/python3.10/subprocess.py', lineno: 526, function: run 0522: # We don't call process.wait() as .__exit__ does that for us. 0523: raise 0524: retcode = process.poll() 0525: if check and retcode: *** 0526: raise CalledProcessError(retcode, process.args, 0527: output=stdout, stderr=stderr) 0528: return CompletedProcess(process.args, retcode, stdout, stderr) 0529: 0530: Exception: subprocess.CalledProcessError: Command 'tar --exclude=./sysroot-only -cf - -C /home/vvdn/LWT_Build/build/tmp/work/imx8mpevk-poky-linux/linux-imx/6.12.34+git/image -p -S . | tar -xf - -C /home/vvdn/LWT_Build/build/tmp/work/imx8mpevk-poky-linux/linux-imx/6.12.34+git/package' returned non-zero exit status 2. Subprocess output: got *at() syscall for unknown directory, fd 4 unknown base path for fd 4, path lib couldn't allocate absolute path for 'lib'. tar: ./usr/lib: Cannot mkdir: Bad address got *at() syscall for unknown directory, fd 4 unknown base path for fd 4, path lib couldn't allocate absolute path for 'lib'. got *at() syscall for unknown directory, fd 4 unknown base path for fd 4, path lib couldn't allocate absolute path for 'lib'. tar: ./usr/lib: Cannot mkdir: Bad address tar: ./usr/lib/modules: Cannot mkdir: No such file or directory Re: i.MX8MP_EVK: YOCTO Compilation Error do_package() (Issue: tar & *at()) It seems that I don't have the permission to download the attachment. Would you please resend it again?

IW612 蓝牙射频测试 大家好， 我正在尝试对基于 IW612 的模块执行射频测试。为此，我参考了几份文件，例如： AN14310 - NXP 蓝牙 UART 驱动程序集成 AN14114 - Linux 操作系统上的射频测试模式 AN14163 - 蓝牙直连测试模式 还有其他人。 我遇到了一些问题： - 在 5 GHz Wi-Fi 频段中，我无法看到低频信道（接近 5 GHz）生成的波形，只能看到高频信道生成的波形。 - 对于蓝牙，我无法生成经典蓝牙的波形，只能生成 BLE 的波形（使用 hcitool 进行扫描和获取配对信息的命令运行正常，因此我认为这不是硬件问题）。 我的配置中，我使用的是 SoM Variscite Dart IMX8M（版本 2.0），配备基于 IW612 的 2EL 无线电。为了获取波形，我使用了 HackRF。 我使用的是内核版本为 6.6.23 的系统。Yocto 定制版本，固件为 sduart_nw61x_v1.bin.se，默认版本 HCI 命令的反馈与文档相符，但我看不到波形。如果我在系统或生成流程中遗漏了什么，请您帮忙看看。这是认证流程的一部分，现在我卡在这里了。 非常感谢 Re: IW612 Bluetooth RF Test Hello 能否将测试命令和结果截图分享给我们？ 顺祝商祺！ 肖恩 Re: IW612 Bluetooth RF Test 你好，肖恩， 当然。我运行了这些 hcitool 和 wifi 命令，并将最终的配置文件附在后面。 适用于蓝牙经典 ------------------------------------ 这些指令直接摘自 UM11490（第 149 页）。 # RESET root@oaslv:/home/hexagon# hcitool -i hci0 cmd 0x03 0x0003 < HCI 命令：ogf 0x03，ocf 0x0003，plen 0 > HCI 事件：0x0e plen 4 01 03 0C 00 # 启用扫描 root@oaslv:/home/hexagon# hcitool -i hci0 cmd 0x03 0x001a 0x3 < HCI 命令：ogf 0x03，ocf 0x001a，plen 1 03 > HCI 事件：0x0e plen 4 01 1A 0C 00 # 启用事件过滤器 root@oaslv:/home/hexagon# hcitool -i hci0 cmd 0x03 0x0005 0x02 0x00 0x02 < HCI 命令：ogf 0x03，ocf 0x0005，plen 3 02 00 02 > HCI 事件：0x0e plen 4 01 05 0C 00 # 进入测试模式 root@oaslv:/home/hexagon# hcitool -i hci0 cmd 0x06 0x0003 < HCI 命令：ogf 0x06，ocf 0x0003，plen 0 > HCI 事件：0x0e plen 4 01 03 18 00 # 启动TX变速器 root@oaslv:/home/hexagon# hcitool -i hci0 cmd 0x3F 0x0019 0x80 0x80 0x80 0x80 0x01 0x00 0x01 0x01 0x0D 0x03 0x0F 0x00 0x00 0x00 0x00 0x00 0x00 0x04 < HCI 命令：ogf 0x3f、ocf 0x0019、plen 18 80 80 80 80 01 00 01 01 0D 03 0F 00 00 00 00 00 00 04 > HCI 事件：0x0e plen 4 01 19 FC 00 # 停止TX传输 root@oaslv:/home/hexagon# hcitool -i hci0 cmd 0x3F 0x0019 0x80 0x80 0x80 0x80 0xF F 0x00 0x01 0x01 0x0D 0x03 0x0F 0x00 0x00 0x00 0x00 0x00 0x00 0x04 < HCI 命令：ogf 0x3f、ocf 0x0019、plen 18 80 80 80 80 FF 00 01 01 0D 03 0F 00 00 00 00 00 00 04 > HCI 事件：0xff plen 6 19 01 39 00 00 00 -------------------- 在发送数据之前停止对蓝牙低功耗 (BLE) 和经典蓝牙 (Classic) 的扫描 ---------------- # RESET root@oaslv:/home/hexagon# hcitool -i hci0 cmd 0x03 0x0003 < HCI 命令：ogf 0x03，ocf 0x0003，plen 0 > HCI 事件：0x0e plen 4 01 03 0C 00 # 启用扫描 root@oaslv:/home/hexagon# hcitool -i hci0 cmd 0x03 0x001a 0x3 < HCI 命令：ogf 0x03，ocf 0x001a，plen 1 03 > HCI 事件：0x0e plen 4 01 1A 0C 00 # 启用事件过滤器 root@oaslv:/home/hexagon# hcitool -i hci0 cmd 0x03 0x0005 0x02 0x00 0x02 < HCI 命令：ogf 0x03，ocf 0x0005，plen 3 02 00 02 > HCI 事件：0x0e plen 4 01 05 0C 00 # 进入测试模式 root@oaslv:/home/hexagon# hcitool -i hci0 cmd 0x06 0x0003 < HCI 命令：ogf 0x06，ocf 0x0003，plen 0 > HCI 事件：0x0e plen 4 01 03 18 00 # 禁用蓝牙扫描 root@oaslv:/home/hexagon# hcitool -i hci0 cmd 0x03 0x001a 0x0 < HCI 命令：ogf 0x03，ocf 0x001a，plen 1 00 > HCI 事件：0x0e plen 4 01 1A 0C 00 # 禁用经典扫描 root@oaslv:/home/hexagon# hcitool -i hci0 cmd 0x08 0x000C 0x00 0x00 < HCI 命令：ogf 0x08，ocf 0x000c，plen 2 00 00 > HCI 事件：0x0e plen 4 01 0C 20 00 # 启动TX变速器 root@oaslv:/home/hexagon# hcitool -i hci0 cmd 0x3F 0x0019 0x80 0x80 0x80 0x80 0x01 0x00 0x01 0x01 0x0D 0x03 0x0F 0x00 0x00 0x00 0x00 0x00 0x00 0x04 < HCI 命令：ogf 0x3f、ocf 0x0019、plen 18 80 80 80 80 01 00 01 01 0D 03 0F 00 00 00 00 00 00 04 > HCI 事件：0x0e plen 4 01 19 FC 00 # 停止TX传输 root@oaslv:/home/hexagon# hcitool -i hci0 cmd 0x3F 0x0019 0x80 0x80 0x80 0x80 0xFF 0x00 0x01 0x01 0x0D 0x03 0x0F 0x00 0x00 0x00 0x00 0x00 0x00 0x04 < HCI 命令：ogf 0x3f、ocf 0x0019、plen 18 80 80 80 80 FF 00 01 01 0D 03 0F 00 00 00 00 00 00 04 > HCI 事件：0xff plen 6 19 01 63 07 00 00 ** 在进入测试模式前禁用扫描时，TX 传输停止会显示以下信息： root@oaslv:/home/hexagon# hcitool -i hci0 cmd 0x3F 0x0019 0x80 0x80 0x80 0x80 0xFF 0x00 0x01 0x01 0x0D 0x03 0x0F 0x00 0x00 0x00 0x00 0x00 0x00 0x04 < HCI 命令：ogf 0x3f、ocf 0x0019、plen 18 80 80 80 80 FF 00 01 01 0D 03 0F 00 00 00 00 00 00 04 > HCI 事件：0xff plen 6 19 01 ED 04 00 00 适用于 5 GHz Wi-Fi -------------------------------------------------------------------------------- 参数：连续发射，带宽 = 40 MHz，802.11ac无DFS，CH = 40，MCS0（13.5），功率 = 14 dBm root@oaslv:/home/hexagon# cat /proc/mwlan/adapter0/config 硬件状态=0 netlink_num=31 驱动模式=7 hssetpara=7,0xff,200,400 sdcmd52rw=0 0x0 0x00 rf_test_mode=1 tx_antenna=1 接收天线=1 band=1 bw=1 频道=44 radio_mode[0]=3 radio_mode[1]= 总处方药包数=0 接收多播/广播数据包计数=0 接收函数调用错误数据包计数=0 发射功率=14 2 0 tx_continuous=0 tx_frame=1 4352 0xaaa 1024 1 20 4294967295 0 0 4294967295 0 0 0 -1 -1 -1 -1 -1 -1 -1 05:43:3f:c4:51:ff he_tb_tx=0 触发帧=0 otp_mac_add_rd_wr= 00:00:00:00:00:00

NXP S32K144 - オートモーティブの入門ガイド こんにちは、 私はNXP S32K144シリーズを初めて使用するので、開発環境をセットアップするための詳細な手順が必要です。もう少し詳しく教えていただけますか:   S32 Design Studioのどのバージョンが必要ですか? 標準 のSDK をインストールするべきか、 RTM/RTD のドライバーをインストールするべきか、どちらが良いでしょうか? この特定のハードウェアシリーズにはどんな追加の ドライバやソフトウェアパッケージ が必要ですか? S32K1 Re: Getting started guide for NXP S32K144 - Automotive こんにちは、 @Buddynさん 特に技術を使い始めたばかりの方は、最新のソフトウェアリリースやツールのバージョンを常におすすめします。 S32K1デバイス向けの最新ソフトウェアリリースはRTD 3.0.0です。これはS32 Design Studio(S32DS)3.6.6で開発・検証されました。しかし、私の経験では、より新しいS32DS 3.6.xでも問題なく動作します。バージョン。したがって、最新のS32DS 3.6リリースをダウンロードして使用することをお勧めします。 これでプラットフォームの使い始めには十分でしょう。追加で必要になるソフトウェアパッケージは、アプリケーションの具体的な要件によって異なります。 S32K1デバイス向けの他のソフトウェアパッケージや例を探りたい場合は、 S32K1リファレンスソフトウェアへアクセスできます。 BR、VaneB Re: Getting started guide for NXP S32K144 - Automotive このRTDベースのソフトウェアについて。それに関するオープンソースのファームウェアのサンプルはありますか？ NXPにはs32DSの設定(クロック、ピン、ペリフェラル)に関するリファレンスやトレーニングセクションはありますか?もしそうなら、参考リンクを教えてください。 前もって感謝します

MCXW72 Matterロックの例として、Aliroミドルウェアの制御アクセスリクエスト NXPサポートの皆様、 私はルーヴェン・カトリック大学／COSICで応用暗号学の博士研究員をしています。私はCSA Aliro 1.0 Reader SDKの学術実装、セキュリティ、相互運用性に関する研究を行っています。 ダウンロードしました： MCUXpresso SDK 26.06.00 for MCX-W72-EVK; 対応するMCUXpresso設定ツールパッケージ、 mcuxsdk-examples-マター-release-v1.4.2; NXPのMatterのlock-app-aliroの例です。 マターの例では、以下の制御ミドルウェアが求められます: > /middleware/aliro/aliro_sdk.cmake しかし、AliroミドルウェアはMCXW72 SDK Builderパッケージやマターの例アーカイブには含まれていません。 MCUXpresso SDK 26.06.00およびMatter Aliroロックの例に対応したAliroミドルウェアパッケージの完全なアクセスを教えていただけますか? 当該資料は、許可された学術分析のみに使用され、適用されるライセンスまたは秘密保持契約に従って取り扱われます。 敬具、 サヨン・ダッタグプタ ポスドク研究員 COSIC、ルーヴェン・カトリック大学   セキュリティ（EdgeLock | セキュアブート | OTP）

DSP Implementation: Microcontrollers or FPGAs Hi, I know this is a topic which has come up again and again on this sub, but I just needed some domain-specific advice from the people in the field here. What I wanted to know is that, if am interested in the DSP applications in Communications field and want to work on implementations for the same, is it worthwhile spending my time learning about microcontroller programming? Am an ECE undergrad, so I was wondering if I should directly focus on FPGAs, which are more interesting to me, honestly. I am confused because I have seen people recommend that you really do need embedded software programming skills to work with the SOCs that are being used more and more now. Really apologise if it's a redundant question! I just haven't been able to find a proper answer regarding the same, and am at a point right now where I might have to prioritise things just a tad bit. Would really appreciate any advice!

IMXRT EDMAエラーIRQハンドラはSDKには実装されていません こんにちは、 SDK内のIMXRT EDMA APIは「ハッピーケース」割り込みを正しく処理しているようです。しかし、エラー割り込みを処理するための仕組みは見当たらないようだ。それだけでなく、すべてのDMAに対して1つのグローバルなDMA_ERROR_IRQHandlerが存在するようです。例えばDMA0とDMA1の両方を使っている場合、状況が「良好」な状態にあるときにDMA0/DMA1のIRQHandlerが呼び出され、SDKがどのDMAがハッピーインタラプトを受け取ったかを識別できます。しかし、DMAエラーが発生した場合、グローバルなエラー割り込みハンドラが1つしかないため、どのDMA（0、1、またはその他）でエラーが発生したかを簡単に知る方法はありません。 以前の質問で、LPUARTエラーIRQ処理について質問したのと同様です。なぜこれがSDKに組み込まれていて、DMAエラーを処理したり適切なコールバックを呼び出したりしないのでしょうか?今は、エラーがどのDMAにあるかを手作業で特定し、SDK外の特別な処理を呼ぶ方法を考えなければなりません。単にコールバックを呼んでもらうのではなく。 本番コードで使えるはずのSDKにしては、堅牢性の機能が欠けているように思えますし、多くの人はこれらのエラーがSDKによって処理されていると思い込んでいて、実際にはそうではないという事実を考えていないのだと思います。 -m Re: IMXRT EDMA error IRQ handler is not implemented in the SDK @nxp16様、 どのi.MX RTデバイスをお使いですか？DMA0とDMA1の話ですが、2つのDMAコントローラペリフェラルではなく、2つのDMAチャネルのことを指していますか? すべての i.MX RTデバイスに2つのeDMAコントローラーがあるわけではありません。例えば： i.MX RT1180には2つのeDMAコントローラが含まれています。スタートアップファイル(例:startup_mimxrt1189_cm33.c)には、DMA_ERROR_IRQHandlerとDMA4_ERROR_IRQHandlerの2つのDMAエラーハンドラがあります。 i.MX RT1050にはeDMAコントローラが1つしかありません。起動ファイル（例えば、startup_mimxrt1052.c）では、DMAエラーハンドラはDMA_ERROR_IRQHandlerという1つだけです。 一般的に、DMAエラーは比較的まれなイベントです。ハードウェアアーキテクチャの観点からは、チャネルエラーの状態はモジュールレベルのエラー要求に集約され、DMAエラー割り込みを引き起こします。したがって、ソフトウェアは各チャネルのエラーステータスレジスタ(例えばCHn_ES)を調べ、どの特定のチャネルがエラーを引き起こしたかを特定しなければなりません。 よろしくお願いいたします。 シェリー・チャン Re: IMXRT EDMA error IRQ handler is not implemented in the SDK すみません、チャネルのことを言いました。私はIMXRT1172を使用しています。 もし使っていた周辺機器に問題があった場合、DMAエラーは起こるのではないでしょうか?つまり、LPSPIとDMAを組み合わせた場合、SPIエラーが発生するとDMAエラーも発生するのではないでしょうか？そうでない場合、DMA使用時のSPIエラーはSPIエラー割り込みをトリガーしますか？ ありがとうございます -m Re: IMXRT EDMA error IRQ handler is not implemented in the SDK @nxp16様、 いいえ。DMA使用中に周辺エラーが発生しても、必ずしもDMAコントローラ自体がエラーを報告するわけではありません。ほとんどの場合、SPIエラーとDMAエラーは2つの別々のステータスおよび割り込み機構で処理されます。 DMAは、DMA、バス、または転送層のエラーのみを報告します。LPSPIにおけるプロトコルレベルまたはFIFO関連のエラーは、LPSPIペリフェラル自身のステータスフラグやエラー割り込みを通じて処理されるべきです。DMAモードで動作させた場合でも、すべてのSPIエラーが自動的にDMAエラーに変換されるわけではありません。 よろしくお願いいたします。 シェリー・チャン Re: IMXRT EDMA error IRQ handler is not implemented in the SDK やはりそうだったか。その場合、SDKの転送APIはさらに堅牢性が低くなります。SDK外でペリフェラルやDMAエラーを処理しなければならない場合、デフォルトのIRQハンドラをやや巧妙にオーバーライドしたり、エラープロセッシング後もSDKハンドラーに呼び出すようにするなど、かなりの追加作業が必要です。これらの機能がSDKの転送APIに含まれていないのは非常に落胆します。 Re: IMXRT EDMA error IRQ handler is not implemented in the SDK @nxp16様、 ご懸念は理解できますし、SDKトランスファーAPIと別にペリフェラルエラーを扱うことで必要なアプリケーションレベルのコード量が増えることに同意します。ご意見ありがとうございます。皆さんのご意見はSDKチームにお伝えします。 よろしくお願いいたします。 シェリー・チャン Re: IMXRT EDMA error IRQ handler is not implemented in the SDK 実際は、思っていたよりもひどい。EDMA LPSPI転送APIを使用すると、LPSPI_MasterTransferEDMAが呼び出す関数LPSPI_PrepareTransferEDMAがすべてのSPI割り込みを無効にするため、SPIエラーを捕捉できなくなります。そのため、エラー割り込みを呼び出し前に有効にすることは不可能で、再度無効化され、SPI EDMA転送がすでに進行中なので遅すぎます。これはこのAPIの重大なバグです。 -m

Request for controlled-access Aliro middleware for MCXW72 Matter lock example Dear NXP Support, I am a postdoctoral researcher in applied cryptography at KU Leuven/COSIC. I am conducting an academic implementation-security and interoperability study of CSA Aliro 1.0 Reader SDKs. I downloaded: MCUXpresso SDK 26.06.00 for MCX-W72-EVK; the corresponding MCUXpresso Config Tools package; mcuxsdk-examples-matter-release-v1.4.2; the NXP Matter lock-app-aliro example. The Matter example expects the following controlled middleware: >  /middleware/aliro/aliro_sdk.cmake However, the Aliro middleware is not present in the MCXW72 SDK Builder package or in the Matter example archive. Could you please provide access to the complete Aliro middleware package compatible with MCUXpresso SDK 26.06.00 and the Matter Aliro lock example? The material will be used solely for authorised academic analysis and will be handled according to any applicable licence or NDA. Kind regards, Sayon Duttagupta Postdoctoral Researcher COSIC, KU Leuven   Security(Edgelock | secure boot | OTP)

SDK 中未实现 IMXRT EDMA 错误 IRQ 处理程序。 您好， SDK 中的 IMXRT EDMA API 似乎能够正确处理“正常情况”中断。然而，似乎没有任何处理错误中断的机制。不仅如此，似乎所有 DMA 都只有一个全局的 DMA_ERROR_IRQHandler。因此，如果您同时使用 DMA0 和 DMA1，当一切正常时，DMA0/DMA1 IRQHandler 将被调用，SDK 可以区分哪个 DMA 收到了正常中断。但是，如果出现 DMA 错误，由于只有一个全局错误中断处理程序，因此没有简单的方法可以知道错误发生在哪个 DMA（0 或 1 或其他）上。 就像我之前关于 LPUART 错误 IRQ 处理的问题一样。为什么 SDK 没有内置处理 DMA 错误并调用相应回调的功能？现在我必须手动确定错误发生在哪个 DMA 上，并在 SDK 之外调用特殊处理，而不是让它为我调用回调。 对于一个本应在生产代码中使用的 SDK 来说，似乎缺少很多健壮性功能，我敢打赌大多数人只是假设这些错误是由 SDK 在底层处理的，而没有考虑到它们实际上并没有被处理。 -m Re: IMXRT EDMA error IRQ handler is not implemented in the SDK 尊敬的@nxp16 ， 您使用的是哪款 i.MX RT 设备？当您提到 DMA0 和 DMA1 时，您指的是两个 DMA 通道，还是两个 DMA 控制器外设？ 并非所有 i.MX RT 设备都具有两个 eDMA 控制器。例如： i.MX RT1180 包含两个 eDMA 控制器。在启动文件（例如 startup_mimxrt1189_cm33.c）中，您可以找到两个 DMA 错误处理程序：DMA_ERROR_IRQHandler 和 DMA4_ERROR_IRQHandler。 i.MX RT1050 仅包含一个 eDMA 控制器。在启动文件（例如 startup_mimxrt1052.c）中，只有一个 DMA 错误处理程序：DMA_ERROR_IRQHandler。 一般来说，DMA 错误是相对不常发生的事件。从硬件架构的角度来看，通道错误状态被聚合为模块级错误请求，从而触发 DMA 错误中断。因此，该软件必须检查每个通道的错误状态寄存器（例如，CHn_ES），以确定哪个特定通道导致了错误。 顺祝商祺！ 张雪莉 Re: IMXRT EDMA error IRQ handler is not implemented in the SDK 抱歉，我指的是频道。我使用的是 IMXRT1172。 如果与之连接的外设出现问题，难道不会发生DMA错误吗？也就是说，如果是 LPSPI 和 DMA，那么任何 SPI 错误都会导致 DMA 错误吗？如果不是，那么在使用DMA时，SPI错误是否会触发SPI错误中断？ 谢谢！ -m Re: IMXRT EDMA error IRQ handler is not implemented in the SDK 尊敬的@nxp16 ， 不。在使用DMA时发生的外围设备错误并不一定意味着DMA控制器本身会报告错误。大多数情况下，SPI 错误和 DMA 错误由两个独立的状态和中断机制处理。 DMA 只报告 DMA 层、总线层或传输层错误。LPSPI 中的协议级或 FIFO 相关错误应通过 LPSPI 外设自身的状态标志和错误中断来处理。以 DMA 模式运行并不会自动将所有 SPI 错误转换为 DMA 错误。 顺祝商祺！ 张雪莉 Re: IMXRT EDMA error IRQ handler is not implemented in the SDK 我猜也是这样。在这种情况下，SDK 的传输 API 就更不可靠了。必须在 SDK 之外处理外围设备和 DMA 错误，这需要相当多的额外工作，包括对默认 IRQ 处理程序进行一些变通的覆盖，并确保它们在处理任何错误后仍然调用 SDK 处理程序。令人沮丧的是，这些内容并未包含在 SDK 传输 API 中。 Re: IMXRT EDMA error IRQ handler is not implemented in the SDK 尊敬的@nxp16 ， 我理解您的担忧，我也同意将外围错误状态的处理与 SDK 传输 API 分开处理可能会增加所需的应用程序级代码量。感谢您的反馈。我会将您的意见转达给SDK团队。 顺祝商祺！ 张雪莉 Re: IMXRT EDMA error IRQ handler is not implemented in the SDK 实际上，情况比我想象的还要糟糕。使用 EDMA LPSPI 传输 API 无法捕获 SPI 错误，因为 LPSPI_MasterTransferEDMA 调用的函数LPSPI_PrepareTransferEDMA会禁用所有 SPI 中断。因此，在调用它之前不可能启用错误中断，因为它会再次禁用它们，而之后就太晚了，因为 SPI EDMA 传输已经开始了。这是该API的一个重大漏洞。 -m

Assistance Required for VSC8254 PHY Bring-up in 1G SGMII Mode on LX2160A Hello everyone, We are working on a custom board based on the LX2160A Rev2 SoC, where the VSC8254 PHY is connected to the SoC through eMDIO1. We are currently facing issues while bringing up the PHY in 1G SGMII mode. So far, we have successfully brought up the PHY in 10G XFI mode by configuring a fixed link in both the DPC file and the Linux kernel Device Tree. After booting, we execute the NXP-provided mdio_cl45_write script to program the required Clause 45 registers, following which the link comes up and operates correctly. However, when we switch the configuration to 1G SGMII mode, we make the following changes: Update the DPC and Linux Device Tree to use SGMII instead of XFI. Execute the corresponding Clause 45 register initialization sequence for 1G. Update the SERDES reference clock from 125 MHz to 100 MHz, as required for the new configuration. Despite these changes, the PHY link does not come up. For reference: The VSC8254 PHY is connected to SERDES1 MAC3 and MAC4. We are using RCW 6 for the 10G XFI configuration. We are using RCW 4 for the 1G SGMII configuration. Could you please let us know if there are any additional configuration changes or initialization steps required to bring up the PHY in 1G SGMII mode? Thank you for your time and support. @yipingwang @chenyin_h  Re: Assistance Required for VSC8254 PHY Bring-up in 1G SGMII Mode on LX2160A 1. Please configure RCW[SRDS_PLL_REF_CLK_SEL_S1] as "00". 2. In Linux Kernel, please configure "CONFIG_VITESSE_PHY". 3. In Linux Kernel dts file arch/arm64/boot/dts/freescale/fsl-lx2160a-rdb.dts, please modify dpmac3 and dpmac4 configuration similar as the following. &dpmac3 { phy-handle = <&aquantia_phy1>; phy-connection-type = "usxgmii"; managed = "in-band-status"; }; aquantia_phy1: ethernet-phy@4 { /* AQR107 PHY */ compatible = "ethernet-phy-ieee802.3-c45"; interrupts-extended = <&extirq 2 IRQ_TYPE_LEVEL_LOW>; reg = <0x4>; }; Modify to: &dpmac3 {         phy-handle = <&sgmii_phy1>;         phy-connection-type = "sgmii";         managed = "in-band-status"; };         sgmii_phy1: ethernet-phy@xx{                 reg = <0xxx>;//specify dpmac3 related MDIO PHY address         }; 4. Please modify dtc file dpc-usxgmii.dts as the following.        board_info {                 ports {                         mac@3 {                                 link_type = "MAC_LINK_TYPE_PHY";                                 enet_if = "USXGMII";                         };                         mac@4 {                                 link_type = "MAC_LINK_TYPE_PHY";                                 enet_if = "USXGMII";                         }; Modify to:         board_info {                 ports {                         mac@3 {                                 link_type = "MAC_LINK_TYPE_PHY";                         };                         mac@4 {                                 link_type = "MAC_LINK_TYPE_PHY";                         };