Multi Source Translation Content

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

Multi Source Translation Content

ディスカッション

ソート順:
EB AutoCore activation fails Hello everyone, Today I tried to activate the new AutoCore licence provided by NXP. When I try to activate it I get a failure message stating the licence is old, but in the web it says it is valid until 12/30/2026. I attach the activation log: Activating NodeLocked License 7FCB-75DF-0F6E-4E7A, Number Of Licenses: 1 Status: 4, Creating request Status: 5, Request created Status: 6, Context created Status: 7, Connected to remote server Status: 8, Request Sent Status: 9, Polling for response Status: 10, Waiting for response Status: 9, Polling for response Status: 10, Waiting for response Status: 9, Polling for response Status: 10, Waiting for response Status: 9, Polling for response Status: 10, Waiting for response Status: 9, Polling for response Status: 10, Waiting for response Status: 9, Polling for response Status: 11, Done ERROR: flxActAppActivationSend (50040,41147,10248) License can not be generated, it is already expired. Connection to FlexNet Operations Server failed. Re: EB AutoCore activation fails Hello, I have the same problem... Re: EB AutoCore activation fails This license is still not working.
記事全体を表示
TagInfoのオクトパスカードの現在の値 AndroidのTagInfoアプリを使ってOctopusの公共交通カードをスキャンしているのですが、現在の金額の計算方法にバグがあるのではないかと思います。 調べてみたところ、2017年10月以降、カードの入金金額が35ドルから50ドルに変更されることが関係しているようです。アプリはメモリ上に0x00000357を表示しますが、これは855 - 350 = 505、つまり50.5ドルです。しかし、実際の値は855 - 500 = 355、つまり35.5ドルです。 もしこの情報をアプリ開発者に転送して、将来のアップデートで計算結果を示せるようにしていただけるとありがたいです。ありがとう。 はじめに Re: TagInfo current value for Octopus cards こんにちは、 @chfoo さん、 ご意見ありがとうございます。残念ながら、これはNXPのポートフォリオに含まれていないサードパーティのアプリケーションや製品に関するものであり、当社のサポート範囲外です。 ご迷惑をおかけして申し訳ございません。 BR ハビブ
記事全体を表示
[I.MX95] LVDS1 + MIPI-DSI の有効化に失敗しました こんにちは、NXPの技術サポートの皆さん、 私のi.mx95のエンビューはlf-6.18.yです。 私はDSI用にpixel_interleaver ch0を、LVDSポート1用にch1を使用しています。 デバイスツリーでLVDS1とMIPI-DSIを同時に有効にすると、MIPI-DSIが動作しないという問題が発生しました。modetestを使って情報を確認しましたが、DSIに関する情報は何も表示されませんでした。 しかし、pixel_interleaver channel@1 を無効にすれば、DSI は問題ないはずだった。DSIとシングルポートLVDSを有効にするには、デバイスツリーをどのように構成すればよいですか?CANの例を教えてもらえますか? 添付ファイルは私のdtsoファイルですが、あなたのウェブページでは.dtsoという拡張子のファイルをアップロードできないため、ファイル名を変更しました。 前もって感謝します。 Re: [I.MX95] Failed to enable LVDS1 + MIPI-DSI こんにちは、 以下のパッチをお試しください。 https://community.nxp.com/t5/Multi-Source-Translation-Content/2046000-en-US/ta-p/2411639 MIPI-DSIに加えて2つのLVDS出力を有効にするため、LVDS1のみを有効にするのは有効なサブセットです。 Re: [I.MX95] Failed to enable LVDS1 + MIPI-DSI すみません、私の間違いでした。何も変更する必要はありませんが、少し変な感じで、lvdsとmipiドライバーの両方をインストールしなければ、modetestでデバイスの情報が見られます。 もし1つだけインストールすると、何も見えません。 申し訳ありませんが、他の問題に取り組んでいたため、まだパッチを試していません。
記事全体を表示
TagInfo current value for Octopus cards I am using the TagInfo app on Android to scan an Octopus public transport card and I think there may be a bug in how it calculates the current value. After doing some research, I think it involves the deposit amount changing from $35 to $50 for cards after October 2017. The app shows 0x00000357 in memory, which is 855 - 350 = 505 or $50.5, but the actual value is 855 - 500 = 355 or $35.5. If this info could be forwarded to the app developers so it can show the updated calculation in a future update, it would be appreciated. Thank you. Getting Started Re: TagInfo current value for Octopus cards Hello @chfoo, Thank you for your comments. Unfortunately, this concerns a third-party application and product that are not part of NXP's portfolio, therefore, this is outside the scope of the support we can provide. I apologize for any inconvenience this may cause. BR Habib
記事全体を表示
SPC5200CVR400B 的状态和可靠性查询 尊敬的恩智浦技术支持团队: 我们的产品中使用了SPC5200CVR400B集成电路。 请您确认一下: • SPC5200CVR400B 是处于活跃状态、过时状态还是已停产状态。 • 如果该设备仍在生产,是否有关于该设备数据/软件损坏的已知问题报告? • 预防或诊断此类损坏的推荐方法。 • 如果设备已过时或即将报废,则提供合适的替代/备用零件。 如果您能就可能的根本原因和纠正措施提供指导,我们将不胜感激。 感谢您的支持。 此致, 阿比吉特·索兰基 Re: Status and Reliability Inquiry for SPC5200CVR400B 你好, 基于 MPC5200 的功能集(Linux MPU、MMU、以太网、USB、CAN、工业级温度、中等性能): 最佳整体 ARM 替代品 LS1021A 工业网络/面向未来的LS1028A 成本最低的现代 ARM 迁移方案 i.MX93 顺祝商祺! Peter Re: Status and Reliability Inquiry for SPC5200CVR400B 请提供备用集成电路的零件编号。 Re: Status and Reliability Inquiry for SPC5200CVR400B 你好, SPC5200CVR400B 是处于活跃状态、过时状态还是已停产状态。 该产品已停产。 如果这款设备仍在生产的话。该设备是否已报告任何与数据/软件损坏相关的已知问题? 无 预防或诊断此类损坏的推荐方法。 我不知道有任何已发布的硅勘误表专门指出 SPC5200CVR400B 的通用数据或软件损坏机制。 要调查潜在的腐败问题,您可以: 使用校验和或 CRC 执行 RAM 和闪存完整性检查。 如果设备已过时或即将报废,则可使用合适的替代/备用零件。 i.MX 应用处理器 - 推荐用于需要持续产品支持的新设计。 顺祝商祺! Peter
記事全体を表示
[I.MX95] 启用 LVDS1 + MIPI-DSI 失败 您好,NXP技术支持团队, 我的 i.mx95 环境是 lf-6.18.y。 我使用 pixel_interleaver ch0 处理 DSI,使用 ch1 处理 LVDS 端口 1。 现在我遇到了一个问题,当在设备树中同时启用 LVDS1 和 MIPI-DSI 时,MIPI-DSI 无法工作。我使用 modetest 查看了信息,但没有看到任何关于 DSI 的信息。 但是,如果我禁用 pixel_interleaver channel@1,DSI 就可以正常工作了。如何配置设备树以启用 DSI + 单端口 LVDS?能给我举个例子吗? 附件是我的 dtso 文件,但我更改了文件名,因为您的网页不允许上传文件名以 .dtso 结尾的文件。 提前致谢。 Re: [I.MX95] Failed to enable LVDS1 + MIPI-DSI 你好, 请尝试使用以下补丁: https://community.nxp.com/t5/Multi-Source-Translation-Content/2046000-en-US/ta-p/2411639 它支持 MIPI-DSI 和两个 LVDS 输出,因此仅启用 LVDS1 是一个有效的子集。 Re: [I.MX95] Failed to enable LVDS1 + MIPI-DSI 抱歉,我的错。不需要做任何更改,但有点奇怪,我必须同时安装 lvds 和 mipi 驱动程序,然后才能通过 modetest 查看设备信息。 如果只安装其中一个,则什么都看不到。 抱歉,我还没有尝试这个补丁,因为我当时正在处理其他问题。
記事全体を表示
SPC5200CVR400Bのステータスおよび信頼性に関する照会 親愛なるNXPサポートチームへ、 私たちは製品にSPC5200CVR400B ICを使用しています。 確認いただけますか: • SPC5200CVR400Bが現役、廃止、または廃止されているかどうか。 ・このデバイスがまだ製造中かどうか。このデバイスに関してデータやソフトウェア破損に関する既知の問題が報告されているかどうか。 ・このような腐敗を防止または診断するための推奨方法 ・機器が旧式化している場合、または耐用年数が近づいている場合は、適切な代替部品または交換部品を用意してください。 考えられる根本原因と是正措置についてのご助言をいただければ大変ありがたいです。 ご支援ありがとうございます。 よろしくお願いします、 アビジート・ソランキ Re: Status and Reliability Inquiry for SPC5200CVR400B こんにちは、 MPC5200機能セット(Linux MPU、MMU、イーサネット、USB、CAN、インダストリアル温度、適度な性能)に基づいて以下の通りです: Best overall ARM replacement                    LS1021A インダストリアル networking / future-proof           LS1028A Lowest cost modern ARM migration           i.MX93 よろしくお願いいたします。 ピーター Re: Status and Reliability Inquiry for SPC5200CVR400B 代替ICの部品番号を教えてください。 Re: Status and Reliability Inquiry for SPC5200CVR400B こんにちは、 SPC5200CVR400Bが現在も使用されているか、旧式化されているか、製造中止になっているか。 この製品は寿命切れです。 この機器がまだ製造されている場合。このデバイスに関してデータやソフトウェア破損に関する既知の問題が報告されているかどうか。 なし このような破損を防止または診断するための推奨方法。 私は、SPC5200CVR400Bに関する公開されたシリコンエラタムで、一般的なデータまたはソフトウェア破損メカニズムを具体的に特定しているものについては存じません。 *(Note: The target text preserves the original polite nuance while accurately inserting "ソフトウェア" as requested by the glossary term, adjusting the surrounding phrasing minimally for grammatical coherence.)* Reintegrated target: 私は、このSPC5200CVR400Bに関する一般的なデータまたはソフトウェア破損メカニズムを特定したシリコンエラタムは知りません。 潜在的な汚職問題を調査するには、以下の方法があります: チェックサムまたはCRCを使用して、RAMとフラッシュメモリの整合性チェックを実行します。 機器が旧式化している場合、または耐用年数が近づいている場合に適した代替部品。 i.MXアプリケーション・プロセッサ - 継続的な製品サポートを必要とする新しいデザインへの推奨パス。 よろしくお願いいたします。 ピーター
記事全体を表示
Getting Started with UWB on the NXP Trimension® SR250 - Part 2: SR250UWBSHIELD + FRDM-RW612 Setup Guide (Japanese Blog) 1. Introduction In the first installment, we introduced the SR250 as a device that integrates UWB ranging and UWB radar onto a single chip, and that it was released for the mass market in March 2026. From this point on, we'll finally get the board working. Let's go through the process together, from obtaining the evaluation board to verifying its operation. 1st Basics of UWB and an overview of the SR250 Part 2 (This article) Setting up the SR250 evaluation board (SR250UWBSHIELD) 3rd Let's try UWB ranging. 4th Try out UWB radar. There are two main ways to try out the SR250: the build-free PnP (Plug-and-Play) route and the Zephyr SDK route for full-fledged development. The necessary preparations differ depending on which route you choose, so it's best to decide beforehand. Those who want to do both are also very welcome! While it can run on systems other than Windows, this guide will use the command prompt on a Windows PC. root For people like this Development environment A. PnP First, I want to try it out easily! Python + PySerial only B. Zephyr SDK I want to develop this seriously and combine it with BLE. Git・CMake・Python・Zephyr SDK 2. Hardware Preparation (Common to A and B) Required hardware For UWB distance measurement, a device on the other end is required. If you have two sets, you can measure distance between two SR250 UWB SHIELD boards. If you have a smartphone equipped with UWB, you can measure distance to the smartphone with just one set. SR250UWBSHIELD : Arduino-compatible shield board equipped with SR250. FRDM-RW612 : Host MCU board ( Wi-Fi 6 / Bluetooth Low Energy 5.4 / 802.15.4 equipped) Two USB Type-C cables One cable is included with the FRDM-RW612, so please prepare another one. You will need a cable that supports data communication, not just a charging-only cable. The connector that connects to the PC can be either Type-A or Type-C. Regarding USB connection The SR250UWBSHIELD + FRDM-RW612 requires two USB-C cables to operate. Let's review the purpose of each cable. connector Purpose remarks J10 (MCU-Link) Power supply, programming, and debugging. This connection is required. Without it, the power will not turn on. J8 (HS-USB) Serial communication (Virtual COM Port) When checking the COM port, use the port number on the J8 side. Two COM ports will appear in Windows Device Manager, but the one used for serial communication is the COM port on the J8 (HS-USB) device. It will be displayed as "USB Serial Device (COMx)". Rework: Critical tasks that need to be checked first. The SR250-ARD shield and FRDM-RW612 communicate via SPI, but SPI does not function correctly with the default Arduino header wiring. Please address this using one of the following two methods. Method 1: Rework by soldering (recommended) If you have a soldering iron, I recommend reworking the SPI lines. Once done, you won't need any cables, resulting in a cleaner setup. For detailed rework procedures, please refer to the Start Guide: Start Guide for the Trimension SR250 Development Board Method 2: Alternative connection using jumper wires (for those who want to try it easily) If you want to try it without soldering, connect the Arduino header pins of the FRDM-RW612 with two female-to-female jumper wires as shown below. If you'd like to test the functionality first, please use this method. 3A. PnP Route: Easily try it with just Python The PnP application requires no build; you can directly control the SR250 from your PC using the USB serial communication and SPI communication protocol converter firmware (PnP firmware) for the FRDM-RW612, available on GitHub. You can verify its operation simply by running a Python UCI script from your PC. When preparing, you will encounter two different firmwares. The first one to be written is the protocol conversion firmware that operates within the RW612. After that, you will update the SR250's firmware. The writing methods for each are different (RW612 via ISP mode, SR250 via PnP firmware), so please pay attention to the procedure.   Obtain the necessary files from GitHub. You can download the ZIP file from the "Code" dropdown menu in the upper right corner. GitHub: SR250 UWB Plug-and-Play Application Required software Python 3.12 or later PySerial: python -m pip install pyserial procedure Step 1: Write the firmware for RW612 PnP Connect two USB cables (J10 and J8). To start the RW612 in ISP mode (In-System Programming), which is a firmware writing-only mode: Press and hold SW3 (ISP), then press and release SW1 (Reset) → Release SW3. To write the firmware to the RW612 using ISP over USB, double-click the program_FRDM-RW612.bat file located in the FRDM-RW612_PnP folder to run the batch file: FRDM-RW612_PnP/program_FRDM-RW612.bat Most errors are caused by the device not starting in ISP mode. If you have difficulty entering ISP mode using switch 2, try connecting the USB to J10 while holding down SW3. Once the batch file processing is complete, unplug the USB cable, replug it, and restart the board. Step 2: SR250 FW Update To update the SR250's firmware, connect the SR250's shield board on top of the RW612 board, and then double-click Update_SR250_FW.bat in the SR250_FW folder to run the batch file: SR250_FW/Update_SR250_FW.bat If successful, unplug the USB cable, replug it, and restart the board. Step 3: Operation Check Check the COM port number for J8 in Device Manager (e.g., COM10). Start the Python script located in the Simple_demos folder, using the COM port number you just confirmed as an argument, and verify that communication is successful. If JLink is not installed, both devices will not be recognized as JLink, as shown in the diagram below (J10), and will both be displayed as "USB Serial Device." In this case, disconnect J8 and check which device disappears from the device list. The device that disappears corresponds to J8. python demo_ranging.py COM10 The PnP route setup is now complete! 3B. Zephyr SDK Route: For full-scale development This route uses a Zephyr OS-based SDK for building and debugging. It supports integration with BLE and the development of custom applications. There are two methods: using VS Code + MCUXpresso, and using the west command line. Either method is fine. Here, we will introduce the method using the west command in a Windows environment. Let's start by creating a folder as close to the root of the C drive as possible. For instructions on using VS Code with MCUXpresso, please refer to the Getting Started guide or the MCUXpresso for VS Code documentation . Please also refer to the important points regarding using VS Code with MCUXpresso, which are listed at the end of this document. Required software Git : Latest version CMake : 3.21.1 or later Zephyr SDK : 0.17.x There are dependencies between the Zephyr version and the Zephyr SDK. This procedure uses Zephyr SDK 0.17.x Please install it. Different SDK versions may cause build errors. Python : 3.8 or later Make sure you have Ninja and West installed. pip3 install west ninja Serial terminal: TeraTerm, PuTTY, or any other serial terminal of your choice. Environment setup procedure Step 1: Clone the repository git clone https://github.com/nxp-uwb/sr250-uwbiot-zephyr.git Step 2: west initialization cd sr250-uwbiot-zephyr west init -l --mf west.yml uwbiot-top Step 3: Obtain Dependencies west update west update This process will take some time to complete. If it stops midway, please restart it. Proceeding to the next step before completion will cause a build error. Step 4: Install Python dependency packages pip install -r zephyr\scripts\requirements.txt Step 5: Setting environment variables Set the path to the Zephyr SDK in your environment variables. zephyr\zephyr-env.cmd Build and write Since an update is required first, we will build a demo for the firmware update. west build -b frdm_rw612 -p auto uwbiot-top\demos\SR2xx\demo_sr2xx_fw_update\zephyr I will write to the file once the build is successful. west flash We will check the logs via serial communication. By default, the code is executed only after communication is established. Connect two USB cables (J10 and J8). Check the COM port number on the side connected to J8 (see Step 3: Operation Check for PnP Root). Launch your terminal software and configure the port as follows: Set the baud rate to 3,000,000 bps . Many terminal programs, such as TeraTerm and PuTTY, do not display 3,000,000 as a baud rate option. Even if it's not in the options, you can enter it manually . Type "3000000" into the text box. If the log message " Success!" appears at the end, as shown below, then it was successful. Similarly, build and flash the calibration demo. west build -b frdm_rw612 -p auto uwbiot-top\demos\SR2xx\demo_device_calibration\zephyr west flash The Zephyr SDK root setup is now complete! Points to note Windows path length limit (MAX_PATH) Windows has a default path length limit of 260 characters. Zephyr repositories have a deep directory structure, which can cause this limitation to be exceeded. We strongly recommend saving your project in a location close to the root of the C drive (e.g., C:\uwb\ ). Placing it in a deeper directory structure like C:\Users\username\Documents\Projects\... will cause the path generated by Zephyr's build system to exceed the limit and result in an error. This issue is more pronounced with VS Code + MCUXpresso. If it's difficult to place it close to the root of the C drive, please consider the following workarounds. How to do it: We recommend using WSL2 (Windows Subsystem for Linux). Alternatively, enable LongPathsEnabled in the Windows registry. Notes on importing projects in VS Code + MCUXpresso When importing a project, you need to set the App type to "Repository application" . This is not highlighted in the Getting Started guide, but it is a point where build errors are likely to occur if you get it wrong. Please be sure to check this. Cases where a pristine build is required If you change build options or the error persists, try a pristine build: west build --pristine -b frdm_rw612 sr250-uwbiot-zephyr/samples/demo_uwb_controller FW version error demo_sr2xx_fw_update Running other demos before executing this will result in a firmware version error. Always perform the firmware update first. Next episode preview Once the environment is set up, we'll finally run the demo. Next time, we'll explain how to run the UWB ranging demo using two different routes: the PnP route and the Zephyr SDK route. Stay tuned! Reference links Trimension SR250 Development Board Start Guide SR250 UWB Plug-and-Play Application (GitHub) sr250-uwbiot-zephyr (GitHub) FRDM-RW612 Product Page Trimension SR250 Evaluation Board MCUXpresso for VS Code ========================= We are currently unable to respond to comments left in the "Comment" section of this post. We apologize for the inconvenience, but please refer to " Technical Questions to NXP - How to Contact Us( Japanese Blog) " when making an inquiry. (If you are already an NXP distributor or have a relationship with NXP, you may ask your representative directly.) In the first installment, we introduced the features of the SR250 (integration of UWB ranging and UWB radar on a single chip). In the second installment, we will set up an environment to actually run the SR250 using the evaluation board SR250UWBSHIELD + FRDM-RW612. We will explain two routes: the build-free PnP (Plug-and-Play) route and the Zephyr SDK route for full-fledged development. (Estimated work time: 10 minutes) Japanese Blog
記事全体を表示
NXP Trimension® SR250 UWB 入门指南 - 第 2 部分:SR250UWBSHIELD + FRDM-RW612 设置指南(日语博客) 1. 引言 在第一期中,我们介绍了 SR250,这是一款将 UWB 测距和 UWB 雷达集成到单个芯片上的设备,并于 2026 年 3 月面向大众市场发布。 从现在开始,我们将最终让电路板正常工作。让我们一起完成整个过程,从获取评估板到验证其运行情况。 第一 UWB基础知识及SR250概述 第二部分(本文) 设置 SR250 评估板 (SR250UWBSHIELD) 第三 我们来试试超宽带测距。 第四 试试超宽带雷达。 体验 SR250 主要有两种方式:无需编译的即插即用 (PnP) 方式和使用 Zephyr SDK 进行全面开发的方式。根据您选择的方式,所需的准备工作有所不同,因此最好提前决定。我们也非常欢迎想要两种方式都尝试的用户! 虽然它可以在 Windows 以外的系统上运行,但本指南将使用 Windows PC 上的命令提示符。 根 对于像这样的人来说 开发环境 A. PnP 首先,我想先尝试一下! 仅限 Python + PySerial B. Zephyr SDK 我想认真开发这项技术,并将其与蓝牙低功耗技术结合起来。 Git、CMake、Python、Zephyr SDK 2. 硬件准备(A 和 B 通用) 所需硬件 对于UWB距离测量,另一端需要一个设备。如果您有两套设备,则可以测量两个SR250 UWB SHIELD板之间的距离。如果您有一部配备UWB功能的智能手机,则只需一套设备即可测量到该智能手机的距离。 SR250UWBSHIELD :配备 SR250 的 Arduino 兼容扩展板。 FRDM-RW612 :主机MCU板(支持Wi-Fi 6/蓝牙低功耗5.4/802.15.4 ) 两条 USB Type-C 数据线 FRDM-RW612 附带一根电缆,请另备一根。 你需要一根支持数据通信的线缆,而不仅仅是一根只能充电的线缆。 与电脑连接的接口可以是A型接口或C型接口。 关于USB连接 SR250UWBSHIELD + FRDM-RW612 需要两根 USB-C 数据线才能工作。我们来看看每根数据线的作用。 连接器 目的 备注 J10(MCU-Link) 电源供应、编程和调试。 这个连接是必需的。没有它,电源将无法开启。 J8(HS-USB) 串行通信(虚拟 COM 端口) 检查 COM 端口时,请使用 J8 端的端口号。 Windows 设备管理器中会出现两个 COM 端口,但用于串行通信的是 J8 (HS-USB) 设备上的 COM 端口。它会显示为“USB 串行设备 (COMx)”。 返工:需要首先检查的关键任务。 SR250-ARD扩展板和FRDM-RW612通过SPI接口通信,但使用默认的Arduino排针接线无法正常工作。请使用以下两种方法之一解决此问题。 方法一:焊接返工(推荐) 如果你有电烙铁,我建议你重新焊接SPI线路。焊接完成后,你就不需要任何线缆了,这样布线会更简洁。 有关详细的返工步骤,请参阅入门指南: 《Trimension SR250 开发板入门指南》 方法二:使用跳线连接(适合想要轻松尝试的人) 如果您想尝试不焊接,请按如下方式将 FRDM-RW612 的 Arduino 排针用两根母对母跳线连接起来。 如果您想先测试一下功能,请使用此方法。 3A. PnP 方案:只需使用 Python 即可轻松尝试 此即插即用 (PnP) 应用无需编译;您可以使用适用于 FRDM-RW612 的 USB 串口通信和 SPI 通信协议转换器固件(即 PnP 固件),直接从 PC 控制 SR250。该固件可在 GitHub 上获取。您只需在 PC 上运行 Python UCI 脚本即可验证其运行情况。 准备过程中,您会遇到两种不同的固件。首先要写入的是RW612内部运行的协议转换固件。之后,您需要更新SR250的固件。两者的写入方法不同(RW612通过ISP模式写入,SR250通过PnP固件写入),请务必仔细阅读操作步骤。   从 GitHub 获取所需文件。您可以从右上角的“代码”下拉菜单下载 ZIP 文件。 GitHub: SR250 UWB 即插即用应用程序 所需软件 Python 3.12 或更高版本 PySerial: python -m pip install pyserial 程序 步骤 1:写入 RW612 PnP 的固件 连接两根 USB 线缆(J10 和 J8)。 要启动 RW612 的 ISP 模式(系统内编程),即固件写入模式:按住 SW3(ISP),然后按下并松开 SW1(重置)→ 松开 SW3。 要使用 USB 上的 ISP 将固件写入 RW612,请双击位于 FRDM-RW612_PnP 文件夹中的 program_FRDM-RW612.bat 文件来运行该批处理文件: FRDM-RW612_PnP/program_FRDM-RW612.bat 大多数错误是由设备未以 ISP 模式启动引起的。如果您在使用开关 2 进入 ISP 模式时遇到困难,请尝试在按住 SW3 的同时将 USB 连接到 J10。 批处理文件处理完成后,拔下 USB 电缆,重新插上,然后重新启动开发板。 步骤 2:SR250 固件更新 要更新 SR250 的固件,请将 SR250 的扩展板连接到 RW612 板的顶部,然后双击 SR250_FW 文件夹中的 Update_SR250_FW.bat 文件来运行该批处理文件: SR250_FW/Update_SR250_FW.bat 如果成功,拔下 USB 连接线,重新插上,然后重启主板。 步骤 3:运行检查 在设备管理器中检查 J8 的 COM 端口号(例如,COM10)。 启动位于 Simple_demos 文件夹中的 Python 脚本,使用您刚刚确认的 COM 端口号作为参数,并验证通信是否成功。 如果未安装 JLink,则两个设备都不会被识别为 JLink 设备(如下图 J10 所示),而是都会显示为“USB 串口设备”。在这种情况下,请断开 J8 连接,并检查哪个设备从设备列表中消失。消失的设备对应于 J8。 python demo_ranging.py COM10 PnP路由设置现已完成! 3B. Zephyr SDK 方案:用于全面开发 此方案使用基于 Zephyr OS 的 SDK 进行构建和调试。它支持与 BLE 集成以及自定义应用程序的开发。 有两种方法:使用 VS Code + MCUXpresso,以及使用 west 命令行。两种方法都可以。这里,我们将介绍在 Windows 环境下使用 west 命令的方法。首先,在尽可能靠近 C 盘根目录的位置创建一个文件夹。 有关如何将 VS Code 与 MCUXpresso 配合使用的说明,请参阅入门指南或MCUXpresso for VS Code 文档。另请参阅本文档末尾列出的关于将 VS Code 与 MCUXpresso 配合使用的要点。 所需软件 Git :最新版本 CMake :3.21.1 或更高版本 Zephyr SDK :0.17.x Zephyr 版本与 Zephyr SDK 之间存在依赖关系。本教程使用Zephyr SDK 0.17.x 版本。请安装。不同版本的 SDK 可能会导致构建错误。 Python :3.8 或更高版本 请确保您已安装 Ninja 和 West。 pip3 install west ninja 串口终端:TeraTerm、PuTTY 或您选择的任何其他串口终端。 环境设置步骤 步骤 1:克隆存储库 git clone https://github.com/nxp-uwb/sr250-uwbiot-zephyr.git 步骤 2:西部初始化 cd sr250-uwbiot-zephyr west init -l --mf west.yml uwbiot-top 步骤 3:获取依赖关系 西部更新 west update 此过程需要一些时间才能完成。如果中途停止,请重新启动。在完成之前进行下一步操作会导致构建错误。 步骤 4:安装 Python 依赖包 pip install -r zephyr\scripts\requirements.txt 步骤 5:设置环境变量 在环境变量中设置 Zephyr SDK 的路径。 zephyr\zephyr-env.cmd 构建和编写 由于首先需要进行更新,我们将构建一个固件更新演示。 west build -b frdm_rw612 -p auto uwbiot-top\demos\SR2xx\demo_sr2xx_fw_update\zephyr 构建成功后,我会将信息写入文件。 west flash 我们将通过串口通信检查日志。默认情况下,代码仅在通信建立后执行。 连接两根 USB 线缆(J10 和 J8)。 检查连接到 J8 的一侧的 COM 端口号(参见步骤 3:PnP Root 的操作检查)。 启动终端软件并按如下方式配置端口: 将波特率设置为3,000,000 bps 。许多终端程序,例如 TeraTerm 和 PuTTY,不会将 3,000,000 列为波特率选项。即使选项中没有,您也可以手动输入。在文本框中输入“3000000”。 如果日志消息“成功!”出现在末尾,如下所示,则表示操作成功。 同样地,构建并刷写校准演示程序。 west build -b frdm_rw612 -p auto uwbiot-top\demos\SR2xx\demo_device_calibration\zephyr west flash Zephyr SDK 根目录设置已完成! 需要注意的事项 Windows 路径长度限制(MAX_PATH) Windows 默认路径长度限制为 260 个字符。Zephyr 仓库的目录结构较深,这可能会导致路径长度超出限制。我们强烈建议您将项目保存在C 盘根目录附近的位置(例如 C:\uwb\ )。如果将其放置在更深的目录结构中,例如 C:\Users\username\Documents\Projects\... ,Zephyr 构建系统生成的路径将超出长度限制,从而导致错误。使用 VS Code + MCUXpresso 时,此问题尤为突出。如果难以将其放置在 C 盘根目录附近,请考虑以下解决方法。 操作方法: 我们建议使用 WSL2(适用于 Linux 的 Windows 子系统)。 或者,在 Windows 注册表中启用 LongPathsEnabled。 关于在 VS Code + MCUXpresso 中导入项目的注意事项 导入项目时,您需要将应用类型设置为“存储库应用程序” 。入门指南中并未重点提及这一点,但如果设置错误,很可能会导致构建错误。请务必检查此项。 需要完美构建的情况 如果更改构建选项或错误仍然存在,请尝试全新构建: west build --pristine -b frdm_rw612 sr250-uwbiot-zephyr/samples/demo_uwb_controller 固件版本错误 demo_sr2xx_fw_update 在执行此操作之前运行其他演示程序会导致固件版本错误。请务必先执行固件更新。 下一集预告 环境搭建完毕后,我们就可以运行演示了。下次,我们将讲解如何使用两种不同的方式运行 UWB 测距演示:即插即用 (PnP) 方式和 Zephyr SDK 方式。敬请期待! 参考链接 Trimension SR250 开发板入门指南 SR250 UWB 即插即用应用程序(GitHub) sr250-uwbiot-zephyr(GitHub) FRDM-RW612 产品页面 Trimension SR250 评估板 适用于 VS Code 的 MCUXpresso ========================= 即使您在本文的“评论”栏留言,我们目前也无法回复。 给您带来不便,我们深感抱歉。请在询问时参阅“NXP技术问题-联系方式(日本博客)”。 (如果您已经是NXP的代理商或与其有合作关系,可以直接向负责人咨询。) 在第一部分中,我们介绍了SR250的特性(将UWB测距和UWB雷达集成在单个芯片上)。在第二部分中,我们将搭建一个环境,使用评估板SR250UWBSHIELD + FRDM-RW612实际运行SR250。我们将介绍两种方案:无需构建的即插即用(PnP)方案和用于完整开发的Zephyr SDK方案。 (预计工作时间:10分钟) 日本博客
記事全体を表示
NXP Trimension® SR250で始めるUWB入門 第2回:SR250UWBSHIELD + FRDM-RW612 セットアップガイド (日本語ブログ) 1. はじめに 第1回では、SR250がUWB測距とUWBレーダーを1チップに統合したデバイスであること、そして2026年3月にマスマーケット向けにリリースされたことを紹介しました。 今回からは、いよいよ実際にボードを動かします。評価ボードを入手して動作確認まで一緒に進めていきましょう。 第1回 UWBの基礎とSR250の概要 第2回(本記事) SR250評価ボード (SR250UWBSHIELD) のセットアップ 第3回 UWB測距 (Ranging) を試してみる 第4回 UWBレーダー (Radar) を試してみる SR250を試す方法は大きく2通りあります。ビルド不要のPnP (Plug-and-Play) ルートと、本格開発向けのZephyr SDKルート、どちらのルートかによって必要な準備が変わるため、先に決めておくとスムーズです。どちらも!という方も大歓迎です。 Windows以外でも動作可能ですが、今回はWindows PCのコマンドプロンプトを使用します。 ルート こんな方に 開発環境 A. PnP まず手軽に動かしてみたい! Python + PySerial のみ B. Zephyr SDK 本格的に開発したい・BLEと組み合わせたい Git・CMake・Python・Zephyr SDK 2. ハードウェアの準備 (A, B共通) 必要なハードウェア UWB測距の場合は相手側のデバイスが必要となります。2セットご用意いただければ、SR250 UWB SHIELDボード同士での測距を行うことができます。UWBが搭載されたスマートフォンをお持ちであれば、1セットのみでスマートフォンと測距することも可能です。 SR250UWBSHIELD:SR250搭載のArduino互換シールドボード FRDM-RW612:ホストMCUボード (Wi-Fi 6 / Bluetooth Low Energy 5.4 / 802.15.4 搭載) USB Type-Cケーブル × 2本 1本はFRDM-RW612に同梱されているので、もう1本ご準備ください 充電専用ケーブルではなく、データ通信対応のケーブルが必要です PCへの接続側はType-AでもType-Cでも構いません USB接続について SR250UWBSHIELD + FRDM-RW612の動作にはUSB-Cケーブルを2本接続します。それぞれの用途を確認しておきましょう。 コネクタ 用途 備考 J10 (MCU-Link) 電源供給・書き込み・デバッグ 接続必須。これがないと電源が入らない J8 (HS-USB) シリアル通信 (Virtual COM Port) COMポート確認時はJ8側のポート番号を使用 Windowsのデバイスマネージャーに2つのCOMポートが表示されますが、シリアル通信に使うのはJ8 (HS-USB) 側のCOMポートです。「USB Serial Device (COMx)」と表示されます。 リワーク:最初に確認が必要な重要作業 SR250-ARDシールドとFRDM-RW612はSPIで通信しますが、デフォルトのArduinoヘッダー配線ではSPIが正しく動作しません。以下の2通りのいずれかで対応してください。 方法1:半田付けによるリワーク(推奨) はんだごてをお持ちの方はSPIラインのリワークを行うことをお勧めします。一度やってしまえばケーブルも不要でスッキリします。 リワーク手順の詳細はスタートガイドを参照してください:Trimension SR250用開発ボードのスタート・ガイド 方法2:ジャンパ線での代替接続(手軽に試したい方) はんだ付けなしで試したい場合は、メスメス (Female-to-Female) のジャンパ線2本でFRDM-RW612のArduinoヘッダーピンを以下のように接続してください。 まず動作確認したい方はこちらの方法からどうぞ。 3A. PnPルート:Pythonだけで手軽に試す PnPアプリはビルド不要で、GitHubで提供されているFRDM-RW612用のUSBシリアル通信とSPI通信のプロトコル変換用FW (PnP用FW) を使ってSR250をPCから直接操作できます。PC側からPythonのUCIスクリプトを実行するだけで動作確認できます。 準備をするにあたって、2つの異なるFWが出てきます。最初に書き込むのは、RW612内で動作するプロトコル変換用のFWです。その後に、SR250のFW更新を行います。それぞれ書き込み方法が異なります (RW612はISPモード経由、SR250はPnP FW経由) ので、手順にご注意ください。   GitHubから必要なファイルを入手します。右上の "Code" のプルダウンメニューからZIPダウンロードが可能です。 GitHub: SR250 UWB Plug-and-Play Application 必要なソフトウェア Python 3.12以降 PySerial: python -m pip install pyserial 手順 Step 1: RW612 PnP用FWの書き込み USBケーブル2本 (J10・J8)を接続 ファームウェア書き込み専用モードであるISPモード(In-System Programming)でRW612を起動させる:SW3(ISP)を押しながらSW1 (リセット) を押して離す → SW3を離す ISP over USBでRW612へFWを書き込むため、FRDM-RW612_PnPフォルダにあるprogram_FRDM-RW612.batをダブルクリックでバッチファイルを実行: FRDM-RW612_PnP/program_FRDM-RW612.bat エラーが出る場合の多くはISPモードで起動できていないことが原因です。2のスイッチ操作でISPモードに入りにくい場合は、SW3を押しながらJ10にUSBを接続してみてください。 バッチファイルの処理が完了したら、USBケーブルを一度抜いて再接続し、ボードを再起動してください。 Step 2: SR250 FWアップデート SR250のFW更新のため、SR250のシールドボードをRW612ボードに重ねて接続し、SR250_FWフォルダにあるUpdate_SR250_FW.batをダブルクリックでバッチファイルを実行: SR250_FW/Update_SR250_FW.bat 成功したら、USBケーブルを一度抜いて再接続し、ボードを再起動してください。 Step 3: 動作確認 デバイスマネージャーでJ8側の通信用COMポート番号を確認します (例: COM10)  Simple_demosフォルダ内にあるPythonスクリプトで先ほど確認したCOMポート番号を引数にして起動し、通信が成功していることを確認します JLinkがインストールされていない場合、下図のJ10のようにJLinkとして認識されず、2つのデバイスがいずれも「USB Serial Device」と表示されます。その場合は、J8の接続を外し、デバイス一覧からどちらのデバイスが消えるかを確認してください。消えたデバイスがJ8に対応します。 python demo_ranging.py COM10 PnPルートの準備はこれで完了です! 3B. Zephyr SDKルート:本格開発向け Zephyr OSベースのSDKを使ってビルド・デバッグを行うルートです。BLEとの組み合わせや独自アプリの開発に対応しています。 VS Code + MCUXpressoを使う方法と、westコマンドラインを使う方法の二つあります。どちらでも構いません。ここではWindows環境でwestコマンドを使う方法を紹介します。なるべくCドライブ直下に近いところにフォルダを作成して始めましょう。 VS Code + MCUXpressoを使う方法についてはスタートガイドやMCUXpresso for VS Codeをご参照ください。VS Code + MCUXpressoを使う方法での注意点だけ最後に記載にしてますので、そちらもご参照ください。 必要なソフトウェア Git: 最新版 Cmake: 3.21.1以降 Zephyr SDK: 0.17.x ZephyrのバージョンとZephyr SDKには依存関係があります。本手順では Zephyr SDK 0.17.x をインストールしてください。異なるバージョンのSDKではビルドエラーが発生する場合があります。 Python: 3.8以降 ninjaとwestをインストールしておきましょう pip3 install west ninja シリアルターミナル: TeraTerm・PuTTYなど、お好みのシリアルターミナル 環境構築手順 Step 1: リポジトリのクローン git clone https://github.com/nxp-uwb/sr250-uwbiot-zephyr.git Step 2: west初期化 cd sr250-uwbiot-zephyr west init -l --mf west.yml uwbiot-top Step 3: 依存関係の取得 west update west update は完了まで時間がかかります。途中で止まった場合は再実行してください。未完了のまま次に進むとビルドエラーの原因になります。 Step 4: Python依存パッケージのインストール pip install -r zephyr\scripts\requirements.txt Step 5: 環境変数の設定 Zephyr SDKのパスを環境変数に設定します。 zephyr\zephyr-env.cmd ビルドと書き込み 最初に更新が必要なため、まずFW更新用のデモをビルドします。 west build -b frdm_rw612 -p auto uwbiot-top\demos\SR2xx\demo_sr2xx_fw_update\zephyr ビルドに成功したら書き込みます。 west flash シリアル通信でログを確認します。デフォルトでは通信が確立してはじめてコードを実行するようになっています。 USBケーブル2本 (J10・J8)を接続 J8に接続している側のCOMポート番号を確認 (PnPルートのStep 3: 動作確認を参照) ターミナルソフトを起動し、ポートを以下のように設定します。 ボーレートは 3,000,000 bps に設定します。TeraTerm・PuTTYなど多くのターミナルソフトでは、ボーレートの選択肢に3,000,000が表示されません。選択肢になくても直接手入力できます。テキストボックスに「3000000」と打ち込んでください。 以下のように、最後にSuccess!のログが出力されていれば成功です。 同様にキャリブレーションデモをビルドして書き込みます。 west build -b frdm_rw612 -p auto uwbiot-top\demos\SR2xx\demo_device_calibration\zephyr west flash Zephyr SDKルートの準備もこれで完了です! 注意点 Windowsのパス長制限(MAX_PATH) Windowsではデフォルトでパス長が260文字に制限されています。Zephyrのリポジトリは深いディレクトリ構造を持つため、この制限に引っかかることがあります。プロジェクトの保存場所はCドライブ直下に近い場所(例: C:\uwb\ など)を強くお勧めします。 C:\Users\username\Documents\Projects\... のような深い階層に置くと、Zephyrのビルドシステムが生成するパスが制限を超えてエラーになります。VS Code + MCUXpressoではこの問題がより顕著です。Cドライブ直下に近い場所に置くのが難しい場合は以下の対処方法をご検討ください。 対処方法: WSL2(Windows Subsystem for Linux)の使用を推奨 またはWindowsのレジストリでLongPathsEnabledを有効化 VS Code + MCUXpressoでのプロジェクトインポート時の注意 プロジェクトのインポート時には、App typeを「Repository application」に設定することが必要です。スタートガイドにはハイライトされていませんが、ここを誤るとビルドエラーになりやすいポイントです。必ず確認してください。 pristine buildが必要なケース ビルドオプションを変更した場合や、エラーが解消しない場合はpristineビルドを試してください: west build --pristine -b frdm_rw612 sr250-uwbiot-zephyr/samples/demo_uwb_controller FWバージョンエラー demo_sr2xx_fw_update を実行する前に他のデモを動かすとFWバージョンエラーが発生します。必ずFWアップデートを最初に実行してください。 次回予告 環境が整ったら、いよいよデモを動かします。次回はUWB測距デモを動かす方法について、PnPルートとZephyr SDKルート、2つのルートそれぞれ解説します。お楽しみに! 参考リンク Trimension SR250用開発ボードのスタート・ガイド SR250 UWB Plug-and-Play Application(GitHub) sr250-uwbiot-zephyr(GitHub) FRDM-RW612 製品ページ Trimension SR250 評価ボード MCUXpresso for VS Code ========================= 本投稿の「Comment」欄にコメントをいただいても、現在返信に対応しておりません。 お手数をおかけしますが、お問い合わせの際には「NXPへの技術質問 - 問い合わせ方法 (日本語ブログ)」をご参照ください。 (既に弊社NXP代理店、もしくはNXPとお付き合いのある方は、直接担当者へご質問いただいてもかまいません。) 第1回ではSR250の特長 (UWB測距+UWBレーダーの1チップ統合) を紹介しました。第2回では評価ボード SR250UWBSHIELD + FRDM-RW612 を使って、実際にSR250を動かすための環境を整えます。ビルド不要のPnP (Plug-and-Play) ルートと、本格開発向けのZephyr SDKルートの2通りを解説します。 (作業時間:最短10分) 日本語ブログ
記事全体を表示
Solution to FRDM-A-S32K144 and FRDM-A-S32K144N not detected during initial USB-C connection Overview The FRDM-A-S32K144 and FRDM-A-S32K144N boards ship with a factory-programmed demonstration application that showcases USB Power Delivery functionality through an RGB LED example. Under certain USB-C host and cable combinations, the factory application may prevent the on-board OpenSDA/K20 debugger from completing its initialization sequence and becoming available to the host system. When this occurs, the board may appear unresponsive and cannot be programmed through the standard OpenSDA interface. This article describes how to identify the condition and provides a simple one-time recovery procedure. This behavior is limited to the following boards: FRDM-A-S32K144 FRDM-A-S32K144N No other FRDM boards are affected. Symptoms The behavior is typically observed during the initial programming session while the factory application is still present. During the first use of the board, users may observe the following: The board is connected using a USB-C to USB-C cable. The operating system does not detect the board. No OpenSDA programming interface appears. Debugging and programming tools cannot establish communication. The OpenSDA/K20 status LED (D4) remains OFF. Although the board may not be detected by the host computer, the factory application may continue running on the target MCU. FRDM-A-S32K144 OpenSDA/K20 debugger status LED (D4) not working as expectedFRDM-A-S32K144 OpenSDA/K20 debugger status LED (D4) not working as expected     Issue The factory image included on the affected boards performs USB Power Delivery negotiation during startup. On certain USB-C host configurations, this initialization sequence may prevent the on-board OpenSDA/K20 debugger from reaching its operational state. As a result, the debugger does not enumerate on the host PC and programming access is not available. Once the factory image is replaced with a user application, the startup sequence changes and the OpenSDA/K20 debugger initializes normally. Workaround Materials required FRDM-A-S32K144 or FRDM-A-S32K144N board USB-A to USB-C data cable Host computer with an available USB port S32 Design Studio IDE 3.6.5 or above Any valid S32K144 application image If the board is not detected through a USB-C to USB-C connection during the initial programming session: Disconnect the board from the host PC Reconnect the board using a USB-A to USB-C cable Verify that the D4 LED is illuminated solid orange Program in S32 Design Studio any valid application to the S32K144 MCU, such as: S32K144 GPIO LED Blink example Any S32K144 Application Code Hub demonstration project Any S32K144 custom user application Wait for the programming operation to complete successfully The newly programmed application replaces the factory image and restores normal debugger operation.   Expected operation Once the workaround described above is applied successfully, the board LED D4 is illuminated with a solid orange light, and the device manager operating system detects the board as a COM port and a PEMicro OpenSDA Debug Driver. FRDM-A-S32K144 OpenSDA/K20 debugger status LED (D4) working as expectedFRDM-A-S32K144 OpenSDA/K20 debugger status LED (D4) working as expected FRDM-A-S32K144 correctly detected by Windows device managerFRDM-A-S32K144 correctly detected by Windows device manager After a successful programming session: USB-C to USB-C cables can be used normally. Debugging functions operate as expected. Programming functions operate as expected. No additional configuration is required. The recovery process only needs to be performed once. Subsequent application updates can be performed using either USB-C to USB-C or USB-A to USB-C connections (if no PD is needed). Troubleshooting checklist If D4 is OFF, the OpenSDA/K20 debugger has not completed initialization. Check the next list before applying the turnaround again:  Verify that D4 is solid orange. Confirm the USB cable supports data transfer. Check that the operating system detects the OpenSDA device. Reprogram the board using a USB-A to USB-C connection. Test with an alternative USB port or host PC. Choose another project application to flash. If D4 is still OFF, the OpenSDA/K20 debugger may be damaged or present another error. Please review the S32K Knowledge Base or the FRDM community for more information. Any support, information, and technology (“Materials”) provided by NXP are provided AS IS, without any warranty express or implied, and NXP disclaims all direct and indirect liability and damages in connection with the Material to the maximum extent permitted by the applicable law. NXP accepts no liability for any assistance with applications or product design. Materials may only be used in connection with NXP products. Any feedback provided to NXP regarding the Materials may be used by NXP without restriction. If your FRDM-A-S32K144 or FRDM-A-S32K144N is not detected during its first USB-C connection, this article explains the cause, how to verify OpenSDA/K20 status, and the steps to quickly enable normal operation.
記事全体を表示
S32K344 EVB HDQFP172 的 ADC 配置 您好, 我想执行连接到板载电位器的 ADC 通道ADC0_P7 ,并将转换后的值用于调暗板载 LED( GPIO29 )。 配置完成后,显示如下内容: 错误: platform.driver.pins 此外,在配置完成后构建项目时,我们遇到了以下编译错误:image(error_Adc) 我还附上了下面的配置设置。 注:我已添加了示例中的项目。 请解决此问题。 谢谢! 拉基 Re: ADC Configuration for S32K344 EVB HDQFP172 您好, 请尝试按照提示解决“问题”窗口中显示的错误。 大部分个人驱动程序可能不会添加到工具链中。在较新的 S32DS 中,通常在通过配置工具更新代码后,此功能就会消失。或者您需要通过“管理 SDK 元器件”手动添加它。 请确保已选择使用的元器件,然后再次更新代码。 对于 Siul2_Port 元器件,可能出现 2 个错误。 - Pin 工具配置了 2 个引脚,而 Siul2_port 只配置了 1 个引脚,两者设置不匹配。 对于 ADC 输入,无需进行引脚设置,模拟路径始终启用,您可以从引脚工具中删除它。 - 另一个可能是引脚工具中的功能组命名。 如果遇到问题,请分享您的完整项目。 BR,彼得 Re: ADC Configuration for S32K344 EVB HDQFP172 您好, 添加 Siul2_Port 后出现此错误。 我的引脚配置如下: 非常感谢您抽出时间回复。 BR, 拉基 Re: ADC Configuration for S32K344 EVB HDQFP172 您好, 添加 Siul2_Port 元器件,更新代码,并构建。 BR,彼得 Re: ADC Configuration for S32K344 EVB HDQFP172 嗨@PetrS , 谢谢你的关注。 附件如下。 Br, 拉基 Re: ADC Configuration for S32K344 EVB HDQFP172 您好, 您没有上传任何文件或截图。 您可以参考以下使用电位器进行ADC采样的示例: 示例 S32K312 ADC IP 连续扫描 DMA (S32DS 3.6, RTD 6.0.0) RTD400 LLD K344 ADC 软件/硬件触发示例 BR,Petr Re: ADC Configuration for S32K344 EVB HDQFP172 嗨,Petrs, 感谢您的支持。 您能否提供一些关于AUTOSAR版本的资源供我尝试? 我尝试了示例中的项目。但却不起作用。 请帮忙。 BR, 拉基
記事全体を表示
MCX-N9XX 评估板 1.8V 电源存在问题。 我有一个 MCXN9XX 评估板,需要从 P1_16 (J17) 和 P1_17 (J18) 焊盘上获得 1.8V 输出,以便与工作电压为 1.8V 的外部 I3C 集线器进行 I3C 通信。为了在焊盘上获得 1.8V 电压,我重新排列了跳线,以便在 MCU_PWR 轨上获得 1.8V 电压,该轨也为 VDD_MCU 供电。执行此配置后,“MCUXpresso”工具无法发现目标设备,并显示“无法与内核通信”(屏幕截图附后)。 请问谁能帮我确定正确的跳线设置,以便在烧录代码的同时,能够在 IO 焊盘 J16 和 J17 上获得 1.8V 电压? 错误截图: 电路板设计 FRDM 培训 HW-开源 MCX N
記事全体を表示
MCX-N9XX評価ボードの1.8V電源の問題。 MCXN9XX評価ボードを持っていて、P1_16(J17)とP1_17(J18)パッドで1.8Vの出力を得る必要があり、外部I3Cハブ(1.8V)と通信を行う必要があります。パッドで1.8Vを得るために、ジャンパーを再配置して、VDD_MCUにも電源を供給するMCU_PWRレールで1.8Vが得られるようにします。この設定を実行すると、「MCUXpresso」ツールはターゲットを検出できず、「コアと通信できません」というエラーメッセージが表示されます(スクリーンショットは下記参照)。 コードを同時にフラッシュしながら、IOパッドのJ16とJ17で1.8Vを出せるように、正しいジャンパー設定を教えていただけませんか? エラー画面のスクリーンショット: ボード設計 FRDMトレーニング HW-Open-Source MCX N
記事全体を表示
S32K344 EVB HDQFP172のADC構成 こんにちは、 基板のポテンショメーターに接続されたADC チャネル ADC0_P7 を実行し、変換した値を基板のLED(GPIO29)を暗めるために使いたいです。 設定後、以下のように表示されます。 エラー: platform.driver.pins さらに、設定後にプロジェクトを構築する際に、以下のコンパイルエラーに遭遇しました:image(error_Adc) 設定ファイルも下記に添付しました。 注:Exampleからプロジェクトを追加しました。 問題を解決してください。 ありがとうございます ラキー Re: ADC Configuration for S32K344 EVB HDQFP172 こんにちは、 「問題」ウィンドウに表示されるヒントに従って、エラーを解決してみてください。 おそらくほとんどの独立ドライバはツールチェーンに追加されません。新しいS32DSでは、設定ツールでコードを更新すると、この問題は通常解消されます。あるいは、Manage SDKコンポーネントから手動で追加する必要があります 使用済みのコンポーネントが選択されていることを確認してから、再度コードを更新してください。 Siul2_Portコンポーネントについては、2つの誤りがあります。 Pinツールでは2つのピンが設定されていますが、Siul2_portでは1つしか設定されておらず、設定に不一致があります。 前方ADC入力ではピン設定は不要で、アナログパスは常に有効で、ピンツールから削除できます。 - もう一つは、ピンツールで機能グループの名前を付けることです。 それでも問題が解決しない場合は、プロジェクト全体を共有してください。 BR、ペトル Re: ADC Configuration for S32K344 EVB HDQFP172 こんにちは、 Siul2_Portを追加した後、このエラーが発生しました。 私のPIN設定は以下のとおりです。 お返事をいただき、本当にありがとうございます。 BR、 ラキー Re: ADC Configuration for S32K344 EVB HDQFP172 こんにちは、 Siul2_Portコンポーネントを追加し、コードを更新してビルドします。 BR、ペトル Re: ADC Configuration for S32K344 EVB HDQFP172 こんにちは、 @PetrS さん。 気づいてくれてありがとう。 添付ファイルは以下のとおりです。 Br、 ラキー Re: ADC Configuration for S32K344 EVB HDQFP172 こんにちは、 ファイルやスクリーンショットが添付されていませんでした。 ポテンショメーターでADCサンプリングを用いる以下の例を参照できます: 例S32K312 ADC IP連続スキャンDMA(S32DS 3.6、RTD 6.0.0) RTD400 LLD K344 ADC ソフトウェア/ハードウェアトリガーの例 BR、ペトル Re: ADC Configuration for S32K344 EVB HDQFP172 こんにちは、ペトルスさん。 サポートありがとうございます。 AUTOSAR版で試せるリソースも教えてもらえますか? サンプルプロジェクトを使って試してみました。しかし、うまくいかない。 どうか助けてください。 BR、 ラキー
記事全体を表示
ソフトウェアの起動中に「同期中止」エラーが発生しました:「handler、esr 0x02000000」。 1. 断続的な障害 (数千回の再起動に 1 回発生): u-boot プロセス中にソフトウェアがフリーズします。障害メッセージは「Synchronous Abort」ハンドラ、esr 0x02000000 です。コードを逆アセンブルすると、次の呼び出しパスが明らかになります: initr_pci → pci_init → dm_pciauto_config_device (pci_auto.c:371) →dm_pci_hose_probe_bus (pci-uclass.c:607) → dm_pciauto_prescan_setup_bridge→ `bl dm_pci_get_bdf`と`ret`の後にポインタ0x8202fc20を取得しようとした際に例外が発生しました。問題は、`ret`が誤ったアドレスにアクセスしていたのに対し、`asr`呼び出しは単なるレジスタシフトであり、本質的にエラーが発生しやすい部分(メモリへのアクセスやジャンプ)がないことです。 2. このソフトウェアはCPLDを使用してウォッチドッグ(外部ウォッチドッグ)にアクティブに信号を送ります。問題発生後、PORESETを使用して外部ウォッチドッグをリセットしましたが、失敗しました。 Re: 软件启动时出现Synchronous Abort" handler, esr 0x02000000 こんにちは、 これは asr 命令自体のエラーではない可能性が高い。主な症状は、 ret 破損または不正なリンク レジスタから PC をロードし、 0x8202fc20 から命令フェッチが発生することです。したがって、異常終了は命令フェッチ時に検出された可能性が高いが、データ破損はそれよりも前に発生したと考えられる。 考えられる原因 まず、以下の分野を調査してください。 スタック破損またはスタックオーバーフロー PCI再帰の各レベルで sp をチェックしてください。 U-Bootスタック周辺にスタックカナリアを追加します。 PCI列挙が設定されたスタックサイズを超えていないことを確認してください。 無効な関数ポインタまたは破損したLR bl dm_pci_get_bdf 直前と直後の x30/LR 、 SP 、 PC 、およびすべてのレジスタをキャプチャします。 スタックに保存されているLRが、想定される戻りアドレスと一致していることを確認してください。 ソースコードだけでなく、正確なバイナリを逆アセンブルしてください。 メモリ破損 DDRの安定性、ECC/エラー状態、キャッシュ構成、およびDMAアクティビティを確認します。 一時的にデータキャッシュ、推測的アクセス、並行DMAを無効にしてください。 未使用のメモリとスタックを既知のパターンで埋め、障害発生後に破損状況を検査する。 PCIe構成アクセスタイムアウト/エラー 列挙前にリンクトレーニングとコントローラーリセットが完了していることを確認してください。 存在しないデバイスが、ハングアップしたり無効なデータを生成したりするのではなく、正当な完了エラーを返すことを確認してください。 PCI初期化を無効にしてテストしてください。問題が解消する場合は、PCIeハードウェア/構成のタイミングに注目してください。 外部ウォッチドッグリセットが失敗する理由 CPUが破損したコードを実行している間もCPLDからウォッチドッグに給料を受けられるため、システムがウォッチドッグのタイムアウトに到達できない可能性があります。また、 PORESET システムを障害状態に維持しているロジックをリセットしない可能性があり、あるいはそのパルスが必要な幅/シーケンスを満たさない可能性があります。 NXPのドキュメントでは外部ウォッチドッグロジックを独立したリセットトリガーとして説明していますが、その実際のリセットパスと影響を受けるドメインはSoCおよびボードリセットアーキテクチャで検証されなければなりません。 オシロスコープまたはロジックアナライザで確認してください。 CPLDウォッチドッグタイムアウト出力 SoCピンの PORESET HRESET / システムリセット PMICリセット入力/出力 リセット試行中の電源レール リカバリ後のリセット原因レジスタ 推奨デバッグ実験 ウォッチドッグポリシーを修正して以下のようにします: U-Bootは、制御された周期的な経路からのみ外部ウォッチドッグにデータを供給する。 PCI列挙中はウォッチドッグはフィードされません。 タイムアウトが発生すると、CPLDはSoC/PMICの仕様を満たすのに十分な長さのリセットパルスを生成します。 リセットの原因を記録し、故障したレジスタをSRAMまたは別の保持領域に保存します。 次に最も価値のある成果物は、 PC 、 LR/x30 、 SP 、 ESR 、 FAR 、 SPSR 、および保存された戻りアドレス周辺のスタックの内容を含む完全な例外ダンプです。そのデータがない場合、障害発生箇所は、破損した戻り値が検出された場所を特定するだけであり、破損が発生した場所を特定するものではありません。   よろしくお願いします。
記事全体を表示
Issue with 1.8V power on MCX-N9XX Evaluation Board. I have an MCXN9XX evaluation board from which I need to obtain 1.8V output at the P1_16 (J17) and P1_17 (J18) pads in order to perform I3C communication with an external I3C hub operating at 1.8V. To obtain 1.8V at the pads, I am re-arranging the jumpers to obtain 1.8V at the MCU_PWR rail which powers the VDD_MCU also. On performing this configuration, the 'MCUXpresso' tool is not able to discover the target and says, 'not able to communicate with the core' (screenshot attached below).  Can anyone please help me with the correct jumper settings so that I am able to get 1.8V at the IO pads J16 and J17 while flashing the code at the same time. Error Screenshot:  Board Design FRDM-Training HW-Open-Source MCXN
記事全体を表示
ADC Configuration for S32K344 EVB HDQFP172 Hi, I want to execute ADC channel ADC0_P7 which is connected to board's Potentiometer, and converted value is used to dim board's LED (GPIO29). After configuration, it is showing: Error:  platform.driver.pins Additionally, when building the project after the configuration, we encountered the following compilation error: image(error_Adc) I also attached the configuration settings below. NOTE: I have added the project from Example. Kindly resolve the issue. Thanks, Raky Re: ADC Configuration for S32K344 EVB HDQFP172 Hi, try to follow hints and resolve errors indicated in Problems window. Most probabbly indiovidual drivers are not added to the toolchain. In newer S32DS this commonly disappear after you Update Code in config tool. Or you need to add it manually through Manage SDK components be sure used components are selecected then Update Code again For the Siul2_Port component, 2 things can be wrong. - Pin tool have 2 pins configured, Siul2_port just 1 and there is missmatch in setting.  Fore ADC input, no pin setting is needed, analog path is always enabled, you can delete it from Pins tool. - another could be naming of Functional group in Pins tool. If you have issue still share your full project. BR, Petr Re: ADC Configuration for S32K344 EVB HDQFP172 Hi, After adding Siul2_Port I got this error. My pin configuration is: I really appreciate taking your time to reply, thanks. BR, Raky Re: ADC Configuration for S32K344 EVB HDQFP172 Hi, add Siul2_Port component, Update Code, and build. BR, Petr Re: ADC Configuration for S32K344 EVB HDQFP172 Hi @PetrS , Thanks for noticing. Here is the attached file below. Br, Raky Re: ADC Configuration for S32K344 EVB HDQFP172 Hi, You did not attach any files or screenshots. You can refer to the following examples that use ADC sampling with a potentiometer: Example S32K312 ADC IP Continuous Scan DMA (S32DS 3.6, RTD 6.0.0) RTD400 LLD K344 ADC SW/HW Trigger Example BR, Petr  Re: ADC Configuration for S32K344 EVB HDQFP172 Hi Petrs, Thanks for the support. Can you also give any resource to try for AUTOSAR version. I tried with the project from example. But not working. Kindly help. BR, Raky 
記事全体を表示
软件启动时出现Synchronous Abort" handler, esr 0x02000000 1、一个偶现故障(上千次重启出现1次):软件在uboot启动过程中卡死,故障现场是:"Synchronous Abort" handler, esr 0x02000000,根据反汇编查看具体调用,发现是:initr_pci→pci_init→dm_pciauto_config_device(pci_auto.c:371)→ dm_pci_hose_probe_bus(pci-uclass.c:607)→dm_pciauto_prescan_setup_bridge → bl dm_pci_get_bdf 后 ret 返回时取指 0x8202fc20 发生异常。问题出在ret到了不正确的地址,而调用的asr只是寄存器移位,它本身没有任何可能出错的地方(不访问内存、不跳转)。 2、软件使用cpld主动喂狗(外部看门狗),在问题出现后,外部看门狗使用PORESET进行复位,但未能成功 Re: 软件启动时出现Synchronous Abort" handler, esr 0x02000000 你好, 这不太可能是 asr 指令本身的错误。关键症状是 ret 从损坏或不正确的链接寄存器加载 PC,导致从 0x8202fc20 获取指令。因此,中止操作很可能是在指令获取阶段检测到的,而损坏则发生在更早的时候。 最可能的原因 首先调查以下几个方面: 堆栈损坏或堆栈溢出 检查每个 PCI 递归级别的 sp 。 在 U-Boot 堆栈周围添加堆栈金丝雀。 确认 PCI 枚举值未超过配置的堆栈大小。 无效的函数指针或损坏的 LR 捕获 x30/LR 、 SP 、 PC 以及 bl dm_pci_get_bdf 之前和之后的所有寄存器。 确认栈上保存的 LR 与预期的返回地址匹配。 反汇编完整的二进制文件,而不仅仅是源代码。 内存损坏 检查 DDR 稳定性、ECC/错误状态、缓存配置和 DMA 活动。 暂时禁用数据缓存、推测性访问和并发 DMA。 用已知模式填充未使用的内存和堆栈,然后在故障后检查损坏情况。 PCIe 配置访问超时/错误 在枚举之前,请确认链路训练和控制器 RESET 已完成。 验证缺失的设备是否返回合法的完成错误,而不是程序挂起或产生无效数据。 禁用 PCI 初始化进行测试;如果问题消失,则重点检查 PCIe 硬件/配置时序。 为什么外部看门狗复位可能会失败 即使 CPU 正在执行损坏的代码,CPLD 仍然可以向看门狗提供信号,因此系统可能永远不会达到看门狗超时。此外, PORESET 可能无法重置使系统保持故障状态的逻辑,或者其脉冲可能不符合所需的宽度/序列。 NXP 文档将外部看门狗逻辑描述为独立的 RESET 触发信号,但其实际 RESET 路径和受影响的功能域必须在 SoC 和板 RESET 架构中进行验证。 用示波器或逻辑分析仪检查: CPLD 看门狗超时输出 SoC引脚上的 PORESET HRESET /系统重置 PMIC复位输入/输出 复位尝试期间的电源轨 恢复后的RESET原因寄存器 建议的调试实验 修改监控策略,使其: U-Boot 仅通过受控的周期性路径向外部看门狗提供数据。 在 PCI 枚举期间,监视程序不会被喂食。 超时时,CPLD 会产生一个足够长的复位脉冲,以满足 SoC/PMIC 规范。 记录复位原因并将故障寄存器保存在 SRAM 或其他保持区域中。 下一个最有价值的工件是包含 PC 、 LR/x30 、 SP 、 ESR 、 FAR 、 SPSR 以及保存的返回地址周围的堆栈内容的完整异常转储。如果没有这些数据,故障定位只能确定检测到损坏的返回数据的位置,而不能确定损坏的源头。   此致
記事全体を表示
The software encountered a "Synchronous Abort" error during startup: "handler, esr 0x02000000". 1. An intermittent fault (occurring once out of thousands of reboots): The software freezes during the u-boot process. The fault message is: "Synchronous Abort" handler, esr 0x02000000. Disassembling the code reveals the following call path: initr_pci → pci_init → dm_pciauto_config_device (pci_auto.c:371) →dm_pci_hose_probe_bus (pci-uclass.c:607) → dm_pciauto_prescan_setup_bridge→ When fetching pointer 0x8202fc20 after `bl dm_pci_get_bdf` and `ret`, an exception occurred. The problem is that `ret` was accessing an incorrect address, while the `asr` call is just a register shift and has no inherent error-prone parts (it does not access memory or jump). 2. The software uses CPLD to actively feed the watchdog (external watchdog). After the problem occurred, the external watchdog was reset using PORESET, but it failed. Re: 软件启动时出现Synchronous Abort" handler, esr 0x02000000 Hello, This is not likely an error in the asr instruction itself. The key symptom is that ret loads the PC from a corrupted or incorrect link register, causing instruction fetch from 0x8202fc20 . The abort is therefore probably detected at instruction fetch, while the corruption occurred earlier. Most likely causes Investigate these areas first: Stack corruption or stack overflow Check sp at every PCI recursion level. Add stack canaries around the U-Boot stack. Verify that PCI enumeration does not exceed the configured stack size. Invalid function pointer or corrupted LR Capture x30/LR , SP , PC , and all registers immediately before and after bl dm_pci_get_bdf . Confirm that the saved LR on the stack matches the expected return address. Disassemble the exact binary, not only the source code. Memory corruption Check DDR stability, ECC/error status, cache configuration, and DMA activity. Temporarily disable data cache, speculative accesses, and concurrent DMA. Fill unused memory and stack with known patterns, then inspect corruption after failure. PCIe configuration access timeout/error Confirm that link training and controller reset are complete before enumeration. Verify that absent devices return a legal completion error rather than hanging or producing invalid data. Test with PCI initialization disabled; if the issue disappears, focus on PCIe hardware/configuration timing. Why the external watchdog reset may fail The watchdog can still be fed by a CPLD while the CPU is executing corrupted code, so the system may never reach the watchdog timeout. Also, PORESET may not reset the logic that is holding the system in the failed state, or its pulse may not meet the required width/sequence. NXP documentation describes external watchdog logic as an independent reset trigger, but its actual reset path and affected domains must be verified in the SoC and board reset architecture. Check with an oscilloscope or logic analyzer: CPLD watchdog timeout output PORESET at the SoC pin HRESET /system reset PMIC reset input/output power rails during the reset attempt reset-cause registers after recovery Recommended debug experiment Modify the watchdog policy so that: U-Boot feeds the external watchdog only from a controlled periodic path. The watchdog is not fed during PCI enumeration. On timeout, the CPLD generates a reset pulse long enough for the SoC/PMIC specification. Record reset cause and preserve the failing registers in SRAM or another retention area. The most valuable next artifact is a complete exception dump containing PC , LR/x30 , SP , ESR , FAR , SPSR , and the stack contents around the saved return address. Without that data, the failure location identifies where the corrupted return is detected, not where the corruption originated.   Regards
記事全体を表示