Multi Source Translation Content

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

Multi Source Translation Content

Discussions

Sort by:
促销优惠券 您好, 为什么我的促销优惠券“ADCWFBXT”对FRDM-MCXN236无效? 普拉莫德·乔格卡 [email protected] 开发板 FRDM 培训 Re: PROMO Coupon 连我都无法使用FRDM-MCXN236 的促销优惠券。 Re: PROMO Coupon 请注意,优惠券 ADCWFBXT 的有效期至 2025 年 12 月 30 日。正如我们网站上所说: FRDM 创新——由我们负责!   祝您今天愉快。 Re: PROMO Coupon FRDM-MCXN236主板还有其他优惠券吗?
View full article
8MPLUSLPD4-PEVK – 現在のeMMCおよびQSPIメモリ構成 こんにちは、 現在出荷されている8MPLUSLPD4-PEVKのメモリ構成を確認させていただきたい。 現在のNXP製品ページには次のように記載されています: 6 GB LPDDR4 16GB eMMC 64 MB QSPI しかし、NXPのPEVKクイックスタートガイドには次のように記載されています。 6 GB LPDDR4 32GB eMMC 32 MB QSPI NXPのライブチャットサポートは、製品ページが現在のハードウェアリビジョンを表している可能性が高く、クイックスタートガイドは以前のバージョンを指している可能性があると示唆しましたが、i.MX 技術チームに確認することを勧めました。 NXPの方が現行の8MPLUSLPD4-PEVKハードウェアリビジョンのeMMCおよびQSPI容量を確認できますか? よろしくお願いします。 Re: 8MPLUSLPD4-PEVK – current eMMC and QSPI memory configuration こんにちは、 NXP Semiconductors製品にご関心いただきありがとうございます。 手元にある8MPLUSLPD4-PEVKで確認したところ、構成は32GBのeMMCと32MBのQSPIでした。最新の回路図リビジョンを確認したところ、どのリビジョンでもメモリの再構成は行われておらず、注文時に同じメモリが届くはずです。 私たちのチームが製品ページをレビューします。共有してくださりありがとうございます。 よろしくお願いします。
View full article
プロモーションクーポン こんにちは、 私のプロモーションクーポン「ADCWFBXT」がFRDM-MCXN236に有効でないのはなぜですか? プラモド・ジョグレカール [email protected] 開発ボード FRDMトレーニング Re: PROMO Coupon 私もFRDM-MCXN236のプロモーションクーポンを使うことができませんでした。 Re: PROMO Coupon クーポンコードADCWFBXTは2025年12月30日まで有効でしたのでご注意ください。当社のウェブサイトに記載されているとおり、 FRDMはイノベーションを推進します。費用は当社が負担します!   良い一日をお過ごしください。 Re: PROMO Coupon FRDM-MCXN236ボード用の他のクーポンはありますか?
View full article
2-CH CAN HAT with FRDM-IMX93 Enabling a 2-Channel CAN HAT (MCP2515) on the NXP i.MX93 FRDM Board This article documents the process of adding hardware support for a 2-Channel CAN HAT from WaveShare using dual Microchip MCP2515 controllers over SPI on the NXP i.MX93 FRDM evaluation board. By default, the board exposes native FlexCAN interfaces, but utilizing a popular Raspberry Pi-compatible CAN HAT requires customizing the Linux device tree and kernel configuration. Prerequisites Hardware: NXP i.MX93 FRDM board, 2-Channel CAN HAT. Software: NXP Linux BSP (Tested in 6.18.y). Toolchain: Toolchain obtained from Yocto (Refer to the 4.5.12 How to build U-Boot and Kernel in standalone environment from i.MX Linux User's Guide). Step 1: Modify the Device Tree We need to edit the main board device tree file  arch/arm64/boot/dts/freescale/imx93-11x11-frdm.dts  to configure the SPI master, add the dual MCP2515 nodes, assign interrupt pins, and disable conflicting native interfaces. The key changes: Power Regulators: Ensured the expansion connectors ( VEXP_3V3 and VEXP_5V ) correctly pull up and preserve state using pinctrl-assert-gpios . Fixed Clock: Defined an external 16MHz clock element required by the MCP2515 crystal oscillators. FlexCAN Deactivation: Disabled conflicting native flexcan2 nodes sharing pins. LPSPI3 Configuration: Replaced the default spidev dummy node with two microchip,mcp2515 nodes, adding two distinct Chip Select (CS) pins ( GPIO2_IO08 and GPIO2_IO07 ) and mapping the respective hardware interrupts ( GPIO2_IO23 and GPIO2_IO25 ). Device Tree Git Diff: diff --git a/arch/arm64/boot/dts/freescale/imx93-11x11-frdm.dts b/arch/arm64/boot/dts/freescale/imx93-11x11-frdm.dts index 18afe964e020..7b3af73f144f 100644 --- a/arch/arm64/boot/dts/freescale/imx93-11x11-frdm.dts +++ b/arch/arm64/boot/dts/freescale/imx93-11x11-frdm.dts @@ -134,6 +134,7 @@ reg_vexp_3v3: regulator-vexp-3v3 { compatible = "regulator-fixed"; regulator-name = "VEXP_3V3"; gpio = <&pcal6524 2 GPIO_ACTIVE_HIGH>; + pinctrl-assert-gpios = <&pcal6524 2 GPIO_ACTIVE_HIGH>; regulator-min-microvolt = <3300000>; regulator-max-microvolt = <3300000>; enable-active-high; @@ -144,6 +145,7 @@ reg_vexp_5v: regulator-vexp-5v { compatible = "regulator-fixed"; regulator-name = "VEXP_5V"; gpio = <&pcal6524 8 GPIO_ACTIVE_HIGH>; + pinctrl-assert-gpios = <&pcal6524 8 GPIO_ACTIVE_HIGH>; regulator-min-microvolt = <5000000>; regulator-max-microvolt = <5000000>; enable-active-high; @@ -269,6 +271,15 @@ K3: user_btn2 { interrupts = <6 IRQ_TYPE_EDGE_FALLING>; }; }; + + clocks { + clk16m: clk16m { + compatible = "fixed-clock"; + #clock-cells = <0>; + clock-frequency = <16000000>; + clock-output-names = "clk16m"; + }; + }; }; &adc1 { @@ -292,7 +303,7 @@ &flexcan2 { pinctrl-0 = <&pinctrl_flexcan2>; pinctrl-1 = <&pinctrl_flexcan2_sleep>; xceiver-supply = <&reg_can2_stby>; - status = "okay"; + status = "disabled"; }; &mu1 { @@ -620,15 +631,29 @@ typec1_dr_sw: endpoint { &lpspi3 { pinctrl-names = "default"; pinctrl-0 = <&pinctrl_lpspi3>; - cs-gpios = <&gpio2 8 GPIO_ACTIVE_LOW>; - pinctrl-assert-gpios = <&pcal6408 0 GPIO_ACTIVE_HIGH>; + cs-gpios = <&gpio2 8 GPIO_ACTIVE_LOW>, <&gpio2 7 GPIO_ACTIVE_LOW>; + pinctrl-assert-gpios = <&pcal6408 0 GPIO_ACTIVE_LOW>; status = "okay"; - spidev0: spi@0 { + can0: can@0 { + compatible = "microchip,mcp2515"; reg = <0>; - compatible = "lwn,bk4"; - spi-max-frequency = <1000000>; + clocks = <&clk16m>; + interrupt-parent = <&gpio2>; + interrupts = <23 IRQ_TYPE_LEVEL_LOW>; + spi-max-frequency = <10000000>; }; + + can1: can@1 { + compatible = "microchip,mcp2515"; + reg = <1>; + clocks = <&clk16m>; + interrupt-parent = <&gpio2>; + interrupts = <25 IRQ_TYPE_LEVEL_LOW>; + spi-max-frequency = <10000000>; + }; + + }; &lpuart1 { /* console */ @@ -894,9 +919,12 @@ MX93_PAD_GPIO_IO29__LPI2C3_SCL 0x40000b9e pinctrl_lpspi3: lpspi3grp { fsl,pins = < MX93_PAD_GPIO_IO08__GPIO2_IO08 0x39e + MX93_PAD_GPIO_IO07__GPIO2_IO07 0x39e MX93_PAD_GPIO_IO09__LPSPI3_SIN 0x39e MX93_PAD_GPIO_IO10__LPSPI3_SOUT 0x39e MX93_PAD_GPIO_IO11__LPSPI3_SCK 0x39e + MX93_PAD_GPIO_IO23__GPIO2_IO23 0x39e + MX93_PAD_GPIO_IO25__GPIO2_IO25 0x39e >; }; After modifying the file, compile your device tree blobs (.dtb) and deploy them to your target boot partition. You can refer to the below post to know the process: How to compile Linux Kernel Image and device tree using Yocto SDK. Step 2: Enable Kernel Driver Support The MCP251x driver must be enabled within the Linux kernel configuration framework. Run the configuration tool: user@host:~/linux-imx$ make menuconfig Navigate through the menu to enable the driver either statically ( [*] ) or as a module ( [M] 😞 [*] Networking support <*> CAN bus subsystem support <*> Raw CAN Protocol (raw access with CAN-ID filtering)   <*> Broadcast Manager CAN Protocol (with content filtering) <*> CAN Gateway/Router (with netlink configuration) And: Device Drivers [*] Network device support <*> CAN Device Drivers CAN SPI interfaces <*> Microchip MCP251x and MCP25625 SPI CAN controllers <*> Microchip MCP251xFD SPI CAN controllers Save your configuration and compile your kernel/modules. Step 3: Initialize and Test Interfaces Once the board boots with the new device tree and kernel, you should see two new network interfaces listed under ip link show ( can0 and can1 ). Manuel_Salas_0-1790114307590.png Now, you can setup the CAN interfaces: $ sudo ip link set can0 up type can bitrate 1000000 $ sudo ip link set can1 up type can bitrate 1000000 $ sudo ifconfig can0 txqueuelen 65536 $ sudo ifconfig can1 txqueuelen 65536 Connect the HAT in loopback: Manuel_Salas_5-1790114793732.png From Interface can0: candump can0 From interface can1: cansend can1 000#11.22.33.44 Manuel_Salas_1-1790114548204.png Manuel_Salas_2-1790114560757.png Manuel_Salas_3-1790114583087.png Hope this can be helpful. Best regards, Salas. i.MX93
View full article
External Boot S32k Does the S32k344 device initially execute an immutable first-stage bootloader from internal ROM? If so, can this ROM bootloader be configured to load a secondary bootloader (or application image) from an external source, such as external flash? If external boot is supported, how would this be configured so the initial bootloader knows where to pull from? Re: External Boot S32k Hi @CTCoder1  Yes, S32K344 contains SBAF code which is executed after reset. However, this should not be considered a configurable bootloader that can directly load an application from an arbitrary external memory. External boot is not supported. The normal S32K3 boot flow expects the boot information/application in the internal code flash only. For example, a user bootloader can be placed at the beginning of internal flash (IVT at 0x00400000) and then execute whatever update/loading mechanism is required.  So, if the intention is to store an application in an external flash, the usual solution is to have user bootloader in internal flash. This bootloader initializes the required peripheral/external memory interface, reads the image from the external device and then either programs it into internal flash or handles it according to the application's requirements. There is no SBAF (or we can say BootROM) configuration where you simply specify an external flash address/device and have the S32K344 SBAF boot the application directly from there. This needs to be managed completely by your software. Regards, Lukas
View full article
S32K3xxマスターECUキーまたはCUST/OEM認証キーのインポート こんにちは、NXPさん。 いつもサポートしてくださりありがとうございます。 FBL関連のお問い合わせに対する以前のご回答に基づき、ライフサイクルがインフィールド状態にある場合、スーパーユーザー(SU)権限を取得するには、MASTER_ECU_KEYまたはCUST/OEM認証キーのいずれかを事前にプロビジョニングしておく必要があり、デバイスが既にインフィールド状態にある場合は、MASTER_ECU_KEYのプロビジョニングは不可能であると理解いたしました。 私たちの理解が正しいか確認していただけますか? 現在、これら2つのキーはどちらもプロビジョニングされていません。今後同様の問題が起きないように、MASTER_ECU_KEYまたはCUST/OEM認証キーのいずれかを事前にプロビジョニングし、NVM/RAMキーカタログをフォーマットし、デバイスがインフィールド状態に入った後にHMACキーを注入できるようにしたいと考えています。 いくつか質問があります。 1.このプロジェクトでは、FBL認証はSHEに基づいていません。その代わりに、RSA公開鍵署名検証方式を採用している。ただし、CRYPTO_SPT_SHE は STD_ON に設定されています。 この場合、MASTER_ECU_KEYをプロビジョニングすべきか、それともCUST/OEM認証キーをプロビジョニングすべきか? 2. MASTER_ECU_KEYやCUST/OEM認証キーのインポート方法を説明するガイドやドキュメントはありますか? ありがとうございます。 よろしくお願いいたします。 Re: S32K3xx Master_ECU_KEY or CUST/OEM authorization key import こんにちは、 @jeongwoo 認証キーは、現在のライフサイクルと、操作に使用するキーの所有者に応じてプロビジョニングする必要があります。 CUST_DELでは、CUST認証キーをプロビジョニングできます。デバイスをOEM_PRODに進めると、OEM認証キーをプロビジョニングし、それを使ってOEM所有キーのスーパーユーザー権を取得することができます。 CUST_DEL中はOEM所有の鍵をプロビジョニングすることはできません。なぜなら、その時点で操作を承認できるOEM認可キーが持っていないからです。したがって、必要な所有者向けのキーカタログは、デバイスがライフサイクルを進める前に、CUST_DEL状態にある間に既に定義しておく必要があります。 OEM_PRODに移行した後は、キーカタログのフォーマットがCUST_DELに制限されるため、カタログの再フォーマットはできません。このライフサイクルの移行は不可逆的である。 ですので、CUSTとOEMの両方の認可機能を持つつもりなら、まずカタログで必要なCUSTおよびOEMキーグループを定義し、CUST_DELでCUST認証キーをプロビジョニングし、OEM_PRODに進み、最後にOEM認証キーをプロビジョニングしてください。 詳細はこのスレッドをご覧ください: https://community.nxp.com/t5/S32K/Change-is-not-possible-in-LC-OEM-PROD/m-p/2356576 HSEレベルでは、キーインポート手順はHSE-Bファームウェアリファレンスマニュアルの「6.2.3 キーインポート」セクションで説明されています。2.8の後に、HSEファームウェアバージョンのHSE Service APIリファレンスマニュアルにある「struct hseImportKeySrv_t」の説明を参照してください。 On AUTOSAR Crypto ドライバ level, it is given by AUTOSAR specification.Crypto_43_HSE_KeyElementSet()およびCrypto_43_HSE_KeySetValid()APIの説明はRTD_CRYPTO_43_HSE_UM.pdfで読むことができます。 認証キーは他のキーと同様の方法でインポートされますが、コンフィギュレータでそのキーに対してUSAGE_AUTHORIZATIONとUSAGE_VERIFYのキーフラグを設定する必要があります。 よろしくお願いいたします。 ルーカス
View full article
BMA8420の完全なデータシートを入手するにはどうすればよいですか?製品概要ではありません   件名:水素燃料電池スタックのEIS測定用BMA8420に関するお問い合わせ   技術サポートチームの皆様へ、 私は現在、水素燃料電池用の電気化学インピーダンス分光法(EIS)測定システムを開発しています。   BMA8420を利用するために、その技術仕様を確認したいのですが、オンラインでデータシートを見つけることができませんでした。   以下の質問について、ご助言いただければ大変ありがたいです。 このBMA8420は水素燃料電池スタックのEISを測定するために使えますか? BMA8420の完全なデータシート(製品ブリーフではない)はどうやって入手できますか? 韓国の連絡先は? ご支援ありがとうございます。皆様からのご連絡を楽しみにしています。   よろしくお願いします、 ヤング、キム     BMA8420 <-- リンク image.png #BMA8420
View full article
S32K3xx Master_ECU_KEY or CUST/OEM authorization key import Hello NXP, Thank you as always for your support. Based on your previous response regarding our FBL-related inquiry, we understood that when the Life-Cycle is in the In-Field state, either the MASTER_ECU_KEY or a CUST/OEM authorization key must have been provisioned in advance in order to obtain SuperUser (SU) authority, and that provisioning the MASTER_ECU_KEY is not possible once the device is already in the In-Field state. Could you please confirm whether our understanding is correct? Currently, neither of these two keys has been provisioned. To prevent similar issues from occurring in the future, we would like to provision either the MASTER_ECU_KEY or a CUST/OEM authorization key in advance, so that we can format the NVM/RAM key catalog and inject the HMAC key after the device enters the In-Field state. We have a few questions as follows: 1. In this project, FBL authentication is not based on SHE. Instead, it uses RSA public-key signature verification. However, CRYPTO_SPT_SHE is configured as STD_ON. In this case, should we provision the MASTER_ECU_KEY, or should we provision a CUST/OEM authorization key? 2. Is there any guide or reference documentation that describes how to import the MASTER_ECU_KEY or a CUST/OEM authorization key? Thank you. Best regards, Re: S32K3xx Master_ECU_KEY or CUST/OEM authorization key import Hi @jeongwoo  The authorization key should be provisioned according to the current lifecycle and the key owner you need to operate with. In CUST_DEL, you can provision the CUST authorization key. Once you advance the device to OEM_PROD, you can provision the OEM authorization key and use it to obtain Super User rights for OEM-owned keys. You cannot provision an OEM-owned key while still in CUST_DEL, because at that point you do not have an OEM authorization key that could authorize the operation. Therefore, the key catalogs for the required owners should already be defined while the device is in CUST_DEL, before advancing the lifecycle. After moving to OEM_PROD, the catalogs cannot be reformatted, because key catalog formatting is restricted to CUST_DEL. This lifecycle transition is also irreversible. So, if your intention is to have both CUST and OEM authorization capabilities, define the required CUST and OEM key groups in the catalogs first, provision the CUST authorization key in CUST_DEL, advance to OEM_PROD, and then provision the OEM authorization key. You can take a look at this thread for details: https://community.nxp.com/t5/S32K/Change-is-not-possible-in-LC-OEM-PROD/m-p/2356576 On HSE level, the key import procedure is described in section “6.2.3  Key Import” in HSE-B Firmware reference manual rev. 2.8 and then see the description of “struct hseImportKeySrv_t” in HSE Service API reference manual of your HSE firmware version. On Autosar Crypto driver level, it is given by Autosar specification. You can read description of Crypto_43_HSE_KeyElementSet() and Crypto_43_HSE_KeySetValid() API in RTD_CRYPTO_43_HSE_UM.pdf. Authorization keys are imported in the same way as other keys, it’s just necessary to set USAGE_AUTHORIZATION and USAGE_VERIFY key flags for that key in your configurator. Regards, Lukas
View full article
如何获取BMA8420的完整数据手册?非产品简介   主题:关于氢燃料电池堆电化学阻抗谱测量用BMA8420的咨询   尊敬的技术支持团队: 我目前正在开发用于氢燃料电池的电化学阻抗谱(EIS)测量系统。   为了使用BMA8420 ,我想查看其技术规格,但我一直没能在网上找到数据表。   非常感谢您能就以下问题提供指导: BMA8420 能否用于测量氢燃料电池堆的电化学阻抗谱 (EIS)? 如何获取BMA8420的完整数据手册(非产品简介)? 韩国的联系点? 感谢您的支持,期待您的回复。   此致, 金杨     BMA8420 <-- 链接 image.png #BMA8420
View full article
外部启动 S32k S32k344 设备最初是否从内部 ROM 执行不可变的第一阶段引导加载程序?如果可以,能否将此 ROM 引导加载程序配置为从外部源(例如外部闪存)加载辅助引导加载程序(或应用程序映像)? 如果支持外部启动,应该如何配置才能让初始引导加载程序知道从哪里获取启动项? Re: External Boot S32k 嗨@CTCoder1 是的,S32K344 包含 SBAF 代码,该代码在 RESET 后执行。然而,这不应被视为可以直接从任意外部存储器加载应用程序的可配置引导加载程序。不支持外部启动。 正常的 S32K3 启动流程仅要求启动信息/应用程序位于内部代码闪存中。例如,可以将用户引导加载程序放置在内部闪存的开头(IVT 地址为 0x00400000),然后执行所需的任何更新/加载机制。 因此,如果目的是将应用程序存储在外部闪存中,通常的解决方案是将用户引导加载程序放在内部闪存中。该引导加载程序初始化所需的外部/外部存储器接口,从外部设备读取映像,然后将其编程到内部闪存中,或根据应用程序的要求对其进行处理。 没有 SBAF(或者我们可以说 BootROM)配置,您只需指定外部闪存地址/设备,S32K344 SBAF 就可以直接从那里启动应用程序。这需要完全由您的软件来管理。 此致, Lukas
View full article
S32K3xx 主ECU密钥或客户/OEM授权密钥导入 您好,NXP, 一如既往地感谢大家的支持。 根据您之前对我们 FBL 相关询问的回复,我们了解到,当生命周期处于现场状态时,必须预先配置 MASTER_ECU_KEY 或 CUST/OEM 授权密钥才能获得超级用户 (SU) 权限,并且一旦设备已处于现场状态,就无法配置 MASTER_ECU_KEY。 请问我们的理解是否正确? 目前,这两个密钥都尚未配置。为防止将来出现类似问题,我们希望预先配置 MASTER_ECU_KEY 或 CUST/OEM 授权密钥,以便在设备进入现场状态后格式化 NVM/RAM 密钥目录并注入 HMAC 密钥。 我们有几个问题,如下所示: 1.在这个项目中,FBL认证不是基于SHE的。它采用的是RSA公钥签名验证。但是,CRYPTO_SPT_SHE 配置为 STD_ON。 在这种情况下,我们应该配置 MASTER_ECU_KEY,还是应该配置 CUST/OEM 授权密钥? 2. 是否有任何指南或参考文档说明如何导入 MASTER_ECU_KEY 或 CUST/OEM 授权密钥? 谢谢。 顺祝商祺! Re: S32K3xx Master_ECU_KEY or CUST/OEM authorization key import 嗨@jeongwoo 授权密钥应根据当前生命周期和您需要与之操作的密钥所有者进行配置。 在 CUST_DEL 中,您可以配置 CUST 授权密钥。将设备升级到 OEM_PROD 后,即可配置 OEM 授权密钥,并使用该密钥获取 OEM 拥有的密钥的超级用户权限。 在 CUST_DEL 状态下,您无法配置 OEM 拥有的密钥,因为此时您没有可以授权该操作的 OEM 授权密钥。因此,在设备处于 CUST_DEL 状态时,在推进生命周期之前,应该已经定义了所需所有者的关键目录。 迁移到 OEM_PROD 后,目录无法重新格式化,因为关键目录格式仅限于 CUST_DEL。这种生命周期转变也是不可逆的。 因此,如果您打算同时拥有 CUST 和 OEM 授权功能,请先在目录中定义所需的 CUST 和 OEM 密钥组,在 CUST_DEL 中配置 CUST 授权密钥,然后进入 OEM_PROD,最后配置 OEM 授权密钥。 您可以查看这个帖子了解详情: https://community.nxp.com/t5/S32K/Change-is-not-possible-in-LC-OEM-PROD/m-p/2356576 在 HSE 层面,密钥导入程序在 HSE-B 固件参考手册 rev. 中的“6.2.3 密钥导入”部分进行了描述。2.8 然后查看 HSE 固件版本的 HSE 服务 API 参考手册中“struct hseImportKeySrv_t”的描述。 在 Autosar Crypto 驱动程序层面,它由 Autosar 规范规定。您可以在 RTD_CRYPTO_43_HSE_UM.pdf 中阅读 Crypto_43_HSE_KeyElementSet() 和 Crypto_43_HSE_KeySetValid() API 的描述。 授权密钥的导入方式与其他密钥相同,只需在配置器中为该密钥设置 USAGE_AUTHORIZATION 和 USAGE_VERIFY 密钥标志即可。 此致, Lukas
View full article
外部ブート S32k S32k344デバイスは、最初に内部ROMから変更不可能な第1段階ブートローダーを実行しますか?もしそうなら、このROMブートローダーは外部フラッシュなどの外部ソースから二次ブートローダー(またはアプリケーションイメージ)をロードするように設定できますか? 外部ブートをサポートしている場合、初期ブートローダーがどこから引き出せばよいか、どのように設定すればよいのでしょうか? Re: External Boot S32k こんにちは、 @CTCoder1さん はい、S32K344にはリセット後に実行されるSBAFコードが含まれています。しかし、これは任意の外部メモリから直接アプリケーションをロードできる設定可能なブートローダーとは見なすべきではありません。外部ブートはサポートされていません。 通常のS32K3ブートフローでは、内部コードのフラッシュのみにブート情報やアプリケーションが反映されることを期待します。例えば、ユーザーのブートローダーを内部フラッシュの開始(IVTは0x00400000)に配置し、必要な更新/読み込みメカニズムを実行することができます。 したがって、アプリケーションを外部フラッシュに保存する意図がある場合、通常の解決策はユーザーブートローダーを内部フラッシュに設定することです。このブートローダーは必要なペリフェラル/外部メモリインターフェースを初期化し、外部デバイスからイメージを読み込み、それを内部フラッシュにプログラムするか、アプリケーションの要件に応じて処理します。 SBAF(あるいはBootROM)構成は存在しません。単に外部フラッシュアドレスやデバイスを指定して、S32K344 SBAFがそこからアプリケーションを直接起動させるようなものです。これは完全にソフトウェアで管理する必要があります。 よろしくお願いいたします。 ルーカス
View full article
E6500 / E5500割り込みパス、RFI対RFCIおよびその他のファミリ命令 こんにちは、 RFIやその他のファミリ命令は、さまざまな割り込みや例外からの返却に使用されます。 E5500およびE6500プロセッサで、SRR0とSRR1が正しい値に戻されている限り(CSRR0、CRSRR1、MCSRR0、MCSRR1などから最初に読み取れる可能性が高い)、それともプロセッサ内部の機構が壊れるのか知りたいです。 よろしくお願いいたします。 アレクシー・トーレス QorIQ T1 デバイス QorIQ T2デバイス Re: E6500 / E5500 Interrupt Path, RFI vs RFCI and other family instructions 迅速なご回答ありがとうございます。それは我々が考えていたことを裏付けるものだ。 Re: E6500 / E5500 Interrupt Path, RFI vs RFCI and other family instructions E5500およびE6500では、SRR0/SRR1レジスタにCSRR0/CSRR1またはMCSRR0/MCSRR1からコピーした値を手動でプリロードした場合でも、「RFI」を他の割り込み復帰命令(「RFCI」、「RFMCI」など)に普遍的に置き換えることは推奨されません。 各リターン命令は、特定の保存/復元レジスタペアからMSRを復元します。「RFI」を使うと必ずSRR1から復元されますが、回復されるMSRビット(マスクや強制されるもの)は命令によって異なる場合があります。レジスタ値だけでなく、ハードウェアレベルでは、`RFCI` または `RFMCI` によって一部のビットの処理方法が異なる場合があります。 「RFCI」と「RFMCI」は「CSSR」/「MCSR」の状態をクリアし、割り込みレベルの内部プロセッサトラッキングを更新します(例:MSRの「CE」/「ME」有効ビット)。手動でコピーした値を「RFI」だけ使用すると、クリティカル/マシンチェック割り込み状態が正しく再有効化またはクリアされず、プロセッサが内部的に不整合な状態に陥る可能性があります。 Power Architecture Embedded Environment(EREF)仕様では、各例外クラスから返すためにどの命令を使うべきかを明示的に定義しています。これから逸脱するとアーキテクチャ的に定義された挙動の範囲外であり、これらのコアに予測不可能な結果をもたらす可能性があります。 推奨される方法は、rfi は標準/非クリティカルな戻り値にのみ使用し、関連する割り込みクラスには rfci、rfdi、rfgi、または rfmci を使用することです。
View full article
RT685 DPD wake via PMIC_IRQ_N not working HW: RT685 + PCA9420, PMIC_IRQ_N connected to RT685 dedicated pin. Problem: POWER_EnterDeepPowerDown(exclude_from_pd={0,0,0,0}) → MCU loses power (VDDCORE off). Pull PMIC_IRQ_N low → no wake. Manually shorting PMIC_IRQ_N to GND for ~1s also does not wake.  Code before entry  :   BOARD_InitPmic(); BOARD_ConfigPMICModes(); BOARD_SetPmicVoltageBeforeDeepPowerDown(); POWER_EnableInterrupts(kPMC_INT_INTRPAD); EnableDeepSleepIRQ(PMC_PMIC_IRQn); BOARD_EnterDeepPowerDown(exclude_from_pd); ```   PMC->FLAGS after failed wake: 0x60170000, DEEPPDF (bit31) = 0. WAKE_UP_WITH_PMIC_IRQ_N = 1. Questions : Is additional RT685-side config needed to make PMIC_IRQ_N a valid DPD wake source? Does PCA9420 stop driving PMIC_IRQ_N when VDDCORE is cut via DPD Anyone successfully used PMIC_IRQ_N to wake RT685 from DPD? Working config?     i.MX-RT600  SERVER-POWER-CONTROL                       Power Re: RT685 DPD wake via PMIC_IRQ_N not working Hi @wx1 , Regarding PMC->FLAGS after failed wake: 0x60170000, DEEPPDF (bit31) = 0. WAKE_UP_WITH_PMIC_IRQ_N = 1.  The reason to have this result is due to that  DEEPPDF (bit 31 of PMC->FLAGS ) is only set when the MCU successfully completes a full DPD cycle and wakes from it. A value of 0 means the MCU never cleanly entered DPD. The co-existing WAKE_UP_WITH_PMIC_IRQ_N = 1 tells you that the PMC detected a low pulse on PMIC_IRQ_N, but the DPD state was never committed. This pattern almost always means PMIC_IRQ_N was already asserted (logic-low) at the moment DPD entry was attempted, causing an immediate phantom wake before DPD could latch. When PMIC_MODE[1:0] transitions to 0b10 (DPD mode, VDDCORE off), the PCA9420 internally detects that SW1_OUT is dropping. This can trigger a brief INTB pulse due to the PCA9420's voltage supervisor logic firing on the SW1 output. If that pulse reaches the PMC before DPD is fully committed, you get exactly what you are seeing. Is additional RT685-side config needed to make PMIC_IRQ_N a valid DPD wake source? Before arming DPD, drain any pending PCA9420 interrupts so that INTB is deasserted (high) when DPD latches. Does PCA9420 stop driving PMIC_IRQ_N when VDDCORE is cut via DPD PMIC_IRQ_N is on the VDD_AO1V8 always-on domain, which stays powered throughout DPD. The PCA9420 INTB output is open-drain and powered from VIN, so as long as VIN (your system supply) is present the PCA9420 can still drive INTB low.   Hope that makes sense,   Have a great day, Kan ------------------------------------------------------------------------------- Note: - If this post answers your question, please click the "Mark Correct" button. Thank you! - We are following threads for 7 weeks after the last post, later replies are ignored Please open a new thread and refer to the closed one, if you have a related question at a later point in time. -------------------------------------------------------------------------------
View full article
S32K314 get stuck at 0x2040012C WFI during HSE recovery in AB swap Hello NXP Support Team, I am testing HSE recovery in AB swap as following steps. Firstly, I use lauterbach to execute HSE FW erase to erase HW, then test the recovery process. The CPU always stops at at 0x2040012C WFI instruction after step 9 issue a functional reset, I need to power off, then power on to get out of this.  Could you please give some tips on what's going wrong?  leo_cheng_0-1789995644535.png leo_cheng_1-1789995683683.png Re: S32K314 get stuck at 0x2040012C WFI during HSE recovery in AB swap Hi @leo_cheng  If it hangs at 0x2040012C after reset, it means that the device entered JTAG based recovery  mode. You can take a look at “2.6.1.3 Recovery Mode” section in the HSE-B Firmware reference manual. If you want to recover using Lauterbach debugger, I wrote attached script which follows section “3.3.1  MU Installation Steps by Host in AB_SWAP Configuration”. It works for installation of the firmware on brand new device and it works for recovery when the firmware is erased completely or when there’s backup image in passive partition. Regards, Lukas
View full article
S32K314 が AB スワップ中の HSE リカバリ中に 0x2040012C WFI で停止する こんにちは、NXPサポートチームの皆さん、 以下の手順で、ABスワップにおけるHSEリカバリのテストを行っています。まず、lauterbachを使用してHSE FW eraseを実行し、ハードウェアを消去してから、リカバリプロセスをテストします。ステップ9で機能リセットを発行した後、CPUは常に0x2040012CのWFI命令で停止します。この状態から抜け出すには、電源をオフにしてからオンにする必要があります。何がうまくいっていないのか、アドバイスをいただけますか? leo_cheng_0-1789995644535.png leo_cheng_1-1789995683683.png Re: S32K314 get stuck at 0x2040012C WFI during HSE recovery in AB swap こんにちは、 @leo_cheng さん。 リセット後に0x2040012Cでハングアップする場合、デバイスがJTAGベースのリカバリモードに入ったことを意味します。「2.6.1.3」をご覧ください。HSE-Bファームウェアリファレンスマニュアルの「リカバリーモード」セクションに記載されています。 Lauterbach デバッガーを使用して復旧したい場合は、セクション「3.3.1」に従って、添付のスクリプトを作成しました。「AB_SWAP構成におけるホストごとのMUインストール手順」これは、新品のデバイスへのファームウェアのインストールに有効であり、ファームウェアが完全に消去された場合や、パッシブパーティションにバックアップイメージが存在する場合の復旧にも有効です。 よろしくお願いいたします。 ルーカス
View full article
RT685 DPDのPMIC_IRQ_Nによるウェイクアップが機能しない HW:RT685 + PCA9420、PMIC_IRQ_N RT685専用ピンに接続されています。 問題: POWER_EnterDeepPowerDown(exclude_from_pd={0,0,0}) →MCUが電源を失います(VDDコアがオフ)。ウェイク→PMIC_IRQ_Nを下げてください。手動でGNDにショートPMIC_IRQ_Nさせて~1秒も起動しません。 入力前にコードを入力してください  :   BOARD_InitPmic(); BOARD_ConfigPMICModes(); BOARD_SetPmicVoltageBeforeDeepPowerDown(); POWER_EnableInterrupts(kPMC_INT_INTRPAD); EnableDeepSleepIRQ(PMC_PMIC_IRQn); BOARD_EnterDeepPowerDown(exclude_from_pd); 「`」   PMC->FLAGS ウェイク失敗後: 0x60170000、DEEPPDF (bit31) = 0。 PMIC_IRQ_Nで起動 = 1. 質問 : PMIC_IRQ_Nを有効なDPDウェイクソースにするには、RT685側で追加の設定が必要ですか? DPD を介して VDDCORE が切断された場合、PCA9420 は PMIC_IRQ_N の駆動を停止しますか? PMIC_IRQ_Nを使用してRT685をDPDからウェイクアップすることに成功した方はいますか?動作する設定はありますか?     i.MX-RT600サーバー電源制御                     パワー Re: RT685 DPD wake via PMIC_IRQ_N not working こんにちは、 @wx1 さん。 PMC->FLAGSについて:0x60170000、DEEPPDF(ビット31)= 0. WAKE_UP_WITH_PMIC_IRQ_N = 1。この結果が出る理由は 、 DEEPPDF ( PMC->FLAGS のビット31)がMCUが完全なDPDサイクルを完了し、そこからウェイクアップした場合にのみ設定されるためです。値が 0 の場合は、MCUがDPDにきれいに入っていなかったことを意味します。共存する WAKE_UP_WITH_PMIC_IRQ_N = 1 は、PMC が PMIC_IRQ_N で低パルスを検出したが、DPD 状態がコミットされなかったことを示しています。このパターンはほとんどの場合、 DPDの入力が試みられた時点ですでにPMIC_IRQ_Nが主張されていた(論理低値)であり、DPDがラッチする前に即座にファントムウェイクが発生しています。 PMIC_MODE[1:0] が 0b10 に遷移すると(DPDモード、VDDCOREオフ)、PCA9420は内部的にSW1_OUTが低下していることを検出します。これにより、PCA9420の電圧スーパーバイザロジックがSW1出力で発動するため、短いINTBパルスがトリガーされることがあります。そのパルスがDPDが完全に作動する前にPMCに到達すると、まさに今見ているような現象が起こります。 PMIC_IRQ_Nを有効なDPDウェイクソースにするには、RT685側で追加の設定が必要ですか? DPDを起動する前に、保留中のPCA9420中断中の割り込みを排水し、DPDがラッチしたときにINTBが解除される(高く)します。 DPD を介して VDDCORE が切断された場合、PCA9420 は PMIC_IRQ_N の駆動を停止しますか? PMIC_IRQ_Nは VDD_AO1V8 常時オンドメイン上にあり、DPD期間中ずっと電源が供給されています。PCA9420のINTB出力はオープンドレインでVINから電力が供給されているため、VINが存在している限りPCA9420はINTBの低電圧を駆動できます。   これで意味が通じるといいのですが。   すてきな一日を、 カン ------------------------------------------------------------------------------- 注記: この投稿があなたの質問への回答になっている場合は、「正解としてマーク」ボタンをクリックしてください。ありがとうございます! - 前回の投稿から7週間Threadをフォローしており、その後の返信は無視しています もし後で関連する質問があれば、新しいThreadを開き、閉じたThreadを参照してください。 -------------------------------------------------------------------------------
View full article
i.MX95 19x19 EVK – M2-JODY-W6 Wi-Fi Card Availability and Camera Module Compatibility Hello NXP Team, We are working with the NXP i.MX95 19x19 EVK (IMX95LPD5EVK-19) for an Android Automotive OS project. We would like to get clarification on the following: 1. M2-JODY-W6 Wi-Fi Card The M2-JODY-W6 Wi-Fi card is not included in our i.MX95 EVK kit. Could you please provide information on: - Availability of the M2-JODY-W6 Wi-Fi card - How we can obtain/purchase the card - Whether NXP provides a sample or recommended ordering channel - Any required documentation or compatibility information for the i.MX95 19x19 EVK 2. Camera Module Compatibility We would also like information about a camera module officially supported/validated with the i.MX95 19x19 EVK. Could you please provide: - Recommended/validated camera module - Exact module/part number - Camera sensor used - Hardware connection/interface information - Relevant documentation - Linux/Android driver or software support information - Any available reference design or configuration information Board: NXP i.MX95 19x19 EVK Part Number: IMX95LPD5EVK-19 Software: Android Automotive OS 16 NXP BSP We would appreciate your guidance on the above questions. Thanks and Regards, Gnana Prasanna Gunakala Re: i.MX95 19x19 EVK – M2-JODY-W6 Wi-Fi Card Availability and Camera Module Compatibility Hello,  For your first question please open a technical case, for the second question please refer to the following AN: https://www.nxp.com/docs/en/application-note/AN14853.pdf  Regards.
View full article
S32K314 在 AB 交换期间的 HSE 恢复中卡在 0x2040012C WFI。 您好,NXP支持团队, 我正在按以下步骤测试 AB 互换中的 HSE 恢复情况。首先,我使用 lauterbach 执行 HSE FW erase 来擦除硬件,然后测试恢复过程。CPU 在步骤 9 发出功能性复位指令后,总是停留在 0x2040012C WFI 指令处,我需要断电重启才能解决这个问题。请问您能否就哪里出了问题提供一些建议? leo_cheng_0-1789995644535.png leo_cheng_1-1789995683683.png Re: S32K314 get stuck at 0x2040012C WFI during HSE recovery in AB swap 嗨@leo_cheng 如果 RESET 后卡在 0x2040012C,则表示设备已进入基于 JTAG 的恢复模式。您可以查看“2.6.1.3”。HSE-B 固件参考手册中的“恢复模式”部分。 如果您想使用 Lauterbach 调试器进行恢复,我编写了附件脚本,该脚本遵循“3.3.1”节。AB_SWAP 配置中主机 MU 安装步骤”。它适用于在新设备上安装固件,也适用于固件完全擦除或被动分区中有备份映像时的恢复。 此致, Lukas
View full article
RT685 DPD 通过 PMIC_IRQ_N 唤醒不起作用 硬件:RT685 + PCA9420,PMIC_IRQ_N 连接到 RT685 专用引脚。 问题: POWER_EnterDeepPowerDown(exclude_from_pd={0,0,0,0}) → MCU 断电(VDDCORE 关闭)。将 PMIC_IRQ_N 拉低 → 无法唤醒。手动将 PMIC_IRQ_N 短接到 GND 约 1 秒也无法唤醒。 入口前需输入代码  :   BOARD_InitPmic(); BOARD_ConfigPMICModes(); BOARD_SetPmicVoltageBeforeDeepPowerDown(); POWER_EnableInterrupts(kPMC_INT_INTRPAD); EnableDeepSleepIRQ(PMC_PMIC_IRQn); BOARD_EnterDeepPowerDown(exclude_from_pd); ```   PMC->FLAGS 唤醒失败后:0x60170000,DEEPPDF(位31)= 0。 WAKE_UP_WITH_PMIC_IRQ_N = 1. 问题 : 是否需要额外的 RT685 端配置才能使 PMIC_IRQ_N 成为有效的 DPD 唤醒源? 当通过 DPD 切断 VDDCORE 时,PCA9420 是否会停止驱动 PMIC_IRQ_N? 有人成功使用 PMIC_IRQ_N 从 DPD 唤醒 RT685 吗?配置可行吗?     i.MX-RT600服务器电源控制                     电源 Re: RT685 DPD wake via PMIC_IRQ_N not working 嗨@wx1 , 关于唤醒失败后的 PMC->FLAGS :0x60170000,DEEPPDF(位31)= 0。 WAKE_UP_WITH_PMIC_IRQ_N = 1. 出现此结果的原因是,只有当 MCU 成功完成一个完整的 DPD 周期并从中唤醒时, DEEPPDF ( PMC->FLAGS 的第 31 位)才会设置。值为 0 表示 MCU 从未干净地进入 DPD。共存的 WAKE_UP_WITH_PMIC_IRQ_N = 1 表示 PMC检测到 PMIC_IRQ_N 上的低脉冲,但 DPD 状态从未被提交。这种模式几乎总是意味着在尝试进入 DPD 时 PMIC_IRQ_N 已经钳位(逻辑低) ,导致在 DPD 锁存之前立即出现幻觉唤醒。 当 PMIC_MODE[1:0] 过渡到 0b10 (DPD 模式,VDDCORE 关闭)时,PCA9420 内部检测到 SW1_OUT 正在下降。由于 PCA9420 的电压监控逻辑在 SW1 输出端触发,这可能会触发短暂的 INTB 脉冲。如果该脉冲在 DPD 完全执行之前到达 PMC,就会出现你现在看到的情况。 是否需要额外的 RT685 端配置才能使 PMIC_IRQ_N 成为有效的 DPD 唤醒源? 在启用 DPD 之前,清除所有待处理的 PCA9420 中断,以便在 DPD 锁存时 INTB 被取消置位(高电平)。 当通过 DPD 切断 VDDCORE 时,PCA9420 是否会停止驱动 PMIC_IRQ_N? PMIC_IRQ_N 位于 VDD_AO1V8 始终开启功能域中,在整个 DPD 期间保持通电状态。PCA9420 INTB 输出为开漏输出,由 VIN 供电,因此只要 VIN(您的系统电源)存在,PCA9420 仍然可以将 INTB 拉低。   希望我解释清楚了。   祝你有美好的一天, 坎 ------------------------------------------------------------------------------- 笔记: - 如果此回复解答了您的问题,请点击“标记为正确答案”按钮。谢谢你! - 我们会持续关注帖子,从最后一条回复发出后持续7周,之后的回复将被忽略。 如果您之后有相关问题,请另开新帖并引用已关闭的帖子。 -------------------------------------------------------------------------------
View full article