Multi Source Translation Content

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

Multi Source Translation Content

ディスカッション

ソート順:
U-Boot USB ID 与主线版本存在回归/错误 你好, U-Boot lf-6.18.20-2.0.0 分支中的 `commit a5c91319731f ("MLK-25803-2: Update VID/PID")` 引入了 USB 用户的一个回归问题。 它强制使用硬编码的 USB 产品 ID,而不是从配置中获取值。这将导致任何使用与 0x0151 不同的值的电路板出现故障。 当在非NXP开发板(使用NXP SoC)上使用此U-Boot分支时,会出现此问题。 该值必须来自配置,而不能硬编码。 以下补丁可以修复该问题,你能将其应用到你的分支吗? ``` diff --git a/arch/arm/mach-imx/spl.cb/arch/arm/mach-imx/spl.c 索引 165cc82d9c72..46e26d138cf9 100644 --- a/arch/arm/mach-imx/spl.c +++ b/arch/arm/mach-imx/spl.c @@ -199,7 +199,7 @@ int g_dnl_bind_fixup(struct usb_device_descriptor *dev, const char *name) snprintf(serial_string, sizeof(serial_string), " %08x% 08x", serialnr.high,serialnr.low); g_dnl_set_serialnumber(serial_string); #endif - put_unaligned(0x0151, &dev->idProduct); + put_unaligned(CONFIG_USB_GADGET_PRODUCT_NUM + 0xfff, &dev->idProduct); 返回 0; } ``` Re: Regression/bug in U-Boot USB ID vs mainline 问题不在于你刚才描述的恩智浦的具体需求。问题在于,将数字硬编码到代码中会阻止任何用户按照设计初衷通过 kconfig 进行配置,从而有效地造成回归。 这种改变无视了现有用户的不同需求,实际上是在破坏现有的使用场景。只需在代码中搜索 CONFIG_USB_GADGET_PRODUCT_NUM,您就会看到它破坏了多个用例。 你需要找到一个不会引入倒退问题的不同解决方案。 Re: Regression/bug in U-Boot USB ID vs mainline 你好, 这一改变是刻意为之的。 VID 0x525 和 PID 0xa4a5 已注册为 PLX Technology, Inc. Linux-USB 文件存储设备 但是 fastboot 设备并非大容量存储设备,Windows 10 最新更新已缓存在上方 VID/PID 中 更改为使用 Freescale VID 0x1fc9 PID 0x151,用于 SPL SDP HID 下载 PID 0x152,用于 Fastboot 进程 ID 0x153,用于内核快速启动 需要更新到 1.4.182 以上版本
記事全体を表示
尽管设置了 SHIFTS,FlexIO0 SPI 控制器的 TX 移位器 (SHIFTCTL, PINCFG=11b) 始终无法驱动其输出引脚。 主板: FRDM-MCXN236(MCX N236,双核 Cortex-M33) 工具链: MCUXpresso IDE 25.6.136裸机寄存器级 C(无 SDK 外设驱动程序) RM 参考: MCX N23x 参考手册 Rev. 4,2025-03-05,第 53 章(FlexIO),表 453(SPI 控制器,CPHA=0 配置) 我正在打造的是: FlexIO0 配置为 SPI 控制器,符合 RM 表 453:2 个移位器(移位器 0 = TX,移位器 1 = RX)+ 1 个定时器(定时器 0 = SCK,双 8 位计数器波特率模式),通过 SPI 读取 BME280 传感器。引脚:P1_0/P1_1/P1_2 复用到 ALT6 (FLEXIO0_D8/D9/D10),通过 PORT1->PCR 回读确认正确。 观察: RX 移位器和 SCK 定时器输出均工作正常——SCK 切换干净利落且按计划进行(通过两个独立的寄存器确认,见下文),SHIFTSTAT/TIMSTAT 报告每次传输均正常、准时、无错误完成。但是,无论向TX 移位器自身的输出引脚 (SDO, D8) 写入什么内容,在我所能想到的所有变化下,它都始终没有任何电信号变化。从传感器读取的芯片 ID 寄存器始终为 0x00,而不是预期的 0x60(在同一块板、同一传感器、同一启动程序上,一个单独的、正常工作的 FlexComm/LPSPI3 驱动程序可以正确读取 0x60)。 寄存器配置(与 RM 表 453 完全匹配,PINSEL 替换为实际引脚) SHIFTCFG0 = 0x0000_0000 (RM: 0000_0000h -- 起始/停止位禁用) SHIFTCTL0 = 0x0083_0002 (RM: 0083_0002h, PINSEL=8 for our real D8/SDO) 解码结果为:TIMSEL=0,TIMPOL=1(负边沿),PINCFG=3(11位,驱动输出), PINSEL=8,PINPOL=0,SMOD=2(传输)——每个字段都已根据RM进行验证 字面意思,只有 PINSEL 被替换 SHIFTCFG1 = 0x0000_0000 SHIFTCTL1 = 0x0000_0101 (RM: 0000_0101h, PINSEL=10 for our real D10/SDI) TIMCMP0 = 根据 RM 自己的公式计算得出(8 位帧,1MHz SCK 波特率分频器) TIMCFG0 = 0x0100_2222(RM 字面值,无需引脚替换) TIMCTL0 = 0x01C3_0201 (RM: 01C3_0201h, PINSEL=9 for our real D9/SCK) 我已通过直接硬件证据(调试器寄存器/内存检查,没有示波器可用)排除了以下可能性: 引脚复用器未到达 ALT6 -- PCR 回读确认所有四个使用的引脚上的 ALT6 配置正确。 传感器/线路故障——一个独立的、正常工作的 FlexComm/LPSPI3 SPI 驱动程序可以从同一个物理传感器、同一个启动过程中正确读取芯片 ID (0x60)。 SCK 从未在物理引脚上切换——通过在同一时刻采样的两个独立寄存器确认切换:FLEXIO0->PIN(位 9)和 GPIO1->PDIR(位 1,一个完全独立的外部模块,其路径中没有 FlexIO 内部逻辑)。双方实时逐个样本地达成一致。 SHIFTBUFBIS(位交换别名寄存器)中的 TX 字节通道放置——尝试了低字节和高字节(重新推导自 RM 53.3.1 的)移位寄存器微架构描述(而不仅仅是摘要表),以及与字节通道无关的完整 32 位交替写入(0xAAAAAAAAA)——所有这些都产生相同的、永久平坦的 SDO。 TX 缓冲区欠载 (SHIFTERR) -- 每次读取 0x0(干净),在成功等待 RX 就绪后立即捕获。 引脚/焊盘特定故障——将 shifter0 的 PINSEL 重新定向到完全不同的物理引脚(D9 而不是 D8);仍然平坦。定时器使用相同的 PINCFG=11b“驱动输出”机制,可以正确驱动任一引脚。 “启用时的隐式加载”(RM 53.3.1:移位器状态标志在“数据已从 SHIFTBUF 加载到移位器或移位器最初配置为发送模式时”设置——即可能存在过时的首周期加载)——通过丢弃的首传输,然后进行跟踪的、明确的次传输来排除:结果完全相同。 SHIFTBUFBIS 别名写入路径不对称——通过普通的、非别名的 SHIFTBUF[0] 寄存器而不是 SHIFTBUFBIS[0] 写入相同的与字节通道无关的模式:结果完全相同。 FLEXIO0->PINOUTD/PINOUTE/PINOUTDIS(全局每引脚软件输出覆盖寄存器,RM 53.3.3.3)-- 实时回读显示所有零,这意味着“由定时器/移位器配置控制”(正常状态),工作 SCK 引脚和非工作 SDO 引脚的值完全相同。并非原因。 FLEXIO0->PIN 读取本身不可靠——参见上面的第 3 点;通过 GPIO1->PDIR 独立确认。 Shifter0 实例特有的缺陷——改用shifter2 ,配置了完全相同的 SHIFTCTL 值,结果出现了相同的扁平化结果。同样的问题。并非特定于某个实例。 RM 53.7.1.27 的记录了两步 PINCFG 写入序列(先写入 10b,然后单独写入 11b,以避免第一次配置时出现短暂的低电平故障)——直接应用:结果相同且平坦。 我还查看了该器件(MCXN23x_0P21K Rev. 2.0)的唯一已发布的掩模集勘误文档——完全没有与 FlexIO 相关的条目——以及 NXP 自己的 FlexIO-SPI 应用笔记(AN12780),该笔记除了 RM 表 453 中已记录的内容外,没有提供任何指导。 问题: 鉴于移位器的内部记录(SHIFTSTAT、SHIFTERR、TIMSTAT)在每次测试中都报告完全正常、按计划、无错误的发送模式工作——包括在同一 CS 括号内的事务中,TX 就绪标志在多次传输中正确清除和重置,根据 RM 53.3.1,这应该只在真正的定时器触发的重新加载时发生——并且移位时钟本身(相同的 PINCFG=11b“驱动输出”机制,只是通过 TIMCTL 而不是 SHIFTCTL)已独立证明能够正确到达其物理引脚: 是否存在已知的硅行为、未记录的先决条件或 RM 间隙,导致移位器的 SHIFTCTL.PINCFG=11b 发送模式输出(与定时器的相同 PINCFG=11b 输出相对)无法到达其在 MCXN23x 掩码集上的指定引脚,即使每个寄存器级配置都与 RM 表 453 中的示例完全匹配? 如果需要,我很乐意分享完整的寄存器级项目源代码和完整的、仅追加的调查日志(尝试过的每一个假设,每一次撤回,以及每一个假设的确切硬件证据)。     MCX N Re: FlexIO0 SPI-controller TX shifter (SHIFTCTL, PINCFG=11b) never drives its output pin, despite SH 嗨@hafeezmhd 根据提供的信息,我没有发现任何已知的 MCXN23x 芯片限制、勘误或已记录的 FlexIO 要求,可以阻止配置为发送模式 SHIFTCTL.PINCFG = 11b 的移位器驱动其分配的引脚,同时同一 FlexIO 实例上的定时器输出正常工作。 由于已确认定时器输出正确到达物理引脚,并且 FlexIO 状态标志指示移位器正常运行,因此您观察到的行为并非我们通常从已记录的 FlexIO SPI 配置中预期的行为。 此时,查看完整的源代码和初始化序列,以及初始化后、传输前立即捕获的完整寄存器转储将很有帮助。这可能有助于识别仅从寄存器摘录中无法明显看出的任何细微配置依赖关系。 如果可以,请分享项目源代码,以便我们仔细查看。 BR 哈里
記事全体を表示
咨询:NXP EasyEVSE 用于 ISO 15118-20 EVCC 仿真与 SECC 测试 你好 我们正在开发定制的充电器侧 ISO 15118-20 SECC。 我们正在考虑使用 NXP EasyEVSE 平台作为电动汽车侧模拟器来测试我们的充电器,而无需使用真正的车辆。我们了解到,MIMXRT1064-EVK 将运行 EVCC 软件,而 EVSE-SIG-BRD2X 和 Green PHY 硬件将为我们的充电器提供 CP/PE 和 PLC 连接。 请您确认一下: 该平台/硬件是否能在EV/EVCC模式下运行并测试定制的SECC。 是否支持 ISO 15118-20 AC 和 AC-BPT。 是否可以测试 CP 状态和 5% PWM、SLAC、SDP、TCP/TLS、授权、服务发现、调度交换、充电循环和会话停止。 是否可以配置模拟电动汽车值,例如当前 SoC、目标 SoC 和充电/放电功率限制。 确切的电动车端硬件 BOM,包括正确的信号板、Green PHY 板、电缆和部件号。 是否包含所需的 SEVENSTAX 软件,或者是否需要单独的评估许可证。 评估是否需要 QA/测试 TLS 证书和安全元件。 哪些电动汽车参数和消息字段可以修改? 充电和放电功率是否可以在会话中动态变化; 此设置仅用于实验室开发和互操作性测试。 顺祝商祺!
記事全体を表示
Plug & Trust 中间件中是否计划支持 SE05x 的 Mbed TLS 4.x / PSA 加密驱动程序? 你好, NXP 是否计划在 Plug & Trust 中间件中集成对 Mbed TLS 4.x 的支持? SE050 Re: Plans for Mbed TLS 4.x / PSA Crypto driver support for SE05x in Plug & Trust Middleware? 嗨@ph-yac , Mbed TLS 4.x 正在考虑于 2027 年第一季度版本。 祝你有美好的一天, 坎 ------------------------------------------------------------------------------- 笔记: - 如果此回复解答了您的问题,请点击“标记为正确答案”按钮。谢谢你! - 我们会持续关注帖子,从最后一条回复发出后持续7周,之后的回复将被忽略。 如果您之后有相关问题,请另开新帖并引用已关闭的帖子。 -------------------------------------------------------------------------------
記事全体を表示
MFS2633的FCCU功能如何使用? 请问MFS2633的PIN.17 FCCU1与PIN.18 FCCU2是如何使用的?两个Pin脚的输入值会构成真值表,引发芯片的不同保护措施? Re: MFS2633的FCCU功能如何使用? 你好,里约! MFS2633 上的 FCCU1(引脚 17)和 FCCU2(引脚 18)是用于接收来自连接的 MCU 的故障信号的数字输入。它们是 FS26 故障保护状态机的 MCU 监控接口的一部分。 它们直接连接到 MCU 的 FCCU 错误输出引脚(例如,S32K3xx MCU 的 FCCU_EOUT[0:1] 或 FSP 输出)。FS26 监控这些输入,当检测到故障情况时,会发出配置的功能安全输出(FS0B 和/或 RSTB)。 在 FS26 初始化阶段,通过 FS_I_SAFE_INPUTS 寄存器中的 FCCU_CFG[2:0] 位选择监视模式。 可用的模式有: Screenshot 2026-08-13 092241.jpg 在最常见的汽车应用中——双稳态(配对)模式——这两个引脚作为互补对工作,而不是作为产生不同反应的独立输入。FS26 预期: 正常/安全状态:FCCU1 = 高电平 (1),FCCU2 = 低电平 (0) 故障状态:FCCU1 = 低电平 (0) 或 FCCU2 = 高电平 (1) 任何偏离预期正常状态的情况都会触发预设的故障响应。默认故障极性为: FCCU1 = 0 or FCCU2 = 1 is a fault 。该极性可通过 FCCU12_FLT_POL 进行配置。 Screenshot 2026-08-13 092736.jpg 功能安全反应(其钳位)不会因 FCCU1/FCCU2 等级的具体组合而有所不同。对于检测到的任何故障,反应都是相同的,但可以使用 FCCU12_FS_REACTION 、 FCCU1_FS_REACTION 和 FCCU2_FS_REACTION 位对每个引脚进行独立配置。 Screenshot 2026-08-13 093010.jpg 检测到故障时,默认反应是将 RSTB 和 FS0B 都置低。如果您希望启用故障恢复策略(MCU 在不复位的情况下处理故障),则必须将响应更改为仅 FS0B。 BRs,托马斯
記事全体を表示
MCIMX8Qでシリアルコンソールが使えず、Linuxも起動できません!XP-CPU(Si B0) - UART上ではゴミ仕様のみ こんにちは、 MCIMX8QXP-CPU(シリコンリビジョンB0)ボードの起動に問題が発生しています。 ハードウェア: MCIMX8QXP-CPU (Si B0) MCIMX8-8X-BB ベースボード IMX-LVDS-HDMIアダプターをJ1に接続 キットに付属していたオリジナルの16GB SDカード また、公式Linux BSP(L6.18.20/MX8QXPC0イメージ)で新しくフラッシュした32GBのSDカードも試しました。 問題: シリアルコンソール(J11)には、115200 8N1 の位置に常にゴミ文字(□□□□)のみが表示されます。 複数のCOMポートを試しました 異なる端末ソフト(PuTTY、Docklight)を試しました 2台の異なるWindowsノートPCで試しました 最新のFTDI VCPドライバーをインストールしました オリジナルのSDカードと新たに書き込んだカードで同じ結果になった。 UUUはシリアルダウンロードモード(SW2 = 1000)ではボードを検出しません。uuu -lsusb を実行してもデバイスが表示されません。ダウンロードモードではデバイスマネージャーにボードが表示されません。 HDMI – まだディスプレイ出力はありません(J1のIMX-LVDS-HDMIを使用中)。 ブートスイッチが試した: SDブート: SW2 = ON ON OFF OFF シリアルダウンロード: SW2 = ON OFF OFF OFF eMMC: SW2 = OFF ON OFF OFF 私が既に行ったこと: Balena EtcherとRufusを使用して公式の.Sdcardイメージをフラッシュしました。 SDカードがJ12に正しく挿入されていることを確認しました。 中古のオリジナル電源 デバッグポート用の複数のUSBケーブルを確認しました どなたかアドバイスをいただけませんか: Si B0ボードのデバッグUARTに関して、既知の問題はありますか? コンソール出力をきれいに表示させるための追加手順はありますか? ボードの復旧/正常性を確認するための推奨方法は?    HW-Open-Source i.MX 8ファミリ | i.MX 8QuadMax (8QM) | 8QuadPlus Re: Unable to get serial console or boot linux on MCIMX8Q!XP-CPU (Si B0) - only garbage on UART こんにちは@drupadh。 NXPサポートにご連絡いただきありがとうございます! 発生しているエラーは、イメージがC0シリコンリビジョン向けに作成されたために発生しています。 残念ながら、B0シリコンリビジョン向けの6.18.20カーネルのプリコンパイル済みイメージは提供しておりません。ただし、Yoctoを使って自分で組み立てることは可能です。 ビルドには、以下のマシン構成「 imx8qxpmek 」を使用してください。 構築プロセスに関して何かお手伝いが必要な場合は、お知らせください。 よろしくお願いします、 アレハンドロ・ガルシア
記事全体を表示
Plans for Mbed TLS 4.x / PSA Crypto driver support for SE05x in Plug & Trust Middleware? Hello, does NXP plan to integrate support for Mbed TLS 4.x in the Plug & Trust Middleware? SE050 Re: Plans for Mbed TLS 4.x / PSA Crypto driver support for SE05x in Plug & Trust Middleware? Hi @ph-yac , Mbed TLS 4.x is being considered for the Q1 2027 release. Have a great day, Kan ------------------------------------------------------------------------------- Note: - If this post answers your question, please click the "Mark Correct" button. Thank you! - We are following threads for 7 weeks after the last post, later replies are ignored Please open a new thread and refer to the closed one, if you have a related question at a later point in time. -------------------------------------------------------------------------------
記事全体を表示
U-Boot USB ID とメインラインにおける回帰/バグ こんにちは、 U-Bootのlf-6.18.20-2.0.0ブランチで「コミットa5c91319731f(「MLK-25803-2: Update VID/PID」)は、USBユーザー全員に回帰を導入します。 設定から値を取得するのではなく、USB製品IDを強制的に入力します。これは、0x0151以外の値を使用しているすべてのボードを破損させます。 この問題は、NXP製以外のボード(NXP製SoCを使用しているボード)でこのU-Bootブランチを使用した場合に発生します。 この値は設定ファイルから取得する必要があり、ハードコーディングしてはいけません。 次のパッチで問題が解決しますが、あなたの支店にも適用できますか? 「`」 diff --git a/arch/arm/mach-imx/spl.c b/arch/arm/mach-imx/spl.c インデックス 165cc82d9c72..46e26d138cf9 100644 --- a/arch/arm/mac-imx/spl.c +++ b/arch/arm/mach-imx/spl.c @@ -199,7 +199,7 @@ int g_dnl_bind_fixup(struct usb_device_descriptor *dev, const char *name) snprintf(serial_string, sizeof(serial_string), "%08x%08x", serialnr.high,シリアル番号.low); g_dnl_set_serialnumber(serial_string); #endif - put_unaligned(0x0151, &dev->idProduct); + put_unaligned(CONFIG_USB_GADGET_PRODUCT_NUM + 0xfff, &dev->idProduct); 0を返す。 } 「`」 Re: Regression/bug in U-Boot USB ID vs mainline 問題は、あなたが先ほど説明したNXP製品に関する具体的なニーズではありません。問題は、コードに数字をハードコーディングすることで、ユーザーがkconfigから設定できず、実質的に回帰を生み出せないことです。 その変更は、異なるニーズを持つ既存ユーザーを無視し、動作するユースケースを積極的に壊すことです。コードの中のgrepでgrep CONFIG_USB_GADGET_PRODUCT_NUMすれば、この問題が壊れている複数のユースケースがわかります。 回帰バグを引き起こさない、別の解決策が必要です。 Re: Regression/bug in U-Boot USB ID vs mainline こんにちは、 この変更は意図的なものであった。 VID 0x525とPID 0xa4a5すでにPLX Technology, Inc.として登録されています。 Linux-USBファイルバックアップストレージガジェット しかし、fastboot デバイスはマスストレージデバイスではありません。Windows 10 の最新アップデートは既に上記の vid/pid をキャッシュしています。 Freescale VID 0x1fc9を使用するように変更します。 PID 0x151、SPL SDP HIDダウンロード用 PID 0x152、Fastboot用 PID 0x153、カーネル高速起動用 uuuを1.4.182以上にアップデートする必要があります
記事全体を表示
MFS2633のFCCU機能の使い方は? MFS2633のPIN.17 FCCU1とPIN.18 FCCU2はどのように使用されますか?これらの2つのピンの入力値はどのような真理値表を形成し、チップのさまざまな保護機能をトリガーしますか? Re: MFS2633的FCCU功能如何使用? こんにちはリオ、 MFS2633上のFCCU1(PIN 17)とFCCU2(PIN 18)は、接続されたMCUからの故障信号を受信するためのデジタル入力です。これらはFS26フェイルセーフステートマシンのMCU監視インターフェースの一部です。 これらはMCUのFCCUエラー出力ピン(例:S32K3xxのFCCU_EOUT[0:1]やFSP出力)に直接接続されます。FS26はこれらの入力を監視し、故障状態が検出されると、設定されたセーフティ出力(FS0Bおよび/またはRSTB)を主張します。 監視モードは、FS26の初期化フェーズ中に FS_I_SAFE_INPUTS レジスタの FCCU_CFG[2:0] ビットによって選択されます。 利用可能なモードは以下のとおりです。 Screenshot 2026-08-13 092241.jpg 最も一般的なオートモーティブ実装であるバイスタッフル(ペアモード)では、2つのピンは相補的なペアとして動作し、異なる反応を生み出す独立した入力としてはなりません。FS26は以下を期待しています。 正常/安全状態:FCCU1 = HIGH(1)、FCCU2 = LOW(0) 故障状態:FCCU1 = LOW (0) または FCCU2 = HIGH (1) 想定される正常状態からの逸脱はすべて、設定された障害反応を引き起こします。デフォルトの障害極性は、 FCCU1 = 0 or FCCU2 = 1 is a fault 。この極性は FCCU12_FLT_POL で設定可能です。 Screenshot 2026-08-13 092736.jpg セーフティ反応(どの出力が主張されるか)は、FCCU1/FCCU2レベルの特定の組み合わせによって違いはありません。反応は検出された故障に対して同じですが、 FCCU12_FS_REACTION ビット、 FCCU1_FS_REACTION ビット、 FCCU2_FS_REACTION ビットを使ってピンごとに独立して設定できます。 Screenshot 2026-08-13 093010.jpg デフォルトの動作は、障害が検出された場合、RSTBとFS0Bの両方をローレベルにすることです。故障回復戦略(MCUがリセットせずに故障を処理する方法)を有効にしたい場合は、リアクションをFS0Bのみに変更する必要があります。 BRs、トーマス
記事全体を表示
LAN96455F Ethernet Switch Integration with i.MX95 – Device Tree Guidance Hi NXP team, We're integrating a Microchip LAN96455F Ethernet switch (LAN9645x family) onto a custom i.MX95 19x19 LPDDR5 board (based on imx95-19x19-evk.dts), and would appreciate guidance on the correct device tree integration Re: LAN96455F Ethernet Switch Integration with i.MX95 – Device Tree Guidance For Linux, model the LAN96455F as a DSA Ethernet switch if you expect Linux to expose/manage the external switch ports individually. The i.MX95 ENETC/NETC Ethernet MAC that connects to the switch’s CPU/uplink port should be the DSA conduit interface; the LAN96455F ports become DSA user netdevs. DSA is designed for switches with a dedicated CPU port connected to an SoC Ethernet controller, and it creates per-front-panel “user” interfaces rather than a separate netdev for the CPU port itself . A good device-tree shape is: /* Replace &enetX / &mdioX with the actual i.MX95 BSP labels used  * in imx95-19x19-evk.dts / imx95.dtsi for your selected NETC ENETC port.  */ /* i.MX95 ENETC port connected to LAN96455F CPU/uplink port */ &enetX {               status = "okay";               /* Must match the electrical interface between i.MX95 and LAN96455F:                * "rgmii-id", "rgmii", "sgmii", "2500base-x", etc.                */               phy-mode = "rgmii-id";               /* MAC-to-switch CPU port is normally PHY-less, so describe it                * as a fixed link unless the LAN96455F CPU port is actually                * managed through a PHY/PCS.                */               fixed-link {                              speed = <1000>;                              full-duplex;               }; }; /* MDIO controller used to access the switch management interface.  * i.MX95 NETC has an external master MDIO interface for external PHYs,  * supporting Clause 22 and Clause 45 .  */ &mdioX {               status = "okay";               ethernet-switch@0 {                              /* Use the compatible string from the LAN9645x driver/binding                               * shipped in your kernel/BSP. Do not invent this string.                               */                              compatible = "microchip, ";                              reg = <0>;                       /* MDIO address strapped on the board */                              ports {                                            #address-cells = <1>;                                            #size-cells = <0>;                                            port@0 {                                                           reg = <0>;                                                           label = "lan0";                                                           /* If this external port has an external PHY:                                                            * phy-handle = <&phy0>;                                                            * phy-mode = "...";                                                            */                                            };                                            port@1 {                                                           reg = <1>;                                                           label = "lan1";                                            };                                            port@2 {                                                           reg = <2>;                                                           label = "lan2";                                            };                                            port@3 {                                                           reg = <3>;                                                           label = "lan3";                                            };                                            /* LAN96455F CPU/uplink port number must match the                                             * Microchip datasheet/driver definition.                                             */                                            port@N {                                                           reg = ;                                                           label = "cpu";                                                           ethernet = <&enetX>;                                                           phy-mode = "rgmii-id";                                                           fixed-link {                                                                         speed = <1000>;                                                                         full-duplex;                                                           };                                            };                              };               }; }; Key points to check before finalizing the DTS: Use the actual LAN9645x binding from your kernel. I could not confirm a public mainline LAN96455F-specific binding from the retrieved sources, so the compatible string above is intentionally a placeholder. Check your NXP BSP/Microchip driver tree under Documentation/devicetree/bindings/net/dsa/ or the Microchip LAN9645x driver source. Put ethernet = <&enetX>; on the switch CPU port, not on every switch port. The DSA port binding says the ethernet property is a phandle to the host Ethernet device that the switch port is connected to. CPU/DSA ports need a phylink-style link description. For a CPU port with ethernet = <&enetX>; , the binding requires phy-mode and one of fixed-link , phy-handle , or managed . Use fixed-link for a direct MAC-to-switch CPU-port connection. The common Ethernet binding defines fixed-link with speed , full-duplex , and optional pause properties; supported fixed-link speeds include 10/100/1000/2500/5000/10000 Mbit/s in the object form. Be precise with RGMII delay mode. phy-mode = "rgmii-id" means the PCB does not provide the RGMII clock/data delay and the MAC/PHY side must provide internal delay; plain "rgmii" means the PCB routing provides the delay. For most custom boards, "rgmii-id" is the expected starting point unless your layout deliberately adds the delay. Do not also configure the i.MX95 MAC as if it had a normal external PHY if the MAC is connected to the switch CPU port. In the DSA model, the MAC is the conduit, and the external user ports are represented by the switch port nodes. Expect Linux interfaces such as lan0 , lan1 , etc. DSA creates user network devices for front-panel ports, and the DSA label property becomes the netdev name. Bring-up checks: dmesg | grep -i -E "dsa|lan964|mdio|enetc|netc" ip link cat /sys/class/net/ /dsa/tagging 2>/dev/null ip link set up ip link set lan0 up ethtool lan0 If no lanX interfaces appear, debug in this order: MDIO address/strap value, reset GPIO timing, interrupt GPIO if required by the driver, correct LAN9645x compatible , correct CPU-port reg , and correct phy-mode /fixed-link speed between i.MX95 and the switch. Use the i.MX95 ENETC port as the DSA conduit, describe the LAN96455F under the MDIO/SPI management bus with a ports block, and make the switch CPU port point back to the ENETC MAC using ethernet = <&enetX> plus a valid phy-mode and fixed-link / managed / phy-handle .
記事全体を表示
NXP S32K312 CAN0 – FIRC vs. FXOSC Clock Source Causing CAN Errors Hi everyone, I am using CAN0 on the S32K312 at 500 kbps with an 87.5% sampling point. Initially, I set up CAN0 to use the internal FIRC_CLK as the clock source. When I connected the S32K312 to a network with multiple CAN nodes, I noticed a lot of CAN error frames. I then switched the CAN clock source from FIRC_CLK to the external FXOSC_CLK while keeping the CAN bitrate and sampling point the same. After this change, the communication became stable, and I stopped seeing the error frames. Could anyone help me understand why switching the clock source from FIRC_CLK to FXOSC_CLK would fix the CAN errors? Re: NXP S32K312 CAN0 – FIRC vs. FXOSC Clock Source Causing CAN Errors Hello @Karthik_R, Usually, FIRC clock is not recommended for FlexCAN communication, as accuracy is over the ~1% requirement according to CAN protocol (ISO 11898-1). You can see from S32K3's Data Sheet that FIRC's deviation is +- 5%. Recommendation is to use either FXOSC or PLL running from XOSC. You can refer to FlexCAN Bit Timing Calculation document, and MPC5xxx/S32Kxx/LPCxxxx: CAN / CAN FD bit timing calculation tool for clock and timing calculations. Hope this is clear. Best regards, Julián
記事全体を表示
如何通过喷嘴拾取 MPXM2053GS 在 SMT 过程中,空气可能会从取放喷嘴吹入压力端口。内部传感器有可能损坏吗? Re: how to pick up MPXM2053GS by nozzle 你好,大卫, 从取放喷嘴到侧面压力端口的短暂低压空气脉冲不太可能造成损坏,只要施加的压力不超过设备的最大额定过压。然而,反复或高压气流原则上可能会使隔膜承受压力,或者在极端情况下,使其受损。 为完全避免任何风险,建议将取放喷嘴放置在 M-PAK 封装的平坦顶部表面上,远离侧面的压力端口。这样可以确保喷嘴永远不会接触或引导气流进入感应端口开口。应用笔记AN1984 – 飞思卡尔压力传感器的处理,针对该设备系列的喷嘴设计和放置提供了具体指导,是 MPX 系列传感器 SMT 处理的主要参考。应用笔记AN936 – MPX 系列压力传感器的安装技术、引脚成型和测试也是一份有用的补充资料。 请注意,截至 2026 年 2 月 2 日,NXP MEMS 传感器产品(包括 MPXM2053GS)已过渡到 STMicroelectronics。如需后续产品支持和文档处理方面的帮助,我建议您直接咨询STM。 BRs,托马斯
記事全体を表示
how to pick up MPXM2053GS by nozzle During the SMT process, air may get blown into the pressure port from the pick-and-place nozzle. Is it possible to damage the sensor inside? Re: how to pick up MPXM2053GS by nozzle Hello David, A brief, low-pressure air pulse from the pick-and-place nozzle into the side pressure port is unlikely to cause damage, provided the applied pressure does not exceed the device's maximum rated overpressure. However, repeated or high-pressure air blasts could in principle stress the diaphragm or, under extreme conditions, compromise it. To avoid any risk entirely, the recommended approach is to position the pick-and-place nozzle on the flat top body surface of the M-PAK package, away from the side pressure port. This ensures the nozzle never contacts or directs airflow into the sensing port opening. Application Note AN1984 – Handling Freescale Pressure Sensors provides specific guidance on nozzle design and placement for this device family and is the primary reference for SMT handling of MPX-series sensors. Application Note AN936 – Mounting Techniques, Lead Forming, and Testing of the MPX Series Pressure Sensors is also a useful complement. Please note that as of February 2, 2026, NXP MEMS sensor products (including the MPXM2053GS) have been transitioned to STMicroelectronics. For ongoing product support and handling documentation going forward, I recommend also consulting STM directly. BRs, Tomas
記事全体を表示
LAN96455F i.MX95とのイーサネット・スイッチ統合 – デバイスツリーガイダンス こんにちは、NXPチームの皆様、 Microchip LAN96455F Ethernet Switch(LAN9645xファミリ)をカスタムのi.MX95 19x19 LPDDR5ボード(imx95-19x19-evk.dtsベース)に統合しています。適切なデバイスツリー統合に関するガイダンスをいただければ幸いです。 Re: LAN96455F Ethernet Switch Integration with i.MX95 – Device Tree Guidance Linuxの場合、外部スイッチポートを個別に公開・管理する予定がある場合は、LAN96455FをDSA イーサネット・スイッチとしてモデル化してください。スイッチのCPU/アップリンクポートに接続するi.MX95 ENETC/NECイーサネットMACはDSAコンジットインターフェースであるべきです。LAN96455FポートはDSAユーザーNetDevとなります。DSAは、専用CPUポートがSoCイーサネットコントローラに接続されたスイッチ向けに設計されており、CPUポート自体の別のネット開発ではなく、フロントパネルごとの「ユーザー」インターフェースを作成します。 適切なデバイスツリーの構造は次のとおりです。 /* &enetX / &mdioX を実際の i.MX95 BSP ラベルに置き換えてください  * 選択した NETC ENETC ポートについては、imx95-19x19-evk.dts / imx95.dtsi を参照してください。 */ /* i.MX95 ENETCポートがCPU/アップリンクポートに接続LAN96455F */ &enetX {                  ステータス = "okay";               /* i.MX95とLAN96455F間の電気インターフェースを一致させる必要があります: * "rgmii-id", "rgmii", "sgmii", "2500base-x", など。                */               phy-mode = "rgmii-id";               /* MACからスイッチへのCPUポートは通常PHYがないため、説明してください               * LAN96455F CPU ポートが実際に固定リンクでない限り、固定リンクとして扱われます。                  * PHY/PCS を介して管理されます。                */ 固定リンク {                              速度 = <1000>; 全二重; }; }; /* MDIOコントローラはスイッチ マネジメント インターフェースにアクセスするために使用されました。 * i.MX95 NETCは外部PHY用のマスターMDIOインターフェースを備えています。  * 条項 22 および条項 45 を支持する 。 */ &mdioX {                  ステータス = "okay"; イーサネットswitch@0 {                              /* LAN9645xのドライバー/バインディングの互換文字列を使用してください * カーネル/BSP に同梱されています。この文字列を創作しないでください。 */ 互換性 = "microchip, reg = <0>; /* MDIO アドレスをボード上に固定 */ ポート { #address-cells = <1> #size-cells = <0>;                                            port@0 { reg = <0>; label = "lan0"; /* この外部ポートに外部 PHY がある場合: * phy-handle = <&phy0> * phy-mode = "..." */                                             };                                            port@1 { reg = <1>; label = 「lan1」;                                             };                                            port@2 { reg = <2>; label = "lan2";                                             };                                            port@3 { reg = <3> label = "lan3";                                             }; /* LAN96455F CPU/アップリンクポート番号は、 * マイクロチップのデータシート/ドライバ定義。 */                                            ポート@N { reg = ; label = "CPU"; イーサネット = <&enetX>;                                                            phy-mode = "rgmii-id";                                                            固定リンク {                                                                             スピード = <1000>; 全二重;                                                               };                                             };                           }; }; }; DTSを最終決定する前に確認すべき重要なポイント: カーネルから実際のLAN9645xバインディングを使用してください。取得したソースから公開されたメインLAN96455Fライン固有のバインディングを確認できなかったため、上記の互換性文字列は意図的にプレースホルダーとして使っています。NXPのBSP/Microchipドライバーツリーのドキュメント/devicetree/bindings/net/dsa/またはMicrochip LAN9645xドライバーソースを確認してください。 イーサネット = <&enetX>すべてのスイッチポートではなく、SwitchのCPUポートに設置しています。 DSAポートバインディングでは、イーサネットプロパティがスイッチポートがコネクテッドされているホストイーサネットデバイスへのphandleであると書かれています。 CPU/DSAポートには、phylink形式のリンク記述が必要です。CPUポートの場合、イーサネット=<&enetX>;このバインディングはphyモードと固定リンク、phyハンドル、またはマネージドのいずれかを必要とします。 固定リンクはMACからスイッチへのCPUポート直接続に使います。 一般的なイーサネットバインディングは、速度、全二重、オプションの一時停止特性を持つ固定リンクを定義しています。サポートされる固定リンク速度には、オブジェクト形式で10/100/1000/2500/5000/10000 Mbit/sが含まれます。 RGMIIの遅延モードは正確に設定してください。phy-mode = "rgmii-id" は、PCB が RGMII クロック/データ遅延を提供せず、MAC/PHY 側が内部遅延を提供する必要があることを意味します。plain "rgmii" は、PCB の配線が遅延を提供することを意味します。ほとんどのカスタムボードでは、レイアウトで意図的に遅延を追加しない限り、「rgmii-id」が想定される開始点となります。 また、i.MX95のMACがスイッチCPUポートに接続されている場合、通常の外部PHYのように設定しないでください。DSAモデルでは、MACが導管となり、外部ユーザーのポートはスイッチポートノードで表されます。 lan0やlan1などのLinuxインターフェースが期待できます。DSAはフロントパネルポート用のユーザーネットワークデバイスを作成し、DSAラベルプロパティがnetdevの名前となります。 準備チェック: dmesg | grep -i -E "dsa|lan964|mdio|enetc|netc" IPリンク cat /sys/class/net/ /dsa/tagging 2>/dev/null ip link set up ip link set lan0 up ethtool lan0 lanXインターフェースが表示されない場合は、次の順番でデバッグを行います:MDIOアドレス/ストラップ値、GPIOタイミングのリセット、ドライバーの要求による割り込みGPIO、正しいLAN9645x互換、正しいCPUポートレジグ、i.MX95とスイッチ間の正しい物理モード/固定リンク速度。 i.MX95 ENETCポートをDSA導管として使い、MDIO/SPI管理バスの下でポートブロックでLAN96455Fを記述し、スイッチCPUポートをENETC MACに戻すようにします。イーサネット = <&enetX>に加え有効なphyモードと固定リンク/マネージド/phyハンドルを使用します。
記事全体を表示
NXP S32K312 CAN0 – FIRC 与 FXOSC 时钟源导致 CAN 错误 大家好, 我正在使用 S32K312 上的 CAN0,速率为 500 kbps,采样点为 87.5%。 最初,我将 CAN0 设置为使用内部 FIRC_CLK 作为时钟源。当我将 S32K312 连接到具有多个 CAN 节点的网络时,我注意到出现了很多 CAN 错误帧。 然后,我将 CAN 时钟源从 FIRC_CLK 切换到外部 FXOSC_CLK,同时保持 CAN 比特率和采样点不变。做出这一改变后,通信变得稳定,我不再看到错误帧。 请问有人能帮我理解一下为什么将时钟源从 FIRC_CLK 切换到 FXOSC_CLK 就能解决 CAN 错误吗? Re: NXP S32K312 CAN0 – FIRC vs. FXOSC Clock Source Causing CAN Errors 你好@Karthik_R , 通常不建议将 FIRC 时钟用于 FlexCAN 通信,因为根据 CAN 协议 (ISO 11898-1),其精度超过了 ~1% 的要求。从 S32K3 的数据表中可以看出,FIRC 的偏差为 +/- 5%。 建议使用 FXOSC 或由 XOSC 运行的 PLL。您可以参考FlexCAN 位时序计算文档和MPC5xxx/S32Kxx/LPCxxxx:CAN / CAN FD 位时序计算工具进行时钟和时序计算。 希望这能说清楚。 此致, 朱利安
記事全体を表示
GCCはプラグマステートメントを無視して、コードをITCMメモリに配置します。 こんにちは! ここでは、S32K3バージョン1.7.1用のMatlab R2025b、Simulink、およびMBDTを使用しています。 私たちが開発中のモーターコントローラアプリケーションの性能を最適化するために、コードの一部をITCMメモリに、さらに後にはデータ用のDTCMメモリに配置したいと考えています。 今のところ、ワークフローをテストするために、ITCMのメモリに関数を配置しようとしています。Simulink/Embedded Coderを使って、以下のような正しいプラグマステートメントをCコードに挿入することに成功しました。 #pragma GCC section text ".itcm_text" static void Motor_Drive_Subsystem(void) ヤージュ .......... } #pragma GCC セクション テキスト "" しかし、アプリケーションをコンパイルする際には、gccはこれらのプラグマ文を無視し、コードを標準の.textに配置しますセグメント。これはobjdumpコマンドで結論づけられます: arm-none-eabi-objdump -h Motor_Control.o (being the .oMotor_Drive_Subsystem関数を含むcファイルから生成されたファイル) .itcm_text はありませんリストには、.text.xxxx セグメントのみが含まれています (他の非テキストセグメントの中に)。 コンパイル時には、MBDT環境で設定された標準のGCCスイッチを使用しています。 arm-none-eabi-gcc -O2 -c -std=c99 -fshort-enums -funsigned-char -fstack-usage -ffunction-sections -fdata-sections -g -pedantic -Wall -Wextra -fmessage-length=0 -funsigned-bitfields -fno-common -Wunused -Wstrict-prototypes -Wsign-compare -Werror=implicit-function-declaration -mcpu=cortex-m7 -mthumb -mlittle-endian -mfloat-abi=hard -mfpu=FPV5-sp-d16 -DD_CACHE_ENABLE -DI_CACHE_ENABLE -specs=nano.specs -specs=nosys.specs --sysroot="C:\MATLAB_Add-Ons\Toolboxes\NXP_MBDToolbox_S32K3\tools\build_tools\gcc_v10.2\gcc-10.2-arm32-eabi\arm-none-eabi\newlib」-DSTEP_GPT_TIMER -DSTEP_GPT_CHANNEL=GptConf_GptChannelConfiguration_StepTimer -DSTEP_GPT_CHANNEL_FREQ=40000000 -DSTEP_GPT_CHANNEL_VALUE_MAX=4294967295 -DAUTOSAR_OS_NOT_USED -D__MW_TARGET_USE_HARDWARE_RESOURCES_H__ -DGCC -DS32K3XX -DS32K396 -DCPU_S32K396 -DENABLE_FPU -DMPU_ENABLE -DMBDT_INIT -DCLASSIC_INTERFACE=0 -DALLOCATIONFCN=0 -DTERMFCN=0 -DONESTEPFCN=1 -DMAT_FILE=0 -DMULTI_INSTANCE_CODE=0 -DINTEGER_CODE=0 -DMT=0 -DTID01EQ=0 -DSTACK_SIZE=64 -DRT -DMODEL=Motor_Control -DNUMST=1 -DNCSTATES=0 -DHAVESTDIO -DMODEL_HAS_DYNAMICALLY_LOADED_SFCNS=0 -IC: ..... 生成されたcコードファイルを修正し、手動でコンパイルすることで、次の結論が得られます。 関数の「static」宣言を削除しても効果はありません。しかし、「static」を削除し、関数に属性ステートメントを追加するという別の方法を使用すると、次のようになります。 static void  __attribute__((section(".itcm_text")))Motor_Drive_Subsystem(void); .itcm_textを作成します.o のセグメントファイル。 私が何か間違ったことをしているのか、それともツールに問題があるのか、よく分かりません。 これをうまく動かす方法を誰か教えてもらえますか? もちろん、ツールチェーンにこの処理を任せたいので、コード生成後にCコードを手動で修正したくはありません。 私の見る限り、startup_cm7.Sのようですまた、ITCMおよびDTCMメモリを処理するためにlinker_flash_s32k396.ldファイルが用意されています。 フォーラムでこの投稿を見つけました。関連性があるかどうかはわかりませんが、こちらです: https://community.nxp.com/t5/S32-Design-Studio/No-GCC-11-4-item-in-new-project-wizard-dialog-on-S32DS-3-6-2/td-p/2134523 MBDTのgccはビルド1728のようですが、投稿で修正されているものはビルド1803です。 よろしくお願いいたします! Re: Gcc ignoring pragma statements to place code into ITCM memory. こんにちは、 カスタムストレージクラスの設定方法については、MathWorksのウェブサイトにある以下のページをご確認ください。プラグマを挿入することによって、メモリ内のデータと関数の配置を制御する。 使用する必要がある部分は、「サブシステム機能とデータのデフォルトメモリ配置を上書きする」です。 SorinIBancila_0-1786627722302.pngSorinIBancila_0-1786627722302.pngSorinIBancila_0-1786627722302.pngSorinIBancila_0-1786627722302.png カスタムストレージクラスを作成した後は、モデルを読み込むように設定する必要があります: 0. カスタムストレージクラスの作成および構成: SorinIBancila_5-1786628332348.pngSorinIBancila_5-1786628332348.pngSorinIBancila_5-1786628332348.pngSorinIBancila_5-1786628332348.png 1. コードパースペクティブに入る SorinIBancila_1-1786628013296.pngSorinIBancila_1-1786628013296.pngSorinIBancila_1-1786628013296.pngSorinIBancila_1-1786628013296.png 2. オープン組み込みコーダー辞書(モデル) SorinIBancila_2-1786628097732.pngSorinIBancila_2-1786628097732.pngSorinIBancila_2-1786628097732.pngSorinIBancila_2-1786628097732.png 3. 先ほど作成したカスタムクラスを読み込みます。 SorinIBancila_3-1786628212316.pngSorinIBancila_3-1786628212316.pngSorinIBancila_3-1786628212316.pngSorinIBancila_3-1786628212316.png 4. モデル内で新しいサブシステムを作成し、それを原子に設定します。 SorinIBancila_6-1786628433580.pngSorinIBancila_6-1786628433580.pngSorinIBancila_6-1786628433580.pngSorinIBancila_6-1786628433580.png 5. コード生成内で、実行関数のメモリセクションをカスタムクラスで設定されている「MemSection_ITCM」に設定します。 SorinIBancila_7-1786628826071.pngSorinIBancila_7-1786628826071.pngSorinIBancila_7-1786628826071.pngSorinIBancila_7-1786628826071.png 6. arm-none-eabi-objdump が.oを.itcm_textに読み込むときに正しくITCM_ToggleDIO植え替えメモリセクション SorinIBancila_8-1786631977524.pngSorinIBancila_8-1786631977524.pngSorinIBancila_8-1786631977524.pngSorinIBancila_8-1786631977524.png arm-none-eabi-nm -n s32k3xx_dio_s32ct.elfも、ITCM_ToggleDIOは0x0住所で見つかると言っています。 SorinIBancila_9-1786632086079.pngSorinIBancila_9-1786632086079.pngSorinIBancila_9-1786632086079.pngSorinIBancila_9-1786632086079.png もし.elfをS32DSからフラッシュし、内部でブレークポイントを使うと関数s32k3xx_dio_s32c_ITCM_ToggleDIO、逆アセンブルビューでは命令がアドレスから始まる0x0が確認できます。 SorinIBancila_0-1786632484317.pngSorinIBancila_0-1786632484317.pngSorinIBancila_0-1786632484317.pngSorinIBancila_0-1786632484317.png よろしくお願いします、 ソリン・バンシラ Re: Gcc ignoring pragma statements to place code into ITCM memory. こんにちは、ソリンさん 手伝ってくれてありがとう! 私は実際にMathWorksのウェブサイトに掲載されていた指示に従っていました。 これで、プラグマ文の代わりに属性文を挿入する機能が動作するようになりました。 しかし、それでもgccは関数を.itcm_textに挿入することを拒否する。セグメント。 ブロックには以下のコード生成設定を使用します。 RNJ_0-1786705067074.pngRNJ_0-1786705067074.pngRNJ_0-1786705067074.pngRNJ_0-1786705067074.png 次のような関数のコードが生成されます。 /* 標準コード生成をITCMにリダイレクトする */ __attribute__ ((section(".itcm_text"))) static void Motor_Drive_Subsystem(void) { .... } 結論: .o に itcm_text セグメントがありませんファイル Gcc は関数を完全に最適化します (.o を逆アセンブルすると確認できます)ファイル) 生成された.cファイルから関数の「static」宣言を削除すると手動で再コンパイルすると、.itcm_text が取得できます。.o のセグメントファイル。 どうやら「static」宣言によって、gccコンパイラは属性プレフィックスを無視するようになるようです。 Modelsimでブロックを「再利用可能な関数」に設定すれば、静的宣言が削除されることを期待します。 RNJ_1-1786705067131.pngRNJ_1-1786705067131.pngRNJ_1-1786705067131.pngRNJ_1-1786705067131.png 私は以下を受け取ります: .itcm_text はまだありません.o のセグメントファイル 生成されたCコードでは、関数は依然として「static」として宣言されています。 .o の逆アセンブルファイルを見ると、gcc はアセンブリコード内に関数を保持しているが、.itcm_text への指示は見られない。セグメント では、「静的」宣言が問題なのか(Simulinkや組み込みコーダーの設定に関係しているのか)、それともGCCが「static」を優先して「attribute」宣言を優先している問題なのか? よろしくお願いいたします。 Re: Gcc ignoring pragma statements to place code into ITCM memory. ああ! 「static」宣言が問題の原因だとわかったので、設定パラメータのコード生成セクションを見てみたところ、以下のことが分かりました。 RNJ_0-1786969749323.pngRNJ_0-1786969749323.pngRNJ_0-1786969749323.pngRNJ_0-1786969749323.png チェックを外したら問題が解決しました! 関数の静的宣言はなく、マッピングファイル内でitcm_textセグメントが見えます。あなたもこれが解決策だとお考えなら、私は満足です。 ご協力ありがとうございました!大変感謝しております! Re: Gcc ignoring pragma statements to place code into ITCM memory. こんにちは、 発生した問題を再現しようと試みましたが、生成された関数には「static」キーワードが含まれていませんでした。 SorinIBancila_0-1786963037855.pngSorinIBancila_0-1786963037855.pngSorinIBancila_0-1786963037855.png 私がテストのために行ったのは、基本的なサンプル(s32k3xx_dio_s32ct)をロードし、サブシステム内のすべてのブロックを移動して、それをアトミックに設定し、MemSection_ITCM定義を使用するように構成することでした。あなたも同じように試してみては?もしこのシナリオで再現されなければ、モデルのどこか設定で生成関数を静的にしているのかもしれません。 よろしくお願いします、 ソリン・バンシラ Re: Gcc ignoring pragma statements to place code into ITCM memory. こんにちは、 問題が解決できてよかったです! 😄 よろしくお願いします、 ソリン・バンシラ
記事全体を表示
Gcc 忽略 pragma 语句,将代码放入 ITCM 内存中。 您好! 这里使用的是 Matlab R2025b、Simulink 和 MBDT for S32K3 版本 1.7.1。 为了优化我们正在开发的电机控制器应用程序的性能,我们希望将部分代码放入 ITCM 内存中,稍后将数据放入 DTCM 内存中。 目前,为了测试工作流程,我正在尝试将一个函数放入 ITCM 内存中。我成功地让 Simulink/嵌入式程序员将正确的编译指示语句插入到 C 代码中,例如: #pragma GCC 部分文本 ".itcm_text" static void Motor_Drive_Subsystem(void) { .......... } #pragma GCC 部分文本“” 然而,在编译应用程序时,gcc 会忽略这些编译指示语句,并将代码放置在标准的 .text 文件中。部分。可以用 objdump 命令得出结论: arm-none-eabi-objdump -h Motor_Control.o (即 .o 文件)由包含 Motor_Drive_Subsystem 函数的 c 文件生成的文件) 没有 .itcm_text列表中只有 .text.xxxx 段(以及其他非文本段)。 编译时,我使用 MBDT 环境中设置的 gcc 标准开关: arm-none-eabi-gcc -O2 -c -std=c99 -fshort-enums -funsigned-char -fstack-usage -ffunction-sections -fdata-sections -g -pedantic -Wall -Wextra -fmessage-length=0 -funsigned-bitfields -fno-common -Wunused -Wstrict-prototypes -Wsign-compare -Werror=implicit-function-declaration -mcpu=cortex-m7 -mthumb -mlittle-endian -mfloat-abi=hard -mfpu=fpv5-sp-d16 -DD_CACHE_ENABLE -DI_CACHE_ENABLE -specs=nano.specs -specs=nosys.specs --sysroot="C:\MATLAB_Add-Ons\Toolboxes\NXP_MBDToolbox_S32K3\tools\build_tools\gcc_v10.2\gcc-10.2-arm32-eabi\arm-none-eabi\newlib"-DSTEP_GPT_TIMER -DSTEP_GPT_CHANNEL=GptConf_GptChannelConfiguration_StepTimer -DSTEP_GPT_CHANNEL_FREQ=40000000 -DSTEP_GPT_CHANNEL_VALUE_MAX=4294967295 -DAUTOSAR_OS_NOT_USED -D__MW_TARGET_USE_HARDWARE_RESOURCES_H__ -DGCC -DS32K3XX -DS32K396 -DCPU_S32K396 -DENABLE_FPU -DMPU_ENABLE -DMBDT_INIT -DCLASSIC_INTERFACE=0 -DALLOCATIONFCN=0 -DTERMFCN=0 -DONESTEPFCN=1 -DMAT_FILE=0 -DMULTI_INSTANCE_CODE=0 -DINTEGER_CODE=0 -DMT=0 -DTID01EQ=0 -DSTACK_SIZE=64 -DRT -DMODEL=Motor_Control -DNUMST=1 -DNCSTATES=0 -DHAVESTDIO -DMODEL_HAS_DYNAMICALLY_LOADED_SFCNS=0 -IC: ..... 通过修改生成的 C 代码文件并手动编译,我可以得出以下结论: 移除函数的“static”声明并不能解决问题。然而,移除“static”并使用另一种方法,即在函数上添加属性语句: static void __attribute__((section(".itcm_text")))Motor_Drive_Subsystem(void); 将创建一个 .itcm_text.o 段文件。 我不确定是我操作有误还是工具出了问题。 请问有人能指导我如何才能让它正常运行吗? 当然,我们希望工具链能够处理这种情况,而不希望在代码生成后手动修改 C 代码。 据我所见,它看起来像是 startup_cm7.s。并准备了 linker_flash_s32k396.ld 文件来处理 ITCM 和 DTCM 存储器。 我在论坛上找到了这篇帖子,不确定是否与此相关: https://community.nxp.com/t5/S32-Design-Studio/No-GCC-11-4-item-in-new-project-wizard-dialog-on-S32DS-3-6-2/td-p/2134523 MBDT gcc 的版本似乎是 1728,而帖子中修复的版本是 1803。 提前感谢! Re: Gcc ignoring pragma statements to place code into ITCM memory. 你好, 请查看 MathWorks 网站上的以下页面,了解如何设置自定义存储类:通过插入编译指示来控制数据和函数在内存中的位置。 您需要使用的部分是“覆盖子系统功能和数据的默认内存放置”。 SorinIBancila_0-1786627722302.pngSorinIBancila_0-1786627722302.pngSorinIBancila_0-1786627722302.pngSorinIBancila_0-1786627722302.png 创建自定义存储类后,必须配置模型以加载它: 0. 创建并配置自定义存储类: SorinIBancila_5-1786628332348.pngSorinIBancila_5-1786628332348.pngSorinIBancila_5-1786628332348.pngSorinIBancila_5-1786628332348.png 1. 进入代码透视图 SorinIBancila_1-1786628013296.pngSorinIBancila_1-1786628013296.pngSorinIBancila_1-1786628013296.pngSorinIBancila_1-1786628013296.png 2. 开放式嵌入式编码器字典(模型) SorinIBancila_2-1786628097732.pngSorinIBancila_2-1786628097732.pngSorinIBancila_2-1786628097732.pngSorinIBancila_2-1786628097732.png 3. 加载你之前创建的自定义类。 SorinIBancila_3-1786628212316.pngSorinIBancila_3-1786628212316.pngSorinIBancila_3-1786628212316.pngSorinIBancila_3-1786628212316.png 4. 在模型内部,创建一个新的子系统并将其设置为原子级。 SorinIBancila_6-1786628433580.pngSorinIBancila_6-1786628433580.pngSorinIBancila_6-1786628433580.pngSorinIBancila_6-1786628433580.png 5. 在代码生成中,设置执行函数的内存部分:“MemSection_ITCM”,如自定义类中设置的那样。 SorinIBancila_7-1786628826071.pngSorinIBancila_7-1786628826071.pngSorinIBancila_7-1786628826071.pngSorinIBancila_7-1786628826071.png 6. arm-none-eabi-objdump 正确报告 ITCM_ToggleDIO.o 已加载到 .itcm_text 中存储器部分 SorinIBancila_8-1786631977524.pngSorinIBancila_8-1786631977524.pngSorinIBancila_8-1786631977524.pngSorinIBancila_8-1786631977524.png arm-none-eabi-nm -n s32k3xx_dio_s32ct.elf 还指出,ITCM_ToggleDIO 位于 0x0 地址。 SorinIBancila_9-1786632086079.pngSorinIBancila_9-1786632086079.pngSorinIBancila_9-1786632086079.pngSorinIBancila_9-1786632086079.png 如果从 S32DS 烧录 .elf 文件,并在s32k3xx_dio_s32c_ITCM_ToggleDIO 函数内部使用断点,则在反汇编视图中我们可以看到指令是从 0x0 地址开始存储的。 SorinIBancila_0-1786632484317.pngSorinIBancila_0-1786632484317.pngSorinIBancila_0-1786632484317.pngSorinIBancila_0-1786632484317.png 此致, 索林·班奇拉 Re: Gcc ignoring pragma statements to place code into ITCM memory. 索林你好 谢谢你的帮助! 我当时确实是按照 Mathworks 网站上的说明操作的。 现在我已经实现了用属性语句代替编译指示语句插入数据的功能。 但是,gcc 仍然拒绝将该函数放入 .itcm_text 文件中。部分。 我使用以下代码块生成设置: RNJ_0-1786705067074.pngRNJ_0-1786705067074.pngRNJ_0-1786705067074.pngRNJ_0-1786705067074.png 为如下函数生成的代码: /* 将标准代码生成重定向到 ITCM */ __attribute__ ((section(".itcm_text"))) static void Motor_Drive_Subsystem(void) { .... } 结论: .o 文件中不存在 itcm_text 段。文件 Gcc 完全优化掉了这个函数(可以通过反汇编 .o 文件看到)。文件) 如果我移除生成的 .c 文件中函数的“static”声明手动重新编译后,我将得到 .itcm_text 文件。.o 段文件。 看起来“static”声明导致gcc编译器忽略了属性前缀。 如果我在 Modelsim 中将该代码块设置为“可重用函数”,希望这样可以移除静态声明: RNJ_1-1786705067131.pngRNJ_1-1786705067131.pngRNJ_1-1786705067131.pngRNJ_1-1786705067131.png 我得到: 仍然没有 .itcm_text.o 段文件 生成的 C 代码中,该函数仍然声明为“静态”函数。 .o 文件的反汇编文件显示 gcc 保留了汇编代码中的函数,但没有迹象表明它指向 .itcm_text 文件。部分 那么,问题是“static”声明(Simulink 或嵌入式编码器中的设置)还是 gcc 优先使用“static”声明而不是“attribute”声明? 顺祝商祺! Re: Gcc ignoring pragma statements to place code into ITCM memory. 你好, 我很高兴你解决了这个问题! 😄 此致, 索林·班奇拉 Re: Gcc ignoring pragma statements to place code into ITCM memory. 啊哈! 既然“static”声明是导致我问题的原因,我查看了配置参数中的代码生成部分,发现了以下内容: RNJ_0-1786969749323.pngRNJ_0-1786969749323.pngRNJ_0-1786969749323.png 取消勾选后问题就解决了! 没有静态声明函数,但我可以在映射文件中看到 itcm_text 段。如果你也认为这是最佳解决方案,我就满意了。 谢谢你的帮助,非常感谢! Re: Gcc ignoring pragma statements to place code into ITCM memory. 你好, 我尝试重现您遇到的问题,生成的函数不包含“static”关键字。 SorinIBancila_0-1786963037855.pngSorinIBancila_0-1786963037855.png 为了进行测试,我加载了一个基本示例(s32k3xx_dio_s32ct),并将所有模块移动到一个子系统中,将其配置为原子操作,并使用 MemSection_ITCM 定义。你能试着也这样做吗?如果这种情况没有重现,可能是你的模型中某些设置强制生成的函数是静态的。 此致, 索林·班奇拉
記事全体を表示
LAN96455F 以太网交换机与 i.MX95 集成 – 设备树指南 您好,NXP团队: 我们正在将Microchip LAN96455F以太网交换机(LAN9645x系列)集成到定制的i.MX95 19x19 LPDDR5板(基于imx95-19x19-evk.dts)上,我希望得到关于正确集成设备树的指导。 Re: LAN96455F Ethernet Switch Integration with i.MX95 – Device Tree Guidance 对于 Linux,如果您希望 Linux 单独公开/管理外部交换机端口,请将 LAN96455F 建模为DSA 以太网交换机。连接到交换机 CPU/上行链路端口的 i.MX95 ENETC/NETC 以太网 MAC 应该是 DSA通道接口;LAN96455F 端口成为 DSA 用户网络设备。DSA 专为具有连接到 SoC 以太网控制器的专用 CPU 端口的交换机而设计,它为每个前面板创建“用户”界面,而不是为 CPU 端口本身创建单独的网络设备。 一个好的设备树结构是: /* 将 &enetX / &mdioX 替换为实际使用的 i.MX95 BSP 标签 * 在 imx95-19x19-evk.dts / imx95.dtsi 中,选择您喜欢的 NETC ENETC 端口。 */ /* i.MX95 ENETC 端口连接到 LAN96455F CPU/上行链路端口 */ &netX { 状态 = "好的" /* 必须匹配 i.MX95 和 LAN96455F 之间的电气接口: * "rgmii-id", "rgmii", "sgmii", "2500base-x", 等。 */               phy-mode = "rgmii-id"; /* MAC 到交换机的 CPU 端口通常是无 PHY 的,因此请对其进行描述 *除非 LAN96455F CPU 端口实际处于固定链路状态,否则不会作为固定链路使用 * 通过 PHY/PCS 进行管理。 */ 固定链接 { 速度 = <1000> 全双工;               }; }; /* MDIO 控制器用于访问交换机管理接口。 * i.MX95 NETC 具有用于外部 PHY 的外部主 MDIO 接口, * 支持第 22 条和第 45 条 。 */ &mdioX { 状态 = "好的" 以太网交换机@0 { /* 使用 LAN9645x 驱动程序/绑定中的兼容字符串 * 已包含在您的内核/BSP 中。不要编造这个字符串。 */ 兼容 = "microchip, " reg = <0>; /* 板上绑定的 MDIO 地址 */ 端口 { #address-cells = <1> #size-cells = <0> port@0 { reg = <0> 标签 = "lan0" /* 如果此外部端口具有外部 PHY: * phy-handle = * phy-mode = "..." */ }; port@1 { reg = <1> 标签 = "lan1" }; port@2 { reg = <2> 标签 = "lan2" }; port@3 { reg = <3> 标签 = "lan3" }; /* LAN96455F CPU/上行链路端口号必须与 * Microchip 数据手册/驱动程序定义。 */                                            端口@N { reg = 标签 = "cpu" 以太网 = <&enetX>;                                                            phy-mode = "rgmii-id"                                                                 固定链接 { 速度 = <1000> 全双工; }; }; };               }; }; 最终确定DTS之前需要检查的关键点: 使用内核中的实际 LAN9645x 绑定。我无法从检索到的源中确认公共主线 LAN96455F 特定绑定,因此上面的兼容字符串故意用作占位符。检查 NXP 电路板支持包/Microchip 驱动程序树,路径为 Documentation/devicetree/bindings/net/dsa/ 或 Microchip LAN9645x 驱动程序源代码。 在交换机 CPU 端口上设置 ethernet = <&enetX>;,而不是在每个交换机端口上设置。DSA 端口绑定表示以太网属性是交换机端口所连接的主机以太网设备的句柄。 CPU/DSA 端口需要 phylink 风格的链路描述。对于以太网 = <&enetX>; 的 CPU 端口,绑定需要 phy-mode 和 fixed-link、phy-handle 或 managed 之一。 使用固定链路实现 MAC 地址到交换机 CPU 端口的直接连接。通用以太网绑定定义了具有速度、全双工和可选的暂停属性的固定链路;支持的固定链路速度包括对象形式的 10/100/1000/2500/5000/10000 Mbit/s。 使用RGMII延迟模式时要精确控制。phy-mode = "rgmii-id" 表示 PCB 不提供 RGMII 时钟/数据延迟,MAC/PHY 端必须提供内部延迟;plain "rgmii" 表示 PCB 布线提供延迟。对于大多数自定义电路板而言,“rgmii-id”是预期的起点,除非您的布局特意添加了延迟。 如果 MAC 连接到交换机 CPU 端口,则不要将 i.MX95 MAC 配置为具有普通外部 PHY 。在 DSA 模型中,MAC 是通道,外部用户端口由交换机端口节点表示。 预计会出现 lan0、lan1 等 Linux 接口。DSA为前面板端口创建用户网络设备,DSA 标签属性将成为网络设备名称。 出院检查: dmesg | grep -i -E "dsa|lan964|mdio|enetc|netc" IP链接 cat /sys/class/net/ /dsa/tagging 2>/dev/null ip 链路已设置 已启动 ip link set lan0 up ethtool lan0 如果没有 lanX 接口出现,请按以下顺序进行调试:MDIO 地址/strap 值、重置 GPIO 时序、如果驱动程序需要中断 GPIO、正确的 LAN9645x 兼容、正确的 CPU 端口寄存器以及 i.MX95 和交换机之间的正确 phy 模式/固定链路速度。 使用 i.MX95 ENETC 端口作为 DSA 通道,在 MDIO/SPI 管理总线下使用端口块描述 LAN96455F,并使交换机 CPU 端口指向 ENETC MAC,使用 ethernet = <&enetX> 加上有效的 phy-mode 和 fixed-link / managed / phy-handle。
記事全体を表示
NXP S32K312 CAN0 – FIRC vs. FXOSC クロックソースによる CAN エラーの発生 こんにちは、皆さん 私はS32K312でCAN0を使用し、500kbpsの速度で87.5%のサンプリングポイントを設定しています。 最初は、CAN0を内部のFIRC_CLKをクロックソースとして使用するように設定しました。S32K312を複数のCANノードがあるネットワークに接続したところ、多くのCANエラーフレームに気付きました。 その後、CANのクロックソースをFIRC_CLKから外部FXOSC_CLKに切り替え、CANのビットレートとサンプリングポイントは同じにしました。この変更後、通信は安定し、エラーフレームが表示されなくなりました。 なぜクロックソースをFIRC_CLKからFXOSC_CLKに切り替えるとCANエラーが直るのか、どなたか教えてもらえますか? Re: NXP S32K312 CAN0 – FIRC vs. FXOSC Clock Source Causing CAN Errors こんにちは、 @Karthik_R さん。 通常、FIRCクロックはFlexCAN通信には推奨されません。なぜなら、精度がCANプロトコル(ISO 11898-1)の~1%要件を超えているためです。S32K3のデータシートを見ると、FIRCの偏差は+-5%です。 FXOSCを使用するか、XOSCから実行されるPLLを使用することを推奨します。FlexCANビットタイミング計算のドキュメントや、MPC5xxx/S32Kxx/LPCxxxx: CAN / CAN FDビットタイミング計算ツールをご参照ください。 これで分かりやすくなったでしょうか。 よろしくお願いします、 ジュリアン
記事全体を表示
Gcc ignoring pragma statements to place code into ITCM memory. Hello! Using Matlab R2025b, Simulink and MBDT for S32K3 version 1.7.1 here. To optimize the performance of a motor controller application we are developing we want to place some parts of the code into the ITCM memory and later on, DTCM memory for data. As for now, for testing the workflow, I am trying to get a function placed into ITCM memory. I managed to get Simulink/ embedded coder to place the correct pragma statements in to the c code like: #pragma GCC section text ".itcm_text" static void  Motor_Drive_Subsystem(void) { .......... } #pragma GCC section text "" However, when compiling the application gcc ignore these pragma statements and places the code in the standard .text segment. This can be concluded with The objdump command: arm-none-eabi-objdump -h Motor_Control.o      (beeing the .o file generated from the c-file containing the Motor_Drive_Subsystem function) There are no .itcm_text in the list just .text.xxxx segments (among the other non text segments). When compiling I use the standard switches for gcc set by the MBDT environment: arm-none-eabi-gcc -O2 -c -std=c99 -fshort-enums -funsigned-char -fstack-usage -ffunction-sections -fdata-sections -g -pedantic -Wall -Wextra -fmessage-length=0 -funsigned-bitfields -fno-common -Wunused -Wstrict-prototypes -Wsign-compare -Werror=implicit-function-declaration -mcpu=cortex-m7 -mthumb -mlittle-endian -mfloat-abi=hard -mfpu=fpv5-sp-d16 -DD_CACHE_ENABLE -DI_CACHE_ENABLE -specs=nano.specs -specs=nosys.specs --sysroot="C:\MATLAB_Add-Ons\Toolboxes\NXP_MBDToolbox_S32K3\tools\build_tools\gcc_v10.2\gcc-10.2-arm32-eabi\arm-none-eabi\newlib" -DSTEP_GPT_TIMER -DSTEP_GPT_CHANNEL=GptConf_GptChannelConfiguration_StepTimer -DSTEP_GPT_CHANNEL_FREQ=40000000 -DSTEP_GPT_CHANNEL_VALUE_MAX=4294967295 -DAUTOSAR_OS_NOT_USED -D__MW_TARGET_USE_HARDWARE_RESOURCES_H__ -DGCC -DS32K3XX -DS32K396 -DCPU_S32K396 -DENABLE_FPU -DMPU_ENABLE -DMBDT_INIT -DCLASSIC_INTERFACE=0 -DALLOCATIONFCN=0 -DTERMFCN=0 -DONESTEPFCN=1 -DMAT_FILE=0 -DMULTI_INSTANCE_CODE=0 -DINTEGER_CODE=0 -DMT=0  -DTID01EQ=0 -DSTACK_SIZE=64 -DRT -DMODEL=Motor_Control -DNUMST=1 -DNCSTATES=0 -DHAVESTDIO -DMODEL_HAS_DYNAMICALLY_LOADED_SFCNS=0 -IC: ..... By modifying the generated c code file and manually compiling it I can conclude the following: Removing the “static” declaration of the function does not help. However, removing “static” and using the alternative way for this by adding an attribute statement on the function: static void  __attribute__((section(".itcm_text")))Motor_Drive_Subsystem(void); will create a .itcm_text segment in the .o file. I am not sure if I am doing something wrong here or if it is a tool problem. Can someone guide me on how to get this working? Of course, we want the tool chain to handle this and do not want to manually modify the c code after code generation. As far as I can see it looks like the startup_cm7.s and linker_flash_s32k396.ld files are prepared for handling the ITCM and DTCM memories. I found this post in the forum, not sure if it is relevant for this: https://community.nxp.com/t5/S32-Design-Studio/No-GCC-11-4-item-in-new-project-wizard-dialog-on-S32DS-3-6-2/td-p/2134523 The MBDT gcc seems to be build 1728 where as the fixed one in the post is build 1803. Thanks in advance! Re: Gcc ignoring pragma statements to place code into ITCM memory. Hello, Please check the following page on MathWorks website how to set up a custom storage class.: Control Data and Function Placement in Memory by Inserting Pragmas. The part that you need to use is "Override Default Memory Placement for Subsystem Functions and Data". SorinIBancila_0-1786627722302.pngSorinIBancila_0-1786627722302.pngSorinIBancila_0-1786627722302.pngSorinIBancila_0-1786627722302.png After you created you custom storage class, you must configure the model to load it:  0. Create and configure the custom storage class: SorinIBancila_5-1786628332348.pngSorinIBancila_5-1786628332348.pngSorinIBancila_5-1786628332348.pngSorinIBancila_5-1786628332348.png 1. Enter Code Perspective SorinIBancila_1-1786628013296.pngSorinIBancila_1-1786628013296.pngSorinIBancila_1-1786628013296.pngSorinIBancila_1-1786628013296.png 2. Open Embedded Coder DIctionary (Model) SorinIBancila_2-1786628097732.pngSorinIBancila_2-1786628097732.pngSorinIBancila_2-1786628097732.pngSorinIBancila_2-1786628097732.png 3. Load the custom class you previously created. SorinIBancila_3-1786628212316.pngSorinIBancila_3-1786628212316.pngSorinIBancila_3-1786628212316.pngSorinIBancila_3-1786628212316.png 4. Inside the model, create a new Subsystem and set it to atomic. SorinIBancila_6-1786628433580.pngSorinIBancila_6-1786628433580.pngSorinIBancila_6-1786628433580.pngSorinIBancila_6-1786628433580.png 5.  Inside the Code Generation, set the Memory section for execution functions: "MemSection_ITCM" as set in the custom class. SorinIBancila_7-1786628826071.pngSorinIBancila_7-1786628826071.pngSorinIBancila_7-1786628826071.pngSorinIBancila_7-1786628826071.png 6.  arm-none-eabi-objdump properly repots that ITCM_ToggleDIO.o is loaded into the .itcm_text memory section SorinIBancila_8-1786631977524.pngSorinIBancila_8-1786631977524.pngSorinIBancila_8-1786631977524.pngSorinIBancila_8-1786631977524.png arm-none-eabi-nm -n s32k3xx_dio_s32ct.elf also says that ITCM_ToggleDIO is found at  0x0 address. SorinIBancila_9-1786632086079.pngSorinIBancila_9-1786632086079.pngSorinIBancila_9-1786632086079.pngSorinIBancila_9-1786632086079.png If the .elf is flashed from the S32DS and a breakpoint is used inside the s32k3xx_dio_s32c_ITCM_ToggleDIO function., in the disassembly view we can see that the instructions are stored starting at 0x0 address. SorinIBancila_0-1786632484317.pngSorinIBancila_0-1786632484317.pngSorinIBancila_0-1786632484317.pngSorinIBancila_0-1786632484317.png Best regards, Sorin Bancila Re: Gcc ignoring pragma statements to place code into ITCM memory. Hi Sorin Thanks for helping out! I was actually following those instructions at Mathworks web site. Now I have the insertion of attribute statements instead of pragma statements working. But still, gcc refuses to put the function into the .itcm_text segment. I use these code generation settings for the block: RNJ_0-1786705067074.pngRNJ_0-1786705067074.pngRNJ_0-1786705067074.pngRNJ_0-1786705067074.png Generated code for function like this: /* Redirect standard code generation to ITCM */ __attribute__((section(".itcm_text")))   static void Motor_Drive_Subsystem(void)   { .... } Conclusion: No itcm_text segment in .o file Gcc optimizes the function away completely (seen by disassembling .o file) If I remove the “static” declaration of the function in the generated .c and manually recompile it I will get the .itcm_text segment in the .o file. It looks like the “static” declaration makes the gcc compiler ignore the attribute prefix. If I set the block to “Reusable function” in modelsim, hoping this would remove the static declaration: RNJ_1-1786705067131.pngRNJ_1-1786705067131.pngRNJ_1-1786705067131.pngRNJ_1-1786705067131.png I get: Still no .itcm_text segment in .o file Function still declared as “static” in generated c code Disassembly of .o file shows that gcc keeps the function in the assembly code but there is no sign of directing to .itcm_text segment So is the “static” declaration the problem (something with settings in Simulink or embedded coder) or is the problem with gcc prioritizing “static” over the “attribute” declaration? Best regards Re: Gcc ignoring pragma statements to place code into ITCM memory. Hello, I tried to reproduce the problem you encounter, the function generated do not include the 'static' keyword. SorinIBancila_0-1786963037855.pngSorinIBancila_0-1786963037855.pngSorinIBancila_0-1786963037855.pngSorinIBancila_0-1786963037855.png What I did to test was to load a basic example (s32k3xx_dio_s32ct) and move all the blocks in a subsystem and configure it to be atomic and to use the MemSection_ITCM definitions. Can you try to do the same? If it doesn't reproduce in this scenario, maybe there are some setting in your model that force the generated function to be static. Best regards, Sorin Bancila Re: Gcc ignoring pragma statements to place code into ITCM memory. Hello, I am glad that you were able to solve the problem! 😄 Best regards, Sorin Bancila Re: Gcc ignoring pragma statements to place code into ITCM memory. Aha! Nowing that the "static" declaration is reason for my problems I had a look at the code generation section in configuration parameters and found this: RNJ_0-1786969749323.pngRNJ_0-1786969749323.png Unticking it solved the problem! No static declaration of the function(s) and I can see the itcm_text segment in the mapping file. I you also think this is the solution I am sattisfied. Thanks for the help, much appreciated!
記事全体を表示