Multi Source Translation Content

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

Multi Source Translation Content

ディスカッション

ソート順:
MPC5746C 的寄存器保护 这些是我为 MPC5746C 实现寄存器保护下锁定机制的模块。 0xFFFB0140, /* CMU------------*/ 0xFFFB0040, /* FXOSC----------*/ 0xFFFB0180, /* MC_CGM --------*/ 0xFFFB8000, /* MC_ME ---------*/ 0xFFFA8000, /* MC_RGM --------*/ 0xFFF50000, /* MEMU_0 -------*/ 0xFFFB0080, /* PLLDIG --------*/ 0xFFFA0400, /* PMCDIG --------*/ 0xFFFC0000, /* SIUL2 ---------*/ 0xFFFB0100, /* SXOSC ---------*/ 0xFFF9C000 /* LPU_CTL -------*/ 样本 1:(0xFFFB0000,偏移 - 0x4,32 位保护) 寄存器:与 ME_MCTL(模式控制寄存器,32 位保护,偏移 0x4,见表 77-5)匹配。 基地址:0xFFFB0000。 保护大小:32 位(所有四个字节均受保护)。 计算 正常地址:基数 + 偏移量 = 0xFFFB0000 + 0x4 = 0xFFFB0004 镜像地址(区域 3):基数 + 0x2000 + 偏移 = 0xFFFB0000 + 0x2000 + 0x4 = 0xFFFB2004 软锁定位地址(区域 4): 区域 4 中的偏移量:offset/4 = 0x4 / 4 = 0x1。 地址: base + 0x3800 + offset/4 = 0xFFFB0000 + 0x3800 + 0x1 = 0xFFFB3801。 对于 32 位寄存器,所有四个 SLB(SLB0—SLB3)控制四个字节(例如,0x4 到 0x7)。 软锁定 选项 1:写入镜像地址: 向 0xFFFB2004 写入 32 位值(例如,0x80000000 可启动模式转换;有关有效值,请参阅 MC_ME 章节)。 这将更新 0xFFFB0004 的 ME_MCTL,并在 0xFFFB3801 的 SLBRn 寄存器中设置 SLB0-SLB3。 示例*(volatile uint32_t *)0xFFFB2004 = 0x80000000; 选项 2:直接写入 SLB: 写入 0xFFFB3801,设置 SLB0-SLB3。 写入 0xFF(WE0—WE3=1,SLB0—SLB3=1)以锁定所有四个字节。 示例*(volatile uint8_t *)0xFFFB3801 = 0xFF; 解锁 写入 0xF0 至 0xFFFB3801(WE0-WE3=1,SLB0-SLB3=0)以清除 SLB0-SLB3,解锁寄存器。 示例*(volatile uint8_t *)0xFFFB3801 = 0xF0; 硬锁定 将 0x00000001 写入 0xFFB3FFC 以设置 GCR.HLB,锁定 SLB 直到 RESET。 示例*(volatile uint32_t *)0xFFFB3FFC = 0x00000001; 下面是一个寄存器设置示例,它的所有 4 个地址设置都是启用的,可以是 R/W。 下面是一个寄存器设置示例,其中基址 + 偏移& 镜像地址已启用,可以设置为 R/W,其他地址不能设置。 这带来了一个严重的问题,因为 SLB 位确认了软锁定,而 GCR 位的设置则是为了实现硬锁定。 对于所有 MC_CGM 带帽寄存器,我都发现了同样的问题。 这些不同行为的原因是什么?有些地址可以修改和变更,有些则被保留。 Re: Register Protection for MPC5746C 你好 如果我硬锁任何一个模块,所有其他模块都会自动被硬锁定,这在电源模式下会出现问题。因为我不希望 FXOSC/SXOSC 和 CMU 在这里被硬锁定。 寄存器保护采用 P 桥。 PBRIDGE 上有 MC_CGM 模块: 然后将外设映射到 MC_CGM 下。看来您需要使用 SLB 而不是 HLB 来解决这个问题。 因为 HLB 会锁定整个 MC_CGM。 顺祝商祺! Peter Re: Register Protection for MPC5746C 嗨,彼得 、 感谢您的帮助。我现在可以为所有模块配置软锁和监测 SLB 了。 我还有一个关于硬锁 GCR 位的问题。根据您的解释,所有 MCCGM 上限模块(即 CMU、FXOSC、SXOSC、PLDIG 和 MCCGM)应具有一个共同的基地址,即 0xFFFB0000。 现在根据第 77.1.1 节寄存器保护配置,N OTE讨论了电源模式下的操作。 正如我所说,在相同的基本地址下,如果我硬锁任何一个模块,所有其他模块都会自动被硬锁定,这在低电源模式下会出现问题。因为我不希望 FXOSC/SXOSC 和 CMU 在这里被硬锁定。 有没有办法解决这个问题? 感谢并致意 Re: Register Protection for MPC5746C 你好 以下是 SLB 的结果 CMU_LFREFR 32 - 地址基数和偏移量 CGM 模块的基数为 0xFFFB_0000 CMU 偏移为 0x140 CGM LFREFR 从模块基数偏移 0x14C 我通过写入镜像为 CMU_LFREFR 设置了 SLB 顺祝商祺! Peter Re: Register Protection for MPC5746C 嗨,这也不起作用。 CMU_LFREFR 32 偏移 0xCh 受保护的大小-16(字节 2 和 3) 0xFFFB0000,/* CMU----------*/ 基地址 -0xFFFB000C 镜像地址 -0xFFFB200C SLB - 0xFFFB3803 GCR - 0xFFFB3FFC Re: Register Protection for MPC5746C 你好 查看简单测试:MC_CMU - CSR 基地址 - 0xFFFB014C - 这是偏移地址。不是基地。 MC_CMU 模块的基数为 0xFFFB 0140。 镜像地址 -0xFFFB214C 即基座 + 偏移 + 镜像 SLB -0xFFFB3943 以参考手册中的整个 CGM 的地址为基准: 所以计算结果是 0xFFFB0000 + 3800 + SLB 的位置 GCR - 0xFFFB413C 同上 0xFFFB0000+3FF0 顺祝商祺! Peter Re: Register Protection for MPC5746C 嗨,彼得,这里有一些 SLB 和 GCR 失效的示例。 请检查这些地址并确认它们是否显示不同的行为。如果不是,那么这些模块会有什么问题? 1.MC_CMU - 0xFFFB0140 - { MODULE_CMU, 0xC,REG_SIZE_16}, CMU_LFREFR 基地址 - 0xFFFB014C 镜像地址 -0xFFFB214C SLB -0xFFFB3943 GCR - 0xFFFB413C 2.MC_CMU - 0xFFFB0140 { MODULE_CMU, 0x18,REG_SIZE_32}, CMU_MDR 基本地址 - 0xFFFB0158 镜像地址 - 0xFFFB2158 SLB - 0xFFFB3946 GCR - 0xFFFB413C 3.PLLDIG 0xFFFB0080 - PLLDIG_PLLCR { MODULE_PLLDIG, 0x20, REG_SIZE_16}, PLLDIG_PLLCR 基本地址 - 0xFFFB00A0 镜像地址 - 0xFFFB20A0 SLB - 0xFFFB0F5D GCR - 0xFFFB407C 4.PLLDIG 0xFFFB0080 - { MODULE_PLLDIG, 0x28,REG_SIZE_32}. { MODULE_PLLDIG, 0x28,REG_SIZE_32}, PLLDIG_PLLDV 基本地址 - 0xFFFB00A8 镜像地址 - 0xFFFB20A8 SLB - 0xFFFB388A GCR - 0xFFFB407C 5.PMCDIG 0xFFFA0400 - { MODULE_PMCDIG, 0x0,REG_SIZE_32}. { MODULE_PMCDIG, 0x0,REG_SIZE_32}、 基本地址 - 0xFFFA0400 镜像地址 - 0xFFFA2400 SLB - 0xFFFA3C00 GCR - 0xFFFA43FC 6.PMCDIG 0xFFFA0400 - { MODULE_PMCDIG, 0x10,REG_SIZE_32}.{ MODULE_PMCDIG, 0x10,REG_SIZE_32}、 基本地址 - 0xFFFA0410 镜像地址 - 0xFFFA2410 SLB - 0xFFFA3C04 GCR - 0xFFFA43FC Re: Register Protection for MPC5746C 你好 我已经检查了 PREG_PROT,它的行为就像参考手册中描述的那样: 在 ME_CGM 寄存器 SC_DC0 上: 基数:0xFFFB0000 + 偏移 7E8 镜像0xFFFB07E8 = 基数 (0xFFFB0000) + 偏移 (7E8) + 镜像 (0x2000) 在示例中,我通过软锁锁定了 SC_DC0 形式的 ME_CGM 模块。 具体情况如下: 区域 4:为 1.5 KB,包含软锁位,区域 1 中每字节一位。与一个模块寄存器字相关的四个软锁位排列在存储器映射中的字节边界处。软锁定位寄存器可使用位掩码直接写入。 因此,必须将软锁定位的面积除以 8,才能看到相应的 SLB 设置。 基础(模块的)+ 3800 +(区域 1 的每字节一位) 对于硬锁位,整个模块只有一个。 区域 5 的大小为 512 字节,用于保存保护模式的配置位。每个模块都有一个配置硬锁位,可以防止对软锁位进行任何进一步的修改,并且只能在设置后通过系统 RESET 来清除。其他位如果被设置,将允许用户访问受保护的模块。 基数(模块) 0xFFFB0000 + 偏移 3FFC 因为 GCR 位于 5 号区域的末端。 顺祝商祺! Peter Re: Register Protection for MPC5746C 你好 我会进行测试,并尽快给您答复。 顺祝商祺! Peter
記事全体を表示
RT1166/RT1170 MIPI-CSI 数据在 RGB888/RGB565 之间转换 HI 我们希望使用 RT1166/RT1170 处理 MIPI-CSI RGB565 16 位数据,并将 RGB56 数据接收到 RAM 中。 参考数据:AN13573 参考话题: https://community.nxp.com/t5/i-MX-RT-Crossover-MCUs/iMXRT1176-MIPI-CSI2-to-UVC-reducing-the-frame-bu...   方法 1: 传感器 RGB565(A) 输出 --> MIPI RGB565 --> RGB888 MIPI 控制器将把 RGB888 保存为 XRGB8888 PXP 可将 XRGB8888 转换为 RGB565(B)。 我认为,如果我们不在格式转换之间修改 RGB565(B),它应该与 RGB565(A)相同。 这些转换不会造成 RGB565(A) 和 RGB565(B) 之间的任何差异。 是否正确? Methold2: RT1166/RT1170 能否绕过 MIPI-CSI RGB565 数据直接将其转换为 RAM,而无需进行 RGB888 格式转换? 此致 Ken Re: RT1166/RT1170 MIPI-CSI data convert between RGB888/RGB565 @kensu 方法 1:传感器 RGB565(A) 输出 --> MIPI RGB565 --> RGB888 MIPI 控制器将 RGB888 保存为 XRGB8888 PXP 可以将 XRGB8888 转换为 RGB565(B)。我认为,如果我们不在格式转换之间修改 RGB565(B),它应该与 RGB565(A)相同。这些转换不会造成 RGB565(A) 和 RGB565(B) 之间的任何差异。是否正确? 答:问得好,我想应该是正确的。我没有硬件环境,但我建议你可以参考这个示例来设置和打印它们。 https://github.com/nxp-mcuxpresso/mcux-sdk-examples/tree/main/evkbmimxrt1170/driver_examples/csi/mipi_rgb/cm7 Methold2:RT1166/RT1170 是否可以绕过 MIPI-CSI RGB565 数据直接将其转换为 RAM,而无需进行 RGB888 格式转换? 答:不能。请参阅 勘误表 (116x)、E rra (117x)以查找以下信息:“由于视频多路复用器控制器(VIDEO_MUX)出现问题,不支持 原始数据 和 MIPI_CSI2 模块的 YUV422(10 位)格式”,这意味着:如果输入数据格式为 RGB 565,MIPI_CSI 会在内部将其转换为 RGB888 并发送到 CSI。 换句话说,CSI 输入数据总线的宽度为 24 位。CSI 将帧保存为 32 位格式 X RGB 8 88 8 。”
記事全体を表示
LIN Wakeup and Timeout Hello  I am using S32k310 with LIN_STACK_2.0.5_D2410_DesignStudio_updatesite and RTD_R21-11_5.0.0_D2410_DesignStudio_updatesite. 1) I am facing issue when master node send Wake up command, Slave node detect Linnode state as wake up signal but I need to call Lin_43_LPUART_FLEXIO_Wakeup function when LPUART_LIN_IP_RX_ACTIVE_EDGE_DETECT. Could you please describe how LIN Wakeup functionality handle in Lin Stack? 2) I want to know more details about LIN Timeout. How LIN Bus will wake up after LIN goes in Sleep mode after timeout? Re: LIN Wakeup and Timeout Hello @pchavapr4, I just tested it on the S32K1xx series which I happen to have on bench, my test project can be found here: https://community.nxp.com/t5/S32K-Knowledge-Base/S32K144-LIN-Go-to-Sleep/ta-p/2136890 It is the same on the S32K310. You can check these functions: Lpuart_Lin_Ip_IRQHandlerWhenInitializedExceptBreakIRQ() Lpuart_Lin_Ip_ProcessWakeupDetect() Lpuart_Lin_Ip_CheckWakeupSignal(). BR, Daniel
記事全体を表示
IARダウンロードKEAが実行されない <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> こんにちは: コードをダウンロードしてリセットした後、プログラムが実行されません。RAMにダウンロードする必要があります。プロジェクトをFlashにダウンロードするように設定するにはどうすればよいですか? Kinetis EシリーズMCU Kinetis EAシリーズMCU Re: IAR 下载KEA不运行 <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> ありがとう、ロビン。 私たちは、Flashloader のダウンロード プロセスに問題がないことを確認しており、同時に、リンク ファイルに指定されている中断方向の量にも問題がないことを確認しました。 Re: IAR 下载KEA不运行 <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> こんにちは、ロビン ジャックの問題は実は私の問題なのです。 具体的には、KEAZN64 チップに使用した開発環境は IAR 8.30.1 であり、プログラムは KEA64 のサンプル ファイルに基づいて開発されました。 エミュレータを接続し、プログラムをダウンロードしてデバッグすると、正常に実行できます。 .outファイル(ダウンロードファイル)を生成した後、エミュレータを取り外した後、プログラムが正常に動作しなくなりました。プログラムはRAMに書き込まれているようですが、フラッシュメモリには書き込まれていないようです。 設定オプション -> リンカー -> 設定 -> KEAZN64xxx2.icf オプションやその他の設定を構成する方法についてアドバイスをいただけますか? Re: IAR 下载KEA不运行 <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> こんにちは:ジャック どの例を使ったのか分かりません。 TRK-KEA128_IAR_LABTS1 サンプルを公式の TRK-KEA128: Kinetis KEA128 StarterTRAK for CAN Applications ページからダウンロードした場合、デフォルトで Flash にダウンロードされます。設定については、このサンプルを参照してください。   よろしくお願いします、 ロビン   ----------------------------------------------------------------------------------------------------------------------- 注: この投稿で質問が解決した場合は、「正解」ボタンをクリックしてください。ありがとう! -----------------------------------------------------------------------------------------------------------------------
記事全体を表示
LIN 唤醒和超时 您好 ,我正在使用 S32k310 与 LIN_STACK_2.0.5_D2410_DesignStudio_updatesite 和 RTD_R21-11_5.0.0_D2410_DesignStudio_updatesite。 1) 我遇到的问题是,当主节点发送唤醒命令时,从节点检测到Linnode状态为唤醒信号,但我需要在LPUART_LIN_IP_RX_ACTIVE_EDGE_DETECT 时调用Lin_43_LPUART_FLEXIO_Wakeup 函数。 2) 我想了解有关LIN超时的更多详情。超时后 LIN 进入睡眠模式后,LIN 总线将如何唤醒? Re: LIN Wakeup and Timeout 你好,@pchavapr4、 我刚刚在 S32K1xx 系列上进行了测试,我的测试项目可以在这里找到: https://community.nxp.com/t5/S32K-Knowledge-Base/S32K144-LIN-Go-to-Sleep/ta-p/2136890 S32K310 也是如此。 您可以检查这些功能: Lpuart_Lin_Ip_IRQHandlerWhenInitializedExceptBreakIRQ() Lpuart_Lin_Ip_ProcessWakeupDetect() Lpuart_Lin_Ip_CheckWakeupSignal(). BR,丹尼尔
記事全体を表示
新世代のSPSDK(v3.1)が利用可能になりました Secure Provisioning SDK (SPSDK) v3.1が利用可能になりました。詳細はこちらをご覧ください。 id:SPSDK [開始:2025年8月5日] [終了:2025年9月5日] 発表
記事全体を表示
IMX8MPLUS EVK I want to run IMX8MPLUS EVK using a LI-ion Battery (12V to 16.8V). Can you please suggest how should I connect my power source (battery) in this case? Where can I connect on board? Is there any modification required on board? How will we control on-off ? Re: IMX8MPLUS EVK Hi @Sadatan123 , I give you reply in the case you creat, so let tall there. Thanks Wish you have a nice day Best Regards Rita
記事全体を表示
IAR 下载KEA不运行 您好: 下载代码后复位后程序不运行,应该是下载到RAM中了,请问如何配置工程下载到Flash中。 Kinetis E Series MCUs Kinetis EA Series MCUs Re: IAR 下载KEA不运行 <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> 谢谢你,罗宾、 我已经帮宁工确认了Flashloader的下载算法没有问题,同时,确认Link文件指定的中断向量地址也没问题,附上截图,请您帮忙看一下,多谢。 Re: IAR 下载KEA不运行 hi Robin Jack的问题其实是我的问题 具体情况是 我使用的KEAZN64的片子 开发环境是 IAR 8.30.1 根据KEA64的例程文件 开发的程序 插着仿真器download and debug程序就可以正常运行 生成了.out文件 download file以后 拔掉仿真器 程序就无法正常运行 感觉像是程序烧写进入了ram 没有烧写进入flash 配置options - >linker -> config -> KEAZN64xxx2.icf 请教一下 该如何配置 options或者其他配置 Re: IAR 下载KEA不运行 您好: Jack 不清楚你用的哪个例程。 如果是官网TRK-KEA128: Kinetis KEA128 StarterTRAK for CAN Applications页面下载的TRK-KEA128_IAR_LABTS1例子,默认就是下载到Flash里的。你可以参考该例程设置。   Best Regards, Robin   ----------------------------------------------------------------------------------------------------------------------- Note: If this post answers your question, please click the Correct Answer button. Thank you! -----------------------------------------------------------------------------------------------------------------------
記事全体を表示
IMX8MPLUSEVK 我想使用锂离子电池(12V 至 16.8V)运行 IMX8MPLUS EVK。在这种情况下,请问我该如何连接电源(电池)?我可以在板上在哪里连接?飞机上需要修改吗?如何控制开关机? Re: IMX8MPLUS EVK 你好@Sadatan123、 我在你创造的情况下给你答复,所以让高个子在那里吧。谢谢 祝您有美好的一天 顺祝商祺! Rita
記事全体を表示
RT1166/RT1170 RGB888/RGB565 間の MIPI-CSI データ変換 ハイ RT1166/RT1170 を使用して MIPI-CSI RGB565 16 ビット データを処理し、RGB56 データを RAM に受信したいと考えています。 参照データ: AN13573 参照Thread: https://community.nxp.com/t5/i-MX-RT-Crossover-MCUs/iMXRT1176-MIPI-CSI2-to-UVC-reducing-the-frame-bu...   方法1: センサRGB565(A)出力 --> MIPI RGB565 --> RGB888 MIPIコントローラはRGB888をXRGB8888に保存します PXPはXRGB8888をRGB565(B)にCAN変換します。 形式変換の間に変更しない限り、RGB565(B) は RGB565(A) と同じになると思います。 これらの変換により、RGB565(A) と RGB565(B) の間に違いは生じません。 それは正しいですか? 方法2: RT1166/RT1170 は、RGB888 形式に変換せずに、MIPI-CSI RGB565 データを RAM に直接CANバイパスしますか? よろしくお願いします。 ケン Re: RT1166/RT1170 MIPI-CSI data convert between RGB888/RGB565 @けんす 方法 1: センサ RGB565(A) 出力 --> MIPI RGB565 --> RGB888 MIPI コントローラは RGB888 を XRGB8888 に保存します。PXP は XRGB8888 を RGB565(B) に変換できます。形式変換の間に変更しない限り、RGB565(B) は RGB565(A) と同じになると思います。これらの変換により、RGB565(A) と RGB565(B) の間に違いは生じません。それは正しいですか? A: いい質問ですね。正しいと思います。ハードウェア環境はありませんが、この例を参照してセットアップし、印刷することをお勧めします。https://github.com/nxp-mcuxpresso/mcux-sdk-examples/tree/main/evkbmimxrt1170/driver_examples/csi/mipi_rgb/cm7 方法 2: RT1166/RT1170 は、RGB888 形式に変換せずに、MIPI-CSI RGB565 データを RAM に直接バイパス CAN か? A: いいえ、CANません。以下の情報については、 Errata (116x)、 Erra (117x) を参照してください。「ビデオMuxコントローラ(VIDEO_MUX)の問題により、MIPI_CSI2ブロックへのrawデータおよびYUV422(10ビット)形式はサポートされていません。」これは、入力データ形式がRGB 565の場合、MIPI_CSIは内部でRGB 888に変換し、CSIに送信します。つまり、CSIの入力データバス幅は24ビットです。CSIはフレームを32ビット形式( RGB 8888 )で保存します。」
記事全体を表示
Register Protection for MPC5746C These are the Modules on which I am implementing Locking mechanism under Register Protection for MPC5746C.     0xFFFB0140, /* CMU------------*/     0xFFFB0040, /* FXOSC----------*/     0xFFFB0180, /* MC_CGM --------*/     0xFFFB8000, /* MC_ME ---------*/     0xFFFA8000, /* MC_RGM --------*/     0xFFF50000, /* MEMU_0 -------*/     0xFFFB0080, /* PLLDIG --------*/     0xFFFA0400, /* PMCDIG --------*/     0xFFFC0000, /* SIUL2 ---------*/     0xFFFB0100, /* SXOSC ---------*/     0xFFF9C000 /* LPU_CTL -------*/ Sample 1: (0xFFFB0000, offset - 0x4, 32-bit protection) Register: Matches ME_MCTL (mode control register, 32-bit protection, offset 0x4 per Table 77-5). Base Address: 0xFFFB0000. Protection Size: 32 bits (all four bytes are protected). Calculations Normal Address: base + offset = 0xFFFB0000 + 0x4 = 0xFFFB0004 Mirrored Address (Area 3): base + 0x2000 + offset = 0xFFFB0000 + 0x2000 + 0x4 = 0xFFFB2004 Soft Lock Bits Address (Area 4): Offset in Area 4: offset/4 = 0x4 / 4 = 0x1. Address: base + 0x3800 + offset/4 = 0xFFFB0000 + 0x3800 + 0x1 = 0xFFFB3801. For a 32-bit register, all four SLBs (SLB0–SLB3) control the four bytes (e.g., 0x4 to 0x7). Soft Locking Option 1: Write to Mirrored Address: Write a 32-bit value to 0xFFFB2004 (e.g., 0x80000000 to initiate a mode transition; refer to MC_ME chapter for valid values). This updates ME_MCTL at 0xFFFB0004 and sets SLB0–SLB3 in the SLBRn register at 0xFFFB3801. Example: *(volatile uint32_t *)0xFFFB2004 = 0x80000000; Option 2: Direct SLB Write: Write to 0xFFFB3801 to set SLB0–SLB3. Write 0xFF (WE0–WE3=1, SLB0–SLB3=1) to lock all four bytes. Example: *(volatile uint8_t *)0xFFFB3801 = 0xFF; Unlocking Write 0xF0 to 0xFFFB3801 (WE0–WE3=1, SLB0–SLB3=0) to clear SLB0–SLB3, unlocking the register. Example: *(volatile uint8_t *)0xFFFB3801 = 0xF0; Hard Locking Write 0x00000001 to 0xFFFB3FFC to set GCR.HLB, locking SLBs until reset. Example: *(volatile uint32_t *)0xFFFB3FFC = 0x00000001; Below in an example of register set whose all 4 address set are enable and can be R/W. Below in an example of register set whose Base + offset & Mirror addresses are enabled and can be R/W and other addresses can’t be set. This poses a serious issue as SLB bits confirms soft locking and GCR bits are set to implement hard lock. For All MC_CGM caped registers I can find the same problem. What could be the reason for these different behavior. Some addresses can be modified and changed other are reserved. Re: Register Protection for MPC5746C Hello, if I Hard lock any one module , all other modules are getting hard locked automatically, which raises issue in Low power mode. since I do not want FXOSC/SXOSC and CMU to be hard locked here. The register protection is applied Pbridge. And on the PBRIDGE is the MC_CGM module: Which have then mapped peripherals under MC_CGM. Looks like you will need to use SLB instead of HLB to solve this. As HLB will lock whole MC_CGM. Best regards, Peter Re: Register Protection for MPC5746C Hi Peter , Thank you for the help. I can configure Soft lock and monitor SLB for all modules now. I have another question regarding Hard Lock GCR bit. According to your explanation for all the MCCGM capped modules which are  CMU,FXOSC,SXOSC, PLLDIG and MCCGM shall have one common base address , that is 0xFFFB0000. now according to section 77.1.1 Register protection configuration, the NOTE talks about operations in Low power mode. As I said , having the same base address , if I Hard lock any one module , all other modules are getting hard locked automatically, which raises issue in Low power mode. since I do not want FXOSC/SXOSC and CMU to be hard locked here. is there any way around this problem. Thanks and regards Re: Register Protection for MPC5746C Hello, Here is the result of SLB for  CMU_LFREFR 32 -  addresses base and offset Base for CGM module is  0xFFFB_0000 CMU offset is 0x140 CGM LFREFR offset is 0x14C from module base I set SLB for CMU_LFREFR via write to mirror Best regards, Peter Re: Register Protection for MPC5746C Hi , This is also not working . CMU_LFREFR 32 Offset 0xCh Protected size - 16 (Bytes 2 and 3) 0xFFFB0000, /* CMU----------*/ Base address -0xFFFB000C Mirror address -0xFFFB200C SLB - 0xFFFB3803 GCR - 0xFFFB3FFC Re: Register Protection for MPC5746C Hello, Looking at simple test: MC_CMU - CSR Base Address - 0xFFFB014C - This is offset address. Not Base. Base for MC_CMU module is 0xFFFB 0140. Mirror Address -0xFFFB214C  Would be base +offset + mirror SLB -0xFFFB3943 Take as base address of whole CGM as present in ref manual: So calculations are: 0xFFFB0000 + 3800 + position of SLB GCR - 0xFFFB413C Same as above 0xFFFB0000+3FF0 Best regards, Peter Re: Register Protection for MPC5746C Hi Peter , here are some samples where SLB and GCR are not working.  can You please check this addresses and confirm if they show different behavior. if not then what could be the problem with these modules ? 1. MC_CMU -  0xFFFB0140 -  { MODULE_CMU, 0xC,REG_SIZE_16}, CMU_LFREFR Base Address - 0xFFFB014C Mirror Address -0xFFFB214C SLB -0xFFFB3943 GCR - 0xFFFB413C 2. MC_CMU -  0xFFFB0140   { MODULE_CMU, 0x18,REG_SIZE_32}, CMU_MDR Base Address - 0xFFFB0158 Mirror Address - 0xFFFB2158 SLB - 0xFFFB3946 GCR - 0xFFFB413C 3. PLLDIG 0xFFFB0080 - { MODULE_PLLDIG, 0x20, REG_SIZE_16}, PLLDIG_PLLCR Base Address - 0xFFFB00A0 Mirror Address - 0xFFFB20A0 SLB - 0xFFFB0F5D GCR - 0xFFFB407C 4. PLLDIG 0xFFFB0080 - { MODULE_PLLDIG, 0x28,REG_SIZE_32}, PLLDIG_PLLDV Base Address - 0xFFFB00A8 Mirror Address - 0xFFFB20A8 SLB - 0xFFFB388A GCR - 0xFFFB407C 5. PMCDIG 0xFFFA0400 - { MODULE_PMCDIG, 0x0,REG_SIZE_32}, Base Address - 0xFFFA0400 Mirror Address - 0xFFFA2400 SLB - 0xFFFA3C00 GCR - 0xFFFA43FC 6. PMCDIG 0xFFFA0400 -{ MODULE_PMCDIG, 0x10,REG_SIZE_32}, Base Address - 0xFFFA0410 Mirror Address - 0xFFFA2410 SLB - 0xFFFA3C04 GCR - 0xFFFA43FC Re: Register Protection for MPC5746C Hello, I have checked the PREG_PROT and it behave like described in reference manual: on ME_CGM register SC_DC0: Base :  0xFFFB0000 + Offset 7E8 Mirror: 0xFFFB07E8 = Base (0xFFFB0000) + Offset(7E8) + Mirror (0x2000) In the example I have locked the SC_DC0 form ME_CGM module by Soft lock. Here is the breakdown: Area 4:  is 1.5 KB and holds the Soft Lock Bits, one bit per byte in area 1. The four Soft Lock Bits associated with one module register  word are arranged at byte boundaries in the memory map. The Soft Lock Bit registers can be directly written using a bit mask. So you have to divide the area of Soft lock bits by 8 to see corresponding SLB settings. Base (of module) + 3800 + (one bit per byte of area 1) For Hard lock bit it is one for whole module. Area 5 is 512 bytes large and holds the configuration bits of the protection mode. There is one configuration hard lock bit per module that prevents all further modifications to the Soft Lock Bits and can only be cleared by a system reset once set. The other bits, if set, will allow user access to the protected module. Base (of module) 0xFFFB0000 + Offset 3FFC As GCR is at end of area 5. Best regards, Peter Re: Register Protection for MPC5746C Hello, I will test it and come back to you ASAP. Best regards, Peter
記事全体を表示
S32K344 CAN FD MCAL 你好,恩智浦。 EVB: S32K344 环境S32DS RTD 5.0.0 我正在使用 MCAL 构建 CAN FD 项目。 是否有任何示例项目可供我参考? 谢谢。 Re: S32K344 CAN FD MCAL 你好@IanHsueh 您可以参考 RTD 中的示例。它们与本培训演示中显示的相同:S32K3xx 通信模块:带有 rtd 和低级驱动程序的 flexcan。 这些项目配置为环回,因此需要启用正常/用户模式并初始化收发器输出引脚(CAN_H& CAN_L)。 还有一些社区帖子提供了一些实例: 示例 S32K344 FlexCAN_Ip TX/RX/EnhanceRXFIFO DMA 测试 S32DS3.5RTD400 - NXP 社区 已解决:S32K344 EVB 与 MCAL FLEXCAN TJA1153 - NXP Community 致以最诚挚的问候, Julián
記事全体を表示
New Generation of SPSDK (v3.1) is now available Secure Provisioning SDK (SPSDK) v3.1 is available.  For details, please visit here id:SPSDK [start:Aug 5 2025] [end:Sept 5 2025] announcement
記事全体を表示
LINウェイクアップとタイムアウト こんにちは 私は、LIN_STACK_2.0.5_D2410_DesignStudio_updatesite と RTD_R21-11_5.0.0_D2410_DesignStudio_updatesite を搭載した S32k310 を使用しています。 1) マスターノードがウェイクアップコマンドを送信し、スレーブノードがLinnodeの状態をウェイクアップ信号として検出した際に問題が発生しています。しかし、 LPUART_LIN_IP_RX_ACTIVE_EDGE_DETECTのときにLIN_43_LPUART_FLEXIO_Wakeup関数を呼び出す必要があります。LINウェイクアップ機能がLINスタックでどのように処理されるのかご説明いただけますか? 2) LIN タイムアウトについての詳細を知りたいです。LIN がタイムアウト後にスリープ モードになった後、LIN バスはどのようにして起動しますか? Re: LIN Wakeup and Timeout こんにちは@pchavapr4さん、 私はたまたまベンチに持っていた S32K1xx シリーズでこれをテストしました。テスト プロジェクトはここにあります: https://community.nxp.com/t5/S32K-Knowledge-Base/S32K144-LIN-Go-to-Sleep/ta-p/2136890 S32K310でも同様です。 以下の機能はCAN確認できます: Lpuart_Lin_Ip_IRQHandler 初期化時例外ブレークIRQ() Lpuart_Lin_Ip_ProcessWakeupDetect() Lpuart_Lin_Ip_CheckWakeupSignal()。 BR、ダニエル
記事全体を表示
RT1166/RT1170 MIPI-CSI data convert between RGB888/RGB565 Hi We want to use RT1166/RT1170 to process MIPI-CSI RGB565 16-bit data, we want to receive the RGB56 data to RAM. Reference data:  AN13573  Reference thread: https://community.nxp.com/t5/i-MX-RT-Crossover-MCUs/iMXRT1176-MIPI-CSI2-to-UVC-reducing-the-frame-bu...   Method1: Sensor RGB565(A) output --> MIPI RGB565 --> RGB888 MIPI controller will save RGB888 to XRGB8888 PXP can convert XRGB8888 to RGB565(B). I think RGB565(B) should be same as RGB565(A) if we don't modify it between format converts. These conversions will not cause any difference between RGB565(A) and RGB565(B). Is it correct? Methold2: Can RT1166/RT1170 bypass the MIPI-CSI RGB565 data to RAM directly without RGB888 format convert? Regards Ken Re: RT1166/RT1170 MIPI-CSI data convert between RGB888/RGB565 @kensu  Method1: Sensor RGB565(A) output --> MIPI RGB565 --> RGB888 MIPI controller will save RGB888 to XRGB8888 PXP can convert XRGB8888 to RGB565(B). I think RGB565(B) should be same as RGB565(A) if we don't modify it between format converts. These conversions will not cause any difference between RGB565(A) and RGB565(B). Is it correct? A: Good question, I assume it should be correct. I don't have the hardware enviroment, but I suggest that you can refer to this example to setup and print them out.  https://github.com/nxp-mcuxpresso/mcux-sdk-examples/tree/main/evkbmimxrt1170/driver_examples/csi/mipi_rgb/cm7  Methold2: Can RT1166/RT1170 bypass the MIPI-CSI RGB565 data to RAM directly without RGB888 format convert? A: No, it can't. Please see Errata(116x), Erra(117x) to find below info, 'Due to an issue in the Video Mux Controller (VIDEO_MUX), raw data and YUV422 (10 bit) formats to the MIPI_CSI2 block are not supported ', it means: if the input data format is  RGB565, the MIPI_CSI converts it to RGB888 internally and sends to CSI. In other words, the CSI input data bus width is 24-bit. The CSI saves the frame as 32-bit format XRGB8888.' 
記事全体を表示
MPC5746Cのレジスタ保護 これらは、MPC5746C のレジスタ保護の下でロック メカニズムを実装しているモジュールです。 0xFFFB0140, /* CMU------------*/ 0xFFFB0040, /* FXOSC----------*/ 0xFFFB0180, /* MC_CGM --------*/ 0xFFFB8000, /* MC_ME ---------*/ 0xFFFA8000, /* MC_RGM --------*/ 0xFFF50000, /* MEMU_0 -------*/ 0xFFFB0080, /* PLLDIG --------*/ 0xFFFA0400, /* PMCDIG --------*/ 0xFFFC0000, /* SIUL2 ---------*/ 0xFFFB0100, /* SXOSC ---------*/ 0xFFF9C000 /* LPU_CTL -------*/ サンプル1: (0xFFFB0000、オフセット - 0x4、32ビット保護) レジスタ: ME_MCTL (モード制御レジスタ、32 ビット保護、表 77-5 に従ってオフセット 0x4) と一致します。 ベースアドレス: 0xFFFB0000。 保護サイズ: 32 ビット (4 バイトすべてが保護されます)。 計算 通常のアドレス:ベース + オフセット = 0xFFFB0000 + 0x4 = 0xFFFB0004 ミラーアドレス(エリア3) :ベース + 0x2000 + オフセット = 0xFFFB0000 + 0x2000 + 0x4 = 0xFFFB2004 ソフトロックビットアドレス(エリア4) : エリア 4 のオフセット: offset/4 = 0x4 / 4 = 0x1。 アドレス: ベース + 0x3800 + オフセット/4 = 0xFFFB0000 + 0x3800 + 0x1 = 0xFFFB3801。 32 ビット レジスタの場合、4 つの SLB (SLB0 ~ SLB3) すべてが 4 つのバイト (たとえば、0x4 ~ 0x7) を制御します。 ソフトロック オプション 1: ミラー アドレスに書き込む: 0xFFFB2004 に 32 ビットの値を書き込みます (例: モード遷移を開始するには 0x80000000。有効な値については MC_ME の章を参照してください)。 これにより、0xFFFB0004 の ME_MCTL が更新され、0xFFFB3801 の SLBRn レジスタの SLB0 ~ SLB3 が設定されます。 例: *(volatile uint32_t *)0xFFFB2004 = 0x80000000; オプション2: 直接SLB書き込み: SLB0~SLB3を設定するには、0xFFFB3801に書き込みます。 4バイトすべてをロックするには、0xFF(WE0~WE3=1、SLB0~SLB3=1)を書き込みます。 例: *(volatile uint8_t *)0xFFFB3801 = 0xFF; ロック解除 0xF0 を 0xFFFB3801 (WE0~WE3=1、SLB0~SLB3=0) に書き込んで SLB0~SLB3 をクリアし、レジスタのロックを解除します。 例: *(volatile uint8_t *)0xFFFB3801 = 0xF0; ハードロック 0x00000001 を 0xFFFB3FFC に書き込んで GCR.HLB を設定し、リセットされるまで SLB をロックします。 例: *(volatile uint32_t *)0xFFFB3FFC = 0x00000001; 以下は、4 つのアドレス セットすべてが有効化され、CAN R/W なレジスタ セットの例です。 以下は、ベース + オフセットおよびミラー アドレスが有効になっていて R/W がCANで、他のアドレスは設定できないレジスタ セットの例です。 SLB ビットはソフト ロックを確認し、GCR ビットはハード ロックを実装するように設定されているため、これは深刻な問題を引き起こします。 すべての MC_CGM キャップ レジスタで同じ問題が見つかります。 これらの異なる動作の理由は何でしょうか。一部のアドレスは変更可能ですが、その他のアドレスは予約されています。 Re: Register Protection for MPC5746C こんにちは、 いずれかのモジュールをハードロックすると、他のすべてのモジュールも自動的にハードロックされ、低電力モードで問題が発生します。FXOSC/SXOSC と CMU をここでハードロックしたくないためです。 レジスタ保護はPbridgeに適用されます。 PBRIDGE には MC_CGM モジュールがあります。 これにより、ペリフェラルが MC_CGM の下にマップされます。これを解決するには、HLB ではなく SLB を使用する必要があるようです。 HLB は MC_CGM 全体をロックします。 よろしくお願いいたします。 ピーター Re: Register Protection for MPC5746C こんにちは、ピーターさん。 ご協力ありがとうございます。すべてのモジュールに対してソフト ロックと監視 SLB を設定できるようになりました。 ハード ロック GCR ビットに関してもう 1 つ質問があります。あなたの説明によれば、CMU、FXOSC、SXOSC、PLLDIG、MCCGM のすべての MCCGM キャップ モジュールには、1 つの共通ベース アドレス (0xFFFB0000) があるはずです。 77.1.1項によればレジスタ保護構成、注記では低電力モードでの動作について説明します。 前述したように、ベース アドレスが同じ場合、いずれかのモジュールをハード ロックすると、他のすべてのモジュールも自動的にハード ロックされ、低電力モードで問題が発生します。FXOSC/SXOSC と CMU をここでハードロックしたくないためです。 この問題を回避する方法はありますか。 ありがとうございます。よろしくお願いします。 Re: Register Protection for MPC5746C こんにちは、 SLBの結果は次のとおりです。 CMU_LFREFR 32 - アドレスのベースとオフセット CGMモジュールのベースは0xFFFB_0000です CMUオフセットは0x140です CGM LFREFRオフセットはモジュールベースから0x14Cです ミラーへの書き込みを介してCMU_LFREFRのSLBを設定しました よろしくお願いいたします。 ピーター Re: Register Protection for MPC5746C こんにちは。これも機能していません。 CMU_LFREFR 32 オフセット 0xCh 保護サイズ - 16 (バイト 2 と 3) 0xFFFB0000 , /* CMU----------*/ ベースアドレス -0xFFFB000C ミラーアドレス -0xFFFB200C SLB - 0xFFFB3803 GCR - 0xFFFB3FFC Re: Register Protection for MPC5746C こんにちは、 簡単なテストを見る: MC_CMU - CSR ベース アドレス - 0xFFFB014C - これはオフセット アドレスです。基地ではありません。 MC_CMU モジュールのベースは 0xFFFB 0140 です。 ミラーアドレス -0xFFFB214C ベース+オフセット+ミラー SLB -0xFFFB3943 参照マニュアルに記載されている CGM 全体のベース アドレスを取得します。 SO計算は次のようになります。 0xFFFB0000 + 3800 + SLBの位置 GCR - 0xFFFB413C 同上 0xFFFB0000+3FF0 よろしくお願いいたします。 ピーター Re: Register Protection for MPC5746C こんにちは、ピーター。SLB と GCR が動作していないサンプルがいくつかあります。これらのアドレスをチェックして、異なる動作が表示されるかどうかをCAN確認してください。そうでない場合、これらのモジュールに何が問題があるのでしょうか? 1. MC_CMU - 0xFFFB0140 - { MODULE_CMU, 0xC,REG_SIZE_16}, CMU_LFREFR ベースアドレス - 0xFFFB014C ミラーアドレス -0xFFFB214C SLB -0xFFFB3943 GCR - 0xFFFB413C 2. MC_CMU - 0xFFFB0140 { MODULE_CMU, 0x18,REG_SIZE_32}, CMU_MDR ベースアドレス - 0xFFFB0158 ミラーアドレス - 0xFFFB2158 SLB - 0xFFFB3946 GCR - 0xFFFB413C 3. PLLDIG 0xFFFB0080 - { MODULE_PLLDIG, 0x20, REG_SIZE_16}, PLLDIG_PLLCR ベースアドレス - 0xFFFB00A0 ミラーアドレス - 0xFFFB20A0 SLB - 0xFFFB0F5D GCR - 0xFFFB407C 4. PLLDIG 0xFFFB0080 - { MODULE_PLLDIG, 0x28,REG_SIZE_32}, PLLDIG_PLLDV ベースアドレス - 0xFFFB00A8 ミラーアドレス - 0xFFFB20A8 SLB - 0xFFFB388A GCR - 0xFFFB407C 5. PMCDIG 0xFFFA0400 - { MODULE_PMCDIG, 0x0,REG_SIZE_32}, ベースアドレス - 0xFFFA0400 ミラーアドレス - 0xFFFA2400 SLB - 0xFFFA3C00 GCR - 0xFFFA43FC 6. PMCDIG 0xFFFA0400 - { MODULE_PMCDIG, 0x10,REG_SIZE_32}, ベースアドレス - 0xFFFA0410 ミラーアドレス - 0xFFFA2410 SLB - 0xFFFA3C04 GCR - 0xFFFA43FC Re: Register Protection for MPC5746C こんにちは、 PREG_PROT をチェックしたところ、リファレンスマニュアルに記載されているとおりに動作します。 ME_CGMレジスタSC_DC0について: ベース: 0xFFFB0000 + オフセット 7E8 ミラー: 0xFFFB07E8 = ベース (0xFFFB0000) + オフセット (7E8) + ミラー (0x2000) この例では、SC_DC0 フォーム ME_CGM モジュールをソフト ロックでロックしています。 内訳は次のとおりです。 エリア 4: 1.5 KB で、エリア 1 のバイトごとに 1 ビットのソフト ロック ビットを保持します。1 つのモジュール レジスタ ワードに関連付けられた 4 つのソフト ロック ビットは、メモリ マップ内のバイト境界に配置されます。ソフト ロック ビット レジスタは、ビット マスクを使用して直接書き込むCAN。 SO、対応する SLB 設定を確認するには、ソフト ロック ビットの領域を 8 で割る必要があります。 ベース(モジュール)+ 3800 + (エリア1のバイトあたり1ビット) ハードロック ビットの場合は、モジュール全体で 1 つになります。 エリア 5 は 512 バイトの大きさで、保護モードの構成ビットを保持します。モジュールごとに 1 つの構成ハード ロック ビットがあり、これによりソフト ロック ビットへのそれ以上の変更がすべて防止され、一度設定されるとシステム リセットによってのみクリアCANます。他のビットが設定されている場合は、保護されたモジュールへのユーザー アクセスが許可されます。 ベース(モジュールの)0xFFFB0000 + オフセット 3FFC GCRはエリア5の端にあります。 よろしくお願いいたします。 ピーター Re: Register Protection for MPC5746C こんにちは、 テストしてできるだけ早くご連絡いたします。 よろしくお願いいたします。 ピーター
記事全体を表示
新一代 SPSDK(v3.1)现已发布 安全配置 SDK (SPSDK) v3.1 现已推出。详情请浏览此处 id:SPSDK [开始时间:2025年8月5日] [结束时间:2025年9月5日] 公告
記事全体を表示
S32K344 CAN FD MCAL こんにちは、NXP。 EVB: S32K344 環境: S32DS RTD 5.0.0 MCAL を使用して CAN FD プロジェクトをビルディングしています。 参照できるサンプル プロジェクトはありますか? ありがとうございます。 Re: S32K344 CAN FD MCAL こんにちは@IanHsueh RTD の例をCAN参照できます。これらは、このトレーニング プレゼンテーションで示されているものと同じです: S32K3XX 通信モジュール: RTD および低レベル ドライバを備えた FLEXCAN。 これらのプロジェクトはループバック用に構成されているSO、通常/ユーザー モードを有効にし、トランシーバ出力ピン (CAN_H および CAN_L) を初期化する必要があります。 例を示すコミュニティ投稿もいくつかあります。 S32K344 FlexCAN_Ip TX/RX/EnhanceRXFIFO DMAテストの例 S32DS3.5RTD400 - NXPコミュニティ 解決済み: S32K344 EVB と MCAL FLEXCAN TJA1153 - NXP コミュニティ よろしくお願いします、 ジュリアン
記事全体を表示
iMX6 SPI controller slave mode burst length When configured for slave mode, my testing indicates that it ignores the burst length and always transfers 32-bits to/from the FIFO. I notice the manual only mentions master mode when it talks about the burst length. Is this by design?  Anyone have it working for 1 byte per word? I set the burst length to 7 (8 - 1) so the control register was loaded with 0x0070e301 and the cfg register with 0. I load the FIFO with 1 byte per word. On a scope I see each byte sent followed by 3 zero bytes. I expect to see the bytes sent consecutively. Works great with 32-bits per word other than the known SS termination issue. i.MX6_All i.MX6UL 回复: iMX6 SPI controller slave mode burst length I ran into the same problem, the burst length doesn't work in salve mode, the default is 32bit. Re: iMX6 SPI controller slave mode burst length @vg53  Hello,   Yes, it is needed to set the burst length to 64*8-1=511, lower SS line, send all 512 bits, and then set SS line to high.     Note: SS is asserted / negated by SPI master. SPI slave can only analyze this signal. Regards, Yuri. Re: iMX6 SPI controller slave mode burst length Hi @Yuri . We want to use iMX8 SPI in slave mode. We need to transfer a 64 byte packet every 32 us. Do I understand correctly I can set the burst length to 64*8-1=511, lower SS line, send all 512 bits, and then set SS line to high? In the manual, they say the data transfer to FIFO upon the positive edge of SS, so I thought I could transfer only 32 bits in a burst in a slave mode. Thank you  Re: iMX6 SPI controller slave mode burst length Hi @Yuri , I see that the BURST_LENGTH parameter is bits 20-32 on CONTROL REGISTER for IMX6dl Thank you.  Re: iMX6 SPI controller slave mode burst length @Yavuz  Hello,    from the erratum: Slave mode with unspecified burst length cannot be supported due to this issue. The burst length should always be specified with the BURST_LENGTH parameter and the SS_CTL[x] should be set to zero.   There is no workaround except for not using the SS_CTL[x] = 1 option in the Slave mode. The accurate burst length should always be specified using the BURST_LENGTH parameter  Regards, Yuri. Re: iMX6 SPI controller slave mode burst length Hi, @Yuri  how to configure the burst length ?  Regards.  Re: iMX6 SPI controller slave mode burst length Hello,   For the slave mode the maximum length of the single SPI burst is defined by FIFO size or SS negation. But due to errata ERR009535, the slave must configure the burst length to match the total number of bits sent by the master in a single transfer (burst).  Regards, Yuri. Re: iMX6 SPI controller slave mode burst length Commenting on my own post. I notice the Linux driver in the BSP (master mode only) configures the burst length to be the number of bits per word, but the response I received from tech. support case #00163683 leads me to believe that the burst length should be set to the number of bits in the entire transfer (at least in slave mode). If that's true, then burst length has a different definitions in master and slave mode -or- the Linux BSP should not be configuring it as bits per word -or- I'm very confused.
記事全体を表示
iMX6 SPI 控制器从模式突发长度 <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> 我的测试表明,当配置为从属模式时,它会忽略突发长度,并始终向 FIFO 传输 32 位数据/从 FIFO 传输 32 位数据。我注意到,手册在谈到连拍长度时只提到了主模式。 这是故意的吗? 有人能用每个字 1 字节吗? 我将连发长度设置为 7(8-1),因此控制寄存器加载了 0x0070e301,cfg 寄存器加载了 0。我在 FIFO 中加载每个字 1 字节。在作用域上,我看到发送的每个字节后面都是 3 个零字节。我希望看到连续发送的字节。 除了已知的 SS 终止问题外,每个字 32 位的工作性能非常好。 i.MX6_All i.MX6UL 回复: iMX6 SPI controller slave mode burst length 我碰到了同样的问题,在salve模式时burst length不生效,默认就是32bit Re: iMX6 SPI controller slave mode burst length @vg53 你好、 是的,需要将突发长度设置为 64*8-1=511,降低 SS 线,发送全部 512 比特,然后将 SS 线设置为高电平。 注意:SS由SPI主站钳位/否定。SPI 从站只能分析该信号。 Yuri。 Re: iMX6 SPI controller slave mode burst length 嗨,@Yuri. 我们希望在从模式下使用 iMX8 SPI。我们需要每隔 32 秒传输一个 64 字节的数据包。我是否可以将突发长度设置为 64*8-1=511,降低 SS 线路,发送全部 512 位,然后将 SS 线路设置为高电平?手册中说,数据在 SS 的正沿时传输到 FIFO,因此我认为在从属模式下一次突发只能传输 32 位。 谢谢 Re: iMX6 SPI controller slave mode burst length 嗨,@Yuri、 我发现 BURST_LENGTH 参数位于 IMX6dl 控制寄存器上的第 20-32 位 谢谢。 Re: iMX6 SPI controller slave mode burst length @Yavuz 你好、 来自勘误:由于这个问题,无法支持具有未指定突发长度的 从模式。突发长度 应始终使用 BURST_LENGTH 参数指定,SS_CTL[x] 应 设置为零。 除了在从属模式下不使用 SS_CTL[x] = 1 选项外,没有其他解决方法。 精确的脉冲串长度应始终使用 BURST_LENGTH 参数指定 Yuri。 Re: iMX6 SPI controller slave mode burst length 您好, @Yuri如何配置突发长度? 此致敬礼 Re: iMX6 SPI controller slave mode burst length <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> 你好 对于从站模式,单个 SPI 脉冲串的最大长度由 FIFO 大小决定 或 SS 否定。但是 从站必须配置脉冲串长度。 以匹配主站在单次传输(突发)中发送的总位数。 此致, 尤里。 Re: iMX6 SPI controller slave mode burst length <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> 评论我自己的帖子。 我注意到电路板支持包(仅限主模式)中的 Linux 驱动程序将突发长度配置为每字的位数,但我从技术人员那里收到了回复。支持案例 #00163683 使我相信,突发长度应设置为整个传输的位数(至少在从属模式下)。如果是这样,那么主模式和从模式下的突发长度有不同的定义——或者——Linux 电路板支持包不应该将其配置为每字位数——或者——我很困惑。
記事全体を表示