Multi Source Translation Content

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

Multi Source Translation Content

Discussions

Sort by:
PNEV5180B 2.0 PN5180 Altium回路図 PNEV5180B 2.0 PN5180の回路図はAltium形式で入手可能ですか? また、PCBも役立つだろう。主にNFCアンテナのために。 PN5180を使用したいので、できるだけ早く稼働させたいと考えています。 Re: PNEV5180B 2.0 PN5180 Altium Schematics こんにちは、 @David-Lightbug さん。 あなたの調子が良いといいのですが。 申し訳ありませんが、PN5180の設計ファイルは利用できません。PN5180評価ボードのクイックスタートガイドを参照すると良いかもしれません。そこには関連する回路図の写真がいくつか載っています。また、 PN5180アンテナ設計もご参照ください。 可能であれば、PN5190 |ペイメント用NFCフロントエンドを検討することをお勧めします。以下の設計ファイルがPNEV5190BPに関連するものがあります: -モジュールボード -ベースボード よろしくお願いいたします。 エドゥアルド。
View full article
关于S32K388的安全手册相关 我目前在做s32k388的安全资料整理,我们已经签订了NDA,我之前申请过一次安全访问权限,在我还没有下载资料时候没几天安全访问权限就自动取消了,我前两周又重新申请访问安全权限,但到现在一直没有他通过,我昨天也通过邮件发送给支持团队附件也粘贴了NDA材料。我目前比较紧急需要拿到安全相关的材料,我需要在安全手册里整理出安全相关检测功能供我们团队使用。 Re: 关于S32K388的安全手册相关 尊敬的用户, 谢谢。让我确认一下,您的安全文件帐户已激活。您申请的 S32K3xx 功能安全手册目前处于待处理状态。是否授予您访问权限取决于文档所有者。您的访问权限获得批准后,我们将另行发送电子邮件通知您。谢谢。祝你今天过得愉快。 帕夫拉 Re: 关于S32K388的安全手册相关 这边一直处于还在审核的状态,但这个状态已经持续快两周了 Re: 关于S32K388的安全手册相关 现在重新提交就会处于这个注册失败的状态。 Re: 关于S32K388的安全手册相关 尊敬的用户, 您的安全文件注册信息被错误地拒绝了。 请重新注册: https://www.nxp.com/webapp-signup/docstoreReg 完成后请告知我,以便我尽快激活您的帐户并授予您访问权限。谢谢。 祝你今天过得愉快。此致 帕夫拉
View full article
2026年に最も優れたeウォレットアプリ開発会社はどこですか? 2026年に最高のeウォレットアプリ開発会社は、フィンテックの専門知識、強力なセキュリティ基準、スケーラブルな技術、そしてカスタムデジタル決済ソリューションの実績を兼ね備えた企業です。Nimble AppGenieでは、スタートアップ、フィンテック企業、銀行、企業のニーズに合わせた安全で機能豊富なeWalletアプリケーションの開発を専門としています。 当社のソリューションには、多通貨ウォレット、ピアツーピアペイメント、QRコードおよびNFCペイメント、ペイメントゲートウェイ統合、KYC/AMLコンプライアンス、AI搭載の不正検出、シームレスなサードパーティ連携が含まれます。イノベーション、規制遵守、ユーザー体験に重点を置き、Nimble AppGenieは、急速に変化するフィンテック環境に適応した信頼性の高いデジタルウォレットプラットフォームの立ち上げを支援しています。
View full article
KW47 扩展广告 您好, 我使用的 SDK 版本是 26.06。 该例程为 kw47loc_loc_reader_freertos。 #define gAppIsPeripheral_d                   1U   经查明,调用 BluetoothLEHost_StartExtAdvertising 的返回值为 4(gBleFeatureNotSupported_c) 我想使用扩展广告。请给予我支持。   谢谢您!  
View full article
KW47 extended advertising Hi, The sdk version I'm using is 26.06 . The routine is kw47loc_loc_reader_freertos . #define gAppIsPeripheral_d                   1U   It was found that the return value of calling BluetoothLEHost_StartExtAdvertising is 4(gBleFeatureNotSupported_c)  I'd like to use extended advertising. Please give me your support.   Thanks!  
View full article
KW47拡張広告 こんにちは、 私が使っているSDKのバージョンは26.06です。 ルーチンは kw47loc_loc_reader_freertos です。 #define gAppIsPeripheral_d                   1U   BluetoothLEHost_StartExtAdvertising の呼び出しの戻り値は 4(gBleFeatureNotSupported_c) であることが判明しました。 拡張広告を利用したいです。どうかサポートしてください。   よろしくお願いします!  
View full article
S32K388に関連する安全マニュアル 現在、S32K388のセキュリティ関連ドキュメントを作成中です。既にNDA(秘密保持契約)を締結済みです。以前セキュリティアクセスを申請しましたが、ドキュメントをダウンロードする数日前に自動的に取り消されてしまいました。2週間前に再度アクセスを申請しましたが、まだ承認されていません。昨日、NDA関連資料を添付ファイルとしてサポートチームにメールで送付しました。セキュリティ関連資料が緊急に必要です。チームで使用するセキュリティ関連の検出機能をセキュリティマニュアルにまとめる必要があるためです。 Re: 关于S32K388的安全手册相关 お客様へ、 ありがとう。お客様のセキュアファイルアカウントが有効化されていることを確認させていただきます。S32K3xxセーフティマニュアルのご要望は現在、保留中です。アクセス権を付与するのは文書所有者の責任です。アクセスが承認され次第、別のメールで通知いたします。ありがとう。良い1日を。 パブラ Re: 关于S32K388的安全手册相关 現在も審査中ですが、この状態がほぼ2週間続いています。 Re: 关于S32K388的安全手册相关 今再送信すると、登録失敗のステータスになります。 Re: 关于S32K388的安全手册相关 お客様へ、 お客様のセキュアファイル登録は、誤って拒否されました。 再度ご登録ください: https://www.nxp.com/webapp-signup/docstoreReg 終わったら教えてください。その後、アカウントを有効化してできるだけ早くアクセス権を付与できます。ありがとう。 良い1日を。よろしくお願いします パブラ
View full article
How to change memory configuration after creating sample from MUCXpresso SDK? I know that when creating the sample from MCUXpresso SDK, we can config memory. But I created the sample, I changed many files in this sample and now I want to change memory configuration for my sample (I could not create new the sample, set memory and change files again because the number of changed files is very large). Whether I can config memory configuration after creating the sample and how? Thank you. I found this method Right click to project => Properties → C/C++ Build → MCU settings. Is that correct? Re: How to change memory configuration after creating sample from MUCXpresso SDK? Hi @nnxxpp , Thanks for your interest in NXP MIMXRT series! Yes, the memory configuration can be changed after the SDK example has been created. There is no need to recreate the project. And you may refer to this post: https://community.nxp.com/t5/MCUXpresso-General/MCUXpresso-Memory-map/m-p/1062500   After updating the Memory Configuration, please clean and rebuild the project, and verify the generated linker script and map file. This applies when the project uses MCUXpresso managed linker scripts. If a custom .ld file is used, please modify that linker script directly.  In addition, I’d like to mention the image view window provided by the IDE, which allows you to easily check whether the layout of the generated image meets your requirements: Best regards, Gavin
View full article
iMX 937处理器的最小和最大睡眠电流(毫安)是多少?   我的项目中使用的是 i.MX937 处理器,i.MX937 处理器的典型睡眠电流(mA)是多少?   Re: What is the min to max sleep current mA for the iMX 937 processor 有了这些维持正常运转所需的资源, 150 µA 的睡眠电流对于 i.MX 937 / i.MX 93 处理器本身来说并不现实。 。 为什么: 模式 电流/功率影响 适合 150 µA? 功能性贴合 BBSM/RTC模式 数据表列表 1.8V 时功率为 0.14 mW 功率测量应用程序说明显示大约 总计 97.978 µW 仅  NVCC_BBSM_1P8  积极的。 就力量而言,是的。 不 — 只有 BBSM/RTC 逻辑保持通电;GPIO 唤醒关闭,定时器/PWM/ADC 不可用。 暂停 数据表列表 典型值 15.1 mW 在 25 °C 下。 不 远高于 150 µA 等效电流 无/有限 — 暂停会关闭时钟,Cortex-A55 掉电,并使可以关闭的内部逻辑/模拟模块掉电。 Linux 挂起 + M33 在 WFI 中 应用笔记列表 122.4 毫瓦 此用例的总计。 无 建筑风格上更接近了,但仍然远远高于你目前的目标。 低功耗运行/使用Cortex-M33的AONMIX AONMIX 可以在其他功能域断电时运行,并且包含定时器/PWM 和定时器资源。 未记录显示符合 150 µA 标准 如果外设必须保持活动状态,则这是相关的 i.MX 93 模式类别,但它不是 150 µA 级模式。   150 µA 的预算仅相当于 1.8V 时功率为 0.27 mW 或者 3.3V 时功率为 0.495 mW 。那与i.MX 93的性能范围相符。 仅限 BBSM/RTC 状态,不是具有活动定时器输出、ADC、PWM、RTC 和 GPIO 的状态。 推荐架构:保留 i.MX 937 BBSM/RTC 或完全断电睡眠 并将始终开启的功能(定时器输出、ADC 监控、PWM 和 GPIO 监控)移至超低功耗的配套 MCU 或模拟/RTC 电路。当满足特定条件时,配套设备可以唤醒 i.MX 937。 i.MX 937 只能在非常有限的 RTC/BBSM 模式下满足 ~150 µA 的电流;在该电流预算内,它无法保持定时器/PWM/ADC/GPIO 功能处于活动状态。 Re: What is the min to max sleep current mA for the iMX 937 processor 我们的应用程序在低功耗/睡眠模式下需要以下资源才能保持正常运行: 1. 定时器输出引脚 1个ADC输入 1 PWM RTC 2-3 个 GPIO 我们对睡眠电流的要求是 150 µA。 Re: What is the min to max sleep current mA for the iMX 937 processor 对于 i.MX 937 / i.MX 93 处理器本身,数据手册没有给出任何以毫安 (mA) 为单位的“睡眠电流”。它规定 SUSPEND 模式总功率在25°C时为 15.1 mW ,并指出该数值取决于使用情况。挂起是功耗最低的模式,时钟关闭,不必要的电源关闭,可关断电源的 SoC 部分被关断,Cortex-A55 完全关断电源,DRAM 处于自刷新/保持状态。 如果您需要用于预算的等效电流,请使用: 因此, 15.1 mW大约相当于: 假定的供应基础 等效电流 5.0V 输入 3.0 毫安 3.3V 输入 4.6毫安 这是等效输入电流,而不是单个 SoC 电源轨电流;实际处理器电流分布在多个电源轨上。 如果您指的是电路板/SOM 深度睡眠电流,则测量值可能会更高,并且取决于配置。一项 i.MX93 SOM DSM 测量报告显示,在 5 V 时电流为 4.04 mA ,而其他优化/配置相关的报告显示,在 5 V 时电流约为 1.5 mA 至 9.3 mA 。 处理器规格中典型的 SUSPEND 功耗为 15.1 mW ;仅根据实际输入电压转换为 mA,例如5 V 时约为 3.0 mA 。
View full article
What is the min to max sleep current mA for the iMX 937 processor   In my project I am using I.MX937 processor, what is the typical sleep current (mA) for the i.MX 937 processor?    Re: What is the min to max sleep current mA for the iMX 937 processor With those resources required to stay functional, 150 µA sleep current is not realistic for the i.MX 937 / i.MX 93 processor itself . Why: Mode Current/power implication Fits 150 µA? Functional fit BBSM / RTC mode Datasheet lists 0.14 mW at 1.8 V , and the power-measurement app note shows about 97.978 µW total , with only  NVCC_BBSM_1P8  active. Power-wise, yes No — only BBSM/RTC logic remains powered; GPIO wakeup is OFF, and timer/PWM/ADC are not available. Suspend Datasheet lists 15.1 mW typical at 25 °C. No — far above 150 µA equivalent No / limited — suspend turns off clocks, powers down the Cortex-A55, and powers down internal logic/analog blocks that can be shut off. Linux Suspend + M33 in WFI App note lists 122.4 mW total for this use case. No Closer architecturally, but still far above your current target. Low-power run / AONMIX using Cortex-M33 AONMIX can run while other domains are powered down, and includes timer/PWM and timer resources. Not documented as meeting 150 µA This is the relevant i.MX 93 mode class if peripherals must remain active, but it is not a 150 µA-class mode.   A 150 µA budget corresponds to only 0.27 mW at 1.8 V or 0.495 mW at 3.3 V . That is in the range of the i.MX 93 BBSM/RTC-only state, not a state with active timer output, ADC, PWM, RTC, and GPIOs. Recommended architecture: keep the i.MX 937 in BBSM/RTC or fully power-gated sleep , and move the always-on functions — timer output, ADC monitoring, PWM, and GPIO supervision — to a very-low-power companion MCU or analog/RTC circuit. The companion device can wake the i.MX 937 when the condition is met. The i.MX 937 can meet ~150 µA only in a very limited RTC/BBSM-style state; it cannot keep timer/PWM/ADC/GPIO functionality active within that current budget. Re: What is the min to max sleep current mA for the iMX 937 processor In our application, the following resources are required to remain functional during the low-power/sleep mode: 1 Timer output pin 1 ADC input 1 PWM RTC 2–3 GPIOs Our requirement of sleep current is 150 µA. Re: What is the min to max sleep current mA for the iMX 937 processor For the i.MX 937 / i.MX 93 processor itself, the datasheet does not give a single “sleep current” in mA. It specifies SUSPEND mode total power = 15.1 mW at 25 °C , and notes that the number is use-case dependent . SUSPEND is the lowest-power mode where clocks are off, unnecessary supplies are off, power-gateable SoC portions are gated, Cortex-A55 is fully power-gated, and DRAM is in self-refresh/retention. If you need an equivalent current for budgeting, use: So 15.1 mW corresponds approximately to: Assumed supply basis Equivalent current 5.0 V input 3.0 mA 3.3 V input 4.6 mA That is an equivalent input current , not a single SoC rail current; the actual processor current is distributed across multiple power rails. If you mean board/SOM deep-sleep current , measured values can be higher and configuration-dependent. One i.MX93 SOM DSM measurement reported 4.04 mA at 5 V , with other optimized/configuration-dependent reports around 1.5 mA to 9.3 mA at 5 V . Use 15.1 mW typical SUSPEND power for the processor spec; convert to mA only against your actual input rail, e.g. about 3.0 mA at 5 V .
View full article
如何通过 MUCXpresso SDK 创建示例后更改内存配置? 我知道在使用 MCUXpresso SDK 创建示例时,我们可以配置内存。但是我已经创建了示例,并且更改了该示例中的许多文件,现在我想更改示例的内存配置(由于更改的文件数量非常大,我无法创建新示例、设置内存并再次更改文件)。 创建示例后是否可以配置内存配置?如何配置?谢谢。 我找到了这个方法:右键单击项目=>属性 => C/C++ 版本 => MCU 设置。这样对吗? Re: How to change memory configuration after creating sample from MUCXpresso SDK? 嗨@nnxxpp , 感谢您对 NXP MIMXRT 系列产品的关注! 是的,SDK 示例创建完成后,可以更改内存配置。无需重新创建该项目。 您还可以参考这篇帖子: https://community.nxp.com/t5/MCUXpresso-General/MCUXpresso-Memory-map/mp/1062500   更新内存配置后,请清理并重新构建项目,并验证生成的链接器脚本和映射文件。 这适用于项目使用 MCUXpresso 管理的链接器脚本的情况。如果使用自定义 .ld 文件,请直接修改该链接器脚本。 此外,我还想提一下IDE提供的图像查看窗口,它可以让您轻松检查生成的图像布局是否符合您的要求: 此致, 加文
View full article
Toolbox setup and how to run an application 1 Table of Contents •Introduction •Overview •Context •References •Conclusion 2 Introduction This article walks through the complete process of setting up the NXP Model-Based Design Toolbox (MBDT) and running a first application on NXP hardware. Before starting the installation, make sure that the prerequisite toolboxes are available in MATLAB. By the end of this guide, the reader will have a fully functional MBDT environment and will have successfully generated, compiled, and deployed embedded C code from a Simulink model to NXP hardware. 3 Overview This guide begins with the installation prerequisites and required toolboxes, then continues with the MATLAB Add-On Explorer flow for installing NXP_Support_Package_S32K3 . After the support package is installed, the guide explains how to launch the multistep installer, verify the required toolboxes and installation path, download the toolbox package from NXP, and complete the toolbox installation before running the first application. Installation Scope and Workflow This article focuses on practical installation flow required to start working with the NXP Model-Based Design Toolbox and run a first example application. It covers the software prerequisites, the toolbox setup sequence, and the validation steps needed before opening and deploying a model on the target board. The installation content in this guide should use the current multistep installer flow. Target Audience This article is intended for engineers and technical professionals who want to begin developing embedded applications for NXP hardware using a Model-Based Design workflow. The main target audience includes: Embedded software engineers MATLAB / Simulink developers evaluating NXP hardware Control and algorithm engineers Students and academic researchers using NXP evaluation boards Model-Based Design engineers Hardware integration engineers 4 Context 3.1 Prerequisites Before starting the installation, verify that the following prerequisite toolboxes and setup conditions are met: MATLAB installed - Required by the support package and multistep installer flow. Simulink installed - Required for model-based development and Simulink example execution. Embedded Coder installed - Required for embedded C code generation from Simulink models. MATLAB Coder installed - Required by the current S32K3 support package prerequisites. Simulink Coder installed - Required by the current S32K3 support package prerequisites. Embedded Coder Support Package for ARM Cortex-M Processors installed - Required by the installer verification step and target support flow. NXP account - Required to access the NXP download page and retrieve the toolbox package. Short local installation path - The installation path should be local, short, and should not contain whitespace to avoid setup issues. Figure 1 - MATLAB Add-On Manager confirming requirement are installed 3.2 Toolbox Setup NXP's Model-Based Design Toolbox is delivered as a MATLAB Toolbox Package that can be installed offline or online from MathWorks Add-ons. The recommended installation path uses the NXP Support Package, a graphical wizard that guides through download, installation, and license activation in a single workflow. Note: Throughout this guide, the placeholder {platform} refers to the NXP MCU family targeted by the toolbox (for example S32K3 , S32K1 , S32M2 , MPC57XX , etc.). Each family has its own dedicated Support Package and Toolbox in the MATLAB Add-On Explorer. When following the steps below, replace {platform} with the identifier matching the hardware family in use, for instance, for the S32K3 evaluation boards, the script name becomes NXP_Support_Package_s32k3.m and the path command becomes mbd_s32k3_path . Step 1 - Install NXP Support Package from MATLAB Add-On Explorer Install the current NXP support package directly from the MATLAB Add-On Explorer. This package provides the multistep installer flow used to verify prerequisites, download the toolbox, and guide the installation for S32K3. In MATLAB, navigate to Home → Add-Ons → Get Add-Ons. Figure 2 - Open the Add-On Explorer from the MATLAB Home tab Search for NXP_Support_Package_S32K3 in the Add-On Explorer. Figure 3 - Search results for NXP_Support_Package_S32K3 in the Add-On Explorer Open the package page and click Add to start the installation. Figure 4 - Open the NXP_Support_Package_S32K3 page and click Add Review the license agreement for NXP_Support_Package_S32K3 and click I Accept. Figure 5 - License agreement shown during installation of NXP_Support_Package_S32K3 Wait for the installation to complete. When finished, the Getting Started Guide opens automatically. Figure 6 - Support package installation completed successfully In the MATLAB Command Window, run sp_s32k3.nxp.setup(); to launch the multistep installer. sp_s32k3.nxp.setup(); Figure 7 - Run sp_s32k3.nxp.setup(); from the MATLAB Command Window Step 2 - Use the multistep installer to download and install the toolbox The multistep installer guides you through prerequisite verification, toolbox download, installation, activation, and access to the documentation for S32K3. Figure 8 - Welcome page of the S32K3 multistep installer In the installer, continue to the download step. On the NXP website, review the software terms and conditions and click I Agree before downloading the toolbox package. If the product download page does not open automatically, sign in to your NXP account and open the Product Download page for the required S32K3 toolbox release or click the link from Download page of the S32K3 multistep installer. Figure 9 - Download page of the S32K3 multistep installer Figure 10 - Accept the NXP software terms and conditions before downloading Download the toolbox package from the Product Download page. The installer accepts both .zip and .mltbx files. Figure 11 - Product Download page for the S32K3 MBDT package The setup verification step checks whether all required toolboxes are installed in MATLAB and whether the installation path is valid for the S32K3 toolbox setup. If any dependency is missing or an unsupported version is detected, resolve the issue before continuing to the download and installation steps. Figure 12 - Setup verification page showing required toolboxes and installation path checks Important: It is recommended to install MATLAB and the NXP Toolbox into a location that does not contain special characters, empty spaces, or mapped drives. Use a short local path whenever possible. After downloading the package, return to the installer and continue with the local file selection step. Browse to the downloaded archive or toolbox package and click Install to continue. The installer accepts both .zip and .mltbx files. Figure 13 - Browse to and download the S32K3 MBDT package from the Product Download page Figure 14 - Accept the license agreement for NXP_MBDToolbox_S32K3 Accept the toolbox license agreement to allow MATLAB to complete the MBDT installation. Figure 15 - Toolbox installation in progress After the installation is complete, use the Add-On Manager context menu to open the installed toolbox folder if you need to inspect the package contents or access installed files directly. Wait until the installation finishes. The process may take several minutes depending on the system configuration and package size. Figure 16 - Open the installed toolbox location from MATLAB Add-On Manager Step 4 - Set the Path for Toolchain Generation The MBDT uses Simulink's toolchain mechanism to enable automatic code generation with Embedded Coder. When installed as a MATLAB add-on, the toolbox path is configured automatically. If manual configuration is still required in your environment, run the platform path script from the installation directory. If manual setup is required, in MATLAB change the Current Directory to the toolbox installation folder: ..\MATLAB\Add-Ons\Toolboxes\NXP_MBDToolbox_{platform}\ Then run the configuration script: mbd_{platform}_path Figure 17 - Output of the mbd_{platform}_path script in the MATLAB Command Window 3.3 How to Run an Application With the toolbox installed and the compiler configured, the following steps demonstrate how to open, build, and deploy the LED blinky example - the embedded equivalent of Hello World to an NXP evaluation board. Open an Example Model Open MATLAB and start Simulink by typing simulink in the Command Window (or by clicking the Simulink button on the Home tab). In the Simulink Start Page, open the Simulink Library Browser (View → Library Browser, or press Ctrl+Shift+L). In the Library Browser tree, expand NXP Model-Based Design Toolbox for {platform} to confirm that the NXP blocks are available. This validates that the toolbox is properly registered with Simulink. Open the Example Projects tab from the Simulink Start Page, it lists every example shipped with the MBDT, grouped by peripheral (ADC, CAN, DIO, PWM, UART, etc.). Browse the list, select the example matching your hardware (for instance s32k3xx_dio_s32ct for the LED blinky on FRDM-A-S32K312 / FRDM-A-S32K344 ), and click Open to load the model. Figure 18 - MBDT Examples Library available from the Simulink Library Browser Open the example model ( .slx / .mdl file). Configure the Target Hardware Figure 19 - Model Settings  Figure 20 - Code Generation Tip: Example models that ship with the MBDT are pre-configured for a specific evaluation board. Always verify the hardware target matches your physical board before building. Build and Deploy Connect the NXP evaluation board to the PC via USB. In Simulink, open the Hardware tab and click Build, Deploy & Start (or use Ctrl+B). Monitor the MATLAB Diagnostic Viewer for build status messages. Verify on Hardware Confirm that the application runs on the target hardware as expected - for example, observe the LED blinking at the rate defined in the model. If the application produces serial output, open a terminal and verify the expected data on the communication port. Use debugging or monitoring tools to inspect variable values and system signals from the running application in real time. 5 References NXP Model-Based Design Toolbox - Product Page Automotive SW - S32K3 - Model-Based Design Toolbox Model-Based Design Toolbox S32K3xx Quick Start Guide (PDF) MathWorks Embedded Coder 6 Conclusion This article described the complete setup of the NXP Model-Based Design Toolbox: from installation and compiler configuration to building and deploying a first application to NXP hardware. The next article in the series focuses on the Toolbox Workflow, presenting in detail the end-to-end development flow with the MBDT, from configuring a Simulink model with NXP blocks, through code generation with Embedded Coder, to building, deploying and validating the resulting application on NXP hardware.
View full article
Front and Rear Lights-Overview 1 Table of Contents • Introduction • Overview • Context • References • Conclusion 2 Introduction Automotive lighting systems play an essential role in vehicle safety, visibility, and communication with other road users. In general, these systems can be grouped into two main categories: Front Lighting and Rear Lighting. Both help provide road illumination for the driver and signal the vehicle's actions and presence to surrounding traffic. Front Lights - General Role and Functions Front lighting improves the driver's visibility in different driving conditions, including low light, nighttime driving, and adverse weather. It includes several key functions commonly found in modern vehicles, such as: Daytime Running Lights (DRL) - increase vehicle visibility during daytime driving Turn Lights - indicate the driver's intention to change direction Head Lights - provide road illumination during nighttime or low-light conditions Fog Lights - improve visibility in fog, rain, snow, or other low-visibility situations Rear Lights - General Role and Functions Rear lighting is primarily used to communicate the vehicle's status and intentions to other road users. It includes important functions such as: Stop Lights - signal braking actions Head Lights - make the vehicle visible from behind Turn Lights - indicate the intended direction of travel Fog Lights - improve vehicle visibility in low-visibility conditions 3 Overview The lighting system presented in this article is developed using a Model-Based Design (MBD) approach. This methodology enables early validation of system behavior, systematic refinement of the control logic, and a direct path from simulation to embedded implementation. The control behavior is modeled in MATLAB/Simulink, where the functionality is structured into modular and reusable components. Stateflow is used to describe the control logic, providing a clear and formal representation of operating modes, state transitions, and event-driven behavior. The Simulink model runs on the NXP S32K3 platform and communicates with other vehicle nodes via CAN Bus. Message reception and signal handling are managed using the Vehicle Network Toolbox, which simplifies CAN communication by utilizing DBC files without introducing additional hand-written interface code. This integration supports a smooth transition from simulation to embedded deployment through automatic code generation, minimizing the risk of discrepancies between modeled behavior and deployed software. Target audience: Engineers interested in Model-Based Design for automotive applications Those learning or experimenting with simulation-based development and control logic Anyone using NXP automotive hardware platforms who wants to faster develop complex applications on real embedded systems Figure 2 - Front Hazard Lights Activated 4 Context In this project, separate models are implemented for front and rear lighting to showcase the physical layout of the car and keep the logic simple and easier to test. Each lighting area handles its own functions, while staying synchronized with overall vehicle behavior through standard vehicle communication. Figure 1 - Front and Rear Lights System highlighted within the EV architecture All lighting commands are received via the CAN bus, ensuring consistent and predictable behavior for functions such as Daytime Running Lights (DRL), Head Lights, Fog Lights, Turn Indicators, and Stop Lights. Using CAN-based commands reflects standard vehicle communication practices and allows the lighting logic to be evaluated under conditions close to those in a production system. Incoming CAN messages are processed by the lighting module. Based on vehicle states and received commands, the module: interprets CAN signals and system status, prioritizes lighting functions and handles fault-related conditions, turns on the lights. This structure keeps responsibilities clear: the CAN layer provides high-level commands, while the lighting control logic handles decision-making and execution. The result is a deterministic and easy-to-follow path from vehicle-level inputs to visible lighting behavior. In our project, the system uses addressable LEDs, allowing individual control of multiple light segments within each lamp. This enables a realistic representation of modern automotive lighting systems, where lighting units are no longer simple on/off devices but consist of multiple independently controlled segments. Addressable LEDs rely on a dedicated communication protocol to transfer control data such as color, brightness, and activation timing to each individual LED element. To simplify the integration of this protocol and ensure deterministic behavior, the LED communication was configured and integrated using NXP's Model-Based Design workflow. This approach allows the LED control logic and communication timing to be defined, simulated, and validated directly at model level. The system behavior can be easily followed from input to output, since each step is clearly defined. CAN messages trigger specific actions, and the result is directly visible in the LEDs. This makes the logic straightforward to understand and verify. 5 References Model-Based Design Toolbox (MBDT) Community Model-Based Design Toolbox (MBDT) - S32K3 - How To 6 Conclusion This article provides a simple overview of how Model-Based Design can be applied to develop an automotive lighting system using NXP hardware, focusing on the general architecture and design approach. In the following articles, we will explain the configuration, implementation, and deployment of the lighting system on the NXP hardware.
View full article
lowlight opensource ai-isp test on imx95   There are many open-source low-light AI-ISP models. The table below is a comparison table provided by Copilot.  Algorithm GitHub Type i.MX95 NPU Suitability MSR (Retinex) jsrsinchana/.../MSR-algorithm Non-AI (ISP) Medium Zero-DCE++ arnabroy734/low_light_enhancement Lightweight CNN + Curve Very High RetinexNet weichen582/RetinexNet CNN (Retinex) Medium EnlightenGAN VITA-Group/EnlightenGAN GAN (CNN) Very High (lite) FLOL cidautai/FLOL Lightweight CNN High SNR-aware JIA-Lab-research/SNR-Aware Transformer + CNN Low KinD zhangyhuaee/KinD Retinex + CNN Medium RetinexNet-lite Derived Light CNN Medium EnlightenGAN-lite Derived Small CNN Very High Fast LLIE CNN Various Small CNN High Tested above open-source models with UVC to perform performance evaluation on the exip-os08a20 module with linear mode. Found that SCI(GitHub - vis-opt-group/SCI: [CVPR 2022] This is the official code for the paper "Toward Fast, Flexib...) computation is relatively small, low-light performance is good in subjective evaluations, and it can basically run on the IMX95. The testing method involves copying the tflite file and test script to the /root/ directory of the IMX95 and running the following command: `python3 test_sci_cvpr_illu_imx95_int8.py --model sci_tpami_illu_imx95_int8.tflite`. The comparison interface shown below is displayed. i.MX Processors Sensor
View full article
S32 Design Studio - Export and Debug 1 Table of Contents • Introduction • Open the generated project in S32 Design Studio • Debug the generated application in S32 Design Studio • Debug the code generated from the Simulink model • Conclusion 2 Introduction This article explains how to take a project generated with the Model-Based Design Toolbox (MBDT) in Simulink and open, build, and debug it in S32 Design Studio. It focuses on the transition from model execution in Simulink to target-level debugging and validation on S32 hardware. 3 Open the generated project in S32 Design Studio MBDT generates code from Simulink models and exports it as an S32 Design Studio-compatible project. After a successful model build, the generated _Config folder contains the files required by the IDE. The project can then be opened directly from Simulink or imported into S32 Design Studio for further configuration, building, and debugging on S32 hardware. Before opening or debugging the project in S32 Design Studio, build the Simulink model. The build process generates the code and project structure required for IDE integration. You can open the generated project either directly from Simulink or manually from within S32 Design Studio. Use the Simulink option when you want to launch the generated project immediately after configuration. Use the IDE import option when you want to manage the project manually from an S32 Design Studio workspace. Open the project from Simulink To open the project from Simulink, open the model Hardware Settings from the Hardware tab or press Ctrl + E. Then go to Hardware Implementation → Hardware board settings → Target hardware resources → S32 Design Studio Project and select Open. Figure 1. S32 Design Studio project settings in Simulink A dialog appears and prompts you to select the S32 Design Studio installation path. Figure 2. S32 Design Studio installation path selection To select the S32 Design Studio installation path later, or to change it during toolbox usage, click Browse in the S32 Design Studio location field under the Tools Paths group. Figure 3. S32 Design Studio path changing The generated project opens in S32 Design Studio and is ready to build, configure, or debug. Figure 4. Generated project opened in S32 Design Studio Open the project inside the IDE To import the project manually into S32 Design Studio, follow these steps: Inside the IDE, select File → Import → Existing Projects into Workspace. Figure 5. Importing an existing project into the workspace Browse for the _Config folder in Select root directory. Before clicking Finish, make sure that Copy projects into workspace is disabled. If the project is copied into the S32 Design Studio workspace, the build process will fail. Figure 6. Directory selection for the generated project 4 Debug the generated application in S32 Design Studio To build and debug the project in S32 Design Studio, select the project and click Debug. S32 Design Studio builds the project and automatically switches to the Debug perspective. Note: Ensure that the target hardware board is connected before starting the debug session. Figure 7. Starting the debug session Figure 8. Debug perspective in S32 Design Studio After the debugger launches and the application is loaded on the target, you can use the following actions to control program execution and inspect the generated code: The Breakpoint action sets a breakpoint when you double-click in the left margin of a .c file:   Figure 9. Breakpoint set in the generated source file The Step Over (F6) action executes the current line while remaining in the same function: Figure 10. Step Over action in the Debug toolbar The Step Into (F5) action enters a called function: Figure 11. Step Into action in the Debug toolbar The Step Return (F7) action runs to the end of the current function: Figure 12. Step Return action in the Debug toolbar The Resume (F8) action runs until the next breakpoint: Figure 13. Resume action in the Debug toolbar Figure 14. Breakpoint reached after pressing Resume action The Suspend (F9) action pauses execution at the current instruction: Figure 15. Suspend action in the Debug toolbar Figure 16. Function paused after pressing Suspend action The Terminate (Ctrl + F2) action stops the debug session and disconnects from the target: Figure 17. Terminate action in the Debug toolbar The Disconnect action leaves the target running while detaching the debugger: Figure 18. Disconnect action in the Debug toolbar 5 Debug the code generated from the Simulink model The code generated by the Simulink model can be found in the _step() function. To enter this function, set a breakpoint before the function call, run the application until the breakpoint is reached, and then select Step Into. Alternatively, Ctrl + Click the function name to open the function and place a breakpoint inside it. Figure 19. modelName_step function In this function, you will also find the generated code for the blocks placed inside the Simulink model. Figure 20. Generated step function in the source code To monitor variable values, hover over a variable to see its current value: Figure 21. Variable value displayed on hover Alternatively, add the variable to the Expressions view by selecting Add new expression, entering the variable name, and pressing Enter. Figure 22. Add new expression in Expressions view Figure 23. Variable added to Expressions view Upon running the code, if the value changes, it will be highlighted. Figure 24. Variable value highlighted during debug The names of the variables in the generated code are the same as the names they have in the Simulink model, making it easier to debug the generated code. Figure 25. Variable name in Simulink model and generated code 6 Conclusion After identifying the generated function and monitoring key variables, you can validate how the Simulink model behavior maps to the generated application running on the target hardware. For more tutorials on installing, activating, and using S32 Design Studio, see the S32 Design Studio tutorials on the community page: S32 Design Studio Knowledge Base.
View full article
TJA1120A 1000BASET1 Linux側の構成 ECUボードTJA1120A am72a7ベースのPHYとDP83TG721EVM-MCメディアコンバーターを使っています。 現在、リンクは有効です root@am62axx-evm:~# dmesg | grep eth [ 0.000000] psci: probing for conduit method from DT. [ 0.944429] optee: probing for conduit method. [ 1.352845] am65-cpsw-nuss 8000000.ethernet: initializing am65 cpsw nuss version 0x6BA01103, cpsw version 0x6BA81103 Ports: 3 quirks:00000006 [ 1.365779] am65-cpsw-nuss 8000000.ethernet: Use random MAC address [ 1.452604] am65-cpsw-nuss 8000000.ethernet: initialized cpsw ale version 1.5 [ 1.459737] am65-cpsw-nuss 8000000.ethernet: ALE Table size 512, Policers 32 [ 1.467615] am65-cpsw-nuss 8000000.ethernet: CPTS ver 0x4e8a010c, freq:500000000, add_val:1 pps:1 [ 1.488042] am65-cpsw-nuss 8000000.ethernet: set new flow-id-base 19 [ 5.875382] am65-cpsw-nuss 8000000.ethernet eth1: PHY [8000f00.mdio:00] driver [Micrel KSZ9031 Gigabit PHY] (irq=POLL) [ 5.890378] am65-cpsw-nuss 8000000.ethernet eth1: configuring for phy/rgmii link mode [ 6.618291] am65-cpsw-nuss 8000000.ethernet eth0: PHY [8000f00.mdio:04] driver [NXP C45 TJA1120] (irq=POLL) [ 6.629693] am65-cpsw-nuss 8000000.ethernet eth0: configuring for phy/rgmii link mode [ 6.662963] am65-cpsw-nuss 8000000.ethernet eth0: Link is Up - 1Gbps/Full - flow control off [ 38.194116] am65-cpsw-nuss 8000000.ethernet eth0: Link is Down [ 116.023614] am65-cpsw-nuss 8000000.ethernet eth0: Link is Up - 1Gbps/Full - flow control off eth0からスレーブモードTJA1120設定し、ハードウェアジャンパーをマスターからメディアコンバーターに設定しました root@am62axx-evm:~# ethtool eth0 Settings for eth0: Supported ports: [ TP MII ] Supported link modes: 1000baseT1/Full Supported pause frame use: Symmetric Supports auto-negotiation: No Supported FEC modes: Not reported Advertised link modes: 1000baseT1/Full Advertised pause frame use: Symmetric Advertised auto-negotiation: No Advertised FEC modes: Not reported Speed: 1000Mb/s Duplex: Full Auto-negotiation: off master-slave cfg: forced slave master-slave status: slave Port: Twisted Pair PHYAD: 4 Transceiver: external MDI-X: Unknown Supports Wake-on: d Wake-on: d Current message level: 0x000020f7 (8439) drv probe link ifdown ifup rx_err tx_err hw Link detected: yes SQI: 7/7 root@am62axx-evm:~# ifconfig eth0 eth0 Link encap:Ethernet HWaddr 64:1C:10:1C:06:E2 inet addr:192.168.1.100 Bcast:192.168.1.255 Mask:255.255.255.0 inet6 addr: fe80::661c:10ff:fe1c:6e2/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:118 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:0 (0.0 B) TX bytes:24044 (23.4 KiB) ECUを192.168.1.100に設定しました。そして私のPC(メディアコンバーターに接続)は192.168.1.101に変換しています ピングは発生していませんが、PCからピングするとECUのLEDインジケーターが点滅します。 acs@a-tract-10:~$ ping 192.168.1.100 PING 192.168.1.100 (192.168.1.100) 56(84) bytes of data. From 192.168.1.101 icmp_seq=1 Destination Host Unreachable From 192.168.1.101 icmp_seq=2 Destination Host Unreachable From 192.168.1.101 icmp_seq=3 Destination Host Unreachable From 192.168.1.101 icmp_seq=4 Destination Host Unreachable From 192.168.1.101 icmp_seq=5 Destination Host Unreachable From 192.168.1.101 icmp_seq=6 Destination Host Unreachable ^C --- 192.168.1.100 ping statistics --- 8 packets transmitted, 0 received, +6 errors, 100% packet loss, time 7185ms pipe 4 車載イーサネットで追加設定は必要ですか? Re: TJA1120A 1000BASET1 Linux side configuration こんにちは、 @vikyhre さん。 新しいログを見る限り、1000BASE-T1側は正常に動作しているようです。TJA1120 PHYが検出され、リンクは1 Gbit/sで確立され、マスター/スレーブの状態は正しく、SQIは7/7と報告されています。 しかし、イーサネットインターフェースの統計では、受信パケットはゼロであり、送信パケットは増加しています。これは受信フレームがLinuxのMAC/ネットワークスタックに届いていないことを示唆しています。 LinuxデバイスツリーでRGMIIのタイミング設定を再確認してください。ログにはインターフェースが「phy/rgmii」として設定されていることが示されています。基板設計でPHYが内部RGMII遅延を提供することを想定している場合、デバイスツリーは通常単なる「rgmii」インスタンスではなく 「rgmii-id」 を使うべきです。RGMIIの遅延設定の不一致はまさにこのような動作を引き起こすことがあります:PHYリンクアップと良好なSQIはあるものの、Linuxによるパケット受信は成功しません。 PC側のWiresharkでECUから送信されたフレームが見えるかどうかも確認してもらえますか?例えば、eth0をECUに起動した後、ECUのMACアドレスからのARP、IPv6の隣接検出、その他のイーサネットフレームがPC上でキャプチャされているか確認してください。 同時に、PCからpingを実行しながら、ECU側でtcpdumpを実行してください。 tcpdump -ni eth0 -e arp または icmp ARP/ICMPパケットがキャプチャされず、RXカウンタがゼロのままの場合、問題は1000BASE-T1リンク自体ではなく、MAC-to-PHY RGMIIパスまたはそのデバイスツリーのタイミング構成にある可能性が最も高いです。 よろしくお願いいたします。 パベル Re: TJA1120A 1000BASET1 Linux side configuration パベルさん、おっしゃる通り、CONFIG3、4ピンをRGMII-IDに設定しました(TJA1120Aデータシートの6.7.2に従って、RGMII-IDとRGMII-ID(TX/RX)の両方を試しました)。また、phy-modeを「rgmii-id」に設定してください。 &cpsw_port1 { status = "okay"; phy-mode = "rgmii-id"; phy-handle = <&cpsw3g_phy0>; }; これはdmesgに反映された。 [ 6.817790] am65-cpsw-nuss 8000000.ethernet eth0: configuring for phy/rgmii-id link mode しかし、pingは依然として機能していなかった。 acs@a-tract-10:~$ ping 192.168.1.100 PING 192.168.1.100 (192.168.1.100) 56(84) bytes of data. From 192.168.1.101 icmp_seq=1 Destination Host Unreachable From 192.168.1.101 icmp_seq=2 Destination Host Unreachable From 192.168.1.101 icmp_seq=3 Destination Host Unreachable From 192.168.1.101 icmp_seq=4 Destination Host Unreachable From 192.168.1.101 icmp_seq=5 Destination Host Unreachable From 192.168.1.101 icmp_seq=6 Destination Host Unreachable From 192.168.1.101 icmp_seq=7 Destination Host Unreachable From 192.168.1.101 icmp_seq=8 Destination Host Unreachable From 192.168.1.101 icmp_seq=9 Destination Host Unreachable From 192.168.1.101 icmp_seq=10 Destination Host Unreachable From 192.168.1.101 icmp_seq=11 Destination Host Unreachable From 192.168.1.101 icmp_seq=12 Destination Host Unreachable From 192.168.1.101 icmp_seq=13 Destination Host Unreachable From 192.168.1.101 icmp_seq=17 Destination Host Unreachable From 192.168.1.101 icmp_seq=18 Destination Host Unreachable From 192.168.1.101 icmp_seq=19 Destination Host Unreachable From 192.168.1.101 icmp_seq=20 Destination Host Unreachable From 192.168.1.101 icmp_seq=21 Destination Host Unreachable From 192.168.1.101 icmp_seq=22 Destination Host Unreachable From 192.168.1.101 icmp_seq=23 Destination Host Unreachable From 192.168.1.101 icmp_seq=24 Destination Host Unreachable ^C --- 192.168.1.100 ping statistics --- 25 packets transmitted, 0 received, +21 errors, 100% packet loss, time 24598ms pipe 4 しかし、あなたの言うとおり、PCからpingしながらECU側を監視しようとしました。 root@am62axx-evm:~# tcpdump -ni eth0 -e arp or icmp [ 36.233694] am65-cpsw-nuss 8000000.ethernet eth0: entered promiscuous mode [ 36.240729] kauditd_printk_skb: 5 callbacks suppressed [ 36.240737] audit: type=1700 audit(1748612373.780:19): dev=eth0 prom=256 old_ prom=0 auid=4294967295 uid=0 gid=0 ses=4294967295 [ 36.257330] audit: type=1300 audit(1748612373.780:19): arch=c00000b7 syscall= 208 success=yes exit=0 a0=4 a1=107 a2=1 a3=fffffb4ab040 items=0 ppid=701 pid=713 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=tty S2 ses=4294967295 comm="tcpdump" exe="/usr/bin/tcpdump" subj=kernel key=(null) [ 36.285128] audit: type=1327 audit(1748612373.780:19): proctitle=74637064756D 70002D6E690065746830002D6500617270006F720069636D70 tcpdump: verbose output suppressed, use -v[v]... for full protocol decode listening on eth0, link-type EN10MB (Ethernet), snapshot length 262144 bytes 13:39:47.956062 4c:cf:7c:bf:f6:a1 > ff:ff:ff:ff:ff:ff, ethertype 802.1Q (0x8100), length 64: vlan 0, p 0, ethertype ARP (0x0806), Request who-has 192.168.1.100 tell 192.168.1.101, length 46 13:39:47.956161 64:1c:10:1c:06:e2 > 4c:cf:7c:bf:f6:a1, ethertype ARP (0x0806), length 42: Reply 192.168.1.100 is-at 64:1c:10:1c:06:e2, length 28 13:39:49.001519 4c:cf:7c:bf:f6:a1 > ff:ff:ff:ff:ff:ff, ethertype 802.1Q (0x8100), length 64: vlan 0, p 0, ethertype ARP (0x0806), Request who-has 192.168.1.100 tell 192.168.1.101, length 46 13:39:49.001576 64:1c:10:1c:06:e2 > 4c:cf:7c:bf:f6:a1, ethertype ARP (0x0806), length 42: Reply 192.168.1.100 is-at 64:1c:10:1c:06:e2, length 28 13:39:50.025527 4c:cf:7c:bf:f6:a1 > ff:ff:ff:ff:ff:ff, ethertype 802.1Q (0x8100), length 64: vlan 0, p 0, ethertype ARP (0x0806), Request who-has 192.168.1.100 tell 192.168.1.101, length 46 13:39:50.025574 64:1c:10:1c:06:e2 > 4c:cf:7c:bf:f6:a1, ethertype ARP (0x0806), length 42: Reply 192.168.1.100 is-at 64:1c:10:1c:06:e2, length 28 13:39:51.049972 4c:cf:7c:bf:f6:a1 > ff:ff:ff:ff:ff:ff, ethertype 802.1Q (0x8100), length 64: vlan 0, p 0, ethertype ARP (0x0806), Request who-has 192.168.1.100 tell 192.168.1.101, length 46 13:39:51.050015 64:1c:10:1c:06:e2 > 4c:cf:7c:bf:f6:a1, ethertype ARP (0x0806), length 42: Reply 192.168.1.100 is-at 64:1c:10:1c:06:e2, length 28 13:39:52.073514 4c:cf:7c:bf:f6:a1 > ff:ff:ff:ff:ff:ff, ethertype 802.1Q (0x8100), length 64: vlan 0, p 0, ethertype ARP (0x0806), Request who-has 192.168.1.100 tell 192.168.1.101, length 46 13:39:52.073561 64:1c:10:1c:06:e2 > 4c:cf:7c:bf:f6:a1, ethertype ARP (0x0806), length 42: Reply 192.168.1.100 is-at 64:1c:10:1c:06:e2, length 28 13:39:53.097481 4c:cf:7c:bf:f6:a1 > ff:ff:ff:ff:ff:ff, ethertype 802.1Q (0x8100), length 64: vlan 0, p 0, ethertype ARP (0x0806), Request who-has 192.168.1.100 tell 192.168.1.101, length 46 13:39:53.097522 64:1c:10:1c:06:e2 > 4c:cf:7c:bf:f6:a1, ethertype ARP (0x0806), length 42: Reply 192.168.1.100 is-at 64:1c:10:1c:06:e2, length 28 13:39:54.121912 4c:cf:7c:bf:f6:a1 > ff:ff:ff:ff:ff:ff, ethertype 802.1Q (0x8100), length 64: vlan 0, p 0, ethertype ARP (0x0806), Request who-has 192.168.1.100 tell 192.168.1.101, length 46 13:39:54.121951 64:1c:10:1c:06:e2 > 4c:cf:7c:bf:f6:a1, ethertype ARP (0x0806), length 42: Reply 192.168.1.100 is-at 64:1c:10:1c:06:e2, length 28 13:39:55.145488 4c:cf:7c:bf:f6:a1 > ff:ff:ff:ff:ff:ff, ethertype 802.1Q (0x8100), length 64: vlan 0, p 0, ethertype ARP (0x0806), Request who-has 192.168.1.100 tell 192.168.1.101, length 46 13:39:55.145526 64:1c:10:1c:06:e2 > 4c:cf:7c:bf:f6:a1, ethertype ARP (0x0806), length 42: Reply 192.168.1.100 is-at 64:1c:10:1c:06:e2, length 28 13:39:56.169569 4c:cf:7c:bf:f6:a1 > ff:ff:ff:ff:ff:ff, ethertype 802.1Q (0x8100), length 64: vlan 0, p 0, ethertype ARP (0x0806), Request who-has 192.168.1.100 tell 192.168.1.101, length 46 13:39:56.169613 64:1c:10:1c:06:e2 > 4c:cf:7c:bf:f6:a1, ethertype ARP (0x0806), length 42: Reply 192.168.1.100 is-at 64:1c:10:1c:06:e2, length 28 13:39:57.193883 4c:cf:7c:bf:f6:a1 > ff:ff:ff:ff:ff:ff, ethertype 802.1Q (0x8100), length 64: vlan 0, p 0, ethertype ARP (0x0806), Request who-has 192.168.1.100 tell 192.168.1.101, length 46 13:39:57.193925 64:1c:10:1c:06:e2 > 4c:cf:7c:bf:f6:a1, ethertype ARP (0x0806), length 42: Reply 192.168.1.100 is-at 64:1c:10:1c:06:e2, length 28 13:39:58.217586 4c:cf:7c:bf:f6:a1 > ff:ff:ff:ff:ff:ff, ethertype 802.1Q (0x8100), length 64: vlan 0, p 0, ethertype ARP (0x0806), Request who-has 192.168.1.100 tell 192.168.1.101, length 46 13:39:58.217629 64:1c:10:1c:06:e2 > 4c:cf:7c:bf:f6:a1, ethertype ARP (0x0806), length 42: Reply 192.168.1.100 is-at 64:1c:10:1c:06:e2, length 28 13:39:59.241465 4c:cf:7c:bf:f6:a1 > ff:ff:ff:ff:ff:ff, ethertype 802.1Q (0x8100), length 64: vlan 0, p 0, ethertype ARP (0x0806), Request who-has 192.168.1.100 tell 192.168.1.101, length 46 13:39:59.241500 64:1c:10:1c:06:e2 > 4c:cf:7c:bf:f6:a1, ethertype ARP (0x0806), length 42: Reply 192.168.1.100 is-at 64:1c:10:1c:06:e2, length 28 13:40:00.265877 4c:cf:7c:bf:f6:a1 > ff:ff:ff:ff:ff:ff, ethertype 802.1Q (0x8100), length 64: vlan 0, p 0, ethertype ARP (0x0806), Request who-has 192.168.1.100 tell 192.168.1.101, length 46 13:40:00.265913 64:1c:10:1c:06:e2 > 4c:cf:7c:bf:f6:a1, ethertype ARP (0x0806), length 42: Reply 192.168.1.100 is-at 64:1c:10:1c:06:e2, length 28 13:40:01.289403 4c:cf:7c:bf:f6:a1 > ff:ff:ff:ff:ff:ff, ethertype 802.1Q (0x8100), length 64: vlan 0, p 0, ethertype ARP (0x0806), Request who-has 192.168.1.100 tell 192.168.1.101, length 46 13:40:01.289468 64:1c:10:1c:06:e2 > 4c:cf:7c:bf:f6:a1, ethertype ARP (0x0806), length 42: Reply 192.168.1.100 is-at 64:1c:10:1c:06:e2, length 28 13:40:02.313582 4c:cf:7c:bf:f6:a1 > ff:ff:ff:ff:ff:ff, ethertype 802.1Q (0x8100), length 64: vlan 0, p 0, ethertype ARP (0x0806), Request who-has 192.168.1.100 tell 192.168.1.101, length 46 13:40:02.313638 64:1c:10:1c:06:e2 > 4c:cf:7c:bf:f6:a1, ethertype ARP (0x0806), length 42: Reply 192.168.1.100 is-at 64:1c:10:1c:06:e2, length 28 13:40:03.337456 4c:cf:7c:bf:f6:a1 > ff:ff:ff:ff:ff:ff, ethertype 802.1Q (0x8100), length 64: vlan 0, p 0, ethertype ARP (0x0806), Request who-has 192.168.1.100 tell 192.168.1.101, length 46 13:40:03.337503 64:1c:10:1c:06:e2 > 4c:cf:7c:bf:f6:a1, ethertype ARP (0x0806), length 42: Reply 192.168.1.100 is-at 64:1c:10:1c:06:e2, length 28 13:40:04.361696 4c:cf:7c:bf:f6:a1 > ff:ff:ff:ff:ff:ff, ethertype 802.1Q (0x8100), length 64: vlan 0, p 0, ethertype ARP (0x0806), Request who-has 192.168.1.100 tell 192.168.1.101, length 46 13:40:04.361800 64:1c:10:1c:06:e2 > 4c:cf:7c:bf:f6:a1, ethertype ARP (0x0806), length 42: Reply 192.168.1.100 is-at 64:1c:10:1c:06:e2, length 28 13:40:05.385632 4c:cf:7c:bf:f6:a1 > ff:ff:ff:ff:ff:ff, ethertype 802.1Q (0x8100), length 64: vlan 0, p 0, ethertype ARP (0x0806), Request who-has 192.168.1.100 tell 192.168.1.101, length 46 13:40:05.385679 64:1c:10:1c:06:e2 > 4c:cf:7c:bf:f6:a1, ethertype ARP (0x0806), length 42: Reply 192.168.1.100 is-at 64:1c:10:1c:06:e2, length 28 13:40:06.409875 4c:cf:7c:bf:f6:a1 > ff:ff:ff:ff:ff:ff, ethertype 802.1Q (0x8100), length 64: vlan 0, p 0, ethertype ARP (0x0806), Request who-has 192.168.1.100 tell 192.168.1.101, length 46 13:40:06.409933 64:1c:10:1c:06:e2 > 4c:cf:7c:bf:f6:a1, ethertype ARP (0x0806), length 42: Reply 192.168.1.100 is-at 64:1c:10:1c:06:e2, length 28 13:40:07.433415 4c:cf:7c:bf:f6:a1 > ff:ff:ff:ff:ff:ff, ethertype 802.1Q (0x8100), length 64: vlan 0, p 0, ethertype ARP (0x0806), Request who-has 192.168.1.100 tell 192.168.1.101, length 46 13:40:07.433464 64:1c:10:1c:06:e2 > 4c:cf:7c:bf:f6:a1, ethertype ARP (0x0806), length 42: Reply 192.168.1.100 is-at 64:1c:10:1c:06:e2, length 28 13:40:08.457402 4c:cf:7c:bf:f6:a1 > ff:ff:ff:ff:ff:ff, ethertype 802.1Q (0x8100), length 64: vlan 0, p 0, ethertype ARP (0x0806), Request who-has 192.168.1.100 tell 192.168.1.101, length 46 13:40:08.457451 64:1c:10:1c:06:e2 > 4c:cf:7c:bf:f6:a1, ethertype ARP (0x0806), length 42: Reply 192.168.1.100 is-at 64:1c:10:1c:06:e2, length 28 13:40:09.482122 4c:cf:7c:bf:f6:a1 > ff:ff:ff:ff:ff:ff, ethertype 802.1Q (0x8100), length 64: vlan 0, p 0, ethertype ARP (0x0806), Request who-has 192.168.1.100 tell 192.168.1.101, length 46 13:40:09.482161 64:1c:10:1c:06:e2 > 4c:cf:7c:bf:f6:a1, ethertype ARP (0x0806), length 42: Reply 192.168.1.100 is-at 64:1c:10:1c:06:e2, length 28 13:40:10.505290 4c:cf:7c:bf:f6:a1 > ff:ff:ff:ff:ff:ff, ethertype 802.1Q (0x8100), length 64: vlan 0, p 0, ethertype ARP (0x0806), Request who-has 192.168.1.100 tell 192.168.1.101, length 46 13:40:10.505346 64:1c:10:1c:06:e2 > 4c:cf:7c:bf:f6:a1, ethertype ARP (0x0806), length 42: Reply 192.168.1.100 is-at 64:1c:10:1c:06:e2, length 28 13:40:11.529470 4c:cf:7c:bf:f6:a1 > ff:ff:ff:ff:ff:ff, ethertype 802.1Q (0x8100), length 64: vlan 0, p 0, ethertype ARP (0x0806), Request who-has 192.168.1.100 tell 192.168.1.101, length 46 13:40:11.529514 64:1c:10:1c:06:e2 > 4c:cf:7c:bf:f6:a1, ethertype ARP (0x0806), length 42: Reply 192.168.1.100 is-at 64:1c:10:1c:06:e2, length 28 13:40:12.554164 4c:cf:7c:bf:f6:a1 > ff:ff:ff:ff:ff:ff, ethertype 802.1Q (0x8100), length 64: vlan 0, p 0, ethertype ARP (0x0806), Request who-has 192.168.1.100 tell 192.168.1.101, length 46 13:40:12.554205 64:1c:10:1c:06:e2 > 4c:cf:7c:bf:f6:a1, ethertype ARP (0x0806), length 42: Reply 192.168.1.100 is-at 64:1c:10:1c:06:e2, length 28 13:40:13.577538 4c:cf:7c:bf:f6:a1 > ff:ff:ff:ff:ff:ff, ethertype 802.1Q (0x8100), length 64: vlan 0, p 0, ethertype ARP (0x0806), Request who-has 192.168.1.100 tell 192.168.1.101, length 46 13:40:13.577575 64:1c:10:1c:06:e2 > 4c:cf:7c:bf:f6:a1, ethertype ARP (0x0806), length 42: Reply 192.168.1.100 is-at 64:1c:10:1c:06:e2, length 28 13:40:14.601223 4c:cf:7c:bf:f6:a1 > ff:ff:ff:ff:ff:ff, ethertype 802.1Q (0x8100), length 64: vlan 0, p 0, ethertype ARP (0x0806), Request who-has 192.168.1.100 tell 192.168.1.101, length 46 13:40:14.601263 64:1c:10:1c:06:e2 > 4c:cf:7c:bf:f6:a1, ethertype ARP (0x0806), length 42: Reply 192.168.1.100 is-at 64:1c:10:1c:06:e2, length 28 13:40:15.625718 4c:cf:7c:bf:f6:a1 > ff:ff:ff:ff:ff:ff, ethertype 802.1Q (0x8100), length 64: vlan 0, p 0, ethertype ARP (0x0806), Request who-has 192.168.1.100 tell 192.168.1.101, length 46 13:40:15.625758 64:1c:10:1c:06:e2 > 4c:cf:7c:bf:f6:a1, ethertype ARP (0x0806), length 42: Reply 192.168.1.100 is-at 64:1c:10:1c:06:e2, length 28 13:40:16.649218 4c:cf:7c:bf:f6:a1 > ff:ff:ff:ff:ff:ff, ethertype 802.1Q (0x8100), length 64: vlan 0, p 0, ethertype ARP (0x0806), Request who-has 192.168.1.100 tell 192.168.1.101, length 46 13:40:16.649272 64:1c:10:1c:06:e2 > 4c:cf:7c:bf:f6:a1, ethertype ARP (0x0806), length 42: Reply 192.168.1.100 is-at 64:1c:10:1c:06:e2, length 28 13:40:17.673325 4c:cf:7c:bf:f6:a1 > ff:ff:ff:ff:ff:ff, ethertype 802.1Q (0x8100), length 64: vlan 0, p 0, ethertype ARP (0x0806), Request who-has 192.168.1.100 tell 192.168.1.101, length 46 13:40:17.673371 64:1c:10:1c:06:e2 > 4c:cf:7c:bf:f6:a1, ethertype ARP (0x0806), length 42: Reply 192.168.1.100 is-at 64:1c:10:1c:06:e2, length 28 13:40:18.698021 4c:cf:7c:bf:f6:a1 > ff:ff:ff:ff:ff:ff, ethertype 802.1Q (0x8100), length 64: vlan 0, p 0, ethertype ARP (0x0806), Request who-has 192.168.1.100 tell 192.168.1.101, length 46 13:40:18.698065 64:1c:10:1c:06:e2 > 4c:cf:7c:bf:f6:a1, ethertype ARP (0x0806), length 42: Reply 192.168.1.100 is-at 64:1c:10:1c:06:e2, length 28 13:40:19.721618 4c:cf:7c:bf:f6:a1 > ff:ff:ff:ff:ff:ff, ethertype 802.1Q (0x8100), length 64: vlan 0, p 0, ethertype ARP (0x0806), Request who-has 192.168.1.100 tell 192.168.1.101, length 46 13:40:19.721706 64:1c:10:1c:06:e2 > 4c:cf:7c:bf:f6:a1, ethertype ARP (0x0806), length 42: Reply 192.168.1.100 is-at 64:1c:10:1c:06:e2, length 28 13:40:20.745228 4c:cf:7c:bf:f6:a1 > ff:ff:ff:ff:ff:ff, ethertype 802.1Q (0x8100), length 64: vlan 0, p 0, ethertype ARP (0x0806), Request who-has 192.168.1.100 tell 192.168.1.101, length 46 13:40:20.745272 64:1c:10:1c:06:e2 > 4c:cf:7c:bf:f6:a1, ethertype ARP (0x0806), length 42: Reply 192.168.1.100 is-at 64:1c:10:1c:06:e2, length 28 13:40:21.770216 4c:cf:7c:bf:f6:a1 > ff:ff:ff:ff:ff:ff, ethertype 802.1Q (0x8100), length 64: vlan 0, p 0, ethertype ARP (0x0806), Request who-has 192.168.1.100 tell 192.168.1.101, length 46 13:40:21.770260 64:1c:10:1c:06:e2 > 4c:cf:7c:bf:f6:a1, ethertype ARP (0x0806), length 42: Reply 192.168.1.100 is-at 64:1c:10:1c:06:e2, length 28 13:40:22.793695 4c:cf:7c:bf:f6:a1 > ff:ff:ff:ff:ff:ff, ethertype 802.1Q (0x8100), length 64: vlan 0, p 0, ethertype ARP (0x0806), Request who-has 192.168.1.100 tell 192.168.1.101, length 46 13:40:22.793738 64:1c:10:1c:06:e2 > 4c:cf:7c:bf:f6:a1, ethertype ARP (0x0806), length 42: Reply 192.168.1.100 is-at 64:1c:10:1c:06:e2, length 28 13:40:23.817397 4c:cf:7c:bf:f6:a1 > ff:ff:ff:ff:ff:ff, ethertype 802.1Q (0x8100), length 64: vlan 0, p 0, ethertype ARP (0x0806), Request who-has 192.168.1.100 tell 192.168.1.101, length 46 13:40:23.817436 64:1c:10:1c:06:e2 > 4c:cf:7c:bf:f6:a1, ethertype ARP (0x0806), length 42: Reply 192.168.1.100 is-at 64:1c:10:1c:06:e2, length 28 ^C 72 packets captured 72 packets received by filter 0 packets dr[ 88.275081] am65-cpsw-nuss 8000000.ethernet eth0: left promiscuous mode opped by kernel [ 88.287106] audit: type=1700 audit(1748612425.824:20): dev=eth0 prom=0 old_prom=256 auid=4294967295 uid=0 gid=0 ses=4294967295 [ 88.340396] audit: type=1300 audit(1748612425.824:20): arch=c00000b7 syscall=57 success=yes exit=0 a0=4 a1=1 a2=2 a3=1d22f010 items=0 ppid=701 pid=713 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=ttyS2 ses=4294967295 comm="tcpdump" exe="/usr/bin/tcpdump" subj=kernel key=(null) [ 88.367618] audit: type=1327 audit(1748612425.824:20): proctitle=74637064756D70002D6E690065746830002D6500617270006F720069636D70 4c:cf:7c:bf:f6:a1は私のPCのイーサネットポートのMACアドレスです これらのメッセージは、PC側で「宛先ホストに到達できません」と表示されてから約2秒後に始まります。
View full article
如何在不启用任何中断的情况下将 LPI2C 外设与 DMA 配合使用? 你好, 我正在使用NXP S32K396 MCU ,并且希望在不启用任何中断的情况下使用 eDMA 执行 LPI2C 主站事务。在我的项目中,我使用了LPI2C1外设。 当启用以下中断时,我可以使用 DMA 成功执行 LPI2C 读写事务: LPI2C1_IRQn eDMA0_DMATTCD_CH16_CH17_IRQn 然而,RTD LPI2C DMA 实现似乎依赖于这些中断。 在 Lpi2c_Ip_MasterSendData() 函数中,LPI2C 主中断始终由驱动程序启用: 此外,通过 Lpi2c_Ip_MasterTxDmaConfig() 和 Lpi2c_Ip_MasterRxDmaConfig() 配置的 TX 和 RX 的 DMA TCD 始终启用 DMA 主循环完成中断: Lpi2c_DmaTransferList[9u] .Param = DMA_IP_CH_SET_CONTROL_EN_MAJOR_INTERRUPT ; Lpi2c_DmaTransferList[9u] .Value = 1U; 我还注意到,在其他函数中 - Lpi2c_Ip_MasterSendDataBlocking() 似乎没有为 LPI2C 传输配置 DMA TCD。 我希望使用 DMA 执行完整的 LPI2C 发送和接收事务,同时禁用 LPI2C1_IRQn 和 eDMA 通道中断。   如果可以的话,NXP能否提供一个使用DMA的LPI2C主控端TX/RX示例,其中LPI2C和DMA中断均被禁用?   MCU:NXPS32K396 RTD:6.0.0 NXP Studio:3.6.1   非常感谢您的帮助。非常感谢! 如有需要,我可以附上我的项目文件。 Re: How to use LPI2C peripheral with DMA without enabling any interrupts? 你好@ rkhw 从当前的驱动程序实现来看,“Lpi2c_Ip_MasterSendData()”依赖于LPI2C主中断和DMA主循环完成中断来进行传输完成和状态处理。 因此,如果不启用中断,就无法启用 DMA。RTD驱动程序不支持此用法。
View full article
SPI用のDMAを設定する必要があります 私はS32DS IDEとRTD 3.0を使っています。SPIでDMAを起動する方法や、ステップバイステップの手順や、もしあれば他の例コードがあれば教えてもらえますか? Re: I need to configure DMA for SPI ご回答ありがとうございます。 この作業はs32k322 MCUで行ってください Re: I need to configure DMA for SPI こんにちは@ershi RTDにはDMAを用いたSPI通信用の2つの例コードが付属しており、1つは低レベルドライバ(Ip)を用い、もう1つは高レベルドライバ(MCAL)を使用します。例のインポート方法については、HOWTO: S32 Design Studio - Create a New S32DS Project from Example Threadを参照してください。 また、スレッドの 例であるS32K31 SPI Multiple Packet Transmit and Receive: Solution for DMA Cache Issueの例を参照することもできます。 BR、VaneB Re: I need to configure DMA for SPI こんにちは@ershi これらの例はS32K322向けに特別に設計されているわけではありませんが、リファレンス・マニュアルに特に記載されていない限り、S32K3 ファミリ全体で機能性は概ね同じです。したがって、このプロジェクトを実装の参考として活用し、必要に応じてデバイスに合わせて調整することができます。
View full article
TJA1120A 1000BASET1 Linux side configuration We are using TJA1120A PHY on our ECU board based on am72a7, and DP83TG721EVM-MC Media Converter.  Right now the Link is ON  root@am62axx-evm:~# dmesg | grep eth [ 0.000000] psci: probing for conduit method from DT. [ 0.944429] optee: probing for conduit method. [ 1.352845] am65-cpsw-nuss 8000000.ethernet: initializing am65 cpsw nuss version 0x6BA01103, cpsw version 0x6BA81103 Ports: 3 quirks:00000006 [ 1.365779] am65-cpsw-nuss 8000000.ethernet: Use random MAC address [ 1.452604] am65-cpsw-nuss 8000000.ethernet: initialized cpsw ale version 1.5 [ 1.459737] am65-cpsw-nuss 8000000.ethernet: ALE Table size 512, Policers 32 [ 1.467615] am65-cpsw-nuss 8000000.ethernet: CPTS ver 0x4e8a010c, freq:500000000, add_val:1 pps:1 [ 1.488042] am65-cpsw-nuss 8000000.ethernet: set new flow-id-base 19 [ 5.875382] am65-cpsw-nuss 8000000.ethernet eth1: PHY [8000f00.mdio:00] driver [Micrel KSZ9031 Gigabit PHY] (irq=POLL) [ 5.890378] am65-cpsw-nuss 8000000.ethernet eth1: configuring for phy/rgmii link mode [ 6.618291] am65-cpsw-nuss 8000000.ethernet eth0: PHY [8000f00.mdio:04] driver [NXP C45 TJA1120] (irq=POLL) [ 6.629693] am65-cpsw-nuss 8000000.ethernet eth0: configuring for phy/rgmii link mode [ 6.662963] am65-cpsw-nuss 8000000.ethernet eth0: Link is Up - 1Gbps/Full - flow control off [ 38.194116] am65-cpsw-nuss 8000000.ethernet eth0: Link is Down [ 116.023614] am65-cpsw-nuss 8000000.ethernet eth0: Link is Up - 1Gbps/Full - flow control off I made TJA1120 eth0 to slave mode, and configured(HW Jumpers) master to Media converter root@am62axx-evm:~# ethtool eth0 Settings for eth0: Supported ports: [ TP MII ] Supported link modes: 1000baseT1/Full Supported pause frame use: Symmetric Supports auto-negotiation: No Supported FEC modes: Not reported Advertised link modes: 1000baseT1/Full Advertised pause frame use: Symmetric Advertised auto-negotiation: No Advertised FEC modes: Not reported Speed: 1000Mb/s Duplex: Full Auto-negotiation: off master-slave cfg: forced slave master-slave status: slave Port: Twisted Pair PHYAD: 4 Transceiver: external MDI-X: Unknown Supports Wake-on: d Wake-on: d Current message level: 0x000020f7 (8439) drv probe link ifdown ifup rx_err tx_err hw Link detected: yes SQI: 7/7 root@am62axx-evm:~# ifconfig eth0 eth0 Link encap:Ethernet HWaddr 64:1C:10:1C:06:E2 inet addr:192.168.1.100 Bcast:192.168.1.255 Mask:255.255.255.0 inet6 addr: fe80::661c:10ff:fe1c:6e2/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:118 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:0 (0.0 B) TX bytes:24044 (23.4 KiB) Now i have set my ECU to 192.168.1.100 and my PC(connected to Media Converter) to 192.168.1.101 Ping is not happening but LED indicators on ECU blink when I ping from my PC acs@a-tract-10:~$ ping 192.168.1.100 PING 192.168.1.100 (192.168.1.100) 56(84) bytes of data. From 192.168.1.101 icmp_seq=1 Destination Host Unreachable From 192.168.1.101 icmp_seq=2 Destination Host Unreachable From 192.168.1.101 icmp_seq=3 Destination Host Unreachable From 192.168.1.101 icmp_seq=4 Destination Host Unreachable From 192.168.1.101 icmp_seq=5 Destination Host Unreachable From 192.168.1.101 icmp_seq=6 Destination Host Unreachable ^C --- 192.168.1.100 ping statistics --- 8 packets transmitted, 0 received, +6 errors, 100% packet loss, time 7185ms pipe 4 Is there any extra configuration to be done for Auto-Ethernet? Re: TJA1120A 1000BASET1 Linux side configuration Hello @vikyhre , Based on the new logs, the 1000BASE-T1 side seems to be working correctly. The TJA1120 PHY is detected, the link is up at 1 Gbit/s, the master/slave status is correct and SQI is reported as 7/7. However, the Ethernet interface statistics still show RX packets equal to zero while TX packets are increasing. This suggests that the received frames are not reaching the Linux MAC/network stack. Please re-check the RGMII timing configuration in the Linux device tree. The log shows that the interface is configured as "phy/rgmii". If your board design expects the PHY to provide the internal RGMII delays, the device tree should typically use "rgmii-id" instead of plain "rgmii" instance. A mismatch in RGMII delay configuration can result in exactly this behavior: PHY link up and good SQI, but no successful packet reception by Linux. Could you also check with Wireshark on the PC side whether any frames transmitted by the ECU are visible there? For example, after bringing eth0 up on the ECU, please check whether ARP, IPv6 neighbor discovery or any other Ethernet frames from the ECU MAC address are captured on the PC. At the same time, please run tcpdump on the ECU side while pinging from the PC: tcpdump -ni eth0 -e arp or icmp If no ARP/ICMP packets are captured and the RX counter remains zero, the issue is most likely still in the MAC-to-PHY RGMII path or its device-tree timing configuration, not in the 1000BASE-T1 link itself. Best regards, Pavel Re: TJA1120A 1000BASET1 Linux side configuration Pavel, just as you said I made CONFIG3,4 pins to RGMII-ID (as per 6.7.2 of TJA1120A Datasheet, I tried both RGMII-ID and RGMII-ID (TX/RX) ). Also set phy-mode as "rgmii-id" &cpsw_port1 { status = "okay"; phy-mode = "rgmii-id"; phy-handle = <&cpsw3g_phy0>; };  This was reflected in dmesg [ 6.817790] am65-cpsw-nuss 8000000.ethernet eth0: configuring for phy/rgmii-id link mode But pinging was still not working acs@a-tract-10:~$ ping 192.168.1.100 PING 192.168.1.100 (192.168.1.100) 56(84) bytes of data. From 192.168.1.101 icmp_seq=1 Destination Host Unreachable From 192.168.1.101 icmp_seq=2 Destination Host Unreachable From 192.168.1.101 icmp_seq=3 Destination Host Unreachable From 192.168.1.101 icmp_seq=4 Destination Host Unreachable From 192.168.1.101 icmp_seq=5 Destination Host Unreachable From 192.168.1.101 icmp_seq=6 Destination Host Unreachable From 192.168.1.101 icmp_seq=7 Destination Host Unreachable From 192.168.1.101 icmp_seq=8 Destination Host Unreachable From 192.168.1.101 icmp_seq=9 Destination Host Unreachable From 192.168.1.101 icmp_seq=10 Destination Host Unreachable From 192.168.1.101 icmp_seq=11 Destination Host Unreachable From 192.168.1.101 icmp_seq=12 Destination Host Unreachable From 192.168.1.101 icmp_seq=13 Destination Host Unreachable From 192.168.1.101 icmp_seq=17 Destination Host Unreachable From 192.168.1.101 icmp_seq=18 Destination Host Unreachable From 192.168.1.101 icmp_seq=19 Destination Host Unreachable From 192.168.1.101 icmp_seq=20 Destination Host Unreachable From 192.168.1.101 icmp_seq=21 Destination Host Unreachable From 192.168.1.101 icmp_seq=22 Destination Host Unreachable From 192.168.1.101 icmp_seq=23 Destination Host Unreachable From 192.168.1.101 icmp_seq=24 Destination Host Unreachable ^C --- 192.168.1.100 ping statistics --- 25 packets transmitted, 0 received, +21 errors, 100% packet loss, time 24598ms pipe 4 But i tried to monitor on ECU side while pinging from my PC as you said root@am62axx-evm:~# tcpdump -ni eth0 -e arp or icmp [ 36.233694] am65-cpsw-nuss 8000000.ethernet eth0: entered promiscuous mode [ 36.240729] kauditd_printk_skb: 5 callbacks suppressed [ 36.240737] audit: type=1700 audit(1748612373.780:19): dev=eth0 prom=256 old_ prom=0 auid=4294967295 uid=0 gid=0 ses=4294967295 [ 36.257330] audit: type=1300 audit(1748612373.780:19): arch=c00000b7 syscall= 208 success=yes exit=0 a0=4 a1=107 a2=1 a3=fffffb4ab040 items=0 ppid=701 pid=713 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=tty S2 ses=4294967295 comm="tcpdump" exe="/usr/bin/tcpdump" subj=kernel key=(null) [ 36.285128] audit: type=1327 audit(1748612373.780:19): proctitle=74637064756D 70002D6E690065746830002D6500617270006F720069636D70 tcpdump: verbose output suppressed, use -v[v]... for full protocol decode listening on eth0, link-type EN10MB (Ethernet), snapshot length 262144 bytes 13:39:47.956062 4c:cf:7c:bf:f6:a1 > ff:ff:ff:ff:ff:ff, ethertype 802.1Q (0x8100), length 64: vlan 0, p 0, ethertype ARP (0x0806), Request who-has 192.168.1.100 tell 192.168.1.101, length 46 13:39:47.956161 64:1c:10:1c:06:e2 > 4c:cf:7c:bf:f6:a1, ethertype ARP (0x0806), length 42: Reply 192.168.1.100 is-at 64:1c:10:1c:06:e2, length 28 13:39:49.001519 4c:cf:7c:bf:f6:a1 > ff:ff:ff:ff:ff:ff, ethertype 802.1Q (0x8100), length 64: vlan 0, p 0, ethertype ARP (0x0806), Request who-has 192.168.1.100 tell 192.168.1.101, length 46 13:39:49.001576 64:1c:10:1c:06:e2 > 4c:cf:7c:bf:f6:a1, ethertype ARP (0x0806), length 42: Reply 192.168.1.100 is-at 64:1c:10:1c:06:e2, length 28 13:39:50.025527 4c:cf:7c:bf:f6:a1 > ff:ff:ff:ff:ff:ff, ethertype 802.1Q (0x8100), length 64: vlan 0, p 0, ethertype ARP (0x0806), Request who-has 192.168.1.100 tell 192.168.1.101, length 46 13:39:50.025574 64:1c:10:1c:06:e2 > 4c:cf:7c:bf:f6:a1, ethertype ARP (0x0806), length 42: Reply 192.168.1.100 is-at 64:1c:10:1c:06:e2, length 28 13:39:51.049972 4c:cf:7c:bf:f6:a1 > ff:ff:ff:ff:ff:ff, ethertype 802.1Q (0x8100), length 64: vlan 0, p 0, ethertype ARP (0x0806), Request who-has 192.168.1.100 tell 192.168.1.101, length 46 13:39:51.050015 64:1c:10:1c:06:e2 > 4c:cf:7c:bf:f6:a1, ethertype ARP (0x0806), length 42: Reply 192.168.1.100 is-at 64:1c:10:1c:06:e2, length 28 13:39:52.073514 4c:cf:7c:bf:f6:a1 > ff:ff:ff:ff:ff:ff, ethertype 802.1Q (0x8100), length 64: vlan 0, p 0, ethertype ARP (0x0806), Request who-has 192.168.1.100 tell 192.168.1.101, length 46 13:39:52.073561 64:1c:10:1c:06:e2 > 4c:cf:7c:bf:f6:a1, ethertype ARP (0x0806), length 42: Reply 192.168.1.100 is-at 64:1c:10:1c:06:e2, length 28 13:39:53.097481 4c:cf:7c:bf:f6:a1 > ff:ff:ff:ff:ff:ff, ethertype 802.1Q (0x8100), length 64: vlan 0, p 0, ethertype ARP (0x0806), Request who-has 192.168.1.100 tell 192.168.1.101, length 46 13:39:53.097522 64:1c:10:1c:06:e2 > 4c:cf:7c:bf:f6:a1, ethertype ARP (0x0806), length 42: Reply 192.168.1.100 is-at 64:1c:10:1c:06:e2, length 28 13:39:54.121912 4c:cf:7c:bf:f6:a1 > ff:ff:ff:ff:ff:ff, ethertype 802.1Q (0x8100), length 64: vlan 0, p 0, ethertype ARP (0x0806), Request who-has 192.168.1.100 tell 192.168.1.101, length 46 13:39:54.121951 64:1c:10:1c:06:e2 > 4c:cf:7c:bf:f6:a1, ethertype ARP (0x0806), length 42: Reply 192.168.1.100 is-at 64:1c:10:1c:06:e2, length 28 13:39:55.145488 4c:cf:7c:bf:f6:a1 > ff:ff:ff:ff:ff:ff, ethertype 802.1Q (0x8100), length 64: vlan 0, p 0, ethertype ARP (0x0806), Request who-has 192.168.1.100 tell 192.168.1.101, length 46 13:39:55.145526 64:1c:10:1c:06:e2 > 4c:cf:7c:bf:f6:a1, ethertype ARP (0x0806), length 42: Reply 192.168.1.100 is-at 64:1c:10:1c:06:e2, length 28 13:39:56.169569 4c:cf:7c:bf:f6:a1 > ff:ff:ff:ff:ff:ff, ethertype 802.1Q (0x8100), length 64: vlan 0, p 0, ethertype ARP (0x0806), Request who-has 192.168.1.100 tell 192.168.1.101, length 46 13:39:56.169613 64:1c:10:1c:06:e2 > 4c:cf:7c:bf:f6:a1, ethertype ARP (0x0806), length 42: Reply 192.168.1.100 is-at 64:1c:10:1c:06:e2, length 28 13:39:57.193883 4c:cf:7c:bf:f6:a1 > ff:ff:ff:ff:ff:ff, ethertype 802.1Q (0x8100), length 64: vlan 0, p 0, ethertype ARP (0x0806), Request who-has 192.168.1.100 tell 192.168.1.101, length 46 13:39:57.193925 64:1c:10:1c:06:e2 > 4c:cf:7c:bf:f6:a1, ethertype ARP (0x0806), length 42: Reply 192.168.1.100 is-at 64:1c:10:1c:06:e2, length 28 13:39:58.217586 4c:cf:7c:bf:f6:a1 > ff:ff:ff:ff:ff:ff, ethertype 802.1Q (0x8100), length 64: vlan 0, p 0, ethertype ARP (0x0806), Request who-has 192.168.1.100 tell 192.168.1.101, length 46 13:39:58.217629 64:1c:10:1c:06:e2 > 4c:cf:7c:bf:f6:a1, ethertype ARP (0x0806), length 42: Reply 192.168.1.100 is-at 64:1c:10:1c:06:e2, length 28 13:39:59.241465 4c:cf:7c:bf:f6:a1 > ff:ff:ff:ff:ff:ff, ethertype 802.1Q (0x8100), length 64: vlan 0, p 0, ethertype ARP (0x0806), Request who-has 192.168.1.100 tell 192.168.1.101, length 46 13:39:59.241500 64:1c:10:1c:06:e2 > 4c:cf:7c:bf:f6:a1, ethertype ARP (0x0806), length 42: Reply 192.168.1.100 is-at 64:1c:10:1c:06:e2, length 28 13:40:00.265877 4c:cf:7c:bf:f6:a1 > ff:ff:ff:ff:ff:ff, ethertype 802.1Q (0x8100), length 64: vlan 0, p 0, ethertype ARP (0x0806), Request who-has 192.168.1.100 tell 192.168.1.101, length 46 13:40:00.265913 64:1c:10:1c:06:e2 > 4c:cf:7c:bf:f6:a1, ethertype ARP (0x0806), length 42: Reply 192.168.1.100 is-at 64:1c:10:1c:06:e2, length 28 13:40:01.289403 4c:cf:7c:bf:f6:a1 > ff:ff:ff:ff:ff:ff, ethertype 802.1Q (0x8100), length 64: vlan 0, p 0, ethertype ARP (0x0806), Request who-has 192.168.1.100 tell 192.168.1.101, length 46 13:40:01.289468 64:1c:10:1c:06:e2 > 4c:cf:7c:bf:f6:a1, ethertype ARP (0x0806), length 42: Reply 192.168.1.100 is-at 64:1c:10:1c:06:e2, length 28 13:40:02.313582 4c:cf:7c:bf:f6:a1 > ff:ff:ff:ff:ff:ff, ethertype 802.1Q (0x8100), length 64: vlan 0, p 0, ethertype ARP (0x0806), Request who-has 192.168.1.100 tell 192.168.1.101, length 46 13:40:02.313638 64:1c:10:1c:06:e2 > 4c:cf:7c:bf:f6:a1, ethertype ARP (0x0806), length 42: Reply 192.168.1.100 is-at 64:1c:10:1c:06:e2, length 28 13:40:03.337456 4c:cf:7c:bf:f6:a1 > ff:ff:ff:ff:ff:ff, ethertype 802.1Q (0x8100), length 64: vlan 0, p 0, ethertype ARP (0x0806), Request who-has 192.168.1.100 tell 192.168.1.101, length 46 13:40:03.337503 64:1c:10:1c:06:e2 > 4c:cf:7c:bf:f6:a1, ethertype ARP (0x0806), length 42: Reply 192.168.1.100 is-at 64:1c:10:1c:06:e2, length 28 13:40:04.361696 4c:cf:7c:bf:f6:a1 > ff:ff:ff:ff:ff:ff, ethertype 802.1Q (0x8100), length 64: vlan 0, p 0, ethertype ARP (0x0806), Request who-has 192.168.1.100 tell 192.168.1.101, length 46 13:40:04.361800 64:1c:10:1c:06:e2 > 4c:cf:7c:bf:f6:a1, ethertype ARP (0x0806), length 42: Reply 192.168.1.100 is-at 64:1c:10:1c:06:e2, length 28 13:40:05.385632 4c:cf:7c:bf:f6:a1 > ff:ff:ff:ff:ff:ff, ethertype 802.1Q (0x8100), length 64: vlan 0, p 0, ethertype ARP (0x0806), Request who-has 192.168.1.100 tell 192.168.1.101, length 46 13:40:05.385679 64:1c:10:1c:06:e2 > 4c:cf:7c:bf:f6:a1, ethertype ARP (0x0806), length 42: Reply 192.168.1.100 is-at 64:1c:10:1c:06:e2, length 28 13:40:06.409875 4c:cf:7c:bf:f6:a1 > ff:ff:ff:ff:ff:ff, ethertype 802.1Q (0x8100), length 64: vlan 0, p 0, ethertype ARP (0x0806), Request who-has 192.168.1.100 tell 192.168.1.101, length 46 13:40:06.409933 64:1c:10:1c:06:e2 > 4c:cf:7c:bf:f6:a1, ethertype ARP (0x0806), length 42: Reply 192.168.1.100 is-at 64:1c:10:1c:06:e2, length 28 13:40:07.433415 4c:cf:7c:bf:f6:a1 > ff:ff:ff:ff:ff:ff, ethertype 802.1Q (0x8100), length 64: vlan 0, p 0, ethertype ARP (0x0806), Request who-has 192.168.1.100 tell 192.168.1.101, length 46 13:40:07.433464 64:1c:10:1c:06:e2 > 4c:cf:7c:bf:f6:a1, ethertype ARP (0x0806), length 42: Reply 192.168.1.100 is-at 64:1c:10:1c:06:e2, length 28 13:40:08.457402 4c:cf:7c:bf:f6:a1 > ff:ff:ff:ff:ff:ff, ethertype 802.1Q (0x8100), length 64: vlan 0, p 0, ethertype ARP (0x0806), Request who-has 192.168.1.100 tell 192.168.1.101, length 46 13:40:08.457451 64:1c:10:1c:06:e2 > 4c:cf:7c:bf:f6:a1, ethertype ARP (0x0806), length 42: Reply 192.168.1.100 is-at 64:1c:10:1c:06:e2, length 28 13:40:09.482122 4c:cf:7c:bf:f6:a1 > ff:ff:ff:ff:ff:ff, ethertype 802.1Q (0x8100), length 64: vlan 0, p 0, ethertype ARP (0x0806), Request who-has 192.168.1.100 tell 192.168.1.101, length 46 13:40:09.482161 64:1c:10:1c:06:e2 > 4c:cf:7c:bf:f6:a1, ethertype ARP (0x0806), length 42: Reply 192.168.1.100 is-at 64:1c:10:1c:06:e2, length 28 13:40:10.505290 4c:cf:7c:bf:f6:a1 > ff:ff:ff:ff:ff:ff, ethertype 802.1Q (0x8100), length 64: vlan 0, p 0, ethertype ARP (0x0806), Request who-has 192.168.1.100 tell 192.168.1.101, length 46 13:40:10.505346 64:1c:10:1c:06:e2 > 4c:cf:7c:bf:f6:a1, ethertype ARP (0x0806), length 42: Reply 192.168.1.100 is-at 64:1c:10:1c:06:e2, length 28 13:40:11.529470 4c:cf:7c:bf:f6:a1 > ff:ff:ff:ff:ff:ff, ethertype 802.1Q (0x8100), length 64: vlan 0, p 0, ethertype ARP (0x0806), Request who-has 192.168.1.100 tell 192.168.1.101, length 46 13:40:11.529514 64:1c:10:1c:06:e2 > 4c:cf:7c:bf:f6:a1, ethertype ARP (0x0806), length 42: Reply 192.168.1.100 is-at 64:1c:10:1c:06:e2, length 28 13:40:12.554164 4c:cf:7c:bf:f6:a1 > ff:ff:ff:ff:ff:ff, ethertype 802.1Q (0x8100), length 64: vlan 0, p 0, ethertype ARP (0x0806), Request who-has 192.168.1.100 tell 192.168.1.101, length 46 13:40:12.554205 64:1c:10:1c:06:e2 > 4c:cf:7c:bf:f6:a1, ethertype ARP (0x0806), length 42: Reply 192.168.1.100 is-at 64:1c:10:1c:06:e2, length 28 13:40:13.577538 4c:cf:7c:bf:f6:a1 > ff:ff:ff:ff:ff:ff, ethertype 802.1Q (0x8100), length 64: vlan 0, p 0, ethertype ARP (0x0806), Request who-has 192.168.1.100 tell 192.168.1.101, length 46 13:40:13.577575 64:1c:10:1c:06:e2 > 4c:cf:7c:bf:f6:a1, ethertype ARP (0x0806), length 42: Reply 192.168.1.100 is-at 64:1c:10:1c:06:e2, length 28 13:40:14.601223 4c:cf:7c:bf:f6:a1 > ff:ff:ff:ff:ff:ff, ethertype 802.1Q (0x8100), length 64: vlan 0, p 0, ethertype ARP (0x0806), Request who-has 192.168.1.100 tell 192.168.1.101, length 46 13:40:14.601263 64:1c:10:1c:06:e2 > 4c:cf:7c:bf:f6:a1, ethertype ARP (0x0806), length 42: Reply 192.168.1.100 is-at 64:1c:10:1c:06:e2, length 28 13:40:15.625718 4c:cf:7c:bf:f6:a1 > ff:ff:ff:ff:ff:ff, ethertype 802.1Q (0x8100), length 64: vlan 0, p 0, ethertype ARP (0x0806), Request who-has 192.168.1.100 tell 192.168.1.101, length 46 13:40:15.625758 64:1c:10:1c:06:e2 > 4c:cf:7c:bf:f6:a1, ethertype ARP (0x0806), length 42: Reply 192.168.1.100 is-at 64:1c:10:1c:06:e2, length 28 13:40:16.649218 4c:cf:7c:bf:f6:a1 > ff:ff:ff:ff:ff:ff, ethertype 802.1Q (0x8100), length 64: vlan 0, p 0, ethertype ARP (0x0806), Request who-has 192.168.1.100 tell 192.168.1.101, length 46 13:40:16.649272 64:1c:10:1c:06:e2 > 4c:cf:7c:bf:f6:a1, ethertype ARP (0x0806), length 42: Reply 192.168.1.100 is-at 64:1c:10:1c:06:e2, length 28 13:40:17.673325 4c:cf:7c:bf:f6:a1 > ff:ff:ff:ff:ff:ff, ethertype 802.1Q (0x8100), length 64: vlan 0, p 0, ethertype ARP (0x0806), Request who-has 192.168.1.100 tell 192.168.1.101, length 46 13:40:17.673371 64:1c:10:1c:06:e2 > 4c:cf:7c:bf:f6:a1, ethertype ARP (0x0806), length 42: Reply 192.168.1.100 is-at 64:1c:10:1c:06:e2, length 28 13:40:18.698021 4c:cf:7c:bf:f6:a1 > ff:ff:ff:ff:ff:ff, ethertype 802.1Q (0x8100), length 64: vlan 0, p 0, ethertype ARP (0x0806), Request who-has 192.168.1.100 tell 192.168.1.101, length 46 13:40:18.698065 64:1c:10:1c:06:e2 > 4c:cf:7c:bf:f6:a1, ethertype ARP (0x0806), length 42: Reply 192.168.1.100 is-at 64:1c:10:1c:06:e2, length 28 13:40:19.721618 4c:cf:7c:bf:f6:a1 > ff:ff:ff:ff:ff:ff, ethertype 802.1Q (0x8100), length 64: vlan 0, p 0, ethertype ARP (0x0806), Request who-has 192.168.1.100 tell 192.168.1.101, length 46 13:40:19.721706 64:1c:10:1c:06:e2 > 4c:cf:7c:bf:f6:a1, ethertype ARP (0x0806), length 42: Reply 192.168.1.100 is-at 64:1c:10:1c:06:e2, length 28 13:40:20.745228 4c:cf:7c:bf:f6:a1 > ff:ff:ff:ff:ff:ff, ethertype 802.1Q (0x8100), length 64: vlan 0, p 0, ethertype ARP (0x0806), Request who-has 192.168.1.100 tell 192.168.1.101, length 46 13:40:20.745272 64:1c:10:1c:06:e2 > 4c:cf:7c:bf:f6:a1, ethertype ARP (0x0806), length 42: Reply 192.168.1.100 is-at 64:1c:10:1c:06:e2, length 28 13:40:21.770216 4c:cf:7c:bf:f6:a1 > ff:ff:ff:ff:ff:ff, ethertype 802.1Q (0x8100), length 64: vlan 0, p 0, ethertype ARP (0x0806), Request who-has 192.168.1.100 tell 192.168.1.101, length 46 13:40:21.770260 64:1c:10:1c:06:e2 > 4c:cf:7c:bf:f6:a1, ethertype ARP (0x0806), length 42: Reply 192.168.1.100 is-at 64:1c:10:1c:06:e2, length 28 13:40:22.793695 4c:cf:7c:bf:f6:a1 > ff:ff:ff:ff:ff:ff, ethertype 802.1Q (0x8100), length 64: vlan 0, p 0, ethertype ARP (0x0806), Request who-has 192.168.1.100 tell 192.168.1.101, length 46 13:40:22.793738 64:1c:10:1c:06:e2 > 4c:cf:7c:bf:f6:a1, ethertype ARP (0x0806), length 42: Reply 192.168.1.100 is-at 64:1c:10:1c:06:e2, length 28 13:40:23.817397 4c:cf:7c:bf:f6:a1 > ff:ff:ff:ff:ff:ff, ethertype 802.1Q (0x8100), length 64: vlan 0, p 0, ethertype ARP (0x0806), Request who-has 192.168.1.100 tell 192.168.1.101, length 46 13:40:23.817436 64:1c:10:1c:06:e2 > 4c:cf:7c:bf:f6:a1, ethertype ARP (0x0806), length 42: Reply 192.168.1.100 is-at 64:1c:10:1c:06:e2, length 28 ^C 72 packets captured 72 packets received by filter 0 packets dr[ 88.275081] am65-cpsw-nuss 8000000.ethernet eth0: left promiscuous mode opped by kernel [ 88.287106] audit: type=1700 audit(1748612425.824:20): dev=eth0 prom=0 old_prom=256 auid=4294967295 uid=0 gid=0 ses=4294967295 [ 88.340396] audit: type=1300 audit(1748612425.824:20): arch=c00000b7 syscall=57 success=yes exit=0 a0=4 a1=1 a2=2 a3=1d22f010 items=0 ppid=701 pid=713 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=ttyS2 ses=4294967295 comm="tcpdump" exe="/usr/bin/tcpdump" subj=kernel key=(null) [ 88.367618] audit: type=1327 audit(1748612425.824:20): proctitle=74637064756D70002D6E690065746830002D6500617270006F720069636D70 4c:cf:7c:bf:f6:a1 is MAC Address of Ethernet Port in my PC These messages start around 2s after Destination Host Unreachable shown in PC side.
View full article
I need to configure DMA for SPI I am using S32DS IDE and RTD 3.0 can anyone tell me how to start the DMA with SPI with step by step instructions or any other example code if available Re: I need to configure DMA for SPI Thank you for your response Do this work for s32k322 MCU Re: I need to configure DMA for SPI Hi @ershi  Included with the RTDs are provided two example codes for SPI communication using DMA, one using Low-Level Drivers (Ip) and one using High-Level Drivers (MCAL). You can refer to the thread HOWTO: S32 Design Studio - Create a New S32DS Project from Example for guidance on how to import the examples. Also, you can refer to the example provided in the thread Example S32K31 SPI Multiple Packet Transmit & Receive: Solution for DMA Cache Issue. BR, VaneB Re: I need to configure DMA for SPI Hi @ershi  Although the examples are not specifically designed for the S32K322, the functionality is generally the same across the S32K3 family, unless otherwise stated in the Reference Manual Therefore, you can use this project as a reference for your implementation and adapt it as needed for your specific device.
View full article