Multi Source Translation Content

キャンセル
次の結果を表示 
表示  限定  | 次の代わりに検索 
もしかして: 

Multi Source Translation Content

ディスカッション

ソート順:
#S32K312 IO入力設定 joshua9264_0-1783597102225.png LPUART0 RXを使用したいのですが、IMCR[699]を設定する必要がありますが、仕様にはIMCR[473]しかありません。どうすればよいでしょうか? Re: #S32K312 IO input config こんにちは、@joshua9264さん S32K3xxリファレンスマニュアル改訂版12のセクション10.1.2には次のように記されています。 「添付のIOMUXファイルで定義されているIMCRは、SIUL2メモリマップセクションで定義されているIMCR番号に対して512のオフセットを持っています。」 オフセットの適用方法を明確にするために、RMのセクション4.4.3にも例が記載されています。 BR、VaneB Re: #S32K312 IO input config はい、見つけました。ありがとう
記事全体を表示
6.12 内核中的 i.MX6ULL 以太网时钟错误 6.12 中的设备树示例对以太网 Phy 进行了硬编码,而不是修复我们在使用的 NXP 5.15 内核中不存在的这个错误。 我们最终编写了一个补丁,因为我们希望内核能够灵活地检测 PHY,而 fec 模块中存在这个问题。该补丁使得在加载驱动程序时读取物理寄存器,而不是在设备树中进行规避。 On i.MX6UL boards that hang both RMII PHYs on FEC2's MDIO bus, PHY@0 uses the FEC1 (ENET1) RMII reference clock. Kernel 6.12 routes that clock through ENET1_REF_SEL, which may not be active when FEC2 reads PHY@0's ID during of_mdiobus_register(), yielding a bogus ID (0x01080108) and binding the generic PHY driver. Briefly enable FEC1's enet_clk_ref (looked up from DT, not via probe defer) around of_mdiobus_register() so the PHY ID read succeeds without changing FEC probe order and breaking FEC_QUIRK_SINGLE_MDIO. --- drivers/net/ethernet/freescale/fec_main.c | 59 +++++++++++++++++++++++ 1 file changed, 59 insertions(+) diff --git a/drivers/net/ethernet/freescale/fec_main.c b/drivers/net/ethernet/freescale/fec_main.c index 811a66062..46f37be0c 100644 --- a/drivers/net/ethernet/freescale/fec_main.c +++ b/drivers/net/ethernet/freescale/fec_main.c @@ -2540,6 +2540,39 @@ static int fec_enet_mii_probe(struct net_device *ndev) return 0; } +static bool fec_enet_mdio_has_phy_addr0(struct device_node *mdio) +{ + struct device_node *child; + u32 reg; + + for_each_available_child_of_node(mdio, child) { + if (of_property_read_u32(child, "reg", ®)) + continue; + if (reg == 0) { + of_node_put(child); + return true; + } + } + return false; +} + +static struct clk *fec_enet_get_rmii_master_refclk(void) +{ + struct device_node *np = NULL; + struct clk *clk; + + while ((np = of_find_compatible_node(np, NULL, "fsl,imx6ul-fec"))) { + if (of_get_child_by_name(np, "mdio")) { + of_node_put(np); + continue; + } + clk = of_clk_get_by_name(np, "enet_clk_ref"); + of_node_put(np); + return clk; + } + return NULL; +} + static int fec_enet_mii_init(struct platform_device *pdev) { static struct mii_bus *fec0_mii_bus; @@ -2553,6 +2586,8 @@ static int fec_enet_mii_init(struct platform_device *pdev) u32 mii_speed, holdtime; u32 bus_freq; int addr; + struct clk *rmii_master_refclk = NULL; + bool peer_ref_enabled = false; /* * The i.MX28 dual fec interfaces are not equal. @@ -2662,7 +2697,26 @@ static int fec_enet_mii_init(struct platform_device *pdev) fep->mii_bus->priv = fep; fep->mii_bus->parent = &pdev->dev; + if (node && fec_enet_mdio_has_phy_addr0(node)) { + rmii_master_refclk = fec_enet_get_rmii_master_refclk(); + if (IS_ERR(rmii_master_refclk)) { + err = PTR_ERR(rmii_master_refclk); + goto err_out_free_mdiobus; + } + if (rmii_master_refclk) { + err = clk_prepare_enable(rmii_master_refclk); + if (err) + goto err_out_free_mdiobus; + peer_ref_enabled = true; + usleep_range(100, 200); + } + } + err = of_mdiobus_register(fep->mii_bus, node); + if (peer_ref_enabled) + clk_disable_unprepare(rmii_master_refclk); + if (!IS_ERR_OR_NULL(rmii_master_refclk)) + clk_put(rmii_master_refclk); if (err) goto err_out_free_mdiobus; of_node_put(node); Re: i.MX6ULL Ethernet Clock Bug in 6.12 kernel 你只需要查看设备树的变化,就会发现新的 FEC 驱动程序偷工减料,不再有时钟,因此物理寄存器最初无法读取。如果你不打算使用多个物理供应商,那么这样做没问题。兼容行用于指定在没有时钟信号时值错误的物理层寄存器: https://github.com/nxp-imx/linux-imx/blob/lf-6.12.y/arch/arm/boot/dts/nxp/imx/imx6ul-14x14-evk.dtsi#L205 在较旧的内核(我们设备树的遗留版本)中,phy 不存在兼容行。此修复允许在读取 PHY 之前打开时钟,以便正确读取寄存器,因此不需要兼容线路,因为旧设备树中没有该线路: https://github.com/nxp-imx/linux-imx/blob/lf-5.4.y/arch/arm/boot/dts/imx6ul-14x14-evk.dtsi#L224 我还没时间测试你们的电路板,因为我正忙着调试我们自己的电路板。我认为这是内核的退步。 Re: i.MX6ULL Ethernet Clock Bug in 6.12 kernel 你好, 感谢分享分析和补丁。 您是否已在 NXP EVK 开发板上验证过这一点? 顺祝商祺!
記事全体を表示
How to smoothly display camera frames in LVGL? Hello, I am using the MIMXRT1176DMAA chip. The board is equipped with a MIPI camera and a MIPI LCD, and the LCD primarily used for displaying LVGL GUI. Currently, I would like to display the camera's images on the screen while overlaying some LVGL labels on top of the camera feed. I have attempted to display the camera frames through an LVGL Canvas, but this approach introduced additional processing overhead in transferring camera frames to the Canvas, resulting in high CPU usage and choppy camera feed. Could you please advise if there is a solution to this issue? For instance, can the Layer feature of LCDIFV2 be utilized to display content on different layers? I would greatly appreciate any suggestions you could provide. Re: How to smoothly display camera frames in LVGL? Hello @Vinos , what was the solution if it's not a secret? Kind regards Re: How to smoothly display camera frames in LVGL? Solved. Re: How to smoothly display camera frames in LVGL? After trying, I found that the camera screen only works smoothly when the LVGL task is closed. Currently, Layer0 is the GUI and Layer1 is the camera. I would like to add another Layer2 when Layer0 is closed and Layer1 is opened. In the center of Layer3, there should be a hollow circle with transparency in all parts except for the arc. Therefore, I used the ARGB4444 format and performed a simple test by drawing a square on the LCD(Layer0 enable and Layer1 disable;or Layer0 disable and Layer1 enable). However, the resulting image was not transparent. Whenever the LCDIFV2_SetLayerBlendConfig function is called, there is no image on Layer3 on the LCD. However, if this function is commented out, the LCD displays the expected non-transparent image. Below is the code,reference the example " lcdifv2_embedded_alpha_cm7" in SDK #define LCD_WIDTH 480 #define LCD_HEIGHT 640 #define CENTER_LAYER 2 #define DEMO_FB0_ADDR ((uint32_t)s_frameBuffer[0]) AT_NONCACHEABLE_SECTION_ALIGN( uint8_t s_frameBuffer[1][LCD_HEIGHT][LCD_WIDTH][2], 32); void DEMO_FillFrameBuffer(void) { uint32_t x, y; for (y = 0; y < LCD_HEIGHT; y++) { for (x = 0; x < LCD_WIDTH; x++) { s_frameBuffer[0][y][x][0] = 0x11; s_frameBuffer[0][y][x][1] = 0x11; } } } void lcd_center_layer_init() { DEMO_FillFrameBuffer(); /* Layer 1: ARGB4444 */ const lcdifv2_buffer_config_t fb1Config = { .strideBytes = (LCD_WIDTH * 2), .pixelFormat = kLCDIFV2_PixelFormatARGB4444, }; const lcdifv2_blend_config_t blend1Config = { .alphaMode = kLCDIFV2_AlphaEmbedded, }; LCDIFV2_SetLayerBufferConfig(LCDIFV2, CENTER_LAYER, &fb1Config); LCDIFV2_SetLayerSize(LCDIFV2, CENTER_LAYER, 240, 240); LCDIFV2_SetLayerOffset(LCDIFV2, CENTER_LAYER, 0, 0); /* comment or not */ LCDIFV2_SetLayerBlendConfig(LCDIFV2, CENTER_LAYER, &blend1Config); LCDIFV2_SetLayerBufferAddr(LCDIFV2, CENTER_LAYER, DEMO_FB0_ADDR); LCDIFV2_EnableLayer(LCDIFV2, CENTER_LAYER, true); LCDIFV2_TriggerLayerShadowLoad(LCDIFV2, CENTER_LAYER); } Is there any error in my code? Thank you. Re: How to smoothly display camera frames in LVGL? Hi again @Vinos, Please look into the following link: https://github.com/lvgl/lvgl/issues/262 I believe it will prove very useful for your inquiry. Let me know if it helps! Edwin. Re: How to smoothly display camera frames in LVGL? Thank you for your suggestion. I have tried the second solution, but in LVGL, the general background is white and there are some labels on top. The actual result is that the white background completely covers the camera image except for the labels. How can I make these white backgrounds transparent? Re: How to smoothly display camera frames in LVGL? Hi @Vinos, I am not aware of how you are approaching this application, so here is my recommendation on how to do so: Refer to the example "SDK_MIMXRT1170-EVK\boards\evkmimxrt1170\driver_examples\csi\mipi_rgb". The captured video from camera needs to be composited with framebuffer of LVGL. There are two methods to do this: 1) Copying the camera image from camera output buffer to framebuffer of LVGL. This can be done with memcpy but it will result in bad performance, so I'd recommend using DMA instead. 2) Using another layer of LCDIFv2 as output buffer of camera directly, then LCDIFv2 h/w composites different layers on display without copy. BR, Edwin.
記事全体を表示
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として指定されています。 ありがとうございます。
記事全体を表示
使用 keyfactor 插件构建镜像时出错 我已经安装了 spsdk 和 spsdk-plugins,以便使用 keyfactor 插件为 RT1064 构建镜像。当我在虚拟环境中运行 build_image_win.bat 文件时,一直出现错误。 SPSDK错误:SPSDK:无法根据配置 type=keyfactor;url=... 创建签名提供程序 日志文件显示以下错误。 信息:spsdk.utils.service_provider:正在加载插件:spsdk.sp INFO:spsdk.utils.service_provider:未找到类型为 keyfactor 的 SignatureProvider。 调试:spsdk.apps.utils.utils:SPSDK:无法根据配置 type=keyfactor;url 创建签名提供程序 我运行了一个测试来检查环境中活动的 Python 入口点,如下所示。 "python -c "import importlib.metadata;print([p.namefor p in importlib.metadata.entry_points(group='spsdk.sp')])"测试结果良好,关键因素在于活跃的 Python 入口点。 我已附上版本批处理文件和 yaml 文件。 我该如何解决这个问题? Re: Error when building a image using keyfactor plugin 嗨@cleo , 插件似乎加载失败。您是否按照https://github.com/nxp-mcuxpresso/spsdk_plugins/tree/master/keyfactor中的指南操作?请参考https://github.com/nxp-mcuxpresso/spsdk_plugins更多详情请见下文。 希望对您有所帮助。 祝你有美好的一天, 坎 ------------------------------------------------------------------------------- 笔记: - 如果此回复解答了您的问题,请点击“标记为正确答案”按钮。谢谢你! - 我们会持续关注帖子,从最后一条回复发出后持续7周,之后的回复将被忽略。 如果您之后有相关问题,请另开新帖并引用已关闭的帖子。 -------------------------------------------------------------------------------
記事全体を表示
MCXC242VFM vs MCXC244VFM pinout differences Hello there, I'm designing a board with the MCXC242VFM chip, but I wanted to make it pin to pin compatible with the MCXC244VFM in case I need more FLASH and RAM. From the MCUXpresso Config Tool I see that there's a few pins that differ between MCXC242VFM and MCXC244VFM, but I cannot find any documentation that explains in detail the difference of pinouts.; only thing I can find online on NXP website is that from the product selection tool the MCXC242VFM is reported to have no I2S and 24 GPIOs, while the MCXC244VFM has 1 I2S and 23 GPIOs. For my project I'm not interested in the I2S. Can someone please point me to a document that clearly states the differences of pinout and pins assignment between these two chips? Kind regards, Michele Perla Board Design MCXC Package and IO|GPIO Re: MCXC242VFM vs MCXC244VFM pinout differences Hi @MichelePerla  The MCXC242VFM and MCXC244VFM are both available in the 32-QFN package, but they should not be assumed to be fully pin-to-pin compatible. Please compare the pin assignment tables in the MCX C24X and MCX C44X reference manual. In particular, several pins differ between the two devices. For example, pin 5 is USB_VDD on MCXC242VFM but VOUT33 on MCXC244VFM; pin 6 is PTE16 on MCXC242VFM but VREGIN on MCXC244VFM; and pin 9 also has different analog/reference-related definitions. Therefore, if the board is intended to support both devices, these pins must be reviewed carefully in the schematic and PCB design. MCXC242 RM: MCX C24X Sub-Family Reference Manual Alice_Yang_2-1783650917873.png MCXC244 RM: MCX C44X Sub-Family Reference Manual Alice_Yang_0-1783650899990.png Hope it helps. BR Alice
記事全体を表示
MCXC242VFM 与 MCXC244VFM 引脚排列差异 你好呀, 我正在设计一款采用 MCXC242VFM 芯片的电路板,但我希望它能与 MCXC244VFM 引脚兼容,以防我需要更大的 FLASH 和 RAM。 从 MCUXpresso 配置工具中,我发现 MCXC242VFM 和 MCXC244VFM 之间有一些引脚不同,但我找不到任何文档详细解释引脚排列的差异。我在 NXP 网站上唯一能找到的信息是,根据产品选择工具显示,MCXC242VFM 没有 I2S 接口,有 24 个 GPIO 接口,而 MCXC244VFM 有 1 个 I2S 接口和 23 个 GPIO 接口。我的项目对 I2S 不感兴趣。 请问谁能提供一份文档,清楚地说明这两款芯片的引脚排列和引脚分配的区别? 此致敬礼, 米歇尔·佩拉 电路板设计 MCXC 代码包,软件包和 I/O|GPIO Re: MCXC242VFM vs MCXC244VFM pinout differences 嗨@MichelePerla MCXC242VFM 和 MCXC244VFM 均采用 32-QFN 封装,但不应假定它们引脚完全兼容。请比较 MCX C24X 和 MCX C44X 参考手册中的引脚分配表。 具体来说,这两个设备有几个引脚不同。例如,MCXC242VFM 的引脚 5 为 USB_VDD,而 MCXC244VFM 的引脚 5 为 VOUT33;MCXC242VFM 的引脚 6 为 PTE16,而 MCXC244VFM 的引脚 6 为 VREGIN;引脚 9 的模拟/参考相关定义也不同。因此,如果板要支持这两个设备,则必须在原理图和 PCB 设计中仔细检查这些引脚。 MCXC242 RM: MCX C24X 子系列参考手册 Alice_Yang_2-1783650917873.png MCXC244 RM: MCX C44X 子系列参考手册 Alice_Yang_0-1783650899990.png 希望对您有所帮助。 BR 爱丽丝
記事全体を表示
Alternative part for NVT4857UKAZ This is less directly software related, but we recently discovered that the NVT4857UKAZ has already reached EOL, and there are no pin-to-pin compatible replacement parts available. Since SD card support is a required feature for our i.MX95-based device, we're trying to understand what alternative solutions are available given this situation. Could you share your recommendations on possible replacement options or design approaches? Re: Alternative part for NVT4857UKAZ Hello! You can refer NVT4858 as a replacement. However, please note that NVT4858 is not a drop-in replacement. Therefore, both hardware and software modifications may be required to accommodate the new device in your application. ErikaC_0-1783547925570.png We recommend carefully reviewing the specifications and design requirements to evaluate the impact of the migration. Hope this helps! Re: Alternative part for NVT4857UKAZ Hello! You can refer NVT4858 as a replacement. However, please note that NVT4858 is not a drop-in replacement. Therefore, both hardware and software modifications may be required to accommodate the new device in your application. ErikaC_0-1783547925570.png We recommend carefully reviewing the specifications and design requirements to evaluate the impact of the migration. Hope this helps!
記事全体を表示
iMXRT1052 カスタムファームウェアでキーブロブを生成しても、起動時に受け入れられません。 こんにちは、   署名済みの暗号化ブートローダーがあり、HABは有効になっていますが、シールはされていません。NXPのセキュアプロビジョニングツールを使ってフラッシュすると、問題なく動作します。同様に、FCB + パディング + 署名および暗号化されたブートローダー + キーブロブ(キーブロブはターミナルで次のコマンドを実行して生成されます)を連結すると、次のようになります。   blhost -t 5000 -u 0x15A2,0x0073 -j -- generate-key-blob "dek.bin" "blob.bin"   それも効果がある。しかし、デバッグセッション(キーブロブを生成するためだけに用いられる)でカスタムファームウェアを使用してこのプロセスを実行すると、生成されたブロブファイルが受け入れられず、ブートローダーの実行に失敗します。どちらのシナリオにおいても、DEKは変化しない。   両方とも.binファイルを生成しましたファイル間の違いは、ブロブオフセットアドレスのみである。   Secure Provisioning Toolが提供するflashloader.binと公開されているソースコード(MCUブート)との間に違いはありますか?   標準のフラッシュローダーは、このバージョンを報告します。 blhost -u 0x15A2,0x0073 -- get-property 1 Response status = 0 (0x0) Success. Response word 1 = 1258424320 (0x4b020800) Current Version = K2.8.0   bl_version.h に基づくと、ソースコードは一貫しているはずであり、Secure Provisioning Tool のバージョンは 25.09 です。   カスタムファームウェアはフラッシュローダーソースからのコードスニペット(特にbl_keyblob_dcp.cにあります)を使用しています。そして、すべての依存関係は同じソースから取得されます。この実装は内部でのみ使用されるため、ファームウェアからDEKを抽出することは問題ありません。   お時間をいただきありがとうございました。 🙂 Re: iMXRT1052 Generating key blob in custom firmware not accepted on boot. こんにちは、 @JordanSt さん。 あなたはiMXRT1052を使って以下のようにテストを行ったと理解してよろしいでしょうか? 1. NXPのセキュアプロビジョニングツールからフラッシュローダーをロードし、以下のコマンドを使用してdek.binとblob.binを取得します。 blhost -t 5000 -u 0x15A2,0x0073 -j -- generate-key-blob "dek.bin" "blob.bin" 2. iMXRT1052でflashloaderのSDKデモのコードを使ってカスタムファームウェアを実行し、上記のコマンドでdek.binとblob.binを得ます。 3. 生成された dek.bin ファイルは同じですが、blob.bin ファイルは異なります。 私の理解が正しければ、ステップ2のSDKのフラッシュローダーは試しましたか?結果は同じだったのでしょうか? すてきな一日を、 カン ------------------------------------------------------------------------------- 注記: この投稿があなたの質問への回答になっている場合は、「正解としてマーク」ボタンをクリックしてください。ありがとうございます! - 前回の投稿から7週間Threadをフォローしており、その後の返信は無視しています もし後で関連する質問があれば、新しいThreadを開き、閉じたThreadを参照してください。 ------------------------------------------------------------------------------- Re: iMXRT1052 Generating key blob in custom firmware not accepted on boot. こんにちは@Kan_Li ご支援ありがとうございます。 関連事項: 1. NXPのSecure Provisioning Toolからフラッシュローダーを読み込み、以下のコマンドでdek.binとblob.binを起動します - そうだ、鍵の塊を手に入れるために。 2. iMXRT1052でflashloaderのSDKデモのコードを使ってカスタムファームウェアを実行し、上記のコマンドでdek.binとblob.binを得ます。 - はい、しました。SDKのデモフラッシュローダーでテストしました。こちらもカスタムファームウェアです。 重要かどうかはわかりませんが、主な違いはSPTのフラッシュローダーは内部のSRAMから実行されるのに対し、カスタムファームウェアやSDKのデモはそうではなく、外部(搭載)SDRAM用に設定・構築されていることです。 3. 生成されたdek.binファイルは同じですが、blob.binファイルは異なります。 はい、どちらのシナリオでも使用される DEK は同じです (当然です)。生成されたキー ブロブを見ると、ヘッダーは同じで、bk セクションと dek セクションのみが異なり、mac セクションはすべてゼロです。 すてきな一日を 🙂 ヨルダン
記事全体を表示
PWMキャプチャはfrdm_mcxw72ボードでは動作しません こんにちは、 frdm_mcxw72 ボードで pwm キャプチャ サンプルを試してみましたが、残念ながらシリアル ツールのプリント メッセージには「 capture cycle err -134 」としか表示されません。frdm_mcxw72ボードのPTA21ピンには、1kHz、デューティサイクル50%のPWM信号が注入されているはずです。 デモケースからプロジェクトファイル全体をインポートしましたが、オーバーレイファイルだけを追加しただけで変更はありません。以下にオーバーレイファイルの設定があります。 anliu114036_0-1783501416708.png なぜ正しい印刷情報がないのか、その理由を調べていただけますか?前もって感謝します! Re: PWM Capture can't work in frdm_mcxw72 board こんにちは、 あなたの調子が良いといいのですが。どのZephyrリポジトリを使っているのか、教えていただけますか? また、あなたは提示された例を参考にしていますか?何か変更しましたか? よろしくお願いいたします。 リカルド Re: PWM Capture can't work in frdm_mcxw72 board こんにちは、リカルドさん リポジトリのバージョンはV4.4.1.0です。以下は私の手順です 1. リポジトリからキャプチャ例のアプリケーションをインポートする anliu114036_0-1783644698775.png 2. 最初のメッセージで投稿したオーバーレイファイルの内容であるDTSオーバーレイファイルをボードフォルダに追加します。 3. 手元にある frdm_mcxw72 ボードにビルドしてフラッシュすると、プリントメッセージは次のようになります。 「キャプチャサイクルエラー」、PWM信号を注入していないのでボードの状態は問題ないように見えますが、PTA21ピンにPWM信号を注入した後もプリントメッセージは同じです。     Re: PWM Capture can't work in frdm_mcxw72 board こんにちは、 どのリポジトリを使っているのか教えていただけますか? アップストリームとダウンストリームのどちらを使用していますか? また、そのサンプルコードは、修正なしでそちら側でも正常に動作しますか? よろしくお願いいたします。 リカルド Re: PWM Capture can't work in frdm_mcxw72 board こんにちは、リカルド リポジトリのバージョンはこちらです anliu114036_0-1783902527295.png オーバーレイファイルだけを更新しますが、このファイルがなければビルドが成功しません。 よろしくお願いいたします! Re: PWM Capture can't work in frdm_mcxw72 board こんにちは、 Upstreamを使っているのか、それともDownstreamを使っているのか、教えていただけますか? よろしくお願いいたします。 リカルド Re: PWM Capture can't work in frdm_mcxw72 board こんにちは、リカルドさん すみません、ここでいう「上流」や「下流」が何なのかよく理解できませんでした。下流側であるべきだと思う。それとも別の説明を変えてもらえますか?
記事全体を表示
i.MX95 启动 ROM:配置 eMMC Boot0/Boot1 为主/从启动盘,FlexSPI NOR 为恢复盘 各位专家好, 我正在尝试了解 i.MX95 启动 ROM 是如何处理主启动、辅助启动和恢复启动阶段的。我已经查阅了参考手册和一些 U-Boot spl 源代码,但我仍然不清楚恢复启动机制的工作原理。 我的目标是实现以下启动架构: 主启动: eMMC Boot0 辅助启动: eMMC 启动1 Recovery 启动: FlexSPI 或非 闪存(黄金恢复镜像) 在查看arch/arm/mach-imx/image-container.c文件时,我注意到以下代码: printf("Boot stage: "); if (rom_data.boot_stage == 0x6) printf("Primary\n"); else if (rom_data.boot_stage == 0x9) printf("Secondary\n"); else if (rom_data.boot_stage == 0xa) printf("Recovery\n"); else printf("USB Serial Download\n"); 根据此,Boot ROM 似乎支持四个启动阶段:主启动、辅助启动、恢复启动和 USB 串口下载启动。但是,我找不到足够的信息来解释如何选择或配置恢复阶段。 我希望就以下问题获得一些指导: 是否可以将FlexSPI 或非 闪存配置为恢复引导设备,同时使用eMMC Boot0 和 Boot1作为主启动分区和辅助启动分区? 如果支持这种配置,推荐的配置方法是什么? 在选择主启动、辅助启动和恢复启动阶段时,启动 ROM 遵循的顺序是什么? 如果主启动和辅助启动都失败,什么情况下会触发恢复启动阶段? 在开发和验证过程中,可以有意重现哪些故障条件来模拟恢复模式? 是否有任何文档或应用说明详细描述了启动 ROM 启动选择算法和恢复启动流程? 引导设备熔丝配置(熔丝模式) 在选择恢复引导设备时 是否 起作用? 恢复设备是由引导设备熔丝决定的吗? 或者,即使启动设备熔丝到 eMMC 上,启动 ROM 能否自动切换到不同的启动设备(例如 FlexSPI NOR)? 最终,我的目标是让系统正常从 eMMC Boot0 启动, 必要时 回退到 eMMC Boot1 , 如果两个 eMMC 启动分区都不可用或无效, 则最终启动 存储在 FlexSPI 或非 中的 Golden Recovery Image 。 如果有人已经实现了类似的启动架构,或者可以向我提供相关的文档或应用笔记,我将非常感谢您的指导。 提前谢谢! BR, 阿伦·库马尔 Re: i.MX95 Boot ROM: Configuring eMMC Boot0/Boot1 as Primary/Secondary and FlexSPI NOR as Recovery 你好, 是否可以将FlexSPI 或非 闪存配置为恢复启动设备,同时使用eMMC Boot0 和 Boot1作为主启动分区和辅助启动分区? 不,这不可能。LP 启动的恢复引导设备只有 LPSPI1/2,你不能将任何其他启动源配置为恢复选项。 Oswalag_0-1783975544422.png
記事全体を表示
IMXRT 1180 系列 您好,NXP团队, 我们目前正在评估恩智浦半导体微控制器在空间机载计算机 (OBC) 应用中的使用情况。 最初,我们考虑的是i.MX RT1170 (MIMXRT1170) ,在评估过程中,我们注意到 NXP 的文档明确指出该器件采用28nm FD-SOI 技术制造。由于半导体工艺技术是我们应用的关键评估标准,因此我们现在也对评估i.MX RT1180系列感兴趣。 在继续进行下一步之前,我们希望了解i.MX RT1180的制造工艺: i.MX RT1180 是否也像 i.MX RT1170 一样,采用28nm FD-SOI 技术制造? 如果没有,能否请您提供RT1180所采用的工艺技术信息? 是否有任何官方文档或产品简介提及该设备的制造节点和工艺技术? 我们查阅了公开的文档,但未能找到有关 RT1180 工艺技术的官方声明。 这些信息对我们的内部技术评估和认证活动非常重要,我们非常感谢您的指导。 感谢您的支持。 Re: IMXRT 1180 Family 嗨@mayliu1 , 感谢您的快速回复,并确认i.MX RT1180采用28nm FD-SOI 技术制造。 我们希望您能再澄清一点。请问这是否适用于整个 i.MX RT1180 系列,包括以下设备? i.MX RT1186 i.MX RT1187 i.MX RT1189 如果 RT1180 系列的所有成员都采用相同的 28nm FD-SOI 工艺制造,则此信息将有助于我们进行外围和特征分析,以确定最适合我们应用的设备。 希望您能确认一下。 感谢您的支持。 此致, 鲁斯维克·R Re: IMXRT 1180 Family 嗨@ruthvik_1 , 非常感谢您对我们产品的关注以及对我们社区的使用。 是的。i.MX RT1180 采用 28 纳米 FD-SOI 技术。 抱歉,目前还没有任何公开的官方文件或产品简介明确提及该设备的制造节点或工艺技术。 希望对你有帮助 顺祝商祺! 5月 Re: IMXRT 1180 Family 嗨@mayliu1 , 感谢您的及时回复和确认。这些信息非常有帮助,非常感谢。 根据您的确认,我们将继续进行评估,并将此视为对该制造技术的确认。 感谢您的支持。 问候, 鲁斯维克·R Re: IMXRT 1180 Family 嗨@ruthvik_1 , 感谢您的反馈。 是的,我查阅了 i.MX RT1186、i.MX RT1187 和 i.MX RT1189 的相关信息。它们均采用相同的 28nm FD-SOI 工艺技术制造。   希望对你有帮助 顺祝商祺! 5月
記事全体を表示
NXPRDLIB_REM_GEN_INTFS の使用状況 <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> こんにちは。 NXP Reader Library のNXPRDLIB_REM_GEN_INTFS定義の正確な目的を知りたいです。 私の見る限り、定義されていればプロジェクトと一緒にソフトウェアAPIインターフェースが構築され、そうでなければバイナリの同等のものに置き換えられます。なぜなら、その場合は関数プロトタイプしか利用できないからです... これは正しいですか?もしそうなら、二進リベラルはどこにあるのでしょうか?バイナリを選ぶことのメリット・デメリットは何ですか? よろしくお願いします、 ペッペ NFCリーダー・ライブラリ Re: NXPRDLIB_REM_GEN_INTFS usage @stephanie_m これはDoxygen-Dokuのバグです。 /* デバッグビルドモード */ /*#define NXPBUILD__PH_DEBUG*/ /**< デバッグビルド定義 */ #define NXPRDLIB_REM_GEN_INTFS したがって、正解はまだ確定していません。 Re: NXPRDLIB_REM_GEN_INTFS usage <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> こんにちは、 リーダーライブラリのAPIドキュメントによると、あなたが見ている定義はビルドデバッグ目的です よろしくお願いいたします。 エステファニア Re: NXPRDLIB_REM_GEN_INTFS usage <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> エステファニアさん、こんにちは。ご関心をお寄せいただきありがとうございます。 例えばPN7462AU-FW_v05.21.00_Full file rootから、その定義は一部のNFCリーダライブラリの例で有効になっています: $ grep -r NXPRDLIB_REM_GEN_INTFS NfcrdlibEx* NfcrdlibEx4_MIFAREClassic/intfs/ph_NxpBuild_App.h:#define NXPRDLIB_REM_GEN_INTFS NfcrdlibEx5_ISO15693/intfs/ph_NxpBuild_App.h:#define NXPRDLIB_REM_GEN_INTFS NfcrdlibEx7_EMVCo_Polling/intfs/ph_NxpBuild_App.h:#define NXPRDLIB_REM_GEN_INTFS NfcrdlibEx9_NTagI2C/intfs/ph_NxpBuild_App.h:#define NXPRDLIB_REM_GEN_INTFS また、PN7462AU PSPの例でも同様のことが言えます。 $ grep -r NXPRDLIB_REM_GEN_INTFS PN7462AU* PN7462AU_ex_phExMain/inc/APP_NxpBuild.h:#define NXPRDLIB_REM_GEN_INTFS PN7462AU_ex_phExVCom/inc/APP_NxpBuild.h:#define NXPRDLIB_REM_GEN_INTFS また、NFCリーダライブラリの多くの資料で確認されています: $ grep -r NXPRDLIB_REM_GEN_INTFS NxpNfcRdLib/ NxpNfcRdLib/comps/phacDiscLoop/src/phacDiscLoop.c:#ifndef NXPRDLIB_REM_GEN_INTFS NxpNfcRdLib/comps/phacDiscLoop/src/phacDiscLoop.c:#endif /* NXPRDLIB_REM_GEN_INTFS */ NxpNfcRdLib/comps/phalFelica/src/phalFelica.c:#ifndefNXPRDLIB_REM_GEN_INTFS NxpNfcRdLib/comps/phalFelica/src/phalFelica.c:#endif /* NXPRDLIB_REM_GEN_INTFS */ NxpNfcRdLib/comps/phalI18000p3m3/src/phalI18000p3m3.c:#ifndefNXPRDLIB_REM_GEN_INTFS NxpNfcRdLib/comps/phalI18000p3m3/src/phalI18000p3m3.c:#endif /* NXPRDLIB_REM_GEN_INTFS */ (…) よろしくお願いいたします。 ペッペ Re: NXPRDLIB_REM_GEN_INTFS usage <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> こんにちは、 使用しているライブラリのバージョンは何ですか?その情報と、その定義が表示されているファイルを教えていただけませんか? APIのドキュメントにもライブラリでも、あなたが言及している定義を見つけることができなかったので、とても助かると思います。 よろしくお願いいたします。 エステファニア
記事全体を表示
HSEからの回答待ち HSEの回答が保留中のまま、S32K312 MCUとのOTAアップデート中に届かなかった過去の事例があるかどうかを伺いたいです。 また、どのような状況下でHSEの対応が保留となる可能性があるのかをご確認ください。 Re: Pending HSE response HSEサービスが永久に保留状態になる原因となる、既知のS32K312 OTAの問題は把握しておりません。 一般的に、すべてのHSEサービスリクエストには応答が返されるべきである。応答がない場合は、HSEファームウェアが致命的なエラーを検出し、シャットダウンモードに入ったことを示している可能性があります。この場合、診断情報についてはMU GSR登録簿を確認することをお勧めします。 原因としては、無効なサービスパラメータ、無効なメモリアドレス、XRDCアクセス違反、ECCエラー、クロックや初期化の問題、リソースの競合、その他の致命的なHSE内部エラーなどがあります。 調査にご協力いただくため、問題発生時のHSEファームウェアのバージョン、実行中の特定のHSEサービス、サービス記述子、およびMUステータスレジスタ(FSR/GSR)の情報をご提供ください。
記事全体を表示
等待 HSE 回复 我想咨询一下,之前是否有过这样的情况:在使用 S32K312 MCU 进行 OTA 更新时,HSE 响应一直处于待处理状态,没有到达。 此外,请确认在何种情况下 HSE 回复可能会处于待定状态。 Re: Pending HSE response 我们目前尚未发现任何已知的 S32K312 OTA 问题会导致 HSE 服务永久处于待处理状态。 一般来说,每个 HSE 服务请求都应该返回一个响应。如果没有收到响应,则可能表明 HSE 固件遇到了致命错误并进入了关机模式。在这种情况下,我们建议检查 MU GSR 寄存器以获取诊断信息。 可能的原因包括无效的服务参数、无效的内存地址、XRDC 访问冲突、ECC 错误、时钟或初始化问题、资源冲突或其他致命的 HSE 内部错误。 为了帮助调查,请提供 HSE 固件版本、正在执行的具体 HSE 服务、服务描述符以及出现问题时的 MU 状态寄存器(FSR/GSR)。
記事全体を表示
Pending HSE response I would like to inquire if there have been previous instances where the HSE response remained pending and did not arrive during an OTA update with the S32K312 MCU. Additionally, please confirm under what circumstances the HSE response might become pending. Re: Pending HSE response We are not aware of a known S32K312 OTA issue that causes HSE services to remain permanently pending. In general, every HSE service request should return a response. If no response is received, it may indicate that the HSE firmware encountered a fatal error and entered shutdown mode. In this case, we recommend checking the MU GSR register for diagnostic information. Possible causes include invalid service parameters, invalid memory addresses, XRDC access violations, ECC errors, clock or initialization issues, resource conflicts, or other fatal HSE internal errors. To help investigate, please provide the HSE FW version, the specific HSE service being executed, the service descriptor, and the MU status registers (FSR/GSR) when the issue occurs.
記事全体を表示
MCTPTX1AK324,FreeMASTER 连接问题 0x80000101 我正在使用MCTPTX1AK324开发板进行电机开发。目前,当我按下按钮3时,电机可以运转。我需要使用MCAT主机来调整设置,但是当我使用freeMASTER通过串口连接时,出现错误:连接超时,0x8000 0101。请问您能否帮忙查看一下示例程序是否需要修改? 目前,演示程序的部分代码被屏蔽了。在 M3 上初始化 GD3000 和 IPCF 会导致程序冻结,因此我们根据 FAE 的建议阻止了它们。 第三季度 Re: MCTPTX1AK324, FreeMASTER connecttion problem 0x80000101 你好, 以下是一些解决 FreeMASTER 连接超时问题的通用提示。如果这些方法都不奏效,我会尝试联系电机控制团队寻求更具体的帮助。 通常情况下,超时意味着板没有响应 FreeMASTER 命令。我建议如下: 1. 请确保您运行的是从 NXP 收到的原始未修改软件,并且使用原装电路板套件。 2. 检查连接端口和电缆。在 FreeMASTER 中,转到“项目/选项”,然后检查串行 COM 端口。您的系统中可能存在多个端口,而您选择了错误的端口。 3. 使用工具/连接向导探测不同的 COM 端口。 4. 尝试将 FreeMASTER 与不同的应用程序一起使用,理想情况下,如果目标板有 FreeMASTER 示例应用程序,则可以使用这些示例应用程序。 5. 进阶:将示波器或逻辑分析仪连接到串行通信线路,查看 RX 和 TX 信号是否有效。在 FMSTR_ProtocolDecoder 处设置断点,看看代码是否会在那里停止。否则,这些命令甚至无法到达MCU。 问候, 米哈尔
記事全体を表示
NXPRDLIB_REM_GEN_INTFS 用法 <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> 你好。 我想知道 恩智浦读取器库 中NXPRDLIB_REM_GEN_INTFS定义的确切用途是什么。 据我观察,如果定义了软件 API 接口,则会在项目中构建该接口;否则,它会被某种二进制等效代码所取代,因为那样的话就只有函数原型可用了…… 这样对吗?如果是这样,二进制库在哪里?选择二进制而非软件 API 的优缺点是什么? 先感谢您, 佩佩 NFC读卡器库 Re: NXPRDLIB_REM_GEN_INTFS usage @stephanie_m 这是 Doxygen-Doku 的一个 bug: /* 调试版本模式 */ /*#define NXPBUILD__PH_DEBUG*/ /**< DEBUG 版本定义 */ #define NXPRDLIB_REM_GEN_INTFS 因此,正确答案尚未揭晓…… Re: NXPRDLIB_REM_GEN_INTFS usage <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> 你好, 根据读取器库的 API 文档,您看到的这个定义是用于版本调试目的的。 此致, 埃斯特法尼亚 Re: NXPRDLIB_REM_GEN_INTFS usage <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> 您好,Estephania,感谢您的关注。 例如,从 PN7462AU-FW_v05.21.00_Full 文件根目录开始,该定义已在某些 NFC 阅读器库示例中启用: $ grep -r NXPRDLIB_REM_GEN_INTFS NfcrdlibEx* NfcrdlibEx4_MIFAREClassic/intfs/ph_NxpBuild_App.h:#define NXPRDLIB_REM_GEN_INTFS NfcrdlibEx5_ISO15693/intfs/ph_NxpBuild_App.h:#define NXPRDLIB_REM_GEN_INTFS NfcrdlibEx7_EMVCo_Polling/intfs/ph_NxpBuild_App.h:#define NXPRDLIB_REM_GEN_INTFS NfcrdlibEx9_NTagI2C/intfs/ph_NxpBuild_App.h:#define NXPRDLIB_REM_GEN_INTFS 在某些PN7462AU PSP示例中也是如此: $ grep -r NXPRDLIB_REM_GEN_INTFS PN7462AU* PN7462AU_ex_phExMain/inc/APP_NxpBuild.h:#define NXPRDLIB_REM_GEN_INTFS PN7462AU_ex_phExVCom/inc/APP_NxpBuild.h:#define NXPRDLIB_REM_GEN_INTFS 而且在 NFC 阅读器库的许多源代码中都有所验证: $ grep -r NXPRDLIB_REM_GEN_INTFS NxpNfcRdLib/ NxpNfcRdLib/comps/phacDiscLoop/src/phacDiscLoop.c:#ifndef NXPRDLIB_REM_GEN_INTFS NxpNfcRdLib/comps/phacDiscLoop/src/phacDiscLoop.c:#endif /* NXPRDLIB_REM_GEN_INTFS */ NxpNfcRdLib/comps/phalFelica/src/phalFelica.c:#ifndefNXPRDLIB_REM_GEN_INTFS NxpNfcRdLib/comps/phalFelica/src/phalFelica.c:#endif /* NXPRDLIB_REM_GEN_INTFS */ NxpNfcRdLib/comps/phalI18000p3m3/src/phalI18000p3m3.c:#ifndefNXPRDLIB_REM_GEN_INTFS NxpNfcRdLib/comps/phalI18000p3m3/src/phalI18000p3m3.c:#endif /* NXPRDLIB_REM_GEN_INTFS */ (……) 顺祝商祺! 佩佩 Re: NXPRDLIB_REM_GEN_INTFS usage <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> 你好, 你使用的是哪个版本的库?请问您能否提供相关信息以及您看到此定义的文件? 我在 API 文档和库中都找不到您提到的定义,所以如果您能提供给我,将对我帮助很大。 问候, 埃斯特法尼亚
記事全体を表示
IMXRT 1180 Family Hello NXP Team, We are currently evaluating NXP microcontrollers for use in a Space On-Board Computer (OBC) application. Initially, we were considering the i.MX RT1170 (MIMXRT1170), and during our assessment we noted that NXP documentation specifies that the device is manufactured using 28nm FD-SOI technology. Since semiconductor process technology is a key evaluation criterion for our application, we are now also interested in evaluating the i.MX RT1180 family. Before proceeding further, we would appreciate clarification regarding the manufacturing process used for the i.MX RT1180: Is the i.MX RT1180 also fabricated using 28nm FD-SOI technology, similar to the i.MX RT1170? If not, could you please provide information on the process technology used for the RT1180? Is there any official documentation or product brief that references the manufacturing node and process technology for this device? We have reviewed the publicly available documentation but were unable to locate an official statement regarding the RT1180 process technology. This information is important for our internal technology assessment and qualification activities, and we would greatly appreciate your guidance. Thank you for your support. Re: IMXRT 1180 Family Hi @mayliu1, Thank you for the quick reply and for confirming that the i.MX RT1180 is manufactured using 28nm FD-SOI technology. We would appreciate one additional clarification. Could you please confirm whether this applies to the entire i.MX RT1180 family, including the following devices? i.MX RT1186 i.MX RT1187 i.MX RT1189 If all members of the RT1180 family are fabricated using the same 28nm FD-SOI process, this information will help us proceed with our peripheral and feature analysis to determine the most suitable device for our application. We would appreciate your confirmation. Thank you for your support. Best regards, Ruthvik R Re: IMXRT 1180 Family Hi @ruthvik_1 , Thank you so much for your interest in our products and for using our community. Yes. The i.MX RT1180 uses 28 nm FD-SOI technology . Sorry, but there is currently no public official documentation or product brief that explicitly references the manufacturing node or process technology for this device. Wish it helps you Best Regards, May Re: IMXRT 1180 Family Hi @mayliu1, Thank you for your prompt response and confirmation. This information is very helpful and greatly appreciated. Based on your confirmation, we will proceed with our evaluation and consider this as confirmation for the manufacturing technology. Thank you for your support. Regards, Ruthvik R Re: IMXRT 1180 Family Hi @ruthvik_1 , Thanks for your feedback. Yes, I checked the information for the i.MX RT1186, i.MX RT1187, and i.MX RT1189. They are all manufactured using the same 28nm FD-SOI process technology.   Wish it helps you Best Regards May
記事全体を表示
NVT4857UKAZ 的替代零件 这与软件的直接关系不大,但我们最近发现NVT4857UKAZ已经停产,并且没有引脚兼容的替代零件可用。由于 SD 卡支持是我们基于 i.MX95 的设备所必需的功能,因此我们正在努力了解在这种情况下有哪些替代方案。您能否就可能的替代方案或设计方案提出一些建议? Re: Alternative part for NVT4857UKAZ 您好! 您可以参考NVT4858作为替代品。 但是请注意,NVT4858 不是直接替代产品。因此,为了在您的应用中适应新设备,可能需要对硬件和软件进行修改。 ErikaC_0-1783547925570.png 我们建议仔细审查规范和设计要求,以评估迁移的影响。 希望这能帮到你! Re: Alternative part for NVT4857UKAZ 您好! 您可以参考NVT4858作为替代品。 但是请注意,NVT4858 不是直接替代产品。因此,为了在您的应用中适应新设备,可能需要对硬件和软件进行修改。 ErikaC_0-1783547925570.png 我们建议仔细审查规范和设计要求,以评估迁移的影响。 希望这能帮到你!
記事全体を表示