MIMXRT1176 ADP – SEGGER J-Link のデバッグの問題 こんにちは、皆さん 現在、 MIMXRT1176 / i.MX RT1170プラットフォーム を使っています 。最初 は MIMXRT1170-EVKB を使って 開発していましたが、現在 は 並列RGBパネルのインターフェース用 に MIMXRT1176-ADP に切り替えました。 ADPボード上でSEGGER J-Linkデバッグを 行う際に問題が発生しています 。 環境: ボード: MIMXRT1176-ADP ボード改訂： 700-51950 REV A1 回路図改訂版： SCH-51950 REV B1 MCUXpresso IDE: v25.6.136 MCUXpresso SDK: v25.09.00 SEGGER J-Link：最新バージョン EVKB では 、 J-LinkとLinkServerの両方が問題なく動作しました 。しかし、ADPでは次の問題が発生しました。 ファームウェアの書き込みに成功しました。 デバッガーはmain()の最初の行に到達しました。 私が 一度 ステップオーバーする と、次の場所で停止します。 デバッグ情報がない、またはプログラムコード外のアドレス「0xdeadbeee」でブレークします。 他の場所にあるブレークポイントは正常に機能し、正しくヒットします。 しかし、 ブレークポイントからの 再開/継続では、 再び 0xDEADBEEE が発生します 。 MIMXRT1176-ADPのMCUXpresso IDEでJ-Linkが完全にサポートされている か 、また特定の J-Linkスクリプト、リセット/デバッグ設定、またはADP固有の初期化 が必要かどうか 、誰か確認していただけます か? これは メモリ構成、外部フラッシュ/SDRAM、あるいは ADPの 起動コード に関連しているのでしょうか? ADP用のJ-Link設定に関するガイダンスや動作確認済みの設定情報があれば、大変ありがたいです。 よろしくお願いします！ Re: MIMXRT1176 ADP – SEGGER J-Link debugging issue こんにちは、 @HasanIqbalKhan さん。 ご質問ありがとうございます！ 私の知る限り、MCUXpresso IDEでRT1170-ADPを使ってJLinkを使う場合、サポートされるのは「attach」のみで、直接デバッグはサポートされていません。これはおそらくJLinkフラッシュローダーのサポート問題でしょう。IARでは、この問題は解決済みです。ご迷惑をおかけして申し訳ございません。 よろしくお願いします、 ギャビン Re: MIMXRT1176 ADP – SEGGER J-Link debugging issue USB（J33）経由でデバッグを行うことは可能ですか？ Re: MIMXRT1176 ADP – SEGGER J-Link debugging issue もう一つ試したのは、外部のMCU-Linkを接続し、MCUXpresso IDEのLinkServer経由でデバッグを試みたことです。 実行はmain関数に到達し、そこからステップ実行できますが、実行を再開しようとすると「アドレス「0x0」でブレークしました。デバッグ情報がありません。またはプログラムコード外です。」というエラーが表示され、また、実行を再開しようとすると「アドレス「0x2230c8」でブレークしました。デバッグ情報がありません。またはプログラムコード外です。」というエラーが表示される場合もあります。 参考までに、私は「MIMXRT1176_dashboard_bt_ble_multiprofile」プロジェクトを実行しようとしています。ボード上のSW1は01に設定され、ボード上のSW5は000000000000に設定されています。 EVKBボードも同じ動作なのでMCU-Linkでテストしてみました。 また、Jlinkは使えないと思います。彼らのウェブサイトにはADPボードが使っているオクタルフラッシュのサポートがないと明記されているからです。 ありがとう。 Re: MIMXRT1176 ADP – SEGGER J-Link debugging issue こんにちは、 @HasanIqbalKhan さん。 1. J33はUSB-OTG1で、デバッグには使用できません。 2. JLinkがオクタルフラッシュをサポートしていないわけではありません。ただデフォルトではEVK/EVKBのフラッシュのみを認識しているだけです。IARに関しては、対応するダウンロードアルゴリズムが提供されているため、このような対応が可能となっています。このテーマに興味があれば、RT-UFLプロジェクトを参照してください。 3. 現在のデバッガ/IDEサポートに関する情報は、AN14387: を参照してください https://docs.nxp.com/bundle/AN14378/page/topics/download_images_to_ADP_board.html よろしくお願いします、 ギャビン

S32K3 浮点配置 各位团队成员，大家好！ 在我的项目中，我尝试使用浮点数据进行算术运算，但计算结果并未按预期进行。 #define 宏 -31.374 当我尝试使用 UTILS PRINTF 函数在宏中打印值时，我得到的是 -32.374。类似地，其他值的值也递增 1。 正因如此，我的计算结果才没有按预期进行。 我需要为此修改什么配置文件吗？ 我目前的目标设定 nirmal_masilamani_0-1790009448678.pngnirmal_masilamani_0-1790009448678.png Re: S32K3 Floating point cfg 你好@nirmal_masilamani 请问您能否解释一下“UTILS PRINTF”是什么意思？ 你是如何进行计算的？结果是否存储在浮点变量中？如果是，那么在调试器中查看变量时，该变量是否已经包含错误的值，还是只有在打印该变量时才会出现问题？ BR，VaneB Re: S32K3 Floating point cfg 你好@VaneB ， 感谢您的支持，是的，问题出在 PRINTF 函数上，调试时我能够读取到正确的数据。

IW612 WLAN 5GHz 传输 你好， 我们计划在我们的物联网产品中使用 IW612 SoC 来实现 WLAN，目标市场是美国和加拿大。IW612 支持双频 2.4GHz 和 5GHz。是否有办法或配置来关闭 5GHz WIFI 操作？因为加拿大 ISED 不允许在没有许可证的情况下在室外环境中进行 UNII-1 (5150-5250Mhz) WIFI 传输，并且限制操作仅限室内。 我们的产品在户外使用，我们希望能够完全禁用 5GHz 频段，只在 2.4GHz 频段下运行。 RSS-247 — 902-928 MHz、2400-2483.5 MHz 频段的数字传输系统、跳频系统和免许可局域网设备MHz、5150-5350 MHz 和 5470-5895 MHz 频段 能否确认并分享一下相关设置？ 此致， Arun 射频 Re: IW612 WLAN 5GHz transmission 你好@pantarun_92 iw612 支持加载功率表，您可以自定义功率表或使用加拿大地区的示例表。它将禁用不允许的通道，并支持DFS通道。 顺祝商祺！ 肖恩

imx95 and vfio_pci passthrough Hi, we want to use a virtual machine with PCI passthrough on the IMX95 SoC. It seems that this isn't possible at all because the SMMU is not cache coherent and the vfio_pci driver requires that. See also: https://community.nxp.com/t5/i-MX-Processors/i-MX95-19x19-EVK-SMMU-coherent-table-walks-IDR0-COHACC-and-vfio/m-p/2410515 and https://github.com/NXP/dpdk/blob/25.11-qoriq/nxp/README_imx95_enetc_vf_vfio#L32 Disabling the IOMMU is not an option. Also I doubt that it will help as the kernel parameter reads: MODULE_PARM_DESC(enable_unsafe_noiommu_mode, "Enable UNSAFE, no-IOMMU mode. This mode provides no device isolation, no DMA translation, no host kernel protection, cannot be used for device assignment to virtual machines, requires RAWIO permissions, and will taint the kernel. If you do not know what this is for, step away. (default: false)"); Could you confirm, that is actually impossible to use the IMX95 SoC with (safe) PCI passthrough? If not, what am I missing here? Best regards, -michael Re: imx95 and vfio_pci passthrough Hi, thanks for the quick answer. But I'm not sure I'm getting it completely. Just to be sure, we don't want to use DPDK, but a generic qemu/kvm virtual machine where we pass through a PCI device. How does this relate to the uio-pci-generic framework? Thanks, -michael Re: imx95 and vfio_pci passthrough Hi, Thank you for your interest in NXP Semiconductor products, In this case, you need to stick with my colleagues response, which is from DPDK team. The only alternative is the one said in the response: "If the customer wants to use SMMU for other use cases, but acceptable to bypass for the DPDK (does not want to use iommu.passthrough=1 in bootargs or disable SMMU node in dts). Then can try to bind the uio-pci-generic framework and disable VSI-PSI messaging (export ENETC4_VSI_MSG_DISABLE=1). But disabling VSI-PSI messages means user won’t be able to use some ENETC features like promisc, VLAN MAC filtering, link information." Regards

请求提供 MTTF-FIT 可靠性数据 尊敬的先生/女士， 我目前正在计算我们产品的平均故障间隔时间 (MTBF) 值，该产品使用了贵公司生产的元器件。 因此，如果可以的话，请您提供下列元器件的 MTTF 和/或 FIT 值。这些信息将有助于我们准确计算产品的平均故障间隔时间（MTBF）。 零件编号：NTS0104BQ,115 描述：双向电压等级转换器，1电路，4通道，50Mbps，14-DHVQFN（2.5x3） 如果需要有关运行条件或应用方面的任何其他信息来提供可靠性数据，请与我们联系。 感谢您的支持。 云实验室 在线调试 在线实验室 虚拟测试

关于滴答时钟建立及基时钟的选择 你好： 我现在想设置一个裸机滴答时钟（S32K358设备），我在BaseNXP 中设置如下图，1.这样设置是否是链接到滴答时钟上 ？2.设置的48MHZ对应设备树上哪一个时钟？ sunshine88_0-1789971547489.png sunshine88_1-1789971658567.png 设置完成后可以以 OsIf_Init(NULL_PTR);  OsIfDelay(x);来调用？ ··························································································································································万分感谢！ Re: 关于滴答时钟建立及基时钟的选择 你好@sunshine88 ， OsIfSystemTimerClockFreq 对应于 CORE_CLK，在我的情况下为 160MHz： PavelL_0-1789999751219.png PavelL_1-1789999832315.png 顺祝商祺！ 帕维尔

ROM引导加载程序写入内存命令CRC16计算 我目前正在尝试使用另一个微控制器和 KL17 内置的 UART ROM 引导加载程序对 KL17 微控制器进行编程。我已经完成了 ping 和擦除操作，至少在纸面上是这样，但是我在向 KL17 写入数据时遇到了困难。数据手册（第 43 页）中的示例指出，对于这些字节（帧数据包，不包括 CRC16 字节 + 内存写入命令数据包）： 0x5A, 0xA4, 0x0C, 0x00, 0x04, 0x00 , 0x00, 0x02, 0x00, 0x04, 0x00, 0x20, 0x64, 0x00, 0x00, 0x00 CRC16 字节为 0x06 0x5A。但是，第 27 页提供的 CRC16 算法对我输出的是 0x2b 0x56。我也尝试过网上各种 CRC16 计算器，以及许多不同的 CRC16 计算方法，但它们都没有给出 0x06 0x5A 的结果。 Noay_0-1790003799652.png 我的假设是，要么是我漏掉了计算中必须包含的字节（我不知道是哪些，因为后面的数据包都有自己的 CRC16 字节），要么是有人把数据表搞砸了（这也不太可能，因为这个例子和 KL17 子系列参考手册中的例子一模一样）。 Re: Rom Bootloader WriteMemory Command CRC16 calculation 你好@Noay ， 感谢你的帖子。我认为参考手册中的“0x06 0x5A”值不正确，很可能是文档错误。根据您提供的信息，您的 CRC 计算结果“0x2B 0x56”看起来是正确的。 您仍然可以使用 blhost 工具来调试引导加载程序命令。参数“-d”将提供主机和目标之间的所有通信过程。 我已在我的 KL27 板上尝试了这个功能，请参见下面的屏幕截图。 我们没有 KL17 EVB 板，您能否在您的 KL17 设备上尝试相同的方法，看看结果如何？ 对于文档错误，我深表歉意。我会将此情况反馈给内部团队，并建议相应地更新文档。 BR 塞莱斯特

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