Seeking help regarding the rotation issue on the RT1052 display. The screen I purchased is portrait orientation, but I need it to be displayed in landscape mode. I used guiguider to generate the basic display code for the RT1052. And add software rotation disp_drv.sw_rotate= 1; disp_drv.rotated = 1;   Set as single buffer SDK_ALIGN( __attribute__ ((section("lvglDisplayBuffer"))) static uint8_t s_frameBuffer[1][DEMO_FB_SIZE], DEMO_FB_ALIGN); SDK_ALIGN( __attribute__ ((section("lvglDisplayBuffer"))) static uint8_t s_lvglBuffer[DEMO_DB_SIZE], DEMO_FB_ALIGN); The screen displays correctly, but the refresh rate is too slow and doesn't meet my needs.   Set as double buffer SDK_ALIGN( __attribute__((section("lvglDisplayBuffer"))) static uint8_t s_frameBuffer[2][DEMO_FB_SIZE], DEMO_FB_ALIGN); Only the backlight is on; the screen is black. why is that?   #if FB_USE_SRAM static void DEMO_WaitVsync(lv_disp_drv_t *disp_drv) { s_framePending = true; #if defined(SDK_OS_FREE_RTOS) if (xSemaphoreTake(s_frameSema, portMAX_DELAY) != pdTRUE) { PRINTF("Display flush failed\r\n"); assert(0); } #else while (s_framePending) { } #endif } static void copy_area(const lv_area_t *area, lv_color_t *color_p, uint8_t *fb, uint32_t fbStrideBytes) { uint32_t y; uint32_t areaWidth = lv_area_get_width(area); fb += (area->y1 * fbStrideBytes + area->x1 * sizeof(lv_color_t)); for (y = area->y1; y <= area->y2; y++) { lv_memcpy(fb, color_p, areaWidth * sizeof(lv_color_t)); fb += fbStrideBytes; color_p += areaWidth; } } static void DEMO_FlushDisplay(lv_disp_drv_t *disp_drv, const lv_area_t *area, lv_color_t *color_p) { /* Wait VSYNC for each small update. / DEMO_WaitVsync(disp_drv); /* Copy data from draw buffer to frame buffer./ copy_area(area, color_p, (uint8_t*) s_frameBuffer, LCD_WIDTH * LCD_FB_BYTE_PER_PIXEL); SCB_CleanInvalidateDCache(); lv_disp_flush_ready(disp_drv); } #else static void DEMO_FlushDisplay(lv_disp_drv_t *disp_drv, const lv_area_t *area, lv_color_t *color_p) { // DCACHE_CleanByRange((uint32_t)color_p, DEMO_FB_SIZE); DCACHE_CleanInvalidateByRange((uint32_t)color_p, DEMO_FB_SIZE); ELCDIF_SetNextBufferAddr(LCDIF, (uint32_t)color_p); s_framePending = true; #if defined(SDK_OS_FREE_RTOS) if (xSemaphoreTake(s_frameSema, portMAX_DELAY) == pdTRUE) { /* IMPORTANT!!! * Inform the graphics library that you are ready with the flushing*/ lv_disp_flush_ready(disp_drv); } else { PRINTF("Display flush failed\r\n"); assert(0); } #else while (s_framePending) { } /* IMPORTANT!!! * Inform the graphics library that you are ready with the flushing*/ lv_disp_flush_ready(disp_drv); #endif } #endif i.MXRT 105x Re: 求助关于RT1052显示旋转问题 Hi @dsd , Thank you for your question! First, please check the following LVGL limitations: Screen rotation is not supported when full_refresh=1 is enabled. Please refer to: 1. https://github.com/lvgl/lvgl/issues/4060 2. https://forum.lvgl.io/t/why-cannot-rotate-a-full-refreshed-display/10490/3   Additionally, the RT1050 has hardware PXP support for rotation, which is the more recommended solution. Please refer to: https://docs.nxp.com/bundle/GUIGUIDERUG-1.6.1/page/topics/rotate_screen_and_widgets.html And the PXP rotation-related demo in the SDK.   Best regards, Gavin Re: 求助关于RT1052显示旋转问题 Helllo, When using NXP i.MX RT1052 with Guiguider (LVGL) for screen rotation development, the "slow single-buffer refresh and black screen with double-buffer" problem you encounter is mainly due to the mismatch between software rotation and the hardware ELCDIF controller, double-buffer switching mechanism, and memory address index. Best Regards Re: 求助关于RT1052显示旋转问题 Thank you very much, rotating the PXP drive does work and perfectly solves the problem.

Rom Bootloader WriteMemory Command CRC16 calculation I'm currently trying to program a KL17 microcontroller using another microcontroller and the KL17's built in UART ROM bootloader. I got pinging and erasing done, at least on the paper, but I'm struggling with writing data to the KL17. The example in the datasheet (page 43) says that for those bytes (framing packet,  excluding CRC16 bytes + memory write command packet):   0x5A, 0xA4, 0x0C, 0x00, 0x04, 0x00 , 0x00, 0x02, 0x00, 0x04, 0x00, 0x20, 0x64, 0x00, 0x00, 0x00  the CRC16 bytes would be 0x06 0x5A. However the CRC16 algorithm provided on page 27 outputs 0x2b 0x56 for me. I've also tried various CRC16 calculators online with many different variants of CRC16 calculation but none of them gave me 0x06 0x5A. Noay_0-1790003799652.png My assumption is that I'm either missing bytes that must be included into the caluclation (I wouldn't know which since the data packets following afterwards all got their own CRC16 bytes) or that someone just messed up the datasheet (which is also unlikely because this example is also exactly like that in the KL17 Sub-Family Reference Manual).  Re: Rom Bootloader WriteMemory Command CRC16 calculation Hello @Noay , Thanks for your post. I think the "0x06 0x5A" value in the Reference Manual is incorrect and most likely a documentation issue. Based on what you provided, your CRC calculation result of "0x2B 0x56" looks correct. You can still use blhost tool to debug Bootloader commands. The parameter "-d" will provide all communication process between Host and Target. I have tried this function on my KL27 board, and please see the screenshot below. We don't have a KL17 EVB board available, could you try the same approach on your KL17 device and see what result you get? Apologies for the documentation mistake. I'll share this with the internal team and recommend updating the documents accordingly. BR Celeste

jailhouse DTS for 9x9 imx.93 Hi - Do you provide DTS files for jailhouse on the 9x9 imx.93?  I can only find ones for the 11x11. Thanks David Re: jailhouse DTS for 9x9 imx.93 Hello, This device tree will be included in the next BSP release. // SPDX-License-Identifier: (GPL-2.0+ OR MIT) /* * Copyright 2023 NXP */ /dts-v1/; #include / { model = "NXP i.MX93 9x9 QSB"; compatible = "fsl,imx93-9x9-qsb", "fsl,imx93"; interrupt-parent = <&gic>; #address-cells = <2>; #size-cells = <2>; aliases { mmc0 = &usdhc1; serial1 = &lpuart2; }; cpus { #address-cells = <1>; #size-cells = <0>; A55_0: cpu@0 { device_type = "cpu"; compatible = "arm,cortex-a55"; reg = <0x0>; enable-method = "psci"; #cooling-cells = <2>; }; }; psci { compatible = "arm,psci-1.0"; method = "smc"; }; gic: interrupt-controller@48000000 { compatible = "arm,gic-v3"; reg = <0 0x48000000 0 0x10000>, <0 0x48040000 0 0xc0000>; #interrupt-cells = <3>; interrupt-controller; interrupts = ; interrupt-parent = <&gic>; }; timer { compatible = "arm,armv8-timer"; interrupts = , , , ; clock-frequency = <24000000>; }; clk_dummy: clock-dummy { compatible = "fixed-clock"; #clock-cells = <0>; clock-frequency = <0>; clock-output-names = "clk_dummy"; }; clk_400m: clock-400m { compatible = "fixed-clock"; #clock-cells = <0>; clock-frequency = <200000000>; clock-output-names = "200m"; }; osc_24m: clock-osc-24m { compatible = "fixed-clock"; #clock-cells = <0>; clock-frequency = <24000000>; clock-output-names = "osc_24m"; }; pci@fd700000 { compatible = "pci-host-ecam-generic"; device_type = "pci"; bus-range = <0 0>; #address-cells = <3>; #size-cells = <2>; #interrupt-cells = <1>; interrupt-map-mask = <0 0 0 7>; interrupt-map = <0 0 0 1 &gic GIC_SPI 227 IRQ_TYPE_EDGE_RISING>, <0 0 0 2 &gic GIC_SPI 228 IRQ_TYPE_EDGE_RISING>, <0 0 0 3 &gic GIC_SPI 229 IRQ_TYPE_EDGE_RISING>, <0 0 0 4 &gic GIC_SPI 230 IRQ_TYPE_EDGE_RISING>; reg = <0x0 0xfd700000 0x0 0x100000>; ranges = <0x02000000 0x00 0x10000000 0x0 0x10000000 0x00 0x10000>; }; soc@0 { compatible = "simple-bus"; #address-cells = <1>; #size-cells = <1>; ranges = <0x0 0x0 0x0 0x80000000>, <0x28000000 0x0 0x28000000 0x10000000>; aips1: bus@44000000 { compatible = "fsl,aips-bus", "simple-bus"; reg = <0x44000000 0x800000>; #address-cells = <1>; #size-cells = <1>; ranges; lpuart2: serial@44390000 { compatible = "fsl,imx93-lpuart", "fsl,imx8ulp-lpuart", "fsl,imx7ulp-lpuart"; reg = <0x44390000 0x1000>; interrupts = ; status = "disabled"; }; }; aips3: bus@42800000 { compatible = "fsl,aips-bus", "simple-bus"; reg = <0x42800000 0x800000>; #address-cells = <1>; #size-cells = <1>; ranges; usdhc1: mmc@42850000 { compatible = "fsl,imx93-usdhc", "fsl,imx8mm-usdhc"; reg = <0x42850000 0x10000>; interrupts = ; fsl,tuning-start-tap = <20>; fsl,tuning-step= <2>; status = "disabled"; }; }; }; }; &lpuart2 { clocks = <&osc_24m>; clock-names = "ipg"; status = "okay"; }; &usdhc1 { clocks = <&clk_dummy>, <&clk_dummy>, <&clk_400m>; clock-names = "ipg", "ahb", "per"; bus-width = <8>; non-removable; status = "okay"; }; Best regards. Re: jailhouse DTS for 9x9 imx.93 do you also have the matching root cell config file for qsb jailhouse on the 9x9? thanks

监狱 DTS 适用于 9x9 imx.93 您好 - 请问你们提供适用于 9x9 imx.93 的 jailhouse 的 DTS 文件吗？我只能找到11x11尺寸的。 谢谢！ 大卫 Re: jailhouse DTS for 9x9 imx.93 你好， 该设备树将包含在下一个 电路板支持包。 版本中。 // SPDX-License-Identifier: (GPL-2.0+ OR MIT) /* * Copyright 2023 NXP */ /dts-v1/; #include / { model = "NXP i.MX93 9x9 QSB"; compatible = "fsl,imx93-9x9-qsb", "fsl,imx93"; interrupt-parent = <&gic>; #address-cells = <2>; #size-cells = <2>; aliases { mmc0 = &usdhc1; serial1 = &lpuart2; }; cpus { #address-cells = <1>; #size-cells = <0>; A55_0: cpu@0 { device_type = "cpu"; compatible = "arm,cortex-a55"; reg = <0x0>; enable-method = "psci"; #cooling-cells = <2>; }; }; psci { compatible = "arm,psci-1.0"; method = "smc"; }; gic: interrupt-controller@48000000 { compatible = "arm,gic-v3"; reg = <0 0x48000000 0 0x10000>, <0 0x48040000 0 0xc0000>; #interrupt-cells = <3>; interrupt-controller; interrupts = ; interrupt-parent = <&gic>; }; timer { compatible = "arm,armv8-timer"; interrupts = , , , ; clock-frequency = <24000000>; }; clk_dummy: clock-dummy { compatible = "fixed-clock"; #clock-cells = <0>; clock-frequency = <0>; clock-output-names = "clk_dummy"; }; clk_400m: clock-400m { compatible = "fixed-clock"; #clock-cells = <0>; clock-frequency = <200000000>; clock-output-names = "200m"; }; osc_24m: clock-osc-24m { compatible = "fixed-clock"; #clock-cells = <0>; clock-frequency = <24000000>; clock-output-names = "osc_24m"; }; pci@fd700000 { compatible = "pci-host-ecam-generic"; device_type = "pci"; bus-range = <0 0>; #address-cells = <3>; #size-cells = <2>; #interrupt-cells = <1>; interrupt-map-mask = <0 0 0 7>; interrupt-map = <0 0 0 1 &gic GIC_SPI 227 IRQ_TYPE_EDGE_RISING>, <0 0 0 2 &gic GIC_SPI 228 IRQ_TYPE_EDGE_RISING>, <0 0 0 3 &gic GIC_SPI 229 IRQ_TYPE_EDGE_RISING>, <0 0 0 4 &gic GIC_SPI 230 IRQ_TYPE_EDGE_RISING>; reg = <0x0 0xfd700000 0x0 0x100000>; ranges = <0x02000000 0x00 0x10000000 0x0 0x10000000 0x00 0x10000>; }; soc@0 { compatible = "simple-bus"; #address-cells = <1>; #size-cells = <1>; ranges = <0x0 0x0 0x0 0x80000000>, <0x28000000 0x0 0x28000000 0x10000000>; aips1: bus@44000000 { compatible = "fsl,aips-bus", "simple-bus"; reg = <0x44000000 0x800000>; #address-cells = <1>; #size-cells = <1>; ranges; lpuart2: serial@44390000 { compatible = "fsl,imx93-lpuart", "fsl,imx8ulp-lpuart", "fsl,imx7ulp-lpuart"; reg = <0x44390000 0x1000>; interrupts = ; status = "disabled"; }; }; aips3: bus@42800000 { compatible = "fsl,aips-bus", "simple-bus"; reg = <0x42800000 0x800000>; #address-cells = <1>; #size-cells = <1>; ranges; usdhc1: mmc@42850000 { compatible = "fsl,imx93-usdhc", "fsl,imx8mm-usdhc"; reg = <0x42850000 0x10000>; interrupts = ; fsl,tuning-start-tap = <20>; fsl,tuning-step= <2>; status = "disabled"; }; }; }; }; &lpuart2 { clocks = <&osc_24m>; clock-names = "ipg"; status = "okay"; }; &usdhc1 { clocks = <&clk_dummy>, <&clk_dummy>, <&clk_400m>; clock-names = "ipg", "ahb", "per"; bus-width = <8>; non-removable; status = "okay"; }; 顺祝商祺！ Re: jailhouse DTS for 9x9 imx.93 您是否也有适用于 9x9 上 qsb jailhouse 的匹配根单元配置文件？ 谢谢

IW612 WLAN 5GHz伝送 こんにちは、 私たちはIoT製品の一つでIW612 SoCをWLAN用に使用する予定で、ターゲットマーケットは米国とカナダです。IW612はデュアルバンドの2.4GHzと5GHzに対応しています。カナダのISEDでは、ライセンスなしでは屋外環境でのUNII-1（5150～5250MHz）Wi-Fi送信が許可されておらず、屋内でのみ動作するように制限されているため、5GHz Wi-Fiの動作をオフにする方法や設定はありますか？ 当社の製品は屋外で動作しており、5GHzを完全に無効化し、2.4GHzのみで動作させる方法が欲しいと考えています。 RSS-247 — 902～928 MHz、2400～2483.5 MHz 帯のデジタル伝送システム、周波数ホッピングシステム、および免許不要のローカルエリアネットワーク機器MHz帯、5150～5350MHz帯、および5470～5895MHz帯 同じ設定を確認して共有してもらえますか? よろしくお願いいたします。 アルン RF Re: IW612 WLAN 5GHz transmission こんにちは、@pantarun_92 iw612はパワーテーブルの読み込みに対応しています。カスタムパワーテーブルを作ったり、カナダ地域ごとにサンプルテーブルを使うこともできます。許可されていないチャネルを無効にし、DFSチャネルをサポートします。 よろしくお願いいたします。 ショーン

RT1052ディスプレイの回転問題について、ご助言をお願いいたします。 購入した画面は縦向きですが、横向きで表示する必要があります。RT1052用の基本的な表示コードを生成するためにguiguiderを使用しました。 さらにソフトウェアローテーションを追加する disp_drv.sw_rotate= 1; disp_drv.rotated = 1;   単一バッファとして設定 SDK_ALIGN( __attribute__ ((section("lvglDisplayBuffer"))) static uint8_t s_frameBuffer[1][DEMO_FB_SIZE], DEMO_FB_ALIGN); SDK_ALIGN( __attribute__ ((section("lvglDisplayBuffer"))) static uint8_t s_lvglBuffer[DEMO_DB_SIZE], DEMO_FB_ALIGN); 画面表示は正しいのですが、リフレッシュレートが遅すぎて私のニーズを満たしていません。   ダブルバッファとして設定 SDK_ALIGN( __attribute__((section("lvglDisplayBuffer"))) static uint8_t s_frameBuffer[2][DEMO_FB_SIZE], DEMO_FB_ALIGN); バックライトだけが点灯しており、画面は真っ暗です。 何故ですか？   #if FB_USE_SRAM static void DEMO_WaitVsync(lv_disp_drv_t *disp_drv) ヤージュ s_framePending = true; #if defined(SDK_OS_FREE_RTOS) if (xSemaphoreTake(s_frameSema, portMAX_DELAY) != pdTRUE) ヤージュ PRINTF("ディスプレイのフラッシュに失敗しました\r\n"); assert(0); } ＃それ以外 while (s_framePending) ヤージュ } #endif } static void copy_area(const lv_area_t *area, lv_color_t *color_p, uint8_t *fb, uint32_t fbStrideBytes) ヤージュ uint32_t y; uint32_t areaWidth = lv_area_get_width(area); fb += (area->y1 * fbStrideBytes + area->x1 * sizeof(lv_color_t)); for (y = area->y1; y <= area->y2; y++) ヤージュ lv_memcpy(fb, color_p, areaWidth * sizeof(lv_color_t)); fb += fbStrideBytes; color_p += areaWidth; } } static void DEMO_FlushDisplay(lv_disp_drv_t *disp_drv, const lv_area_t *area, lv_color_t *color_p) ヤージュ /* 各小さな更新ごとに VSYNC を待機します。/ DEMO_WaitVsync(disp_drv); /* ドローバッファからフレームバッファにデータをコピーします。/ copy_area(area, color_p, (uint8_t*) s_frameBuffer, LCD_WIDTH * LCD_FB_BYTE_PER_PIXEL); SCB_CleanInvalidateDCache(); lv_disp_flush_ready(disp_drv); } ＃それ以外 static void DEMO_FlushDisplay(lv_disp_drv_t *disp_drv, const lv_area_t *area, lv_color_t *color_p) ヤージュ // DCACHE_CleanByRange((uint32_t)color_p, DEMO_FB_SIZE); DCACHE_CleanInvalidateByRange((uint32_t)color_p, DEMO_FB_SIZE); ELCDIF_SetNextBufferAddr(LCDIF, (uint32_t)color_p); s_framePending = true; #if defined(SDK_OS_FREE_RTOS) if (xSemaphoreTake(s_frameSema, portMAX_DELAY) == pdTRUE) ヤージュ /* 重要！！！ * グラフィックライブラリに、フラッシュの準備ができたことを通知します */ lv_disp_flush_ready(disp_drv); } それ以外 ヤージュ PRINTF("ディスプレイのフラッシュに失敗しました\r\n"); assert(0); } ＃それ以外 while (s_framePending) ヤージュ } /* 重要！！！ * グラフィックライブラリに、フラッシュの準備ができたことを通知します */ lv_disp_flush_ready(disp_drv); #endif } #endif i.MXRT 105x Re: 求助关于RT1052显示旋转问题 こんにちは、 @dsd さん。 ご質問ありがとうございます！ まず、以下のLVGLの制限事項をご確認ください。full_refresh=1が有効になっている場合、画面の回転はサポートされません。詳細は以下を参照してください。 1. https://github.com/lvgl/lvgl/issues/4060 2. https://forum.lvgl.io/t/why-cannot-rotate-a-full-refreshed-display/10490/3   さらに、RT1050は回転のためのハードウェアPXPサポートを備えており、こちらの方が推奨されるソリューションです。詳細については、 https://docs.nxp.com/bundle/GUIGUIDERUG-1.6.1/page/topics/rotate_screen_and_widgets.htmlを参照してください。 SDKにはPXPの回転に関するデモも含まれています。   よろしくお願いします、 ギャビン Re: 求助关于RT1052显示旋转问题 こんにちは、 NXP i.MX RT1052をGuiguider（LVGL）と組み合わせて画面回転の開発に使用する場合、「シングルバッファのリフレッシュが遅く、ダブルバッファを使用すると画面が真っ黒になる」という問題が発生するのは、主にソフトウェアの回転とハードウェアのELCDIFコントローラ、ダブルバッファ切り替えメカニズム、およびメモリアドレスインデックスとの不一致が原因です。 よろしくお願いします Re: 求助关于RT1052显示旋转问题 どうもありがとうございました。PXPドライブを回転させることで問題が解決し、完全に解決しました。

FRDM-K64F PITの異なるRevボード こんにちは、 私はNRF23L01トランシーバを搭載した6枚のFRDM-K64Fボードを使った無線ネットワークの実験を行っています。 1秒を10のタイムスロットに分割しています。つまり、スロット1の送信はタイムスロット2で繰り返され、タイムスロット2はタイムスロット3に繰り返される、という中継の目的です。 PITを使って100ms間隔で割り込みを発生させており、スコープで確認しています。 リビジョンC、F、Fの3枚の基板では正常に動作しており、データが無線で繰り返し送信されているのを確認しています。しかし、3つのリビジョンF1ボードでは、送信ルーチンがタイムスロット1が回ってくるのを待ってハングアップしてしまいます。割り込みが発生しません！ 例えば、Rev FとRev F1の間で何が変わったことで、このような挙動が引き起こされたのか、ご存知の方はいらっしゃいますか？ これが私の初期化ルーチンです。 SIM->SCGC6 |= SIM_SCGC6_PIT_MASK; // PIT のクロックをオンにするPIT- > MCR = 0x1; // PIT タイマーを有効にする PIT>チャネル[0]。LDVAL = 5999999; リロード値を100mSに設定 PIT->チャネル[0].TCTRL = 0x03; // Turn PIT timer 0 on, interrupts on そして主な内容は： NVIC_EnableIRQ(PIT0_IRQn); // PIタイマー、ch 0割り込みを有効にする そしてISR： void PIT0_IRQHandler ( void ) { /* 割り込みフラグをクリアする */ ピット・>チャネル[0]。TFLG = PIT_TFLG_TIF_MASK; NVIC_ClearPendingIRQ( PIT0_IRQn ); // 保留中のPIタイマー、 ch 0割り込みをクリアします //scope_trigger(); time_lot +=1; if (time_slot > 10) time_slot = 0; __DSB(); ARM の訂正 838869を追加し、Cortex-M4に影響します } どんな助けでもありがたいです！ 乾杯 ナイジェル Kinetis KシリーズMCU Re: FRDM-K64F PIT on different Rev boards ああ！ありがとうございます。はい、そのマスクは3つのチップすべてに付いています。これまでとても役に立ったあなたのAIエンジンがそれを出さなかったのは驚きです!何か代替策はありますか？遅延か、それとも失敗か？はい、 PIT->MCR = 0x1; は別の行にあるべきで、 は切り取りと貼り付けの際に抜け落ちてしまったのでしょう。 Re: FRDM-K64F PIT on different Rev boards こんにちは、 @ve3id さん。 投稿ありがとうございます！ e7914があなたのMCUに適用されているか確認してください:Kinetis_K_1N83J.pdf FRDM-K64F REV F1でテストしましたが動作しました。SDK 2.11.0とMCUXpresso IDE 25.06を使っていました。 また、共有したコードの中で「PIT->MCR = 0x1;」がSCGC6のイネーブルメントにコメントとして含まれているのに気づきましたが、投稿中のタイプミスかどうか確認したいだけです Re: FRDM-K64F PIT on different Rev boards 遅延時間を100秒に変更しても、PITアクションは発生しませんでした。 Re: FRDM-K64F PIT on different Rev boards イニットコードをこのように変えましたが、同じ問題が続いています: 遅延(10); 揮発性uint32_t PIT_MCR_read = PIT->MCR;1N83Jマスクセットの問題を克服するために 2026-09-22 NWJ PIT->MCR = 0x1;PITタイマーを有効にする ピット>チャネル[0]。LDVAL = 5999999;リロード値を100mSに設定 PIT->CHANNEL[0]。TCTRL = 0x03;PITタイマー0をオンにし、割り込みをオンにします Re: FRDM-K64F PIT on different Rev boards こんにちは、 @ve3id さん。 正誤表に記載されている回避策は、PIT_MCRレジスタに書き込む前に、そのレジスタを読み取ることです。 私はPITのSDK例をベースにして、FRDM REV F1で何をしているかをテストしています。以下のように修正しました carlos_o_0-1790096350978.png 問題なく動作します。

RT1064 在线升级计划 下图是我们产品的硬件扩展示意图： 1. PC 和主板通过 TCP 连接。 2.主板通过四条SPI总线与四个子板连接，各子板的功能相同。 3.主板上的UART4可以通过串口切换芯片切换到4个子板的UART1。 foreverwlh2025_0-1789970732170.png 由于项目需要， PC需要通过TCP升级四块RT1064子板的固件程序。基于硬件扩展情况，能否提供最简单的子板固件升级方案（考虑到上位机开发、主板开发和子板开发的工作量）？ i.MX RT106x Re: RT1064 Online Upgrade Plan 亲爱的@foreverwlh2025 ， 谢谢你的提问。 推荐方法 PC通过TCP协议与主板通信。主板充当 TCP 服务器，并实现 UART 透明桥接。主板上的 UART4 通过串行切换芯片路由到所选子板的 UART1 接口。子板运行 RT1064 ROM 引导加载程序，因此子板端不需要额外的引导加载程序或固件开发。 单个子板的逐步升级流程： 对子板 N 施加 RESET 信号；设置 BOOT_MODE[1:0] = 01（串行下载器模式） 将串口切换芯片切换为连接 UART4 和子板 N 的 UART1。 释放 RESET 按钮——子板 N 进入 RT1064 ROM 引导加载程序并等待 UART 命令。 启用 TCP↔UART4 字节转发 切换 RESET 开关并将 BOOT_MODE 恢复为正常模式——子板 N 将使用新固件启动。 将串行选择器切换到下一个子板并重复上述步骤。 硬件先决条件 请在实施前确认以下硬件条件已具备： 主板对每个子板的BOOT_MODE[1:0]引脚具有独立的 GPIO 控制。 主板对每个子板的RESET引脚具有独立的 GPIO 控制。 该串行切换芯片可通过主板GPIO控制，并支持在所有4个子板之间进行切换。 如有任何疑问或想进一步讨论实施细节，请随时联系我们。 Re: RT1064 Online Upgrade Plan 亲爱的@foreverwlh2025 ， 以下是针对您的固件升级场景推荐的解决方案概要。 1. 电脑工具 在 PC 端，我们提供了blhost——一个开源的命令行客户端，它实现了 NXP 的 MCU 引导加载程序私有帧协议（BSD/MIT 许可证）。设备端协议由MCU片上ROM引导加载程序实现。它们共同实现了固件下载和设备配置。 该工具支持 USB 和 UART1，不支持 TCP。 开源仓库： https://github.com/nxp-mcuxpresso/spsdk blhost 和 ROM 引导加载程序使用专有的帧数据包协议进行通信，请参阅： MCU 引导加载程序 v2.5.0 参考手册 (MCUBOOTRM) 对于固件映像的生成和打包，请使用 NXP 的SPSDK（安全配置 SDK）中包含的nxpimage工具。 2. 推荐方案：通过主板实现 TCP 透明转发 对于你的场景（PC→主板→子板），最省力的方法是让主板充当透明的 TCP 到 UART 桥接器，只需对 blhost 进行少量修改，将串行数据封装在 TCP 中即可： 建筑学： PC (modified blhost) ↓ TCP packet (include original UART byte stream) Main Board (TCP Server) ↓ Unpack and forward to sub-board via UART Sub-board (ROM Bootloader) 关键修改点： 修改 blhost 传输层：在 blhost 源代码中添加一个新的 TCP 传输模块。现有的UART字节流（帧数据包）在发送路径上直接封装成TCP数据包，在接收路径上解封装。 主板实现了一个 TCP 服务器：从 PC 接收 TCP 数据，通过 UART1 将有效载荷逐字节地转发到子板；子板的响应以同样透明的方式通过 TCP 转发回 PC。 子板无需任何更改：子板 MCU 只需处于 ISP 模式，ROM 引导加载程序正在运行，等待标准 UART 命令即可。 Re: RT1064 Online Upgrade Plan 4.启用TCP↔UART4字节转发 -----请问，数据传输的这一步骤是否需要额外开发一台上位计算机？例如，PC应该以什么格式传输图像数据？它应该如何解析子板返回的响应数据？以及它应该如何与子板交互？

jailhouse DTS for 9x9 imx.93 こんにちは。9x9 imx.93版の「Jailhouse」のDTSファイルは提供していますか？11x11用のものしか見つかりません。 よろしくお願いします。 デビッド Re: jailhouse DTS for 9x9 imx.93 こんにちは、 このデバイスツリーは、次回のBSPリリースに含まれる予定です。 // SPDX-License-Identifier: (GPL-2.0+ OR MIT) /* * Copyright 2023 NXP */ /dts-v1/; #include / { model = "NXP i.MX93 9x9 QSB"; compatible = "fsl,imx93-9x9-qsb", "fsl,imx93"; interrupt-parent = <&gic>; #address-cells = <2>; #size-cells = <2>; aliases { mmc0 = &usdhc1; serial1 = &lpuart2; }; cpus { #address-cells = <1>; #size-cells = <0>; A55_0: cpu@0 { device_type = "cpu"; compatible = "arm,cortex-a55"; reg = <0x0>; enable-method = "psci"; #cooling-cells = <2>; }; }; psci { compatible = "arm,psci-1.0"; method = "smc"; }; gic: interrupt-controller@48000000 { compatible = "arm,gic-v3"; reg = <0 0x48000000 0 0x10000>, <0 0x48040000 0 0xc0000>; #interrupt-cells = <3>; interrupt-controller; interrupts = ; interrupt-parent = <&gic>; }; timer { compatible = "arm,armv8-timer"; interrupts = , , , ; clock-frequency = <24000000>; }; clk_dummy: clock-dummy { compatible = "fixed-clock"; #clock-cells = <0>; clock-frequency = <0>; clock-output-names = "clk_dummy"; }; clk_400m: clock-400m { compatible = "fixed-clock"; #clock-cells = <0>; clock-frequency = <200000000>; clock-output-names = "200m"; }; osc_24m: clock-osc-24m { compatible = "fixed-clock"; #clock-cells = <0>; clock-frequency = <24000000>; clock-output-names = "osc_24m"; }; pci@fd700000 { compatible = "pci-host-ecam-generic"; device_type = "pci"; bus-range = <0 0>; #address-cells = <3>; #size-cells = <2>; #interrupt-cells = <1>; interrupt-map-mask = <0 0 0 7>; interrupt-map = <0 0 0 1 &gic GIC_SPI 227 IRQ_TYPE_EDGE_RISING>, <0 0 0 2 &gic GIC_SPI 228 IRQ_TYPE_EDGE_RISING>, <0 0 0 3 &gic GIC_SPI 229 IRQ_TYPE_EDGE_RISING>, <0 0 0 4 &gic GIC_SPI 230 IRQ_TYPE_EDGE_RISING>; reg = <0x0 0xfd700000 0x0 0x100000>; ranges = <0x02000000 0x00 0x10000000 0x0 0x10000000 0x00 0x10000>; }; soc@0 { compatible = "simple-bus"; #address-cells = <1>; #size-cells = <1>; ranges = <0x0 0x0 0x0 0x80000000>, <0x28000000 0x0 0x28000000 0x10000000>; aips1: bus@44000000 { compatible = "fsl,aips-bus", "simple-bus"; reg = <0x44000000 0x800000>; #address-cells = <1>; #size-cells = <1>; ranges; lpuart2: serial@44390000 { compatible = "fsl,imx93-lpuart", "fsl,imx8ulp-lpuart", "fsl,imx7ulp-lpuart"; reg = <0x44390000 0x1000>; interrupts = ; status = "disabled"; }; }; aips3: bus@42800000 { compatible = "fsl,aips-bus", "simple-bus"; reg = <0x42800000 0x800000>; #address-cells = <1>; #size-cells = <1>; ranges; usdhc1: mmc@42850000 { compatible = "fsl,imx93-usdhc", "fsl,imx8mm-usdhc"; reg = <0x42850000 0x10000>; interrupts = ; fsl,tuning-start-tap = <20>; fsl,tuning-step= <2>; status = "disabled"; }; }; }; }; &lpuart2 { clocks = <&osc_24m>; clock-names = "ipg"; status = "okay"; }; &usdhc1 { clocks = <&clk_dummy>, <&clk_dummy>, <&clk_400m>; clock-names = "ipg", "ahb", "per"; bus-width = <8>; non-removable; status = "okay"; }; よろしくお願いいたします。 Re: jailhouse DTS for 9x9 imx.93 9x9 用の qsb jailhouse に対応するルートセル設定ファイルもお持ちですか？ ありがとう

インラインECC検証方法 こんにちは、 私はiMX8M Plusの外部DDRメモリ向けにインラインECCの実装に取り組んでいます。 ECCは動作しているようです(U-Bootの修正完了、LinuxにEDACドライバーが表示され、/sys/devices/system/edac/mc/mc0/仮想ファイルも存在します)。 保護機能をテストし、検証する方法を探しています。 私の理解では、データ自体にエラーを注入することは不可能であり、代わりにECCパリティビットを破損させる必要があるということです。 AN 13566 セクション 3.2.9同社は「この機能に関する詳細情報は、ご要望に応じて提供いたします」と述べている。 この情報はどのように依頼すればよいのでしょうか?この件に関して特定のNXPの連絡先やチャネルはありますか? よろしくお願いします、 Re: Inline ECC validation method こんにちは、 私は外部DDRを搭載したi.MX 8M PlusにインラインECCを実装しています。ECCは正常に動作しているようです:U-Bootの設定済み、LinuxのEDACドライバが有効、/sys/devices/system/edac/mc/mc0/が存在します。 次に、意図的に訂正可能なエラーと訂正不可能なエラーを生成することで、ECC保護機能を検証したいと思います。 AN13566、セクション3.2.9、インラインECCエラーは、ECC_REGION_PARITY_LOCKを用いてECC領域を解除し、ECCパリティビットを上書きすることで注入できると述べています。また、この機能に関する詳細情報はリクエストに応じて提供されるとも記載されている。 Re: Inline ECC validation method こんにちは、 もちろん提供は可能ですが、この件にはサポートチケットを作成する必要があります https://support.nxp.com/s/?language=en_US リクエストの本文に私の名前を記載していただければ、チケットの追跡や資料の提供ができます。 よろしくお願いいたします。 アルド。

FRDM-K64F PIT 在不同版本的板上 您好， 我正在尝试使用六块配备 nrf23l01 收发器的 FRDM-K64F 板进行无线电联网。 我将一秒钟分成十个时隙，其目的是让时隙 1 中的传输在时隙 2 中重复，时隙 2 中的传输在时隙 3 中重复，依此类推进行转发。 所以我使用 PIT 以 100 毫秒的周期生成中断，我已经用示波器检查过了。 在三块电路板（C、F 和 F 版本）上，此功能运行正常，我看到空中数据重复出现。然而，使用这三块 rev F1 电路板时，我的发射程序会卡住，等待时间段 1 到来。我没有收到中断！ 有人知道版本 F 和版本 F1 之间发生了什么变化会导致这种现象吗？ 这是我的初始化程序： SIM->SCGC6 |= SIM_SCGC6_PIT_MASK; // 开启 PIT 时钟 PIT - > MCR = 0x1; // 启用 PIT 定时器 PIT -> CHANNEL [0]. LDVAL = 5999999; // 设置重载值为 100 毫秒 PIT -> CHANNEL [0]. TCTRL = 0x03; // 开启 PIT 定时器 0，中断开启 主要内容： NVIC_EnableIRQ(PIT0_IRQn); // 启用 PI 定时器，通道 0 中断 以及 ISR： void PIT0_IRQHandler ( void ) { /* 清除中断标志 */ PIT-> CHANNEL [0]. TFLG = PIT_TFLG_TIF_MASK; NVIC_ClearPendingIRQ( PIT0_IRQn ); // 清除待处理的 PI 定时器，通道0 中断 //scope_trigger(); time_slot += 1; 如果（时间段 > 10）时间段 = 0； __DSB(); // 添加以应对 ARM勘误表838869，影响 Cortex-M4 } 非常感谢您的帮助！ 干杯 奈杰尔 Kinetis K系列MCU Re: FRDM-K64F PIT on different Rev boards 啊哈！谢谢。是的，我的三个芯片上都装了那个面罩。我很惊讶，你们的AI引擎（到目前为止，我觉得它非常有用）竟然没有提出这个问题！是否有建议的解决方法？延迟或失败？是的， PIT->MCR = 0x1; 应该单独一行， 肯定是在剪切粘贴过程中丢失了。 Re: FRDM-K64F PIT on different Rev boards 嗨@ve3id 感谢您的帖子！ 请检查勘误表 e7914 是否适用于您的 MCU： Kinetis_K_1N83J.pdf 我在 FRDM-K64F REV F1 上测试过，可以正常工作，我使用了 SDK 2.11.0 和 MCUXpresso IDE 25.06。 另外，我注意到您分享的代码中，在启用 SCGC6 的代码里，有一行“PIT->MCR = 0x1”作为注释，我想确认一下这是否是帖子中的笔误。 Re: FRDM-K64F PIT on different Rev boards 嗨@ve3id 勘误表中提到的解决方法是在写入 PIT_MCR 寄存器之前先读取该寄存器。 我以SDK中的PIT示例为基础，在FRDM板REV F1上测试您正在进行的操作，并进行了如下修改： carlos_o_0-1790096350978.pngcarlos_o_0-1790096350978.pngcarlos_o_0-1790096350978.png 运行正常，没有任何问题。 Re: FRDM-K64F PIT on different Rev boards 我已将初始化代码更改为以下内容，但问题仍然存在： 延迟(10)； volatile uint32_t PIT_MCR_read = PIT->MCR; // 为了解决 1N83J 掩码集勘误表中的问题（2026-09-22 NWJ） PIT->MCR = 0x1; // 启用 PIT 定时器 PIT->CHANNEL[0].LDVAL = 5999999; // 设置重载值为 100 毫秒 PIT->CHANNEL[0].TCTRL = 0x03; // 开启 PIT 定时器 0，中断开启 Re: FRDM-K64F PIT on different Rev boards 我甚至把延迟时间改成了 100 微秒，但 PIT 仍然没有反应。

RT1064 Online Upgrade Plan The following figure is the hardware expansion diagram of our product： 1.The PC and mainboard are connected via TCP 2.The mainboard is connected to four subboards through four SPI buses, and the functions of the subboards are the same 3.The uart4 of the mainboard can be switched to UART1 of 4 sub boards through a serial port swtich chip foreverwlh2025_0-1789970732170.png Due to project requirements, the PC needs to upgrade the firmware program of four sub boards RT1064 through TCP. Based on hardware expansion, can you help provide the simplest solution for upgrading the sub board firmware (considering the workload of upper computer development, mainboard development, and sub board development) i.MXRT 106x Re: RT1064 Online Upgrade Plan Dear @foreverwlh2025 , Thank you for your questions. Recommended Approach The PC communicates with the mainboard over TCP. The mainboard acts as a TCP server and implements a UART transparent bridge. UART4 on the mainboard is routed through a serial switch chip to the UART1 interface of the selected sub-board. The sub-board runs the RT1064 ROM Bootloader, so no additional bootloader or firmware development is required on the sub-board side. Step-by-step upgrade flow for a single sub-board : Assert RESET on sub-board N; set BOOT_MODE[1:0] = 01 (Serial Downloader mode) Switch the serial switch chip to connect UART4 to sub-board N's UART1 Release RESET — sub-board N enters the RT1064 ROM Bootloader and waits for UART commands Enable TCP↔UART4 byte forwarding Toggle RESET and restore BOOT_MODE to normal — sub-board N boots with the new firmware Switch the serial selector to the next sub-board and repeat Hardware Prerequisites Please confirm the following hardware conditions are in place before implementation: Mainboard has independent GPIO control over each sub-board's BOOT_MODE[1:0] pins Mainboard has independent GPIO control over each sub-board's RESET pin The serial switch chip is controllable by mainboard GPIO and supports switching among all 4 sub-boards Please feel free to reach out if you have any questions or would like to discuss implementation details further. Re: RT1064 Online Upgrade Plan 4.Enable TCP↔UART4 byte forwarding -----Excuse me, do we need to develop an additional upper computer for this step of data transmission? For example, what format should the PC transmit image data in, how should it parse the response data returned by the sub board, and how should it interact Re: RT1064 Online Upgrade Plan Dear @foreverwlh2025 , Please find below a summary of our recommended solution for your firmware upgrade scenario. 1. PC Tool  On the PC side, we provides blhost — an open-source command-line client that implements NXP's MCU Bootloader private framing protocol (BSD/MIT license). The device-side protocol is implemented by the MCU on-chip ROM Bootloader. Together, they enable firmware download and device configuration.  The tool supports USB and UART1, doesn't support TCP. Open-source repository: https://github.com/nxp-mcuxpresso/spsdk blhost and the ROM Bootloader communicate using a proprietary framing packet protocol, please refer to: MCU Bootloader v2.5.0 Reference Manual (MCUBOOTRM) For firmware image generation and packaging, please use the nxpimage tool included in NXP's SPSDK (Secure Provisioning SDK). 2. Recommended Solution: TCP Transparent Forwarding via Mainboard For your scenario (PC→ Mainboard → Sub-board), the minimum-effort approach is to have the mainboard act as a transparent TCP-to-UART bridge, with a small modification to blhost to wrap serial data in TCP: Architecture: PC (modified blhost) ↓ TCP packet (include original UART byte stream) Main Board (TCP Server) ↓ Unpack and forward to sub-board via UART Sub-board (ROM Bootloader) Key modification points: Modify blhost transport layer: Add a new TCP transport module in the blhost source code. The existing UART byte stream (Framing Packets) is wrapped into TCP packets as-is on the send path, and unwrapped on the receive path.  Main board implements a TCP Server: Receives TCP data from the PC, forwards the payload byte-for-byte to the sub-board via UART1; sub-board responses are forwarded back to the PC via TCP in the same transparent manner. Sub-board requires no changes: The sub-board MCU simply needs to be in ISP mode with the ROM Bootloader running, waiting for standard UART commands.

FRDM-K64F PIT on different Rev boards Hi, I am experimenting with radio networking using six FRDM-K64F boards equipped with nrf23l01 transceivers. I am splitting a second into ten time slots, the idea being that a transmission in slot 1 gets repeated in time slot 2, time slot 2 into time slot 3 etc for relaying. So I am using PIT to generate interrupts at 100 ms periods, which I have checked on a scope. On three boards, rev C,F, and F this is working fine and I am seeing the data on air being repeated.  However with the three rev F1 boards my transmit routine gets hung waiting for time slot 1 to come around. I am not getting the interrupt! Does anybody know what changed between, say rev F and Rev F1 that would cause this behaviour? Here is my init routine: SIM->SCGC6 |= SIM_SCGC6_PIT_MASK; // Turn on clock to to the PIT PIT->MCR = 0x1; // Enable PIT timers PIT->CHANNEL[0].LDVAL = 5999999; // Set reload value to 100mS PIT->CHANNEL[0].TCTRL = 0x03; // Turn PIT timer 0 on, interrupts on and in main: NVIC_EnableIRQ(PIT0_IRQn); // Enable PI timer, ch 0 interrupt and the ISR: void PIT0_IRQHandler(void) { /* Clear interrupt flag */ PIT->CHANNEL[0].TFLG = PIT_TFLG_TIF_MASK; NVIC_ClearPendingIRQ(PIT0_IRQn); // Clear pending PI timer, ch 0 interrupt //scope_trigger(); time_slot +=1; if (time_slot >10) time_slot=0; __DSB(); // Add for ARM errata 838869, affects Cortex-M4 } any help appreciated! cheers nigel Kinetis K Series MCUs Re: FRDM-K64F PIT on different Rev boards Aha! Thanks for that. Yes I have that mask on all three chips. I'm surprised that your AI engine that I have found very useful so far did not bring that up! Is there a suggested work-around? A delay or nops maybe? And yes, the PIT->MCR = 0x1; should be on a separate line, the   must have have slipped out during cut and paste. Re: FRDM-K64F PIT on different Rev boards Hi @ve3id  Thank you for your post!  Please review if the errata e7914 applies for your MCU: Kinetis_K_1N83J.pdf I've tested it in FRDM-K64F REV F1 and it works, I used SDK 2.11.0 and MCUXpresso IDE 25.06. Also, I notice that in the code you share the "PIT->MCR = 0x1;" is included as a comment in the enablement of the SCGC6, I only want to confirm if that is a typo in the post Re: FRDM-K64F PIT on different Rev boards Hi @ve3id  The workaround mentioned with the errata is to put a read of the PIT_MCR register before writing it. I use the PIT example of the SDK as base to test what you are doing in a FRDM board REV F1, I modified as following  carlos_o_0-1790096350978.pngcarlos_o_0-1790096350978.pngcarlos_o_0-1790096350978.png It works without issues.  Re: FRDM-K64F PIT on different Rev boards I even changed the delay to 100 us and still no PIT action Re: FRDM-K64F PIT on different Rev boards I've changed my init code to this and still have the same problem: delay(10); volatile uint32_t PIT_MCR_read = PIT->MCR; // to overcome problem in 1N83J mask set errata 2026-09-22 NWJ PIT->MCR = 0x1; // Enable PIT timers PIT->CHANNEL[0].LDVAL = 5999999; // Set reload value to 100mS PIT->CHANNEL[0].TCTRL = 0x03; // Turn PIT timer 0 on, interrupts on

デフォルトのWinbond FlashをEverspin Memory Custom Flash Driverに置き換えるための助けが必要です こんにちは、NXPコミュニティの皆さん、 私は i.MX RT1170 EVKB / MIMXRT1176 ボード を扱っており 、デフォルトのWinbond外部メモリを Everspin EM032LXQADG13IS2T メモリデバイス に交換する方法についてアドバイスが必要です 。 現在のハードウェア この基板は元々 Winbond W25Q512というデバイスを使用していましたが、私はそれを以下のデバイスに交換しました。 Everspin EM032LXQADG13IS2T 主な問題は、Everspinメモリが SFDPをサポートしていないのに対し、デフォルトのWinbondメモリはSFDPに対応していることです。 現在の状況 すでに i.MX RT1170 FlexSPIインターフェースを使ってEverspinメモリと通信できています。 アプリケーションがRAMから動作している間は、メモリは機能的に動作しています。特に： Everspin製メモリとのFlexSPI通信は正常に動作しています。 メモリの読み書き操作も可能です。 アプリケーションイメージ(XIPイメージ)はメモリ書き込みコードを使ってEverspinメモリにロード・プログラムできます。 Everspinメモリに保存されたイメージは、正常にアクセス・実行可能です。 しかし、 通常のRT1170フラッシュプログラミングでは、アプリケーションを直接Everspinメモリにフラッシュ・プログラムすることはできません i.MX。 EverspinメモリはSFDPをサポートしていないため、Winbondメモリに使われているデフォルトのFlexSPIフラッシュドライバー/設定ではEverspinデバイスを自動的に識別・設定できないのではないかと疑っています。 SFDP以外のメモリデバイスをサポートするためのNXPの推奨アプローチについて理解を深めたい。 アドバイスをいただければ幸いです。 1. RT1170のEverspin EM032LXQADG13IS2T用のカスタムフラッシュドライバー i.MX どうやって作成できますか? 2. i.MX RT1170 FlexSPIコントローラで非SFDPのSPI/QSPIメモリをサポートする既存の例はありますか? ブートROM|ブート|フラッシュ 開発ボード Re: Help Required Replacing Default Winbond Flash with Everspin Memory Custom Flash Driver @jyothzz様、 ご質問ありがとうございます。 はい、MIMXRT1170_SFDP_QSPI.cfxフラッシュドライバーはRT1170 EVKおよびMCUXpresso SDKで使われているデフォルトのフラッシュドライバーです: ShellyZhang_0-1790052100477.png 現在、i.MX RT1170 FlexSPIコントローラで非SFDP SPI/QSPIメモリをサポートする例は存在しません。顧客の修正なしで直接サポートされているフラッシュドライバーは以下の通りです: ShellyZhang_1-1790052161488.png カスタムフラッシュドライバーを作成するには、以下の情報を参照してください: 1. https://community.nxp.com/t5/i-MX-RT-Crossover-MCUs-Knowledge/How-to-create-a-new-Flash-driver-of-the-MCUXPresso-IDE/ta-p/1274718 2. https://community.nxp.com/t5/i-MX-RT-Crossover-MCUs-Knowledge/RT1170-flexSPI1-secondary-QSPI-flash-debug-flashdriver/tac-p/1938828 カスタムフラッシュドライバーの開発中にご質問があれば、どうぞお気軽にお問い合わせください。 よろしくお願いいたします。 シェリー Re: Help Required Replacing Default Winbond Flash with Everspin Memory Custom Flash Driver こんにちは、 @ShellyZhang さん。 ご回答ありがとうございました。大変参考になりました。 新しいメモリでSFDPをサポートしていないフラッシュドライバーの問題は解決しました。 同じi.MXRT117x_SFDP_QSPIドライバを使っていました。SFDPの部分はi.MXRT1050_QSPIの非SFDPドライバーを指しています。 その後、新しいドライバーファイル(.cfx)を生成し、問題なく動作しました。 改めて、ご指導いただきありがとうございました。 よろしくお願いいたします。 ジョーティッシュ

Regarding the establishment of the tick clock and the selection of the base clock Hello: I want to configure a bare-metal tick clock (S32K358 device). My BaseNXP settings are shown in Figure 1. Is this configuration sufficient to connect to the tick clock?2. Which clock in the device tree does the set 48MHz correspond to? sunshine88_0-1789971547489.png sunshine88_1-1789971658567.png After setting it up, can it be called using OsIf_Init(NULL_PTR); OsIfDelay(x);? Thank you so much! Re: 关于滴答时钟建立及基时钟的选择 Hello @sunshine88 , OsIfSystemTimerClockFreq corresponds to CORE_CLK, which is 160MHz in my case: PavelL_0-1789999751219.png PavelL_1-1789999832315.png Best regards, Pavel

在线ECC验证方法 你好， 我正在研究 iMX8M Plus 在外部 DDR 内存上的内联 ECC 实现。 ECC 似乎正在工作（U-Boot 修改已完成，EDAC 驱动程序出现在 Linux 中，/sys/devices/system/edac/mc/mc0/ 虚拟文件存在）。 我正在寻找测试和验证该保护措施的方法。 我的理解是，错误注入不可能直接发生在数据本身，而是必须破坏 ECC 奇偶校验位。 AN 13566 第 3.2.9 节声明：“有关此功能的更多信息可应要求提供。” 我该如何获取这些信息？NXP方面是否有专门的联系人/渠道负责此事？ 先感谢您， Re: Inline ECC validation method 你好， 我正在使用外置DDR在i.MX 8M Plus上实现内联ECC。ECC 似乎工作正常：U-Boot 已配置，Linux EDAC 驱动程序已激活，并且 /sys/devices/system/edac/mc/mc0/ 存在。 现在我想通过故意生成可纠正和不可纠正的错误来验证 ECC 保护。 AN13566，第 3.2.9 节，声明指出，可以通过使用 ECC_REGION_PARITY_LOCK 解锁 ECC 区域并覆盖 ECC 奇偶校验位来注入内联 ECC 错误。文中还提到，如有需要，可提供有关此功能的更多信息。 Re: Inline ECC validation method 你好， 当然可以，但需要您创建一个支持工单。 https://support.nxp.com/s/?language=en_US 您可以在请求正文中提及我，以便我跟踪工单并提供所需材料。 此致敬礼/Saludos， 阿尔多。

MTTF-FIT信頼性データのリクエスト 拝啓 現在、御社製の部品を使用した製品のMTBF値を計算しています。 つきましては、下記の部品について、MTTF値および/またはFIT値が入手可能な場合は、ご提供いただけますようお願い申し上げます。この情報により、当社の製品のMTBFを正確に計算するのに役立ちます。 部品番号:NTS0104BQ,115 説明:電圧レベル変換器 双方向 1回路4チャネル 50Mbps 14-DHVQFN(2.5x3) 信頼性データを提供するために、運用条件やアプリケーションに関する追加情報が必要な場合はお知らせください。 再開まで今しばらくお待ちください。 クラウド・ラボ オンラインデバッグ オンラインラボ 仮想テスト

IW612 WLAN 5GHz transmission Hi,  We are planning to use IW612 SoC for WLAN in one of our IoT product, target market is US and Canada. IW612 supports dual band 2.4Ghz and 5GHz. Is there a way or configuration to turn 5GHz WIFI Operation OFF, as ISED Canada doesn't allow UNII-1 (5150-5250Mhz) WIFI transmission in outdoor environment without a license and limits operation to Indoor ONLY. Our product operates in Outdoor and we would like a way to Disable 5GHz entirely and operate on 2.4Ghz only. RSS-247 — Digital Transmission Systems, Frequency Hopping Systems and Licence-Exempt Local Area Network Devices in 902-928 MHz, 2400-2483.5 MHz, 5150-5350 MHz, and 5470-5895 MHz bands Can you confirm and share settings for same? Regards, Arun RF Re: IW612 WLAN 5GHz transmission Hello @pantarun_92  iw612 support loading power table, you could custom power table or use sample table for Canada region. It will disable not allowed channels and support DFS channel. Best Regards Shaun

imx95 和 vfio_pci 直通 您好， 我们希望在 IMX95 SoC 上使用具有 PCI 直通功能的虚拟机。这似乎完全不可能，因为 SMMU 不是缓存一致的，而 vfio_pci 驱动程序需要缓存一致性。参见： https://community.nxp.com/t5/i-MX-Processors/i-MX95-19x19-EVK-SMMU-coherent-table-walks-IDR0-COHACC-and-vfio/mp/2410515 和 https://github.com/NXP/dpdk/blob/25.11-qoriq/nxp/README_imx95_enetc_vf_vfio#L32 禁用 IOMMU 不是一个可行的方案。另外，我怀疑这样做是否会有帮助，因为内核参数是这样写的： MODULE_PARM_DESC(enable_unsafe_noiommu_mode, "启用不安全、无 IOMMU 模式。此模式不提供设备隔离、DMA 转换、主机内核保护，不能用于将设备分配给虚拟机，需要 RAWIO 权限，并且会污染内核。如果你不知道这是做什么用的，请远离。（默认值：false）"); 能否确认一下，是否真的无法将 IMX95 SoC 与（安全的）PCI 直通一起使用？如果不是，那我到底漏掉了什么？ 此致， -迈克尔 Re: imx95 and vfio_pci passthrough 您好， 感谢您的快速回复。但我不太确定我是否完全理解了。为了确保万无一失，我们不想使用 DPDK，而是使用通用的 qemu/kvm 虚拟机，并在其中传递 PCI 设备。这与 uio-pci-generic 框架有何关系？ 谢谢， -迈克尔 Re: imx95 and vfio_pci passthrough 您好， 感谢您对恩智浦半导体产品的关注， 在这种情况下，你需要采纳我同事的回复，也就是 DPDK 团队的回复。唯一的替代方案就是回复中提到的那个： “如果客户希望将 SMMU 用于其他用例，但可以接受绕过 DPDK（不想在 bootargs 中使用 iommu.passthrough=1 或在 dts 中禁用 SMMU 节点）。 然后可以尝试绑定 uio-pci-generic 框架并禁用 VSI-PSI 消息传递（export ENETC4_VSI_MSG_DISABLE=1）。但是禁用 VSI-PSI 消息意味着用户将无法使用某些 ENETC 功能，例如混杂模式、VLAN MAC 过滤和链路信息。 此致

How to get the full datasheet for BMA8420 ? not Product Brief   Subject: Inquiry regarding BMA8420 for Hydrogen Fuel Cell Stack EIS Measurement   Dear Technical Support Team, I am currently developing an Electrochemical Impedance Spectroscopy (EIS) measurement system for hydrogen fuel cells.   To utilize the BMA8420, I would like to review its technical specifications, but I have been unable to locate the datasheet online.   I would highly appreciate your guidance on the following questions: Can the BMA8420 be used to measure the EIS of a hydrogen fuel cell stack? How can I obtain the BMA8420 full datasheet(not Product Brief ) ? Contact point in Korea ? Thank you for your support, and I look forward to hearing from you.   Best regards, Young, Kim       BMA8420   <-- link image.png #BMA8420