Multi Source Translation Content

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

Multi Source Translation Content

Discussions

Sort by:
S32K3XXアプリケーションについて sunshine88_0-1787046454804.pngsunshine88_0-1787046454804.png S32K358 RTDライブラリに`Cache_Ip_init()`関数がないのはなぜでしょうか?初期化関数がない場合、システムはどのようにキャッシュを初期化するのでしょうか?システムは自動的にキャッシュ初期化プロセスを開始するのでしょうか? Re: About S32K3XX APPLICATION こんにちは、 S32K358 RTDライブラリに`Cache_Ip_init()`関数がないのはなぜか教えていただきたいです。初期化関数がない場合、システムはどのようにキャッシュを初期化するのでしょうか?システムはキャッシュの初期化プロセスを自動的に開始しますか? S32K358 RTDは、最近のRTDリリースでは専用のCache_Ip_Init() APIを提供していません。キャッシュのイネーブルメントは、デバイス起動時にプラットフォーム/システムの初期化コードを通じて処理されます。キャッシュが有効化されると、Cortex-M7ハードウェアは自動的にキャッシュの割り当て、無効化、行の置き換えを管理します。したがって、明示的なアプリケーションレベルのキャッシュ初期化関数は必要ありません。 よろしくお願いいたします。 ピーター
View full article
S32K344 OTA Active Region 1. S32K3_HSE_DemoExamples_1_0_0\S32K3_HSE_DemoExamples\Template\S32K344_DemoAppTemplate\drivers\dcm_register\hse_dcm_register.c xionggang_0-1787021979735.pngxionggang_0-1787021979735.png 2. AN13465_S32K3xx Secure Boot.pdf xionggang_1-1787021998225.pngxionggang_1-1787021998225.png The description of the "Active Region" is inconsistent between the documentation and the code. Who is correct? Re: S32K344 OTA Active Region Hi It appears that Dcm_ActiveAddressOTARegion() has reversed the mapping from DCMOTAR=0/1 to the low/high value. We've discussed DCMSTAT[DCMOTAR] before: https://community.nxp.com/t5/S32K/s32k312/td-p/1697583 Best Regards, Robin
View full article
About S32K3XX Application sunshine88_0-1787046454804.pngsunshine88_0-1787046454804.png I'd like to ask why there's no `Cache_Ip_init()` function in the S32K358 RTD library. If there's no initialization function, how does the system initialize the cache? Does the system automatically start the cache initialization process? Re: About S32K3XX APPLICATION Hello, I'd like to ask why there's no `Cache_Ip_init()` function in the S32K358 RTD library. If there's no initialization function, how does the system initialize the cache? Does the system automatically start the cache initialization process? The S32K358 RTD does not provide a dedicated Cache_Ip_Init() API in recent RTD releases. Cache enablement is handled during device startup through platform/system initialization code. After the cache is enabled, the Cortex-M7 hardware automatically manages cache allocation, invalidation, and line replacement. Therefore, no explicit application-level cache initialization function is required. Best regards, Peter
View full article
S32K344 OTAアクティブ領域 1. S32K3_HSE_DemoExamples_1_0_0\S32K3_HSE_DemoExamples\テンプレート\S32K344_DemoAppTemplate\ドライバ\dcm_register\hse_dcm_register.c xionggang_0-1787021979735.pngxionggang_0-1787021979735.png 2. AN13465_S32K3xx セキュアブート.pdf xionggang_1-1787021998225.pngxionggang_1-1787021998225.png 「アクティブ領域」の説明はドキュメントとコードで一貫していません。どちらが正しいのか? Re: S32K344 OTA Active Region ハイ Dcm_ActiveAddressOTARegion () は、 DCMOTAR =0/1 から低値/高値へのマッピングを反転させたようです。 DCMSTAT [ DCMOTAR ] については以前にも議論しました。https: //community.nxp.com/t5/S32K/s32k312/td-p/1697583 よろしくお願いいたします ロビン
View full article
About S32K3XX APPLICATION sunshine88_0-1787046454804.pngsunshine88_0-1787046454804.png 想咨询一下,为什么在S32K358 RTD库函数中,没有Cache_Ip_init()函数,如果没有初始化函数,系统又是怎样初始的哪?系统自启动Cache初始化过程吗? Re: About S32K3XX APPLICATION 你好, 我想请问为什么 S32K358 RTD 库中没有 `Cache_Ip_init()` 函数。如果没有初始化函数,系统如何初始化缓存?系统是否会自动启动缓存初始化过程? 在最近的 RTD 版本中,S32K358 RTD 没有提供专用的 Cache_Ip_Init() API。缓存启用是在设备启动期间通过平台/系统初始化代码处理的。启用缓存后,Cortex-M7 硬件会自动管理缓存分配、失效和行替换。因此,不需要显式的应用层缓存初始化函数。 顺祝商祺! Peter
View full article
S32K344 OTA 活动区 1. S32K3_HSE_DemoExamples_1_0_0\S32K3_HSE_DemoExamples\Template\S32K344_DemoAppTemplate\drivers\dcm_register\hse_dcm_register.c xionggang_0-1787021979735.png雄钢_0-1787021979735.png 2. AN13465_S32K3xx 安全启动.pdf xionggang_1-1787021998225.pngxionggang_1-1787021998225.png 文档和代码中对“活动区域”的描述不一致。谁的说法正确? Re: S32K344 OTA Active Region HI Dcm_ActiveAddressOTAREgion () 似乎已经将DCMOTAR =0/1 到低/高值的映射反转了。 我们之前讨论过DCMSTAT [ DCMOTAR ]: https://community.nxp.com/t5/S32K/s32k312/td-p/1697583 此致敬礼, Robin
View full article
S32K3 MBDT SENTの実装について? S32K3上のSENTプロトコルのモデルベースの実装作成は進展していますか? この投稿(解決済み:S32K3 MBDTにおけるSENTプロトコルサポートに関するもの - NXPコミュニティ)を見ましたが、数年前のものです。それ以降、何か進展はありましたか?
View full article
S32K3 MBDT SENT implementation? Has there been any progress on creating a model based implementation for the SENT protocol on the S32K3? I saw this post (Solved: Re: SENT Protocol Support in S32K3 MBDT - NXP Community) but it is a few years old. Has anything been developed since then?
View full article
S32K3 MBDT SENT 实现? 在 S32K3 上为 SENT 协议创建基于模型的实现方面,是否有任何进展? 我看到了这篇帖子(已解决:回复:S32K3 MBDT 中的 SENT 协议支持 - NXP 社区),但它已经是几年前的帖子了。此后是否有任何进展?
View full article
lwip_FreeRTOS_s32k396 example project for MCSPTR2AK396 Development Kit Hello! I am working with the 3-Phase Permanent Magnet Synchronous Motor Control Development Kit with S32K396 MCSPTR2AK396. To test the base firmware, I installed the following stack: S32DS_3.6.5_RFP_win32 S32K3_ETPU_SW_4.9_2.0.1_D2512 SW32K3_S32M27x_RTD_R23-11_7.0.0_QLP03_D2512 SW32K3_FreeMASTER_Driver_1.5.0_D2512 S32K3xx_AMMCLIB_RTM_1_1_45_BIN MCSPTR2AK396_SW GCC version 10.2 After several unsuccessful attempts to synchronize all software versions, it finally worked, and the base firmware started functioning. However, I wanted to test the Ethernet communication functionality next, and that’s where I encountered unresolved issues at the moment. I additionally installed: SW32K3_FreeRTOS_11.1.0_0.8.0_CD1_D2603 SW32K3_TCPIP_STACK_4.0.0_D2512 And I took the test project lwip_FreeRTOS_s32k396, but it never compiled without errors; there were always conflicts in descriptions and other issues. I tried using the latest version of SW32K3_TCPIP_STACK_5.0.0_CD01_D2605, and I had to apply a file replacement during the update code process. In the end, the firmware compiled with warnings but no errors. After that, I moved on to testing. I set up the system as follows: personal computer -> GeekStore 100BT1-PRO2 Automotive Converter (http://pinzhi-tech.com.cn/en/home_eng/product_list_100base-t1_eng/100bt1-pro2_eng/) -> MCSPTR2AK396. I aligned the IP addresses of the Ethernet connection on the computer and the one specified in the firmware so they would be in the same subnet. However, attempting to ping the motor's assigned IP from the computer was unsuccessful, although it seems the network polling is ongoing, as indicated by the converter. What could be the issue? Could it be that I shouldn’t have used the latest version of TCPIP_STACK? Are there possible issues with the board itself? On the controller board stickers, revisions B1 and B are indicated. Is it possible to obtain additional documentation specifically for these revisions (on the website, I only saw documentation for revision A)? I would appreciate any advice or clarifying questions. Re: lwip_FreeRTOS_s32k396 example project for MCSPTR2AK396 Development Kit Hello @Anna_Anna, Firstly, I am not sure what errors were present with TCPIP v4.0.0, since it is also compatible with RTD 7.0.0 & FreeRTOS 7.0.0 CD01 packages, however, latest TCPIP stack (v5.0.0) is OK. Can you share what was the file modification? I was able to import, generate and compile the project without problem. My environment: S32DS v3.6.0, RTD v7.0.1, FreeRTOS v7.0.0 CD 01 and TCPIP Stack version 5.0.0 CD 01. It seems that MCSPTR2AK396 has a design oversight. EMAC_MII_RMII_RX_DV (PTD14) is not connected to RX_CTL - CONFIG6: MCSPTR2AK396 EVB ethernet connectivity, CRS_DV signal clarification. That said, is the task and OS is running?  xTickCount — this should be incrementing continuously if the RTOS tick interrupt is active. xSchedulerRunning — this should be set to 1 if the scheduler is running. Best regards, Julián    Re: lwip_FreeRTOS_s32k396 example project for MCSPTR2AK396 Development Kit Hello  Regarding the design files, I can see that the HW Design Package for MCSPTR2AK396 includes revision B2: Julin_AragnM_3-1786576291659.pngJulin_AragnM_3-1786576291659.png Best regards, Julián Re: lwip_FreeRTOS_s32k396 example project for MCSPTR2AK396 Development Kit Hello @Anna_Anna, Yes, the fsdata.c and EthIf.c in previous release was reported and fixed; EthIf.c file from RTD is just a stub. We provide our own minimal implementation for EthIf, so the file from RTD can be safely excluded from the project. Secondly, yes, from your description, it seems that the example works properly. The connection is needed and should be done as mentioned (routing/soldering CRS_DV to PTD14).  Best regards, Julián Re: lwip_FreeRTOS_s32k396 example project for MCSPTR2AK396 Development Kit Hello @Julián_AragónM! The issue with building the test project using TCPIP v4.0.0 was resolved by excluding two files, fsdata.c and EthIf.c, from the build. This conflict seems to have been automatically resolved in version 5.0.0. I also checked the values of the variables xSchedulerRunning and xTickCount through the Expressions window in the S32DS debugger. xSchedulerRunning indeed takes the value 1, and the second one increases sequentially (1, 5001, 10001...), leading me to conclude that FreeRTOS is functioning correctly on the board, and the problem is not in the software. If I understand correctly, the only remaining cause is a hardware issue—the absence of a connection between CRS_DV (CONFIG6) on the TJA1103A and pin PTD14? To resolve this, do I need to solder these two contacts together? Please confirm. Best regards, Anna  Re: lwip_FreeRTOS_s32k396 example project for MCSPTR2AK396 Development Kit Thanks, I'll try this approach a little later and report back on the results. Re: lwip_FreeRTOS_s32k396 example project for MCSPTR2AK396 Development Kit Hello. After I soldered pin 41 (PTD 14) of the MCU and pin 25 (RX_CTL/CONFIG6) of the TJA1103A, the ping really started working. Thanks!
View full article
Eフラッシュ書き込み中のLIN通信障害 LIN通信の障害は、内部EEPROMへの100バイトの書き込み操作中に検出されます。適切なLIN通信回復方法を提案してください。 Re: LIN communication failure during E-Flash write こんにちは、 @SivaB さん。 どのS32Kデバイスを使っているのか教えていただけますか? 一つの説明としては、エミュレーテッドEEPROMの操作には比較的長い時間がかかり、その結果の遅延がソフトウェアが必要なタイミング制約内でLIN割り込みを処理できない可能性があることです。もう一つの可能性として、読み取り同時書き込み競合が考えられます。フラッシュ消去やプログラム操作中、現在プログラムまたは消去中のフラッシュブロック内のコードやデータは取得・読み取れません。もしアプリケーションがそのようなコードやデータを必要とする場合、アプリケーションがクラッシュし、結果的に観察されたLIN通信障害を引き起こす可能性があります。 また、問題が発生した場合に何が起こるのかも説明してもらえますか?アプリケーションは完全にクラッシュするのか、それとも動作を続けてLIN通信だけが機能しなくなるのか? よろしくお願いいたします。 ルーカス Re: LIN communication failure during E-Flash write S32K144:アプリケーションは期待通りに動作しています。しかし、LIN通信が失敗し、その失敗が起こるとLIN通信は復元できません。 EEPROMへの書き込み/保存時間は約175ミリ秒です。
View full article
当另一个端口失去连接时,端口上的 T1040 mEMAC TX_FIFO_OVFL 会发出警报。 我正在调试 T1040 上的以太网问题,该交换机使用 1G mEMAC RGMII 接口。当另一个端口失去物理连接(例如,电缆断开)时,我发现以太网端口上出现丢包现象。当两个端口都以高数据速率运行时,这种情况似乎最常发生。 当出现问题时,我看到正常端口的中断事件寄存器(`IEVENT`)中设置了`TX_FIFO_OVFL`位。 我目前的解释是,当一个正在发送数据的 mEMAC 失去物理链路时,FMan/mEMAC 发送路径中的某些东西会暂时阻止另一个 mEMAC 足够快地耗尽其 TX FIFO。正常端口最终会报告 `IEVENT[TX_FIFO_OVFL]`,导致帧丢失。然而,我尚未确定导致这种行为的共享资源或机制。 我的问题是: * 这是已知的 T1040 / FMan v3 / mEMAC 芯片问题还是勘误? * 1G mEMAC 端口之间是否存在共享资源,导致一个端口在传输时出现载波丢失,从而暂时影响另一个端口的 TX FIFO? * 当 PHY 失去链路时,是否有必要的顺序,例如停止 QMI 出队、禁用 BMI TX 端口、禁用 mEMAC TX/RX 或重置 mEMAC? * 是否有任何 mEMAC 或 FMan 状态寄存器可以在溢出发生之前检测到导致 `TX_FIFO_OVFL` 的情况? * 是否有建议的 FMan/mEMAC 或 PHY 配置更改可以防止在这种情况下出现 `TX_FIFO_OVFL`? 谢谢! Re: T1040 mEMAC TX_FIFO_OVFL on port when another port loses link 你好, 目前尚无公开记录的 T1040/FMan v3 硅勘误表,专门描述由对等端口链路丢失触发的健康端口上的 TX_FIFO_OVFL 。T1040 芯片勘误表文档受 NDA 控制,未公开索引,但尚未发现 T1040 mEMAC 存在此类跨端口 TX FIFO 溢出勘误。 您观察到的行为很可能是共享的 FMan BMI 资源中的架构交互,而不是芯片缺陷。   此致 Re: T1040 mEMAC TX_FIFO_OVFL on port when another port loses link 您好, 四个共享的 BMI 资源是 TNUM(任务)、DMA 通道、FIFO(MURAM)和流水线深度。由于您的 FIFO 大小、流水线深度 ( DPDE ) 和 FIFO 低阈值 ( FLCL ) 的更改没有产生任何改进,因此 DMA 通道层很可能是瓶颈,而不是 MURAM 分配。 T1040 FMan 具有固定的 DMA 通道池,该通道池在所有活动的 TX 端口之间共享。每个端口的发送路径为: CPU → QMI dequeue → BMI opens DMA read (DDR → MURAM) → TX FIFO → mEMAC → wire     当您的停滞端口失去链路并且您清除 COMMAND_CONFIG[TX_EN] 时,mEMAC 会停止向线路发送数据,但任何已在流水线中间的帧(特别是 BMI TX 端口已发出 DMA 读取事务 (DDR → MURAM TX FIFO) 的帧)不会立即完成。DMA 读取可能已经将数据移入 TX FIFO,而 FMan DMA 引擎现在正在等待“DMA 完成/EBD(外部缓冲区描述符)释放”确认,这取决于正在使用 FIFO 的 MAC。当 TX_EN=0 ,MAC 不进行消费,因此 DMA 事务保持打开状态。 停滞端口上的那些未关闭的 DMA 事务占用共享的 DMA 通道槽位。在高负载下,健康端口的 BMI TX 路径无法获得足够的 DMA 通道槽位来从 DDR 快速获取数据,从而无法保持其 TX FIFO 的供应 → TX FIFO 短暂为空 → 然后回填速度比 MAC 的耗尽速度更快 → TX_FIFO_OVFL 。 此致 Re: T1040 mEMAC TX_FIFO_OVFL on port when another port loses link 谢谢。您能否确定是哪种共享的 BMI 资源或仲裁机制导致了这种行为? 我测试了FMBM_PFS[IFSZ]、FMBM_TFP[DPDE]和FMBM_TFP[FLCL]的更改,但没有看到有意义的变化。当 IF_STATUS[RGLINK] 变为低电平时,我也会立即停止入队并禁用 mEMAC TX,但健康的端口仍然可能会丢包。 是否有已记录或推荐的配置方法可以将端口与这种交互隔离?此外,是否有计数器、状态寄存器或调试机制可以显示哪个 BMI 资源正在耗尽、阻塞或以其他方式阻止健康的 mEMAC 清空其 TX FIFO? Re: T1040 mEMAC TX_FIFO_OVFL on port when another port loses link 谢谢你的解释。我检查了 1G TX 端口的 FMBM_PP 配置。它们均配置为默认值: MXT = 3:最多 4 个并发任务 MXD = 2:最多 3 个未完成的 DMA 请求 我还尝试调整了每个端口的资源限制。我调整了DMA请求和并发任务数的设置。这并没有对 TX FIFO 溢出产生明显的改善。 鉴于默认配置下 1G TX 端口只能有 3 个未完成的 DMA 请求,我不确定一个停滞的 1G 端口如何能消耗足够的共享 DMA 资源,从而对另一个端口产生重大影响。 是否存在一个与 84 项 FMan v3 DMA 命令队列分开的较小的共享 DMA 通道/资源池?或者少量停滞的 DMA 事务是否会导致队头阻塞,或者阻止其他端口的 DMA 事务继续进行? 另外,是否有 DMA 状态/调试寄存器或计数器可以用来确认链路断开端口的未完成 DMA 事务在此情况下是否仍然保持打开状态?
View full article
R45 MIPICSI2 BUFFOVF 错误 亲爱的, 我们使用 R45 MIPI 从其他芯片 MIPI 接收数据,但现在 R45 在接收数据一段时间后会报告缓冲区错误。MIPI 发送速率为 600M,R45 接收速率也为 600M。 R45 参考手册对 buffovf 错误描述如下:   evalin_1-1729739919559.pngevalin_1-1729739919559.png R45 CSI2 在什么情况下会报告此错误?谢谢。 Re: R45 MIPICSI2 BUFFOVF ERR 嗨,Peter @petervlna 现在我们团队使用的是 NXP S32R45 S32R45 ,我们也遇到了同样的错误。我们将 ADC 数据传输到 R45 CSI2 接口(发送方是另一个芯片)。有时,0x80000错误代码会持续存在。ADC 数据从 MIPI 传输到 SRAM,然后保存到 DDR 内存。ADC 数据捕获始终在后台运行(12ms 捕获 2MB 数据),同时 SPT 处理也在前台进行,中间数据保存到 您有什么建议吗? 谢谢您! Re: R45 MIPICSI2 BUFFOVF ERR 你好, 当内部缓冲已满时,需手动输入。 请务必在数据满溢之前清空/转移数据。 可能是您的DMA或核心触发信号的数据传输速度太慢。 顺祝商祺! Peter
View full article
AFT05MP075GNR1 您好,我想了解AFT05MP075N的测试电路。我尝试在QucsStudio中复现这个问题,但是失败了。 ag_martinez_0-1786897992439.pngag_martinez_0-1786897992439.pngag_martinez_0-1786897992439.png ag_martinez_1-1786898112546.pngag_martinez_1-1786898112546.pngag_martinez_1-1786898112546.png 我还想用它做一个带宽为 200MHz 的滤波器。我如何根据我的需求改造电路。 Re: AFT05MP075GNR1 你好 ag_martinez 再会! 很遗憾,我没有使用过你正在使用的模拟器,所以无法进行全面比较,但就我所见,我可以告诉你以下几点: 在 ADS/AWR 中,原始布局包括: T型不连续点, 斜接弯头, 开放式效果, 耦合效应。 此外,我了解到 AWR 仿真“考虑”了封装中可能存在的寄生效应。 您的原理图图像质量有点模糊,我无法正确看到所有元器件,但简而言之,AWR 考虑了元器件中可能出现的更多效应,这使得在其他仿真器中手动创建精确表示变得更加困难(我不建议这样做)。 由此造成的不便,我们深表歉意。 希望这些信息对您有所帮助,如果您还需要其他帮助,请告诉我。 祝你今天过得愉快,一切顺利。 Re: AFT05MP075GNR1 谢谢。您建议使用数据手册中给出的电路,还是您有针对特定应用的定制电路方案?如果真是这样,那具体策略是什么? 很难获得精确的PCB图,而且我认为我无法获得数据手册中的介电常数,所以我不得不重新计算所有的传输线。有什么建议吗?
View full article
PB16でFlashの保護を解除する みなさん、こんにちは! このフラッシュのこの部分のRAMにあるMC9S08PB16の最初のセクター(0xC000から0xDFF)を、PB16リファレンスマニュアル第10章に記載されているフラッシュコマンドを使ってセーブする方法を見つけたいです。どなたか助けていただけるといいのですが。 よろしくお願いいたします! Re: Unprotecting Flash in PB16 こんにちは、 メモリセクターを保護するために使っているコマンドやプロセスについて説明してもらえますか? 第10.3.5.2章のコマンドのことでしょうか?表10-4、または第10.3.9.1章のFlashコマンド、表10-10? フラッシュメモリ内の領域を保護するために、FPROTレジスタを設定しましたか? 第10.3.8.2章では、フラッシュメモリを消去してMCUの安全を解除する方法を説明してください。もしそれがセクターの安全解除に役立つなら。 敬具、ルイス
View full article
S32K3 FS26 new WDG period not work Hello, On my board, after power‑on reset, I configure the FS26 watchdog period to INFINITE during initialization. Then I exit DEBUG mode and enter NORMAL mode (the value read from SBC_FS26_FS_STATES_ADDR is 0xB). After that, I change the watchdog period to 64 ms (as shown in the screenshot), perform one watchdog refresh (feed), and the return value indicates success. WD_RFR_CNT increases by 1, and reading SBC_FS26_FS_WDW_DURATION_ADDR gives 0xB0CD, confirming that the period has been successfully updated to 64 ms. However, if I stop feeding the watchdog after this point, no error or reset occurs. In contrast, if I configure the watchdog period to 64 ms during initialization , then after exiting DEBUG mode, not feeding the watchdog does cause a reset as expected. Why does the watchdog not take effect when the period is changed from INFINITE to 64 ms in NORMAL mode, even though the register write and the refresh both succeed? Jason22_0-1785918605528.pngJason22_0-1785918605528.pngJason22_0-1785918605528.pngJason22_0-1785918605528.png S32K344 RTD7.0.0 FS26 6.0.0 S32DS3.6.4 EB30.0 BR, Jason Re: S32K3 FS26 new WDG period not work Hello, Oh! I forgot to switch accounts when replying – Jason07 is my another account. BR, Jason Re: S32K3 FS26 new WDG period not work Hello, Thank you very much for your reply. The reason I set the watchdog period to INFINITE during initialization is that, according to the driver code, certain operations are only performed when the period is INFINITE – for example, closing INIT_FS during the execution of the Sbc_fs26_InitDevice() function, and calling Sbc_fs26_WdRefresh inside Sbc_fs26_ClearFaultErrorCounter to clear the fault error counter. Jason07_1-1785986004068.pngJason07_1-1785986004068.pngJason07_1-1785986004068.pngJason07_1-1785986004068.png Jason07_2-1785986074130.pngJason07_2-1785986074130.pngJason07_2-1785986074130.pngJason07_2-1785986074130.png If I set the period to a finite value,  Sbc_fs26_WaitFailsafeRelease return E_NOT_OK inside Sbc_fs26_FsxbRelease, and the FS26 stays in the FS_STATES_FS0B_ASSERT state, unable to transition to FS_STATES_NORMAL_FS. Jason07_0-1785985959468.pngJason07_0-1785985959468.pngJason07_0-1785985959468.pngJason07_0-1785985959468.png BR, Jason Re: S32K3 FS26 new WDG period not work Hello, The watchdog does not become active because it was disabled when INIT_FS was closed. Configuring WDW_PERIOD[3:0] = 0000 selects the Infinite Open Window. According to the FS26 watchdog specification, the watchdog window can be disabled only during the initialization phase, and the disabling becomes effective when the initialization phase is closed. A watchdog disabled in this way cannot subsequently be enabled in NORMAL mode by writing a finite value to FS_WDW_DURATION. The successful register readback confirms that the new WDW_PERIOD field was written, and the incremented WD_RFR_CNT confirms that the refresh was accepted. These observations do not indicate that watchdog timeout monitoring was re-enabled. Runtime period changes are supported when the watchdog was enabled with a finite period during initialization. Therefore, configure a finite watchdog period during INIT_FS, for example the maximum finite period of 1024 ms if a long initialization interval is required. After entering NORMAL mode, the period can be changed to 64 ms. The new finite period becomes effective after the next watchdog refresh. This behavior also explains why the reset occurs when 64 ms is configured during initialization: in that case, the watchdog is enabled when INIT_FS closes. petervlna_0-1785930476258.pngpetervlna_0-1785930476258.pngpetervlna_0-1785930476258.pngpetervlna_0-1785930476258.png From safety perspective, infinite state is reached by watchdog disable, as the compare is in HW and flag will always rise on match. Best regards, Peter Re: S32K3 FS26 new WDG period not work Hello, Based on the observed behavior, the FS26 watchdog monitoring does not appear to start after changing WDW_PERIOD from Infinite Open Window to 64 ms in NORMAL_FS. The register write is successful, as confirmed by the readback value (0xB0CD), and watchdog refresh commands continue to be accepted, as indicated by WD_RFR_CNT incrementing. However, the absence of any watchdog timeout reaction after refreshes are stopped indicates that watchdog supervision itself is not active. When the watchdog period is configured as Infinite Open Window, Sbc_fs26_NormalFSSequence() closes INIT_FS by issuing an immediate watchdog refresh. Likewise, Sbc_fs26_ClearFaultErrorCounter() clears the fault error counter using consecutive watchdog refreshes because there is no watchdog window timing restriction in Infinite mode. When a finite watchdog period is configured, the driver follows a different path. Watchdog refreshes must be synchronized with the valid watchdog window, and the driver uses the watchdog timing mechanism (pfWdgNotification, timer synchronization, and Sbc_fs26_TimeWaitClearFault()) instead of issuing consecutive immediate refreshes. petervlna_0-1786002507583.pngpetervlna_0-1786002507583.pngpetervlna_0-1786002507583.pngpetervlna_0-1786002507583.png Re: S32K3 FS26 new WDG period not work Hello @Jason22  Did you manage to solve this problem? Did you succeed to push FS26 out of FS0B_ASSERT state to NORMAL_FS state after the call of Sbc_fs26_InitDevice ? Thank you. Re: S32K3 FS26 new WDG period not work Thank you for your answer. Re: S32K3 FS26 new WDG period not work Hello@Djuric Normal mode can be entered only when the watchdog period is initialized to infinity. If the initial value of the watchdog period is finite, the normal mode cannot be entered.
View full article
QorIQ T1022 DDR Validation Suite Passes with Good Margin, but Memory Corruption Seen in Application Hello, We are working with a QorIQ T1022 design and have completed DDR bring-up and validation using the NXP DDR Validation Suite. The results are encouraging: All DDR validation tests pass successfully. We have achieved good timing margins across the tested conditions. No errors are reported by the validation suite during stress testing. However, when we load and run our main application, we begin to observe what appear to be memory-related issues/corruption. These issues are not reproducible using the DDR validation tests alone. This has raised the question of whether there are additional mechanisms or test methodologies we should be using to detect issues that may only appear under real application workloads. We are interested in understanding: What types of DDR or memory subsystem issues can escape the standard DDR Validation Suite tests on the T1022? Are there known application-level scenarios that can expose problems not detected during DDR training and validation? Are there additional stress tests, performance monitors, error counters, or debugging techniques available on the T1022 that could help identify the root cause? Has anyone encountered a situation where DDR validation showed excellent margins, yet memory corruption or instability was later observed in a production application? Any guidance on additional diagnostics, hardware checks, or software debugging approaches would be greatly appreciated. Thank you. QorIQ T1 Devices Re: QorIQ T1022 DDR Validation Suite Passes with Good Margin, but Memory Corruption Seen in Applicat Hello, The QCVS DDRv tool tests DDR timing margins (write leveling, read/write centering, clock adjustment) using sequential, deterministic access patterns from a single core via JTAG. It does not exercise: Multi-master / multi-core concurrent access — The T1022 has two e5500 cores plus the DPAA (Data Path Acceleration Architecture) with frame managers, queue managers, and DMA engines all competing for the DDR bus simultaneously. Contention-induced timing violations only appear under real traffic. Cache coherency stress — Application workloads involving cache flushes, invalidations, and coherent DMA transfers create access patterns the validation suite never generates. Thermal and power-supply variation — DDR margins measured at room temperature under light load can degrade significantly when the SoC is at full utilization and the AVDD_DDR supply droops under load. DQ mapping errors — If the DQ_MAPn registers are incorrect, the controller may still pass validation (which uses known training patterns) but corrupt data under real application traffic. This is a documented T1022-specific issue. Marginal single-bit ECC errors — The validation suite may not accumulate enough transactions to trigger SBE threshold reporting, while a real application running for hours will accumulate them silently. DQ Mapping Misconfiguration The DQ_MAPn registers provide the mapping of DRAM DQ signals to the controller. If these are wrong, the controller cannot correctly interpret training patterns, and data corruption occurs under real workloads. NXP has confirmed this on T1022 designs: clearing all DQn_MAP registers (setting to 0 for 1:1 mapping) is a recommended diagnostic step. Memory Ordering / Pipeline Effects (PowerPC e5500) The e5500 core has well-documented memory ordering subtleties. Writes may not be fully committed to DDR before subsequent reads, especially without explicit msync/isync barriers. NXP's apps team has confirmed: "The write may not be fully committed to memory before the error injection is disabled. The subsequent read may hit a cache or pipeline, not triggering the ECC logic immediately."In application code, missing barriers around DMA setup or shared-memory structures can cause apparent corruption that is actually a coherency ordering issue. ECC Single-Bit Error Accumulation The T1022 DDR controller supports ECC. Single-bit errors (SBEs) are silently corrected by the hardware but counted in ERR_SBE[SBEC]. If the SBE counter crosses the threshold ERR_SBE[SBET], a critical interrupt is generated. Under light validation traffic, this threshold is never reached. Under a real application, accumulated SBEs can eventually become uncorrectable multi-bit errors (MBEs), which are fatal — data cannot be recovered. Multi-Bit ECC Errors Manifesting as Application Crashes NXP has documented cases on QorIQ platforms (P2020, T1042) where application crashes (e.g., a lwz instruction faulting on a valid-looking address) were traced to MBE events in DDR. The crash is not a software bug — it is the e5500 core receiving corrupted data from the DDR controller and raising an IVOR1 Machine Check Exception. Importantly, the MCSR register shows 0xA000 (uncorrectable L1 cache/tag error) even when the memory region is cache-inhibited, because the DDR controller asserts a corrupted-data signal that the core registers as an L1 error Cross-check your board design against: AN3940 — Hardware and Layout Design Considerations for DDR3 SDRAM Memory Interfaces AN5097 — Hardware and Layout Design Considerations for DDR4 SDRAM Memory Interfaces AN4039 — PowerQUICC and QorIQ DDR3 SDRAM Controller Register Setting Considerations Pay particular attention to: AVDD_DDR power supply noise and decoupling, DDR reset signal routing (HRESET_B to DRAM RESET), and termination resistor values. Regards
View full article
T1040 mEMAC TX_FIFO_OVFL on port when another port loses link I'm debugging an Ethernet issue on a T1040 using the 1G mEMAC RGMII interfaces. I am seeing packet loss on an Ethernet port when a different port loses physical link (e.g. the cable is disconnected). This appears to happen most frequently when both ports are operating at high data rates. When the issue occurs, I see the `TX_FIFO_OVFL` bit set in the Interrupt Event Register (`IEVENT`) of the healthy port. My current interpretation is that when an actively transmitting mEMAC loses physical link, something in the FMan/mEMAC transmit path temporarily prevents another mEMAC from draining its TX FIFO quickly enough. The healthy port eventually reports `IEVENT[TX_FIFO_OVFL]` and frames are lost. However, I have not identified the shared resource or mechanism that could cause this behavior. My questions are: * Is this a known T1040 / FMan v3 / mEMAC silicon issue or erratum? * Are there shared resources between the 1G mEMAC ports that could cause loss of carrier on one port while transmitting to temporarily affect another port's TX FIFO? * Is there a required sequence when a PHY loses link, such as stopping QMI dequeue, disabling the BMI TX port, disabling mEMAC TX/RX, or resetting the mEMAC? * Is there any mEMAC or FMan status register that can detect the condition leading to `TX_FIFO_OVFL` before the overflow occurs? * Are there recommended FMan/mEMAC or PHY configuration changes that might prevent `TX_FIFO_OVFL` in this situation? Thanks Re: T1040 mEMAC TX_FIFO_OVFL on port when another port loses link Hello, There is no publicly documented T1040/FMan v3 silicon erratum that specifically describes TX_FIFO_OVFL on a healthy port triggered by link loss on a peer port. The T1040 Chip Errata document is NDA-controlled and not publicly indexed, but no such cross-port TX FIFO overflow erratum has been identified for the T1040 mEMAC. The behavior you are observing is most likely an architectural interaction within the shared FMan BMI resources rather than a silicon defect.   Regards Re: T1040 mEMAC TX_FIFO_OVFL on port when another port loses link Thanks. Can you identify which shared BMI resource or arbitration mechanism is expected to cause this behavior? I have tested changes to FMBM_PFS[IFSZ], FMBM_TFP[DPDE], and FMBM_TFP[FLCL] without seeing a meaningful change. I also stop enqueueing and disable mEMAC TX immediately when IF_STATUS[RGLINK] goes low, but the healthy port can still lose packets. Is there a documented or recommended configuration to isolate the ports from this interaction? Also, is there a counter, status register, or debug mechanism that can show which BMI resource is becoming exhausted, blocked, or otherwise preventing the healthy mEMAC from draining its TX FIFO? Re: T1040 mEMAC TX_FIFO_OVFL on port when another port loses link Hi, The four shared BMI resources are TNUMs (tasks), DMA channels, FIFO (MURAM), and pipeline-depth. Since your FIFO size, pipeline depth ( DPDE ), and FIFO low threshold ( FLCL ) changes produced no improvement, the DMA channel layer is the most likely bottleneck, not MURAM allocation. The T1040 FMan has a fixed pool of DMA channels shared across all active TX ports. The TX path for each port is: CPU → QMI dequeue → BMI opens DMA read (DDR → MURAM) → TX FIFO → mEMAC → wire     When your stalled port loses link and you clear COMMAND_CONFIG[TX_EN] , the mEMAC stops transmitting to the wire, but any frames that are already mid-pipeline — specifically those for which the BMI TX port has already issued a DMA read transaction (DDR → MURAM TX FIFO) — do not immediately complete. The DMA read may have already moved data into the TX FIFO, and the FMan DMA engine is now waiting for a "DMA complete / EBD (external buffer descriptor) release" acknowledgment that depends on the MAC consuming the FIFO. With TX_EN=0 , the MAC is not consuming, so the DMA transaction stays open. Those open DMA transactions on the stalled port hold shared DMA channel slots. Under high load, the healthy port's BMI TX path cannot acquire enough DMA channel slots to fetch data from DDR quickly enough to keep its TX FIFO supplied → the TX FIFO goes empty briefly → then backfills faster than the MAC drain rate → TX_FIFO_OVFL . Regards Re: T1040 mEMAC TX_FIFO_OVFL on port when another port loses link Thanks for the explanation. I checked the FMBM_PP configuration for the 1G TX ports. They are configured with the default values: MXT = 3: 4 maximum concurrent tasks MXD = 2: 3 maximum outstanding DMA requests I also experimented with the per-port resource limits. I increased and decreased DMA requests and concurrent tasks settings. This did not produce an observable improvement with TX FIFO Overflow. Given that a 1G TX port can only have 3 outstanding DMA requests with the default configuration, I am not sure how a single stalled 1G port could consume enough of the shared DMA resources to significantly affect another port. Is there a smaller shared DMA channel/resource pool separate from the 84-entry FMan v3 DMA command queue, or can a small number of stalled DMA transactions cause head-of-line blocking or otherwise prevent DMA transactions from other ports from progressing? Also, is there a DMA status/debug register or counter that can be used to confirm that outstanding DMA transactions from the link-down port are actually remaining open during this condition?
View full article
S32M276XX LVR(低电压复位)功能测试 您好,NXP技术员, 我想对 S32M276 IC 的 VDD_HV_A 引脚上的 LVR(低电压复位)功能进行硬件测试。S32M276 是一款 SoC IC,所有电源均由其内部产生,那么我如何在 PCBA 层面验证此功能呢?请您提出任何建议。 Ted_Qiao_0-1787054923749.pngTed_Qiao_0-1787054923749.png Re: S32M276XX LVR(low voltage reset) function test 嗨@Ted_Qiao , LVR 默认启用,并生成 POR。芯片上电复位事件发生后,您可以通过读取低电压模式下的PORF和LVRx标志来确定是哪个电源域导致了该事件。 状态和控制(LVSC)寄存器。 你可以从外部限制 IC 的供电电压,尝试产生 低压检测 事件或 LVR POR,并检查 LVRAF 标志。 此致, 朱利安
View full article
适用于 MCSPTR2AK396 开发套件的 lwip_FreeRTOS_s32k396 示例项目 你好!我正在使用 S32K396 MCSPTR2AK396 三相永磁同步电机控制开发套件。为了测试基础固件,我安装了以下软件包: S32DS_3.6.5_RFP_win32 S32K3_ETPU_SW_4.9_2.0.1_D2512 SW32K3_S32M27x_RTD_R23-11_7.0.0_QLP03_D2512 SW32K3_FreeMASTER_Driver_1.5.0_D2512 S32K3xx_AMMCLIB_RTM_1_1_45_BIN MCSPTR2AK396_SW GCC 版本 10.2 经过多次尝试同步所有软件版本均告失败后,终于成功了,基础固件开始运行。不过,接下来我想测试以太网通信功能,而这正是我目前遇到的尚未解决的问题。 我还安装了: SW32K3_FreeRTOS_11.1.0_0.8.0_CD1_D2603 SW32K3_TCPIP_STACK_4.0.0_D2512 我尝试了测试项目 lwip_FreeRTOS_s32k396,但它始终无法编译,总是出现错误;描述中总是存在冲突和其他问题。我尝试使用最新版本的 SW32K3_TCPIP_STACK_5.0.0_CD01_D2605,并且在更新代码过程中必须进行文件替换。最终,固件编译成功,虽然出现了一些警告,但没有出现错误。 之后,我便开始进行测试。我的系统设置如下:个人电脑 -> GeekStore 100BT1-PRO2 汽车变流器 ( http://pinzhi-tech.com.cn/en/home_eng/product_list_100base-t1_eng/100bt1-pro2_eng/ )-> MCSPTR2AK396。我调整了计算机上以太网连接的 IP 地址和固件中指定的 IP 地址,使它们位于同一子网中。然而,从计算机尝试 ping 电机的分配 IP 地址却失败了,尽管变流器显示网络轮询正在进行中。 问题可能出在哪里?是不是我不应该使用最新版本的 TCPIP_STACK?电路板本身是否存在问题?控制器板上的标签标明了版本 B1 和 B。是否可以获取专门针对这些修订的更多文档(在网站上,我只看到了修订版 A 的文档)?任何建议或疑问,我都非常感激。 Re: lwip_FreeRTOS_s32k396 example project for MCSPTR2AK396 Development Kit 你好@Anna_Anna , 是的,是 fsdata.c之前版本中报告的 EthIf.c 文件问题已修复;EthIf.c来自 RTD 的文件只是一个短截线。我们提供了自己的 EthIf 最小实现,因此可以安全地将 RTD 中的文件从项目中排除。 其次,是的,根据您的描述,该示例似乎运行正常。需要进行连接,并且应该按照所述方式进行(将CRS_DV布线/焊接至PTD14 )。 此致, 朱利安 Re: lwip_FreeRTOS_s32k396 example project for MCSPTR2AK396 Development Kit 谢谢,我稍后会尝试这种方法,并向你汇报结果。 Re: lwip_FreeRTOS_s32k396 example project for MCSPTR2AK396 Development Kit 你好@Anna_Anna , 首先,我不确定 TCPIP v4.0.0 存在哪些错误,因为它也与 RTD 7.0.0 兼容。FreeRTOS 7.0.0 CD01 软件包,但是最新的 TCPIP 协议栈 (v5.0.0) 可以正常工作。能否告知一下您修改了哪些文件? 我顺利地导入、生成和编译了该项目。我的环境:S32DS v3.6.0,RTD v7.0.1、FreeRTOS v7.0.0 CD 01 和 TCPIP 协议栈版本 5.0.0CD 01。 MCSPTR2AK396似乎存在设计缺陷。EMAC_MII_RMII_RX_DV ( PTD14 ) 未连接到RX_CTL - CONFIG6 : MCSPTR2AK396 EVB 以太网连接,CRS_DV 信号澄清。 也就是说,该任务和操作系统是否正在运行? xTickCount — 如果 RTOS 滴答中断处于活动状态,则此值应持续递增。 xSchedulerRunning — 如果调度程序正在运行,则应将其设置为 1。 此致, 朱利安   Re: lwip_FreeRTOS_s32k396 example project for MCSPTR2AK396 Development Kit 你好@Julián_AragónM ! 使用 TCPIP v4.0.0 构建测试项目时遇到的问题已通过从构建过程中排除 fsdata.c 和 EthIf.c 这两个文件得到解决。此冲突似乎已在 5.0.0 版本中自动解决。 我还通过 S32DS 调试器的“表达式”窗口检查了变量 xSchedulerRunning 和 xTickCount 的值。xSchedulerRunning 的值确实为 1,而 xTickCount 的值依次递增(1、5001、10001……),这让我得出结论:FreeRTOS 在板载上运行正常,问题不在于软件。如果我理解正确,剩下的唯一原因就是硬件问题——TJA1103A 上的 CRS_DV (CONFIG6) 引脚与 PTD14 引脚之间没有连接?要解决这个问题,我需要将这两个触点焊接在一起吗?请确认。 此致, 安娜 Re: lwip_FreeRTOS_s32k396 example project for MCSPTR2AK396 Development Kit 你好 关于设计文件,我可以看到 MCSPTR2AK396 的硬件设计包包含 B2 版本: Julin_AragnM_3-1786576291659.pngJulin_AragnM_3-1786576291659.png 此致, 朱利安 Re: lwip_FreeRTOS_s32k396 example project for MCSPTR2AK396 Development Kit 你好。在我将 MCU 的引脚 41 (PTD 14) 和 TJA1103A 的引脚 25 (RX_CTL/CONFIG6) 焊接好之后,ping 功能就真正开始工作了。谢谢!
View full article