Multi Source Translation Content

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

Multi Source Translation Content

Discussions

Sort by:
LX2160 上的 UE 到 UE 通信失败 恩智浦团队你好, 我们的 一位客户使用非IPsec模式和静态IP设置了以下配置。该板以 2160 ASF 为 基础。 核心区有一个 BH 服务器,从 BH 服务器分别 ping 到 UE1 和 UE2 都正常。 IP 地址:192.168.205.3 但当它们从 UE1 ping 到 UE2 时,ping 却不起作用。从 pcap 看来,ping 数据包是从 UPF 到达 gnb 的,但没有转发到 dpdk,而是转发到了 Linux 栈。 当我们看到"restool dpni info dpni.3" stats ingress_bytes 在增加,但 egress_bytes 没有增加。Dpni.3 是 ASF 接口。 我们尝试手动执行 setbhinfo 和 conntrack flush,但仍然没有成功。 问题出在哪里? 请参见附件中的 pcap 和 nf_conntrack dump。 Re: UE to UE communication failure on LX2160 根据您的描述,您似乎正在使用"ASFSIB ASK" ,这是付费的 SDK。 在社区讨论这个话题很不方便。 我看到您创建了一个内部案件。我们将在内部案件中为您提供支持。
View full article
S32K3 FRDM オートモーティブ ボードインストールパッケージのダウンロードに関する問題:「保留中(不正行為者)」エラー こんにちは、 S32K3開発用の特定のソフトウェアパッケージをダウンロードしようとした際に問題が発生しており、アカウント権限または輸出管理スクリーニングに関連しているようです。 1. ダウンロード対象パッケージ: S32K3 / FRDM オートモーティブ基板インストールパッケージ(バージョン:2026.02) 同梱物:FreeMaster 1.5.0RFP D2512、S32 Design Studioおよび構成ツール3.6.5D2511、リアルタイム・ドライバ 7.0.0QLP03 D2512、FreeRTOS 7.0.0CD1 HF1 D2511、LINスタック 4.0.0D2511、TCP/IPスタック4.0.0D2512 2. 問題発生とエラーメッセージの発生順序: ステップ 1 (最初の試み - エラー メッセージ):最初はメインリストから FRDM オートモーティブ ボードインストール パッケージを直接選択しました。しかし、「輸出管理」段階への移行中に、次の警告メッセージが表示されました。 「以下のパッケージは保留状態(不正行為者)です。この要求により、他のパッケージが無効になる可能性があることに注意してください。」その結果、次のステップに進むボタンは完全に無効になり、[終了]ボタンのみが有効になった。(「nxp error2.png」を参照してください) ステップ 2 (エラー発生後 - アクセスがブロックされました):このエラーが発生した後、パッケージを再度ダウンロードしようとすると、システムはそれを失敗したカスタム選択リンクとして扱うようです。「警告:この選択には、現在入手できないパッケージが1つ以上含まれています」という警告が表示されたポップアップウィンドウが表示され、[この選択を適用]ボタンがグレー表示になっていて、先に進むことができません。(「nxp error.png」を参照してください) 3. 質問: この文脈において、「保留中(悪質な行為者)」というステータスは具体的に何を意味するのでしょうか?この問題は、私のアカウントの輸出管理審査/承認における遅延または制限が原因ですか? 現在、ポップアップウィンドウが表示されて先に進めず、このパッケージの再選択やダウンロード処理を進めることができません。この問題を解決し、FRDM オートモーティブ ボードインストールパッケージを正常にダウンロードするために、私がどのような対応を取る必要がありますか?あるいは、NXP側でどのような調整が必要ですか? ご協力ありがとうございました。 よろしくお願いいたします。 Re: Issue with Downloading S32K3 FRDM Automotive Board Installation Package: 'Pending(Bad Actor)' Er こんにちは、 @iamengineer さん、 類似の事例に基づくと、「保留中(悪意のある行為者)」というメッセージは、通常、ソフトウェアのダウンロードに関するアカウントまたは権限の制限を示しており、パッケージ自体に問題があるわけではありません。 お近くのNXP FAEにご連絡いただき、NXPアカウントのメールアドレス、会社名/国名、正確なパッケージ名/バージョン、およびメッセージのスクリーンショットをお送りください。 バンドルに含まれるコンポーネントを個別にダウンロードしてみることもできます。 よろしくお願いいたします。 パベル
View full article
NXP S32G-VNP-RDB2に関するヘルプ 私は組み込みLinuxに関しては全くの初心者で(ほとんど何も知りません)、NXP S32G-VPN-RDB2ボードを持っています。このボードでは、定期的にボード内の情報(CPU使用率、RAM使用率など)を収集し、テキストファイルに保存する必要があります。また、これをバックグラウンドサービスとして実行する必要があります。私は既にこれらの作業を実行するためのスクリプトを作成済みでした。ボードの起動は成功し、スクリプトも正常に実行されましたが、スクリプトをサービスにするために、Linux PC の systemd を使用しました。しかし、ボードの Linux (Auto Linux BSP 39.0) には systemd が存在せず、apt コマンド、systemctl、bashrc も存在しません。何をすればいいのか、このスクリプトをサービスにするにはどうすればいいのか、本当に困っています。どこかで、Yoctoを使えばボード上のLinuxをカスタマイズできると読んだのですが、全く知識がなく、どこから始めたらいいのか分かりません。助けてください :') Re: Help with NXP S32G-VNP-RDB2 こんにちは、 @lengoyeko 投稿ありがとうございます。 BSP42のようなより新しいBSPバージョンで作業することは可能でしょうか、それとも前述のとおりBSP39を使用することにこだわるのでしょうか? RDB3をベースにしたBSP42(テスト準備が整っているため)で簡単なテストを行ったところ、systemdをベースにしたサービスを実装することをお勧めします。私のテストでは、このリリースで問題なく動作しているようです。 BR チェイン
View full article
SE05X - 同時アクセスおよび並列アクセスのサポート こんにちは、 私はSE05xをPlug & Trustミドルウェアを使用して運用していますが、同時アクセス(並列アクセス)のサポート状況について理解を深めたいと思っています。 複数のスレッドまたはプロセスから同時にSE05Xにアクセスすることは可能ですか? はいの場合: 同時アクセスを使用する際に、何か制限や制約はありますか? SE05Xは内部的に同期処理を行いますか、それともホスト側で完全に管理する必要がありますか? マルチスレッドまたはマルチセッションでの利用に関して、推奨されるベストプラクティスはありますか? そうでない場合: - マルチスレッドまたはマルチプロセス環境でSE05Xを使用する場合、推奨されるアーキテクチャは何ですか? ご説明や関連ドキュメントへの参照などございましたら、大変ありがたく存じます。 ご回答をお待ちしています。 スマート・カード Re: SE05X - Support for concurrent and parallel access こんにちは@nofarbe あなたの調子が良いといいのですが。 SE05xはマルチテナントモデルをサポートしています。SE050A/B/C/Dユーザーガイド/ EdgeLock SE050Eユーザーガイドの第5章を参照してください。 よろしくお願いいたします。 エドゥアルド。
View full article
Guidance for Low Power Mode on i.MX8MP Hi NXP Team, I am working on a custom product based on i.MX8M Plus (i.MX8MP) using Yocto Linux and BusyBox userspace. Current hardware configuration: i.MX8MP LA9410 connected through PCIe LTE modem (u-blox LARA-L6) connected through USB MIPI CSI camera connected to i.MX8MP Yocto BSP based Linux BusyBox rootfs Project requirement: We need to implement low power operation with: Low latency wakeup Fast resume back to normal operation PCIe and USB subsystem stability after resume Camera pipeline recovery after wakeup LTE modem reconnect/resume support We are currently evaluating: WAIT mode STOP mode DSM (Deep Sleep Mode) From the Reference Manual and AN13400, DSM gives maximum power saving, but our concern is wakeup latency and peripheral resume stability. Main questions: Which low power mode is recommended for this use case? WAIT STOP DSM For low latency wakeup with PCIe + USB + camera active systems, is suspend-to-idle preferred over deep suspend? Are there any known limitations for: PCIe device resume (LA9310) USB LTE modem resume CSI camera recovery after suspend Which BSP version/kernel is most stable for low power support on i.MX8MP? We are currently considering: LF 6.6.3 BSP Yocto Nanbield Are there recommended SDKs, patches, or reference implementations for: PCIe wakeup USB wakeup Runtime PM DSM entry/exit Low latency suspend/resume Is there any recommended approach for keeping LTE connectivity partially active while reducing overall system power? Reference documents we are studying: AN13400: i.MX 8M Low Power Design By M Core Running i.MX8MP Reference Manual Chapter 5 (GPC / Low Power) Linux PM framework gpcv2 driver Any guidance, reference SDKs, Yocto layers, example DTS configurations, or suspend/resume debug methods would be very helpful. Thank you. FRDM-Training Hands-On Training HW-Open-Source i.MX 8 Family | i.MX 8QuadMax (8QM) | 8QuadPlus i.MX 8M | i.MX 8M Mini | i.MX 8M Nano PMIC Security Suspected Software Defect Yocto Project Re: Guidance for Low Power Mode on i.MX8MP Hi, 1. I would recommend Runtime PM first, use runtime PM/autosuspend for individual subsystems while Linux is running: PCIe endpoint idle handling, need PCIe endpoint driver support: https://docs.kernel.org/power/pci.html USB modem autosuspend / remote wakeup: linux/Documentation/driver-api/usb/power-management.rst camera stream stop / sensor power management, should be shutdown before IDLE/SLEEP CPU idle / DVFS 2. For short idle periods and fast wakeup, use Linux suspend-to-idle. DSM only for long idle / maximum power saving 3. For  the BSP verison, recommend to use latest version. Best Regards, Zhiming
View full article
Boar Green Boresight Review Available? Ask Yourself 2026 Boar Green Boresight is becoming one of the most talked-about firearm alignment tools in 2026 because it focuses on improving sight accuracy and reducing wasted ammunition instead of relying on time-consuming manual adjustments. Designed for shooters, hunters, and firearm enthusiasts, the device helps users quickly align optics and sights before live firing, making the setup process faster, easier, and more efficient. Boar Green Boresight Ready to go What makes it stand out is its beginner-friendly and practical approach. Rather than requiring advanced gunsmith knowledge or expensive range sessions, the tool is designed to simplify the sighting process for everyday users. Many firearm owners appreciate that it can help save time, reduce frustration, and minimize unnecessary ammo use while improving overall accuracy setup. In 2026, with rising ammunition costs and increasing interest in shooting sports, hunting, and firearm maintenance, more people are looking for affordable tools that improve efficiency and precision. Boar Green Boresight taps directly into this trend by offering a convenient alignment solution that supports faster scope adjustments and better preparation before heading to the range. Is it worth buying? For firearm owners looking for a practical sight alignment tool, the answer appears to be yes. The value comes from the convenience, time-saving benefits, and ease of use provided by the system. However, proper firearm handling and final live-fire testing are still necessary for the best accuracy results. It is best suited for users who want a simpler and more efficient way to prepare their optics and sights before shooting sessions. see more: - https://tinyurl.com/skhtee8p
View full article
MMOexp:Warborne: Above Ashes Void Weapons Guide In the brutal battlefield of Warborne: Above Ashes, few weapon archetypes are as terrifying or strategically oppressive as the Void Weapons. While other classes rely on raw burst damage, mobility, or defensive utility, Void users specialize in one thing above all else: overwhelming enemies through relentless attrition. Their toolkit revolves around Plague, a devastating status effect that weakens opponents, Warborne Above Ashes Solarbite, and turns prolonged fights into nightmares. Void Weapons are not simply about dealing damage. They dominate engagements by corrupting enemy positioning, limiting mobility, draining survivability, and creating constant pressure that forces opponents into mistakes. Whether you are fighting in PvP skirmishes, large-scale guild wars, or difficult PvE encounters, understanding how Void abilities synergize together is essential for maximizing their potential. This article breaks down every major Void Weapon ability, explores the importance of the Plague mechanic, and explains why Void builds are rapidly becoming one of the most feared archetypes in Warborne: Above Ashes. The Core Identity of Void Weapons At the center of every Void build is the Plague debuff. Nearly every skill in the Void arsenal either applies Plague directly or amplifies its effects through crowd control and debuffs. Unlike simple damage-over-time mechanics found in many MMOs, Plague acts as a layered pressure system. The longer enemies remain exposed, the weaker and more vulnerable they become. This creates a combat style focused on sustained dominance rather than immediate elimination. Void players excel in prolonged engagements where they can slowly choke enemy resources, reduce healing efficiency, and control movement. The strength of Void Weapons comes from three major factors: Continuous area denial Multi-target pressure Stacking debuffs that cripple enemy performance Because of this, Void users are especially effective in coordinated team fights where allies can capitalize on weakened enemies. Touch of Plague – The Foundation of Every Void Build Every Void Weapon begins with the passive attack ability known as Touch of Plague. On the surface, it appears simple: basic attacks deal 90% Magic Damage and apply Plague. However, this ability forms the backbone of the entire archetype. Unlike weapons that rely heavily on cooldown bursts, Void users constantly apply pressure through ordinary attacks. Every strike contributes to long-term damage scaling while setting up stronger abilities later in the rotation. The importance of Touch of Plague becomes especially clear during extended engagements. Opponents cannot simply ignore basic attacks because every hit strengthens the overall Plague presence on the battlefield. Over time, even heavily armored enemies begin to crumble under sustained corruption. This passive also makes Void Weapons exceptionally strong in group combat. When multiple enemies are infected simultaneously, the battlefield becomes increasingly difficult for healers and frontline tanks to stabilize. Plague Strike – Reliable Mid-Range Pressure Plague Strike introduces one of the most versatile tools in the Void arsenal. The skill releases a shockwave in a target direction, dealing 120% Magic Damage while inflicting Plague on every enemy hit. This ability excels because of its straightforward reliability. The linear projectile allows Void players to pressure clustered enemies, punish retreating targets, and safely apply Plague from mid-range distances. In PvP, Plague Strike becomes particularly dangerous during chokepoint battles. Enemy teams attempting to advance through narrow paths can quickly become infected all at once, creating opportunities for allied damage dealers to follow up. The ability also works extremely well as an opener. Applying Plague to multiple enemies before activating heavier debuff abilities dramatically increases overall battlefield control. Because of its speed and reach, Plague Strike is one of the most commonly used abilities in aggressive Void rotations. Venom Pool – Area Control at Its Finest One of the defining strengths of Void Weapons is their ability to dictate enemy movement, and Venom Pool perfectly embodies that identity. This skill throws a venomous pool onto the battlefield that lasts four seconds. Enemies inside are slowed by 20% while receiving Plague every second. Although the raw damage may seem modest compared to burst-oriented skills, Venom Pool creates immense tactical value. Players trapped within the area become increasingly vulnerable while struggling to reposition effectively. In large-scale warfare, Venom Pool can completely reshape engagements. Placing it on objectives, choke points, or escape routes forces opponents to either endure constant Plague application or abandon critical positioning. The skill becomes even more oppressive when combined with allied crowd control. Tanks and melee fighters can pin enemies inside the pool while Void users continuously stack pressure. Venom Pool is also highly effective defensively. Retreating players can drop the ability behind them to slow pursuers and create breathing room during chaotic fights. Scourge – Sustained Pressure and Self-Sustain Scourge is one of the most intimidating single-target abilities available to Void users. The skill channels continuous damage every 0.7 seconds, inflicting Plague while simultaneously restoring 25% HP to the caster. The tradeoff is mobility. Players cannot move while channeling Scourge, meaning positioning becomes absolutely critical. When used correctly, however, Scourge can completely swing duels and frontline encounters. The combination of repeated damage ticks and self-healing allows Void players to outlast opponents who rely on burst windows. This ability is especially devastating against isolated targets. Enemies caught without mobility cooldowns or interrupts can rapidly lose health while the Void user sustains themselves through incoming damage. Scourge also synergizes exceptionally well with slowing effects from Venom Pool or Plague Surge. Once opponents are immobilized or heavily slowed, escaping the channel becomes significantly more difficult. In PvE, Scourge serves as a reliable sustain tool during boss encounters and elite farming, allowing Void players to maintain pressure without depending entirely on healers. Plague Surge – Massive Crowd Pressure Among all Void abilities, Plague Surge stands out as one of the strongest team-fight initiators. The ability releases a surge of plague energy in a target direction, dealing 160% Magic Damage, applying two stacks of Plague, and reducing enemy Speed by 30% for four seconds. This combination is incredibly dangerous because it simultaneously delivers damage, debuffs, and crowd control in a single action. The double-stack Plague application accelerates the corruption process immediately, making enemies vulnerable much faster than standard attacks alone. Meanwhile, the movement reduction severely limits repositioning options. Plague Surge is particularly effective when engaging grouped enemies. Landing the ability on multiple targets can instantly shift momentum in favor of your team. In coordinated PvP scenarios, Void players often use Plague Surge as the opening strike before allies unleash heavy AoE abilities. Slowed enemies become easier targets for follow-up crowd control, ranged attacks, and burst combos. Because of its high impact and strong scaling potential, Plague Surge is often considered a mandatory skill in competitive Void builds. Spread Plague – Constant Battlefield Oppression If there is one skill that truly defines the oppressive identity of Void Weapons, it is Spread Plague. While active, the ability continuously consumes MP every three seconds and automatically inflicts Plague on nearby enemies. Opponents also suffer a 30% chance for basic attacks to miss for five seconds. This ability transforms Void users into walking zones of corruption. In prolonged fights, Spread Plague creates enormous passive pressure simply by existing near enemy players. Melee fighters struggle to maintain efficiency because missed attacks dramatically reduce damage consistency. The psychological effect is equally powerful. Opponents are forced to either disengage entirely or remain inside an increasingly punishing aura. Spread Plague shines brightest during large-scale warfare and objective control. Void players can push directly into enemy formations and destabilize entire frontlines through passive debuffs alone. However, the ability requires careful MP management. Poor resource control can leave players vulnerable after exhausting mana reserves. Skilled Void users know exactly when to activate or deactivate Spread Plague depending on the pace of battle. Exhaustion – One of the Strongest Debuff Skills in the Game Exhaustion may be the single most strategically powerful utility skill available to Void Weapons. The ability creates a draining field lasting six seconds. Enemies inside are slowed by 30% while receiving stacks of Exhaustion every second. Each stack reduces Damage Boost, Healing Bonus, and Attack Speed by 6%, stacking up to six times. At maximum stacks, enemies suffer catastrophic stat reductions: 36% reduced Damage Boost 36% reduced Healing Bonus 36% reduced Attack Speed This is absolutely devastating in organized PvP. Healers become dramatically less effective. DPS players lose offensive momentum. Tanks struggle to maintain threat and sustain. Entire enemy formations can collapse if trapped inside the field too long. Exhaustion works especially well during sieges and defensive holds. Placing the field around objectives forces enemies to either retreat or fight while severely weakened. Combined with Venom Pool and Spread Plague, Exhaustion creates layered zones of denial that can completely dominate terrain control. Many experienced players already consider Exhaustion one of the strongest utility abilities currently available in Warborne: Above Ashes. Toxic Matter – Chain Corruption and Resistance Shredding Toxic Matter represents the high-skill, high-value side of the Void arsenal. After a brief cast time, the projectile launches toward a target and bounces between enemies up to nine times. Each hit deals 120% Magic Damage, applies Plague, and reduces Magic Resistance by 15% for four seconds. This ability becomes incredibly dangerous in clustered fights. The bouncing mechanic allows Toxic Matter to spread corruption rapidly through entire enemy groups while simultaneously amplifying magical damage from allied casters. The Magic Resistance reduction is particularly important because it strengthens not only the Void player’s own abilities but also the effectiveness of allied magic users. In coordinated guild battles, Toxic Matter often serves as the setup tool for devastating magical burst combinations. The bounce limit also rewards intelligent targeting. Skilled players aim at central enemies to maximize spread efficiency and ensure the debuff reaches priority targets. Because each enemy can only be hit twice, positioning and timing become critical factors in mastering the skill. Why Void Weapons Are Becoming Meta The growing popularity of Void Weapons in Warborne: Above Ashes comes down to versatility. Few archetypes can simultaneously: Control space Apply sustained AoE pressure Reduce enemy effectiveness Support allied damage Maintain self-sustain Dominate prolonged engagements Void users thrive in nearly every type of combat scenario. Small-scale duels reward their sustain and attrition. Large-scale wars amplify their debuff potential. PvE encounters benefit from their constant pressure and survivability. Most importantly, Void Weapons punish mistakes harder the longer fights continue. Enemies who fail to disengage early often find themselves trapped in overlapping debuffs with little chance of recovery. As the competitive meta evolves, Void players are quickly becoming essential members of organized groups and guild compositions. Final Thoughts Void Weapons in Warborne: Above Ashes are more than simple damage dealers. They are battlefield corrupters designed to dismantle enemy formations piece by piece through relentless pressure and debilitating effects. From the constant infection of Touch of Plague to the overwhelming debuffs of Exhaustion and the chain devastation of Toxic Matter, every skill contributes to a combat style built around domination through attrition cheap Warborne Above Ashes Solarbite. Players who enjoy strategic warfare, area denial, and methodical battlefield control will likely find Void Weapons among the most rewarding archetypes in the game. While they may lack the flashy burst of assassin classes or the straightforward durability of tanks, their ability to weaken entire enemy teams makes them one of the most dangerous forces currently emerging in Warborne: Above Ashes.
View full article
Profinet source code example does not seem to boot on MIMXRT1180-EVK I have downloaded the Profinet library from here and am following the PDF files/videos contained in the zip files. This seems to go well until chapter 6 PROFINET protocol validation using ICE tool. When I scan the network at step 2, no device is found. It seems to me an earlier step, during building or flashing, went wrong, because I also don’t see any UART logging or other indication that the firmware boots. It is also not possible to attach the MCULink debugger. I suspect there may be an issue with the Secure provisioning/MCUXpresso plugin tool versions and changes that were made to the generation of the bootable image. The PDF and video use the 2509 SDK release, and I assume SEC tool. I started with the latest SDK release (2603) although I have also tried to downgrade to 2509. Still the SEC tool post build step, triggered from the VSCode MCUXpresso plugin after cmake completes, seems to work differently now and creates ELF files in: projects\goal_pnio_rpc_lib\00_cc\vsc\nxp\mimxrt1180_evk_cm33_rtos\.secureprovisioning I have tried to program the image from the guide projects\goal_pnio_rpc_lib\00_cc\vsc\nxp\mimxrt1180_evk_cm33_rtos\flexspi_nor_release\mimxrt1180_evk_cm33_rtos as well as the secure provisioning one, but the result seems the same. If I download the Profinet Eval Binarires. When I flash those, I can find the Profinet device, change cyclic data In the ICE tool and see logging from the COM port of the MCULink, so I don’t think there’s anything wrong with the hardware. That image does not seem to be XIP however (when loaded in SEC tool), so it is hard to compare the differences after flashing.  Should this example still work with the 2603 SEC tool and SDK or do I need to downgrade my whole setup? Is there something I could be doing wrong and if so, how can I test if earlier steps were successful ? I have tried many things: Reading back the programmed flash looking for the FCB (It looks ok, but it's a needle in a haystack to me). Trying other demos (blinky works, multicore trigger as well, but the flashing workflow is different, using an additional image for the CM7 core) Adding extra logging, right after initializing the board (nothing shows up) Using nxpele to look for boot info and events (they seem volatile and require a restart to start the flash loader?). I have also tried to build the Debug configuration of the example, to see if the firmware hangs instead of the secure boot, but that is not possible. The resulting text section is too big (about 320kB) to be placed in the reserved and remaining RAM, so the linker fails.  Thanks for anyone that can provide a hint. I am out of ideas. Re: Profinet source code example does not seem to boot on MIMXRT1180-EVK The problem has been reproduced and our team is resolving it internally now. We will promptly update you once a solution is available.  Re: Profinet source code example does not seem to boot on MIMXRT1180-EVK Dear Maurits Fassaert, I have reverted all the tool version back to 2509, and the Profinet device is now successfully detected: You could check the mcuxpresso-tools.json file in the project to see the SDK version currently in use: In addition, please use MCUXpresso Secure Provisioning Tool 25.09 to flash the image.   If you are using a self-compiled ELF file, it is expected that no UART log will be output after boot. You can verify the boot status by checking the ENET3 port and the Ethernet port on your PC. If the orange LED is blinking, it indicates the network is connected, which means the boot process has completed successfully.  Re: Profinet source code example does not seem to boot on MIMXRT1180-EVK Thanks!  That works for now, so I am no longer blocked. 
View full article
i.MX93 LPSPI7 Usage on Cortex-M33 and Sampling Rate Verification Hi NXP Team, I would like to ask whether LPSPI7 on the i.MX93 can be assigned to and controlled by the Cortex-M33 core instead of the Cortex-A55 cores. If this is supported, Is there any reference example or SDK project demonstrating LPSPI7 operation on the M33 core? In addition, I would like to evaluate the SPI performance when running on the M33 core. Is there a recommended method to measure the actual SPI sampling rate / data throughput? Are there any known limitations regarding the maximum achievable SPI clock frequency or sampling performance when LPSPI7 is controlled by the M33 core? Thank you. BR, Sean Linux Re: i.MX93 LPSPI7 Usage on Cortex-M33 and Sampling Rate Verification Can LPSPI7 be assigned to Cortex‑M33 instead of Cortex‑A55? Yes. Practical configuration steps (inferred from architecture) You will need: TRDC configuration Assign LPSPI7 peripheral region to M33 domain Remove A55 access (optional but recommended for isolation) Clock + reset setup Typically done by A55 → passed to M33 (or handled via SCFW/firmware depending on flow) Interrupt routing Ensure LPSPI7 IRQ enabled in M33 NVIC DMA (optional) Use eDMA channel: TX: mux slot 83 RX: mux slot 84 Is there an SDK example for LPSPI on M33 (i.MX93)? What likely exists (based on MCUXpresso design) Generic LPSPI driver for Cortex‑M33 Example projects (board-dependent): lpspi_master lpspi_interrupt lpspi_edma How to measure SPI throughput / sampling rate?   Method 1 — GPIO toggle (cycle-accurate) Method 2 — pure bus clock verification Method 3 — DMA stress test (recommended) For max throughput: Use LPSPI + eDMA Continuous transfer (loop / ping‑pong buffer) Measure: sustained bandwidth CPU utilization Performance / clock limitations on M33 The RM provides system capability but does not explicitly state “M33-specific SPI limit”. However: M33 runs @ ~250 MHz LPSPI supports DMA (important for high throughput) No architectural limitation tying SPI speed to A55 Re: i.MX93 LPSPI7 Usage on Cortex-M33 and Sampling Rate Verification I discussed more with the AE team, please refer to the following update from them. i.MX93 does not isolate M33 and A55 cores. LPSPI7 can be controlled by M33 without any changes, the bottom line is you don't control it from A55 side simutaniously. There's no specific SDK example for LPSPI7. You'll have to adapt to LPSPI7 using existing examples. To measure the actual SPI sample rate, an oscilloscope or logic analyser is recommended. M33 should be able to reach the max data rate specified in the specs, no known limitations as I'm aware of. Re: i.MX93 LPSPI7 Usage on Cortex-M33 and Sampling Rate Verification Hi @yipingwang , Thank you for your reply. Could you also confirm whether both TPM2 and ADC1 can be controlled by the M33 core? We noticed a statement in the i.MX93 Reference Manual indicating that "any peripheral can be assigned to any domain." Based on this, it appears that TPM2 and ADC1 should be assignable to the M33 domain. However, we would like to double-check and obtain confirmation from NXP. Thank you! Best Regards, Sean Re: i.MX93 LPSPI7 Usage on Cortex-M33 and Sampling Rate Verification Yes, there's no restriction to assign TPM2 and ADC1 to M33 Re: i.MX93 LPSPI7 Usage on Cortex-M33 and Sampling Rate Verification Hi @yipingwang , OK, thank you
View full article
CAN MX6 rev 3は、ハードウェアやソフトウェアの変更なしに、MX6 rev 6と直接置き換えることができますか? アプリケーションのハードウェアとソフトウェアはMX6 rev 6向けに設計されていますが、現在入手可能なのはMX6 rev 3のみです。rev 3で代用することは可能でしょうか?どのようなハードウェアまたはソフトウェアの変更が必要になりますか? Re: Can MX6 rev 3 directly replace MX6 rev 6 without hardware or software changes? リタ・ワンさん、ありがとうございます。 これは、Rev 1.3向けに設計されたアプリケーションハードウェアが、変更なしでRev 1.6を使用できることを示しています。そしてそれは、ソフトウェアを修正する必要があることを示している。 メーカーは、Rev 1.6チップ向けに設計されたアプリケーションハードウェアに使用したいRev 1.3チップの在庫を保有している。 Rev 1.3向けに設計されたソフトウェアをインストールすれば良いと伝えても良いでしょうか? 私のために時間を割いてくださったことに、心から感謝しています! Re: Can MX6 rev 3 directly replace MX6 rev 6 without hardware or software changes? ジョアン・シエさん、ありがとうございます。 おっしゃる通りです。メーカーはRev 1.3の在庫を保有しており、それらを活用したいと考えています。 ハードウェアとソフトウェアの変更計画を提供できれば、彼らは大変喜ぶでしょう。計画を実行するのは私の仕事ではありません。 もし私が、その変更を行うことが現実的ではないことを彼らに示せれば、彼らは失望するだろうが、満足するだろう。なぜなら、それらが生み出す製品は高価であり、信頼性に欠けるからである。 少なくとも、私は彼らの可能性を調査するという自分の仕事は果たしたことになる。 改めてありがとうございました。 Re: Can MX6 rev 3 directly replace MX6 rev 6 without hardware or software changes? 既にREV 1.6を使用しているのに、なぜREV 1.3に戻す必要があるのですか?Rev 1.6ではRev 1.3のいくつかの問題を修正し、一部のヒューズも変更されています。既にこれらのヒューズを使用している場合、Rev 1.3を使用すると問題が発生する可能性があります。可能であれば、Rev 1.6を使用することをお勧めします。 Re: Can MX6 rev 3 directly replace MX6 rev 6 without hardware or software changes? 確認済みなので、共有させていただきます。 これがあなたのお役に立てば幸いです。 Re: Can MX6 rev 3 directly replace MX6 rev 6 without hardware or software changes? MX6 Rev 1.6を使用しているアプリケーションをMX6 Rev 1.3を使用するように変更するために必要なハードウェアおよびソフトウェアの変更点を具体的に記載したドキュメントを教えていただけますか? Re: Can MX6 rev 3 directly replace MX6 rev 6 without hardware or software changes? Rita_Wangさん、ありがとうございます。 Rev 1.6を使用しているアプリケーションをRev 1.3を使用するように変更するために必要なハードウェアおよびソフトウェアの変更点を具体的に明記したドキュメントを、あなたまたは他のどなたか教えていただけませんか? Re: Can MX6 rev 3 directly replace MX6 rev 6 without hardware or software changes? ソフトウェアやハードウェアの変更は一切不要です。 Re: Can MX6 rev 3 directly replace MX6 rev 6 without hardware or software changes? 念のため補足しておきますが、正しくはリビジョン1.6とリビジョン1.3と言うべきでした。 Re: Can MX6 rev 3 directly replace MX6 rev 6 without hardware or software changes? 皆様、ありがとうございました。あなたの回答と参照された文書から私が理解したことは以下のとおりです。 1. Rev 1.3のハードウェアを使用しているユーザーは、ソフトウェアをアップデートすることでRev 1.6のデバイスを使用できます。 2. したがって、Rev 1.6 ハードウェアを持っている人は、ファームウェアとシステムソフトウェアを改訂して、Rev 1.3 デバイスを使用することができます。 3.しかし、それらにはRev 1.6デバイスで行われた修正や改良は一切含まれていない。 私の言っていることは正しいですか? もし間違っていたら、訂正してください。 改めてありがとうございました。 Re: Can MX6 rev 3 directly replace MX6 rev 6 without hardware or software changes? こんにちは、 @RobertPeruzzi さん。 質疑応答: 1. はい、その通りです。 2\問題が発生する可能性があり、上記でお伝えした違いは、お客様がその2つのセクションを使用しない場合は問題ないかもしれません。 3. 正解です。 これがあなたのお役に立てば幸いです。 素敵な一日をお過ごしください よろしくお願いいたします。 リタ Re: Can MX6 rev 3 directly replace MX6 rev 6 without hardware or software changes? リタ・ワンさん、改めてありがとうございました。まさに私が探していた情報です。 素敵な一日をお過ごしください。 ボブ・P
View full article
PN5190 Offscreen NFC Test PCD Analog TA132 4-plane FAIL Hello, we are developing an off-screen NFC, and we are currently experiencing some problems with the PCD Analog test: TA132's 4-plane test Fail The contents of the FAIL are shown in the figure, and so far it has been verified as follows: 1. Extinguish the screen to test PASS 2. When lighting up the screen, the maximum output voltage of DPC needs to drop to 4.5V, TA132 4-plane test PASS, but TAB111 4-plane field voltage will Fail! 3. In the middle of the attempt to debug the ARC parameters, the test results did not significantly improve the effect, please ask whether there are other parameters can be optimized 4. Read 5190 documentation, mentioned SDT can solve this problem, please advise how to correctly debugging We have tried debugging, with TypeA parameters loaded, no specific waveform information (GTK wave) in the captured log, using the recommended Signal Detection Threshold, no improvement Re: PN5190 屏下NFC测试PCD Analog TA132 4平面fail Tested with loopback, also tested with transaction send A, both reported errors. Re: PN5190 屏下NFC测试PCD Analog TA132 4平面fail Hello @mark_tang  Please use EMVCo stack to test as the below: Re: PN5190 屏下NFC测试PCD Analog TA132 4平面fail Hello @mark_tang Was the antenna under the screen when you tested it? Re: PN5190 屏下NFC测试PCD Analog TA132 4平面fail Yes, the antenna has three edges under the screen glass and one edge directly below the screen (the metal frame behind the screen has been removed), schematically as follows Re: PN5190 屏下NFC测试PCD Analog TA132 4平面fail Hello, any suggestions, this side of the debugging passive matching has not much progress, TA132's 4-plane test Fail this problem has not been solved!
View full article
How to get temperature in S32R45 on Linux? How to get temperature in S32R45 on Linux? I am using BSP37  /sys/class/thermal# ls -l total 0 Re: How to get temperature in S32R45 on Linux? Hello, On S32R45 with Linux BSP37, the empty /sys/class/thermal directory is expected behavior. In Linux, temperature is exposed only when a thermal sensor driver is implemented and registered as a thermal zone. Without this registration, no entries appear in /sys/class/thermal. Although S32R45 hardware includes temperature sensing capability, BSP37 does not enable or expose this feature through the Linux thermal framework. As a result, no thermal zones are created and temperature cannot be read from user space. According to NXP BSP documentation, not all hardware features are necessarily enabled in a given BSP release, which explains the absence of temperature support in this case. Best regards, Peter
View full article
RT1062 SAI MCLK入力をマスターとして 誤ってi.mxプロセッサ全般のフォーラムに投稿してしまったので、こちらに再投稿します。 RT1062のSAI1を送信用のI2Sマスターとして使用しつつ、1060 EVKBの外部クロックソースからの入力としてMCLKを使用しようとしています。RT1062のSAI1を、内部PLLから生成されたMCLKを使用してI2Sマスターとして動作させており、J23のピン1(信号GPIO_AD_B1_09)でMCLK出力を確認でき、同じヘッダー上でBCLKなども確認できます。 このThreadから私が理解したことは次のとおりです。 https://community.nxp.com/t5/i-MX-Processors/SAI1-MCLK1-source-select/mp/1435023 その同じピンをMCLK入力として使用できるということです。これらのレジスタフィールドを変更します(RMのp326-327): - IOMUXC_GPR_GPR1 の SAI1_MCLK1_SEL - MCLK ピンを選択するには、000 から 011 に変更します。 - IOMUXC_GPR_GPR1 の SAI1_MCLK1_DIR - 入力として MCLK を選択するには、1 から 0 に変更します。 また、どちらの場合も IOMUXC_SW_MUX_CTL_PAD_GPIO_AD_B1_09 は 3 に設定され、AD_B1_09 が MCLK 機能に選択されます。 この操作を行い、J23のピン1に外部クロック信号を供給すると、I2S出力が表示されません。BCLKの生成なども行われません。 I2Sマスタ送信の入力としてMCLKを選択するために、他にレジスタの変更が必要ですか? i.MXRT 106x Re: RT1062 SAI MCLK input as master こんにちは、 @EdwinHz さん。 情報ありがとうございました!おかげで解決しました!SAI1_MCLK_2_SELECT_INPUTレジスタを1に設定してAD_B1_09を選択したところ、外部MCLK発振器を使用したI2S出力は正常に動作しています。 リファレンス・マニュアルの改訂版が発行される予定があるかどうかは分かりませんが、もしそうであれば、この記録簿にその旨を記した短い注記を追加することをお勧めします。この場合、レジスタの名前だけではその機能を完全に示すことはできません。特に、MCLK2と表記されているにもかかわらず、ここではMCLK1を入力として使用できるようになっているからです。 貴重な情報、ありがとうございました。 Re: RT1062 SAI MCLK input as master こんにちは、 @mojolabs さん。 GPIO_AD_B1_09のMCLK信号を入力として使用できるようにするには、あと1つレジスタ設定を調整する必要があります。 この調整で問題は解決するはずですが、それでも問題が解決しない場合はお知らせください。 BR、 エドウィン。
View full article
升级到 BSP46 后,M 核心无法启动 A 核。 升级到 BSP46 后,M 核心无法启动 A 核。系统运行至bl2_w_dtb.bin-sdcard加载完毕并触发 A 核启动,之后 M 内核的程序计数器 (PC) 行为异常。 你能否提供在 BSP46 上启动 A-core 的 M-core 演示? Re: After upgrading to BSP46, the M-core fails to boot the A-core. 你好,@zhijie 谢谢您的帖子。 您能介绍一下工作环境吗? 1。我能知道更新到 BSP46 之前使用的原始 BSP 版本吗? 2.在您之前可用的设置中,引导加载程序的版本是什么?在 M 内核上使用的是哪种应用程序(基于哪个版本的 RTD/PFE_MCAL 等)? BR 切宁 Re: After upgrading to BSP46, the M-core fails to boot the A-core. 问题解决了,谢谢!......
View full article
S32G3上のTrustZone こんにちは、 現在、S32G3上でARM TrustZoneを有効化する作業に取り組んでいます。 私の状況は以下の通りです。 私のテストカードでは、Rich OSとOP-TEEを起動できます。NXPリポジトリからこのOP-TEEを取得しました https://github.com/nxp-auto-linux/optee_os/tree/release/bsp46.0-4.0 。 ビルドプロセス中に、OP-TEEクライアントとOP-TEEサンプルをビルドします。サンプルとして提示された信頼できるアプリに関連するバイナリファイルは、私のテスト用カードのファイルシステム上の適切な場所に存在しています。 サンプルとして提供されている信頼済みアプリをテストしようとしています。そのためには、まずtee-supplicantを起動し、次にテストしたいtrusted-appに関連するバイナリを実行します。 しかし、次のようなエラーが発生します。 E/LD: init_elf:486 sys_open_ta_bin(8aaaf200-2450-11e4-abe2-0002a5d5c51b) 等:?0 ldelf_init_with_ldelf:152 ldelf が res: 0xffff0000 で失敗しました optee_example_hello_world: TEEC_Opensession がコード 0xffff0000 で失敗しました。発生元 0x3 コードを確認したり、他のフォーラムを読んだりしたところ、tee-supplicantはOP-TEEからの指示を受け取っていないようです。 より正確に言うと、/proc/$(tee_supplicant_pid)/maps を見ると、OP-TEE の共有マップが tee_supplicant のアドレス空間にマッピングされていないことがわかります。 [ 0.000000] OF: 予約済みメモリ: 0x00000000fe000000..0x00000000ff3fffff (20480 KiB) nomap 再利用不可 optee@fe000000 [ 0.000000] OF: 予約済みメモリ: 0x00000000ff400000..0x00000000ff5fffff (2048 KiB) nomap 再利用不可optee-shm@ff400000 しかし、/proc/$(tee_supplicant_pid)/maps では: 5567a84000-5567a8f000 r-xp 00000000 01:00 402 /usr/sbin/tee-supplicant 5567a8f000-5567a90000 r--p 0000a000 01:00 402 /usr/sbin/tee-supplicant 5567a90000-5567ad1000 rw-p 0000b000 01:00 402 /usr/sbin/tee-supplicant 5567ad1000-5567ad2000 rw-p 00000000 00:00 0 55a4ca6000-55a4cc7000 rw-p 00000000 00:00 0 [ヒープ] 7fbe028000-7fbe02a000 rw-p 00000000 00:00 0 7fbe02a000-7fbe1ad000 r-xp 00000000 01:00 155 /lib/libc.so.6 7fbe1ad000-7fbe1b0000 r--p 00183000 01:00 155 /lib/libc.so.6 7fbe1b0000-7fbe1b2000 rw-p 00186000 01:00 155 /lib/libc.so.6 7fbe1b2000-7fbe1bf000 rw-p 00000000 00:00 0 7fbe1bf000-7fbe1c2000 r-xp 00000000 01:00 184 /lib/libteec.so.2 7fbe1c2000-7fbe1c3000 r--p 00002000 01:00 184 /lib/libteec.so.2 7fbe1c3000-7fbe1c4000 rw-p 00003000 01:00 184 /lib/libteec.so.2 7fbe1c4000-7fbe1c6000 rw-p 00000000 00:00 0 7fbe1c6000-7fbe1c8000 r--p 00000000 00:00 0 [vvar] 7fbe1c8000-7fbe1c9000 r-xp 00000000 00:00 0 [vdso] 7fbe1c9000-7fbe1f0000 r-xp 00000000 01:00 151 /lib/ld-linux-aarch64.so.1 7fbe1f0000-7fbe1f2000 r--p 00026000 01:00 151 /lib/ld-linux-aarch64.so.1 7fbe1f2000-7fbe1f3000 rw-p 00028000 01:00 151 /lib/ld-linux-aarch64.so.1 7fbe1f3000-7fbe1f4000 rw-p 00000000 00:00 0 7fc6441000-7fc6462000 rw-p 00000000 00:00 0 [スタック] 今のところ、なぜこのようなことが起こるのか原因が分かりません。 どなたか何かご存知の方はいらっしゃいますか? よろしくお願いいたします。 ユーザー6 Re: TrustZone on S32G3 こんにちは、 @user6 ご返信ありがとうございます。 どうやらあなたはBSP45のカーネルとBSP46のカーネルが混在した環境で作業しているようですね。BSP46で完全にテストしてみることをお勧めします。 簡単に言うと、Yoctoを使って構築してみると良いでしょう。 BR チェイン Re: TrustZone on S32G3 こんにちは、 @chenyin_h さん。 迅速なご回答ありがとうございます。 私はカスタム基板でテストを行っています。 私のセットアップについて: - LinuxはBSP 45.0-6.6.87-rtに基づいています - このdtsは、OP-TEEの要件に適合するカスタムdtsです。 - RootfsはOP-TEEの要件を満たす古典的なものです この設定で問題になりそうな点はありますか? よろしくお願いいたします。 ユーザー6 Re: TrustZone on S32G3 こんにちは、 @user6 投稿ありがとうございます テスト環境についてもう少し詳しく教えていただけますか? 1. それは、自社開発のボードでテストされたものですか、それともリファレンスボード(例えばRDB3やEVB3)でテストされたものですか? 2. あなたはBSP46で使用されているOPTEEバージョンに取り組んでいると理解していますが、テスト環境もBSP46(Linux、dts、Rootfsなど)に基づいているのでしょうか? BR チェイン Re: TrustZone on S32G3 こんにちは、 @chenyin_h さん。 お返事ありがとうございます。 BSP46 で完全に試してみましたが、bsp46 のベースとなっている optee-os のバージョンが 4.0.0 であるため、optee-client と optee-examples のバージョンも 4.0.0 に変更しました。 しかし、エラーは依然として発生している。S32G3ベースのSoCにTrustZoneを統合した社内事例はありますか? よろしくお願いいたします。 ユーザー6 Re: TrustZone on S32G3 こんにちは、 @user6 ご返信ありがとうございます 1.OPTEE OS/OPTEEアプリケーションのデフォルトのBSP設定を使用した場合、BSP46ではxtestが問題なく正しく実行されることを確認しました。 2. 関係するすべてのパッケージの正しいブランチを使用しているかどうか確信が持てません。BSP46 をベースにテストしたい場合は、まず Yocto で直接ビルドし、次に bitbake fsl-image-auto で作成したイメージでテストすることをお勧めします。 3. 独自の OPTEE パッチ (OS またはアプリケーション) をお持ちの場合は、上記の説明どおりにデフォルト設定が正しく動作することを確認した後、それらをデフォルトの BSP ブランチに移植して独自の機能を実装することをお勧めします。 BR チェイン
View full article
IMXRT1170 ibis models The  i.MX RT1170 | Crossover MCU Family with Arm Cortex-M7 and Cortex-M4 Cores. | NXP Semiconductors page has the following ibis models: IMXRT1170_BGA14X14 IBIS Model IMXRT1170B_BGA14X14 IBIS Model   What's the difference? Which one should be used?
View full article
恩智浦 T2080 专为小端版本 你好, 我使用的是内置大端模式的 电路板支持包 的 T2080 板,但我需要为小端模式构建它。是否有任何现成的 电路板支持包 可用于小端模式,或者有任何文档可用于在 T2080 板 上构建小端 Linux? Re: NXP T2080 Build for Little endian T2080 NXP BSP 仅支持大端模式。 没有测试小端内核的构建及其进一步运行。
View full article
PN7462 HSU UART TX 完全回调未触发 嗨,团队、 我正在使用 PN7462 进行 HSU UART 通信,并实现了如下的 HIF 初始化: void Hif_UartInit(void) { phStatus_t status; gHifConfig.eInterface = E_HIF_HSU; gHifConfig.sConfig.sHsuConfig.bIsHsuBoot = 0; gHifConfig.sConfig.sHsuConfig.bBaudRate = E_HSU_BAUDRATE_9_6K; gHifConfig.sConfig.sHsuConfig.bStopBits = 1; gHifConfig.sConfig.sHsuConfig.bDummyBytes = 0; gHifConfig.sConfig.sHsuConfig.bEOF = 0; gHifConfig.bTimeout = 0; gHifConfig.eBufferType = E_BUFFER_FORMAT_FREE; gHifConfig.bShortFrameLen = 0; gHifConfig.bStoreErrData = 0; gHifConfig.bHeaderSize = 0; status = phhalHif_Init( &gHifConfig, (pphhalHif_Callback_t)Hif_UartErrorCallback ); status = phhalHif_InitRxBuffer( E_RX_BUFFER_ID0, HIF_UART_RX_MAX_FRAME, gHifRxBuffer, (pphhalHif_Callback_t)Hif_UartRxCallback ); gUartStream = xStreamBufferCreate( HIF_UART_STREAM_SIZE, 1 ); } 在我的实施过程中观察到的行为: 正确触发 RX 触发信号回调 成功接收命令 调用 TX 应用程序接口 但是,TX 完成回调不会持续触发 来自 main() 的连续传输未按预期完成 我的简化方案是 int main(void) { phFlashBoot_Main(); phhalTimer_Init(); phOsal_Init(); Hif_UartInit(); while(1) { LOG_TXT("sending....\n"); Hif_Print("hello"); phUser_Wait(10000000); } return 0; } 我还将其与 PN7462 phExDoorAccess 示例进行了比较。 以 DoorAccess 为例: int main(void) { phFlashBoot_Main(); phhalTimer_Init(); phOsal_Init(); phExDoorAccess_SystemTaskInit(); phExDoorAccess_BootHandler(); phRtos_Start(); return 0; } 在 DoorAccess 中观察到的行为: 系统任务初始化 使用 phRtos_Start()启动实时操作系统调度程序 卡检测/验证后,主机接口上的 UART 传输正常工作 成功接收 TX 完成回调 但是,在我从 main () 持续触发传输的实现中,没有观察到 TX 完成回调。 我想了解一下: 除了 phhalHif_Init() 和 phhalHif_InitRxBuffer(),是否还需要额外的 HIF/HSU 配置? HSU TX 回调是否需要明确注册或启用? HSU TX 完成回调是否必须使用 phRtos_Start() / 调度器? HIF 是否需要单独的 API 来在缓冲区初始化后启动 RX/TX 处理? 在 DoorAccess 示例(任务/事件/RTOS 上下文)中,是否存在启用 UART TX 完成处理的依赖关系? 是否存在成功调用传输 API 但未生成 TX 完整回调的已知情况? 如果缺少任何初始化序列或配置,请告诉我。 谢谢。 Re: PN7462 HSU UART TX Complete Callback Not Triggering 你好 感谢您的意见和分享参考资料。我将介绍 PN7462 UART 通信讨论以及 NFC 阅读器库中的 ex_phexhif 演示。 同时,我直接在 phExDoorAccess示例项目中直接进行了一次简单的 UART 周期性传输测试: #include int main(void) { phFlashBoot_Main(); phhalTimer_Init(); phOsal_Init(); /* Initialize HSU */ phExDoorAccess_Utils_HsuHifConfig(); while(1) { LOG_TXT("sending....\n"); phExDoorAccess_Utils_Fill_Tx_Buffer("hello nxp "); phExDoorAccess_Utils_Hsu_Print( gphExDoorAccess_Utils_SysHsuTxBuffer); phUser_Wait(10000000); } return 0; } 使用的传输应用程序接口是 void phExDoorAccess_Utils_Hsu_Print(uint8_t *inBuf) { #ifdef PHFL_ENABLE_HSU phhalHif_Transmit( (uint32_t *)inBuf, (uint16_t)strlen((const char *)inBuf), (pphhalHif_Callback_t) &phExDoorAccess_Utils_HsuHifTransmitCallBack); #endif } 观察: 当 UART 传输从正常的 DoorAccess 流触发时(例如在卡检测/身份验证之后),传输将起作用并接收 TX 回调。 但是,如果直接从 main()启动实时操作系统/任务流之前直接使用上述周期性传输测试时,传输效果并不尽如人意。 能否请您解释一下,为什么在 主程序中的这种周期性 HSU 传输方法不起作用,而常规 DoorAccess 流程中的 UART 传输却正常运行的原因?我想了解 HSU TX 的完成是否取决于 RTOS/任务初始化、额外的 HIF 设置或其他所需的执行环境。 谢谢。 Re: PN7462 HSU UART TX Complete Callback Not Triggering 你好@uday_gowda 希望你一切顺利。 我正在核实您的询问。 在此期间,请您看一下PN7462 UART 通信这篇文章。也许你能在讨论中找到一些有用的提示,请告诉我你的发现。 另外,你有没有参考过 NFC读取器库中针对 PN7462 的 ex_phexhif 演示? Eduardo。 Re: PN7462 HSU UART TX Complete Callback Not Triggering 您好, 我尝试了以下配置,并通过逻辑分析仪看到了输出结果:     gphExDoorAccess_Utils_HsuHifConfig.eInterface = E_HIF_HSU;     gphExDoorAccess_Utils_HsuHifConfig.sConfig.sHsuConfig.bBaudRate = E_HSU_BAUDRATE_9_6K;     gphExDoorAccess_Utils_HsuHifConfig.sConfig.sHsuConfig.bDummyBytes = 0;     gphExDoorAccess_Utils_HsuHifConfig.sConfig.sHsuConfig.bStopBits = 1;     gphExDoorAccess_Utils_HsuHifConfig.sConfig.sHsuConfig.bEOF = 0x8;     gphExDoorAccess_Utils_HsuHifConfig.bTimeout = 0x00;     gphExDoorAccess_Utils_HsuHifConfig.eBufferType = E_BUFFER_FORMAT_FREE;     gphExDoorAccess_Utils_HsuHifConfig.bShortFrameLen = 0;     gphExDoorAccess_Utils_HsuHifConfig.bStoreErrData = 0; Eduardo。
View full article
IMX93 uuu libusb error Hello, I am having issues using uuu to flash an IMX93 (MIMX9352CVVXMAB). I am using Ubuntu 24.04.4 and uuu version: uuu (Universal Update Utility) for nxp imx chips -- lib1.5.141 I can successfully flash the MCU on an IMX93EVK so I am confident that the laptop and software are not the issue. The boot pins on the MCU are set to 0001 and the MCU is detected when powered. dmesg output: [15894.841580] usb 3-2: new high-speed USB device number 44 using xhci_hcd [15894.966279] usb 3-2: New USB device found, idVendor=1fc9, idProduct=014e, bcdDevice= 0.01 [15894.966293] usb 3-2: New USB device strings: Mfr=1, Product=2, SerialNumber=0 [15894.966297] usb 3-2: Product: OO Blank 93 [15894.966300] usb 3-2: Manufacturer: NXP SemiConductor Inc [15894.969654] hid-generic 0003:1FC9:014E.0011: hiddev0,hidraw4: USB HID v1.10 Device [NXP SemiConductor Inc OO Blank 93] on usb-0000:00:14.0-2/input0 uuu -lsusb output: james@laptop:~$ uuu -lsusb uuu (Universal Update Utility) for nxp imx chips -- lib1.5.141 Connected Known USB Devices Path Chip Pro Vid Pid BcdVersion ================================================== 3:2 MX93 SDPS: 0x1FC9 0x014E 0x0001 But when I try and flash the MCU: james@laptop:~$ uuu -v -V -b emmc_all imx-boot-imx93-sd.bin-flash_singleboot image-dev-imx93.rootfs-20260521113620.wic.zst uuu (Universal Update Utility) for nxp imx chips -- lib1.5.141 Build in config: Pctl Chip Vid Pid BcdVersion ================================================== SDPS: MX8QXP 0x1fc9 0x012f [0x0002..0xffff] SDPS: MX8QM 0x1fc9 0x0129 [0x0002..0xffff] SDPS: MX8DXL 0x1fc9 0x0147 SDPS: MX28 0x15a2 0x004f SDPS: MX815 0x1fc9 0x013e SDPS: MX865 0x1fc9 0x0146 SDPS: MX8ULP 0x1fc9 0x014a SDPS: MX8ULP 0x1fc9 0x014b SDPS: MX93 0x1fc9 0x014e SDPS: MX95 0x1fc9 0x015d SDP: MX7D 0x15a2 0x0076 SDP: MX6Q 0x15a2 0x0054 SDP: MX6D 0x15a2 0x0061 SDP: MX6SL 0x15a2 0x0063 SDP: MX6SX 0x15a2 0x0071 SDP: MX6UL 0x15a2 0x007d SDP: MX6ULL 0x15a2 0x0080 SDP: MX6SLL 0x1fc9 0x0128 SDP: MX7ULP 0x1fc9 0x0126 SDP: MXRT106X 0x1fc9 0x0135 SDP: MX8MM 0x1fc9 0x0134 SDP: MX8MQ 0x1fc9 0x012b SDPU: SPL 0x0525 0xb4a4 [0x0000..0x04ff] SDPV: SPL1 0x0525 0xb4a4 [0x0500..0x9998] SDPV: SPL1 0x1fc9 0x0151 [0x0500..0x9998] SDPU: SPL 0x0525 0xb4a4 [0x9999..0x9999] SDPU: SPL 0x3016 0x1001 [0x0000..0x04ff] SDPV: SPL1 0x3016 0x1001 [0x0500..0x9998] FBK: 0x066f 0x9afe FBK: 0x066f 0x9bff FBK: 0x1fc9 0x0153 FB: 0x0525 0xa4a5 FB: 0x18d1 0x0d02 FB: 0x3016 0x0001 FB: 0x1fc9 0x0152 FB: 0x0483 0x0afb Run built-in script: uuu_version 1.4.149 # @_flash.bin | bootloader, which can extract from wic image # @_image [_flash.bin] | wic image burn to emmc. # This command will be run when i.MX6/7 i.MX8MM, i.MX8MQ SDP: boot -f imx-boot-imx93-sd.bin-flash_singleboot -scanlimited 0x800000 # This command will be run when ROM support stream mode # i.MX8QXP, i.MX8QM SDPS: boot -scanterm -f imx-boot-imx93-sd.bin-flash_singleboot -scanlimited 0x800000 # These commands will be run when use SPL and will be skipped if no spl # SDPU will be deprecated. please use SDPV instead of SDPU # { SDPU: delay 1000 SDPU: write -f imx-boot-imx93-sd.bin-flash_singleboot -offset 0x57c00 SDPU: jump -scanlimited 0x800000 # } # These commands will be run when use SPL and will be skipped if no spl # if (SPL support SDPV) # { SDPV: delay 1000 SDPV: write -f imx-boot-imx93-sd.bin-flash_singleboot -skipspl -scanterm -scanlimited 0x800000 SDPV: jump -scanlimited 0x800000 # } FB: ucmd setenv fastboot_dev mmc FB: ucmd setenv mmcdev ${emmc_dev} FB: ucmd mmc dev ${emmc_dev} FB: flash -raw2sparse all image-dev-imx93.rootfs-20260521113620.wic.zst/* FB: flash -scanterm -scanlimited 0x800000 bootloader imx-boot-imx93-sd.bin-flash_singleboot FB: ucmd if env exists emmc_ack; then ; else setenv emmc_ack 0; fi; FB: ucmd mmc partconf ${emmc_dev} ${emmc_ack} 1 0 FB: done Wait for Known USB Device Appear... New USB Device Attached at 3:2 3:2>Start Cmd:SDPS: boot -scanterm -f imx-boot-imx93-sd.bin-flash_singleboot -scanlimited 0x800000 3:2>Fail HID(W):LIBUSB_ERROR_IO(0.114s) This error sometimes also appears as a LIBUSB_ERROR_TIMEOUT. I have read through all the existing threads I can find about libusb errors but none have helped me. Any suggestions or advice are appreciated. Re: IMX93 uuu libusb error Hi @jamesfowkes, Thank you for contacting NXP Support. As I understand, you are using a custom board. Could you please confirm this? Have you ported our software to match the hardware on your board by following our porting guide? Additionally, could you try using the latest version of the UUU tool? Have you completed DDR training and generated the corresponding timing files for your hardware? Best regards, Chavira Re: IMX93 uuu libusb error Hi, Yes we are using a custom board. I have used the latest version of `uuu`, there is no change in behaviour. We can successfully boot images and run from an SD card so the issue is isolated specifically to the USB boot.
View full article
IMX93 uuu libusb 错误 你好 我在使用uuu闪存 IMX93 (MIMX9352CVVXMAB) 时遇到问题。 我使用的是Ubuntu 24.04.4和 uuu 版本: uuu (Universal Update Utility) for nxp imx chips -- lib1.5.141 我可以在 IMX93EVK 上成功闪存 MCU,因此我确信笔记本电脑和软件不是问题所在。 微控制器上的启动引脚设置为 0001,并且在通电时会检测到 MCU。 dmesg输出: [15894.841580] usb 3-2: new high-speed USB device number 44 using xhci_hcd [15894.966279] usb 3-2: New USB device found, idVendor=1fc9, idProduct=014e, bcdDevice= 0.01 [15894.966293] usb 3-2: New USB device strings: Mfr=1, Product=2, SerialNumber=0 [15894.966297] usb 3-2: Product: OO Blank 93 [15894.966300] usb 3-2: Manufacturer: NXP SemiConductor Inc [15894.969654] hid-generic 0003:1FC9:014E.0011: hiddev0,hidraw4: USB HID v1.10 Device [NXP SemiConductor Inc OO Blank 93] on usb-0000:00:14.0-2/input0 uuu -lsusb输出: james@laptop:~$ uuu -lsusb uuu (Universal Update Utility) for nxp imx chips -- lib1.5.141 Connected Known USB Devices Path Chip Pro Vid Pid BcdVersion ================================================== 3:2 MX93 SDPS: 0x1FC9 0x014E 0x0001 但当我尝试闪存 MCU 时: james@laptop:~$ uuu -v -V -b emmc_all imx-boot-imx93-sd.bin-flash_singleboot image-dev-imx93.rootfs-20260521113620.wic.zst uuu (Universal Update Utility) for nxp imx chips -- lib1.5.141 Build in config: Pctl Chip Vid Pid BcdVersion ================================================== SDPS: MX8QXP 0x1fc9 0x012f [0x0002..0xffff] SDPS: MX8QM 0x1fc9 0x0129 [0x0002..0xffff] SDPS: MX8DXL 0x1fc9 0x0147 SDPS: MX28 0x15a2 0x004f SDPS: MX815 0x1fc9 0x013e SDPS: MX865 0x1fc9 0x0146 SDPS: MX8ULP 0x1fc9 0x014a SDPS: MX8ULP 0x1fc9 0x014b SDPS: MX93 0x1fc9 0x014e SDPS: MX95 0x1fc9 0x015d SDP: MX7D 0x15a2 0x0076 SDP: MX6Q 0x15a2 0x0054 SDP: MX6D 0x15a2 0x0061 SDP: MX6SL 0x15a2 0x0063 SDP: MX6SX 0x15a2 0x0071 SDP: MX6UL 0x15a2 0x007d SDP: MX6ULL 0x15a2 0x0080 SDP: MX6SLL 0x1fc9 0x0128 SDP: MX7ULP 0x1fc9 0x0126 SDP: MXRT106X 0x1fc9 0x0135 SDP: MX8MM 0x1fc9 0x0134 SDP: MX8MQ 0x1fc9 0x012b SDPU: SPL 0x0525 0xb4a4 [0x0000..0x04ff] SDPV: SPL1 0x0525 0xb4a4 [0x0500..0x9998] SDPV: SPL1 0x1fc9 0x0151 [0x0500..0x9998] SDPU: SPL 0x0525 0xb4a4 [0x9999..0x9999] SDPU: SPL 0x3016 0x1001 [0x0000..0x04ff] SDPV: SPL1 0x3016 0x1001 [0x0500..0x9998] FBK: 0x066f 0x9afe FBK: 0x066f 0x9bff FBK: 0x1fc9 0x0153 FB: 0x0525 0xa4a5 FB: 0x18d1 0x0d02 FB: 0x3016 0x0001 FB: 0x1fc9 0x0152 FB: 0x0483 0x0afb Run built-in script: uuu_version 1.4.149 # @_flash.bin | bootloader, which can extract from wic image # @_image [_flash.bin] | wic image burn to emmc. # This command will be run when i.MX6/7 i.MX8MM, i.MX8MQ SDP: boot -f imx-boot-imx93-sd.bin-flash_singleboot -scanlimited 0x800000 # This command will be run when ROM support stream mode # i.MX8QXP, i.MX8QM SDPS: boot -scanterm -f imx-boot-imx93-sd.bin-flash_singleboot -scanlimited 0x800000 # These commands will be run when use SPL and will be skipped if no spl # SDPU will be deprecated. please use SDPV instead of SDPU # { SDPU: delay 1000 SDPU: write -f imx-boot-imx93-sd.bin-flash_singleboot -offset 0x57c00 SDPU: jump -scanlimited 0x800000 # } # These commands will be run when use SPL and will be skipped if no spl # if (SPL support SDPV) # { SDPV: delay 1000 SDPV: write -f imx-boot-imx93-sd.bin-flash_singleboot -skipspl -scanterm -scanlimited 0x800000 SDPV: jump -scanlimited 0x800000 # } FB: ucmd setenv fastboot_dev mmc FB: ucmd setenv mmcdev ${emmc_dev} FB: ucmd mmc dev ${emmc_dev} FB: flash -raw2sparse all image-dev-imx93.rootfs-20260521113620.wic.zst/* FB: flash -scanterm -scanlimited 0x800000 bootloader imx-boot-imx93-sd.bin-flash_singleboot FB: ucmd if env exists emmc_ack; then ; else setenv emmc_ack 0; fi; FB: ucmd mmc partconf ${emmc_dev} ${emmc_ack} 1 0 FB: done Wait for Known USB Device Appear... New USB Device Attached at 3:2 3:2>Start Cmd:SDPS: boot -scanterm -f imx-boot-imx93-sd.bin-flash_singleboot -scanlimited 0x800000 3:2>Fail HID(W):LIBUSB_ERROR_IO(0.114s) 该错误有时也会以LIBUSB_ERROR_TIMEOUT 的形式出现。 我阅读了所有能找到的关于 libusb 错误的现有主题,但没有一个能帮到我。 如果您有任何建议或意见,我们将不胜感激。 Re: IMX93 uuu libusb error 嗨,@jamesfowkes、 感谢您联系恩智浦支持中心。 据我了解,你使用的是自定义主板。能否请您确认一下? 您是否按照我们的移植指南移植了我们的软件以匹配主板上的硬件? 此外,您能否尝试使用最新版本的UUU 工具? 您是否完成了 DDR 培训并为硬件生成了相应的时序文件? 致以最崇高的敬意, Chavira Re: IMX93 uuu libusb error 您好, 是的,我们使用的是自定义板。 我已经使用了最新版本的 `uuu`,但行为没有变化。 我们可以成功启动映像并从 SD 卡运行,因此问题仅限于 USB 启动。
View full article