Multi Source Translation Content

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

Multi Source Translation Content

Discussions

Sort by:
i.MX6ULL以太网接口在接头温度高于95℃时断开连接 您好,NXP, 我们使用 i.mx6ull 08AB 版本设计了我们的产品,并发现了一个如下所示的问题。 1>零件编号: MCIMX6Y2CVM08AB 2>问题: 当接头温度高于 95℃ 时,部分板会出现以太网断开连接的问题。 您有什么建议可以帮助我们解决这个问题吗? 非常感谢。 i.MX6UL Re: i.MX6ULL ethernet disconnect when joint temperature is higher than 95℃ 您的客户中有多少家主板存在这个问题?他们测试的是哪个版本的BSP? Re: i.MX6ULL ethernet disconnect when joint temperature is higher than 95℃ 测试1 相同条件:环境温度 65 摄氏度,6 个板处于空闲状态。 第一板:93.82摄氏度 第二块板:91.88摄氏度 板3:96.35摄氏度 第四块板:91.92摄氏度 第五块板:91.81摄氏度 第六块板:93.46摄氏度 测试 2 室温25摄氏度时: 3号板显示温度为65摄氏度,其他板都显示温度在60摄氏度左右。 测试 3 运行一些任务后,板 3 和板 6 失去了以太网连接(ENET1 使用外部 YT8512H PHY,ping 失败)。 当时,板 3 的温度为 99 摄氏度,板 6 的温度为 97.2 摄氏度。 ABA交叉验证 我们将 MCIMX6Y2CVM08AB 从热板 3 换到了另一块载板上。高温随芯片转移到了新的板上。 问题 为什么这款 MCIMX6Y2CVM08AB 在相同条件下读数比其他型号高出约 5°C? 当温度超过 97 摄氏度时,3 号和 6 号板出现以太网 ping 失败的情况,请问对此有什么建议吗?
View full article
i.MX95 NPUのReLU6出力が6を超えてもエラーや警告なしに問題ないのは予想されますか? こんにちは、 私たちは、i.MX95 Neutron NPU上でReLU6がどのように挙動するかを理解しようとしています。 私たちが理解している限りでは、ReLU6は常に0から6の間の出力値を維持するはずです。私たちは気づきました SSD MobileNet V1モデルではCPUに比べてNPUの検出精度が低いため、 中間層の出力をチェックし始めました。ReLU6を使うレイヤーの場合、基板上の値は 6を超え(最大で約25まで)、同じCPUの同じレイヤー(同じモデル、同じ入力)が常に使われていました 予想通り0-6の差を保ちました。 実行時にボード上でこれに関するエラーや警告は一切表示されませんでした。モデル変換中、 Neutron-compilerは量子化に関する一般的な警告をいくつか表示しますが、どれも表示していません この点に関係しているようです。 以下の点について教えていただけますか: 1.このNPUでReLU6の出力が6を超えることは期待できますか? 2. もしそうでなければ、その場合にコンパイラやランタイムがエラーや警告を表示するべきではないでしょうか? 環境: - ボード:i.MX95 EVK - BSP:LF_6.18.20_2.0.0 - eIQ Neutron SDK: 3.2.3 - モデル:SSD MobileNet V1(uint8、Arm ML-Zoo) ご回答をお待ちしています。 Re: Is it expected that a ReLU6 output can exceed 6 on the i.MX95 NPU, with no error or warning? こんにちは、 NXP Semiconductors製品にご関心いただきありがとうございます。 ReLU6はNeutron Supported Operatorsのマークダウンでサポートされているオペレーターとしてリストされていますが、もしそのレイヤーがReLUに変更されていないか確認したいのですが、再現の手順と入手するバイナリを教えていただけますか? eIQ Model Zoo mobilenetv1を試して、Neutronに変換するのも良いでしょう。 よろしくお願いします。 Re: Is it expected that a ReLU6 output can exceed 6 on the i.MX95 NPU, with no error or warning? こんにちは、 迅速なご返信ありがとうございます。 1) ReLUではなくReLU6であることを確認する いいえ、この層はReLUに変更されていません。ニュートロンコンパイラ自身のニュートロンIR(--dump-neutron-ir-final-file) それでもFusedActivation = "Relu6"と表示されており、私たちのファイルの解釈ではありません。参照 正確なモデル、コマンド、出力のためのevidence/01_confirm_still_relu6/。 2) 再現手順と取得したバイナリ 正確なコマンド、コンパイルされたモデル、入力についてはevidence/02_reproduction_npu_exceeds_bound/を参照してください。 スクリプト、コンソールログ、そして生の出力テンソルです。i.MX95 EVKボードについて: 最小値=-15 最大値=96 ReLU6の上限値(生データ):上限値を超える要素数:720000個中4650個(0.65%) CPU 上の同じレイヤーは予想通り 0~6 の範囲内に収まります (実際の最大値=5.999、NPU の実際の最大値=24.664)。 3) eIQ Model Zoo mobilenetv1 を試すについて 試してみました(あなたのrecipe.shにあるmobilenet_v1_0.25_128_quant.tflite)。28人のうち、誰もいない CONV_2D/DEPTHWISE_CONV_2Dオペレーターは実際にはReLU6を融合した作動として使っているので、このモデルには含まれていません 報告している問題を再現(または除外)してください。 参考までに、これらはすべてeIQ Neutron SDK 3.2.3を使用していますコンパイラおよび搭載ランタイム全体で。私たちは 問題はNeutronコンパイラ自体にあると推測されます。ReLU6でこのレイヤーをコンパイルするとプレーンに変更されました ReLUはバイトごとに同一のマイクロコードを生成したため、上限は 生成コード自体が問題ありません。 ご自身で確認していただけますか?他に何か必要なことがあれば教えてください。 ご回答をお待ちしています。 Re: Is it expected that a ReLU6 output can exceed 6 on the i.MX95 NPU, with no error or warning? こんにちは。 専門家からはまだ最新情報が届いておらず、彼らはまだ調査中です。できるだけ早く最新情報をお伝えします。 その間に、この Thread を参照してサポートチケットを作成してもらえますか?https://support.nxp.com/s/?language=en_US よろしくお願いいたします。 Re: Is it expected that a ReLU6 output can exceed 6 on the i.MX95 NPU, with no error or warning? こんにちは。この件に関して何か進展があったかどうか確認したくご連絡いたしました。ありがとう!
View full article
LPCScrypt 无法在 Windows 11 25H2 上运行 [LPCScrypt版本2.1.3_83] 为了启动和刷新旧的 LPC1857,我们使用 lpcsCrypt 来更新设备固件。 自 Windows 11 25H2 起,LPCScrypt 就坏了:在命令行(即 PowerShell)上调用它会导致"错误:来自 CreateProcess 的错误:系统无法找到指定的文件" Sysinternal 的 Process 监测 假设 LpcsCrypt 正在使用 " wmic 路径 win32_pnPentity 执行 wmi 查询,其中(像 '%usbser%' 这样的服务,像 '%lpc%' 这样的名称)get.exe "。 但是,wmic 已于 2016 年宣布弃用,并已于 25H2 起从 Windows 11 中 移除 (请参阅 Windows Management Instrumentation Command-line (WMIC) removal from Windows - Microsoft Support) 。 请求恩智浦开发团队解决:这个问题是否已被发现?如何让它在未来发挥作用? Re: LPCScrypt not running on Windows 11 25H2 你好,ErichStyger,你说得没错。从 Windows 10 升级后,wmic 将保留在 Windows 11 中。 但我不得不重新安装 Windows 11 系统,结果遇到了这个问题。 Re: LPCScrypt not running on Windows 11 25H2 感谢您提供的信息。 我的解决办法是在 Windows 11 中添加 wmic 支持,具体如下 以管理员身份打开系统设置,进入可选功能(... 更多功能...)并添加 wmic 或使用" DISM/Online /Add-Capability /CapabilityName:WMIC" [请参阅将 WMIC 安装到 Windows 11 计算机 - Microsoft Q& A] 。 此致, 马蒂亚斯 Re: LPCScrypt not running on Windows 11 25H2 可能是因为我已经从 Win10 升级到了 Win11,我的机器上仍然有 WMIC: Re: LPCScrypt not running on Windows 11 25H2 我最近从 Win10 升级到了 Win11 25H2。 但到目前为止,我还没有看到 LPCScrypt 出现问题(尚未)。使用 LinkServer v25.9.134 中代码包的那个(见下文) 用 LPCScrypt 更新我的 LPC-Link2 运行正常。 我不是 WMIC 方面的专家,但根据信息,它在 25H2 中消失了,chatGTP 建议将旧版本 Windows 中的 wmic.exe 和 wmic.exe.mui 复制到 25H2。 恩智浦已经意识到了这个问题,下一个LinkServer版本中可能会有更新的LPCsCrypt。 Re: LPCScrypt not running on Windows 11 25H2 你好@mathiasmonse 感谢您的提问。 如果 WMIC 支持被移除,可以尝试安装。或者使用早期的 Windows 版本,或者在 Linux 或 macOS 上运行 LPCScrypt。 BR 爱丽丝 Re: LPCScrypt not running on Windows 11 25H2 这个问题已通过 LPCScrypt 2.1 解决,该版本似乎包含在 LinkServer 的最新版本中。
View full article
S32 Design Studio for Power Architecture 2017.R1 shows “License missing” after license expired Hi NXP Support team, I am using S32 Design Studio for Power Architecture 2017.R1 on Windows. The IDE now shows “License missing”, and it seems the license has expired.
View full article
RT1064 Online Upgrade Plan The following figure is the hardware expansion diagram of our product: 1.The PC and mainboard are connected via TCP 2.The mainboard is connected to four subboards through four SPI buses, and the functions of the subboards are the same 3.The uart4 of the mainboard can be switched to UART1 of 4 sub boards through a serial port swtich chip foreverwlh2025_0-1789970732170.png Due to project requirements, the PC needs to upgrade the firmware program of four sub boards RT1064 through TCP. Based on hardware expansion, can you help provide the simplest solution for upgrading the sub board firmware (considering the workload of upper computer development, mainboard development, and sub board development) i.MXRT 106x Re: RT1064 Online Upgrade Plan Dear @foreverwlh2025 , Thank you for your questions. Recommended Approach The PC communicates with the mainboard over TCP. The mainboard acts as a TCP server and implements a UART transparent bridge. UART4 on the mainboard is routed through a serial switch chip to the UART1 interface of the selected sub-board. The sub-board runs the RT1064 ROM Bootloader, so no additional bootloader or firmware development is required on the sub-board side. Step-by-step upgrade flow for a single sub-board : Assert RESET on sub-board N; set BOOT_MODE[1:0] = 01 (Serial Downloader mode) Switch the serial switch chip to connect UART4 to sub-board N's UART1 Release RESET — sub-board N enters the RT1064 ROM Bootloader and waits for UART commands Enable TCP↔UART4 byte forwarding Toggle RESET and restore BOOT_MODE to normal — sub-board N boots with the new firmware Switch the serial selector to the next sub-board and repeat Hardware Prerequisites Please confirm the following hardware conditions are in place before implementation: Mainboard has independent GPIO control over each sub-board's BOOT_MODE[1:0] pins Mainboard has independent GPIO control over each sub-board's RESET pin The serial switch chip is controllable by mainboard GPIO and supports switching among all 4 sub-boards Please feel free to reach out if you have any questions or would like to discuss implementation details further. Re: RT1064 Online Upgrade Plan 4.Enable TCP↔UART4 byte forwarding -----Excuse me, do we need to develop an additional upper computer for this step of data transmission? For example, what format should the PC transmit image data in, how should it parse the response data returned by the sub board, and how should it interact Re: RT1064 Online Upgrade Plan Dear @foreverwlh2025 , Please find below a summary of our recommended solution for your firmware upgrade scenario. 1. PC Tool  On the PC side, we provides blhost — an open-source command-line client that implements NXP's MCU Bootloader private framing protocol (BSD/MIT license). The device-side protocol is implemented by the MCU on-chip ROM Bootloader. Together, they enable firmware download and device configuration.  The tool supports USB and UART1, doesn't support TCP. Open-source repository: https://github.com/nxp-mcuxpresso/spsdk blhost and the ROM Bootloader communicate using a proprietary framing packet protocol, please refer to: MCU Bootloader v2.5.0 Reference Manual (MCUBOOTRM) For firmware image generation and packaging, please use the nxpimage tool included in NXP's SPSDK (Secure Provisioning SDK). 2. Recommended Solution: TCP Transparent Forwarding via Mainboard For your scenario (PC→ Mainboard → Sub-board), the minimum-effort approach is to have the mainboard act as a transparent TCP-to-UART bridge, with a small modification to blhost to wrap serial data in TCP: Architecture: PC (modified blhost) ↓ TCP packet (include original UART byte stream) Main Board (TCP Server) ↓ Unpack and forward to sub-board via UART Sub-board (ROM Bootloader) Key modification points: Modify blhost transport layer: Add a new TCP transport module in the blhost source code. The existing UART byte stream (Framing Packets) is wrapped into TCP packets as-is on the send path, and unwrapped on the receive path.  Main board implements a TCP Server: Receives TCP data from the PC, forwards the payload byte-for-byte to the sub-board via UART1; sub-board responses are forwarded back to the PC via TCP in the same transparent manner. Sub-board requires no changes: The sub-board MCU simply needs to be in ISP mode with the ROM Bootloader running, waiting for standard UART commands. Re: RT1064 Online Upgrade Plan Here are a few questions: 1. Can't the bin firmware compiled directly from mcuXpressIDE be used? Do I have to use nxpimage? 2. It seems that to complete the upgrade of the sub board, we need to switch the MCU's startup mode and switch channel using our own upper computer software. In other words, we must use our own upper computer and blhost software together. If we upgrade four sub boards, frequent switching can be a bit troublesome 3. The motherboard TCP needs to enter transparent mode first in order for the BLhost to interact with the subboard. After the interaction is complete, how can the motherboard be triggered to switch from transparent mode to TCP receiving mode, so that the subboard can enter normal startup mode 4. Add a new TCP transmission module to the blhost source code - do you have an example 5. Is there any suggestion for implementing serial port transparent transmission on the motherboard, such as using DMA or implementing interrupt and blocking Re: RT1064 Online Upgrade Plan Dear  @ShellyZhang  Can you provide a response to the issue raised last time today? Thank you!! PS:The upgrade plan for this project is brand new and may require a lot of your support Re: RT1064 Online Upgrade Plan Dear @foreverwlh2025 , 1. The BIN file generated directly by MCUXpresso IDE cannot boot.  nxpimage converts the BIN file generated by MCUXpresso IDE into a bootable image. 2. Yes, you need to modify your host PC software yourself. With this approach, the four sub -boards can only be upgraded one at a time. 3. The main-board application needs to handle this. After the firmware upgrade is completed, the main-board should switch back to TCP receive mode by itself, control the sub-board's boot mode to switch to QSPI boot mode, and then reset the sub-board. The sub-board will then boot normally. 4. No, we do not have an example for this. 5. No specific recommendation. After all the TCP data has been received, send it to the sub-board through UART. We recommend using a polling method for the UART transmission. Best Regards, Shelly Re: RT1064 Online Upgrade Plan Dear @foreverwlh2025 , 1. After blhost completes programming the firmware to the board via UART1, the bootloader will return a response after it finishes verification of the programmed image. For your use case, the PC can monitor this response and then command the main board to switch to the TCP received mode. 2. Instead of acting as a transparent forwarding device, the main board can function as a server and implement the MCU Bootloader protocol (host) directly in its firmware. This allows the main board to manage the firmware upgrade process and communication with the sub-boards itself. Best Regards, Shelly Re: RT1064 Online Upgrade Plan Dear @ShellyZhang  After the firmware upgrade is completed, the main-board should switch back to TCP receive mode by itself 1.In transparent transmission mode, the mainboard cannot detect that the sub board upgrade has ended, right? 2.It seems that this solution has some less coding on the device side, but there are many things to do on the host side, and upgrading all of them makes the operation more complicated. Is there any other solution?
View full article
PN7160 燃焼 こんにちは。私は現在、EVKで終わったPN7160キットを使っています。パイに接続する帽子を使い、正しく接続されているか確認しました(私たちの知る限り)。昨日はI2Cで通信しているのを確認し、問題なく動作していましたが、今日ラボに戻って昨夜と同じように接続したところ、PN7160のICから煙が出始めたSO、プラグを抜きました pn7160をつけていないとPiは正常に起動するので、昨日から今日の間に何があったのかはわかりませんが、鍵はロックされていて、私だけが鍵を持っています。 私たちはトヨタとスポンサー付きプロジェクトを行っていて、サポートチームに相談するよう勧められたので、皆さんに何かアイデアや何が起きたのか分かるか聞きたかっただけです
View full article
NXP LPSPI Configuration S32K344 EVB Hi team, I am currently working on LPSPI communication on the S32K344 EVK using NXP RTD 4.0.0. I have completed the required configuration for LPSPI and am trying to develop an SPI loopback communication on the EVK. However, I am currently facing an issue where the data is being transmitted, but I am not receiving the expected data in the RX buffer. I have attached the following for your reference: Project source code Relevant configuration details Could you please go through the attached project and configuration and help me identify the issue? Specifically, I would appreciate your support in checking: LPSPI master/slave configuration LPSPI pin configuration and signal routing TX/RX buffer configuration API usage for LPSPI transmit and receive Any additional configuration required for loopback communication on the S32K344 EVK Please let me know if any additional information or logs are required from my side. Thanks, Raky Re: NXP LPSPI Configuration S32K344 EVB Hi @rakYps21  I reviewed your code and configuration, and I could not find any issues. I also flashed the project onto an FRDM-A-S32K344 board, and as shown in the screenshots below, the RX buffers on both the master and slave sides contain the expected data for both transmissions.  I understand that you are using an S32K3x4EVB board. Could you please let me know which specific EVB variant you are using? Also, if possible, could you share a picture of the MCU on your board? I would like to check the device marking and mask set.  BR, VaneB Re: NXP LPSPI Configuration S32K344 EVB Hi @VaneB, Thank you for your acknowledgment and for testing the setup from your end. I am currently using the FRDM Automotive S32K344MINI-EVB board HDQFP172 MCU. I have also shared an image of the MCU mounted on the board for your reference. Kindly check and confirm. Please let me know if you need any additional information from my side. Regards, Raky Re: NXP LPSPI Configuration S32K344 EVB Hi @rakYps21  Thank you for sharing the image. It looks like we are using a very similar setup. To make sure both setups are aligned, could you please double-check that your SPI signals on your setup are connected as shown below and match the pin assignments specified in the FRDM-A-S32K344 Rev. A schematic? Re: NXP LPSPI Configuration S32K344 EVB Hi @rakYps21  The connections were a little difficult to distinguish in the photo, so I have marked them on the FRDM-A-S32K344 image below using different colors for clarity: brown for CLK, red for PCS, orange for MOSI, and yellow for MISO. I am also attaching the captured signals so you can verify that the SPI communication is working as expected. Re: NXP LPSPI Configuration S32K344 EVB @VaneB  Also, could you please share images of your setup and the physical connections for reference? Looking forward to your response and further guidance on the issue. BR, Raky Re: NXP LPSPI Configuration S32K344 EVB Hi @VaneB , I have double-checked the SPI signal connections and pin assignments on my setup, and they are configured as specified in the FRDM-A-S32K344. Everything matches the configuration you mentioned. Looking forward to your response and further guidance on the issue. Best regards, Raky Re: NXP LPSPI Configuration S32K344 EVB @VaneB Thank you so much for your support. It is working as expected now. Does LPSPI support internal Loopback for this FRDM-A-S32K344 EVB ?
View full article
PN7160燃烧 您好,我目前使用的是型号以 EVK 结尾的 PN7160 开发板,我们使用了连接到树莓派的扩展板,并确保其正确连接(据我们所知)。昨天一切正常,I2C 通信也正常。但今天我们回到实验室并再次连接(与昨晚的连接方式相同)后,PN7160 芯片上的集成电路开始冒烟,所以我们立即拔掉了电源。 即使没有 pn7160,Pi 也能正常启动,所以我不太清楚昨天到今天之间发生了什么,但它被锁起来了,只有我有钥匙。 我们正在和丰田合作做一个赞助项目,他建议我们联系他们的支持团队,所以我们想看看大家有没有什么建议或者知道发生了什么。
View full article
MCALポートモジュールのPortPinModeはEB tresos 30.0で選択できませんでした EB tresos 30.0は29.0とは全く違うと感じます。バージョン29.0ではすべて順調だったが、バージョン30.0では多くの問題が発生した。 ポートモジュールの「PortPin Mode」設定項目については、GPIO以外の選択肢が見当たりませんでした。 例えばUART TXピンの場合、UART TXオプションに変更できませんでした。 その理由は?どうすれば解決できますか? Re: PortPinMode of mcal port module could not be select in EB tresos 30.0 どなたかアドバイスをいただけませんか?
View full article
LPCScrypt not running on Windows 11 25H2 [LPCScrypt version 2.1.3_83] For booting and flashing an old LPC1857 we use LPCScrypt for updating device firmware. Since Windows 11 25H2 LPCScrypt is broken: calling it on the command line (ie PowerShell) leads to "Error: Error from CreateProcess: The system cannot find the file specified" Sysinternal's Process Monitor leads to the assumption that LPCScrypt is performing a wmi query by using "wmic path Win32_PnPEntity where (service like '%usbser%' and name like '%lpc%') get.exe". But wmic is declared deprecated since 2016 and had been removed from Windows 11 since 25H2 (see Windows Management Instrumentation Command-line (WMIC) removal from Windows - Microsoft Support) Request to NXP dev team: Is this issue known yet? How to get it to work in the future? Re: LPCScrypt not running on Windows 11 25H2 Hi ErichStyger, you are right. By upgrading from Windows 10 wmic is kept in Windows 11. But I had to setup a fresh Windows 11 system and came accross that issue. Re: LPCScrypt not running on Windows 11 25H2 Thank you for the information. My workaround was to add wmic support to Windows 11 as follows open system settings as an administrator, go to optional features (...further features...) and add wmic  or by using "DISM /Online /Add-Capability /CapabilityName:WMIC" [see Install WMIC to a Windows 11 computer - Microsoft Q&A] Regards, Mathias Re: LPCScrypt not running on Windows 11 25H2 Probably because I have upgraded from Win10 to Win11, I still have WMIC on my machine: Re: LPCScrypt not running on Windows 11 25H2 I recently upgraded from Win10 to Win11 25H2. But so far, I have not seen an issue with LPCScrypt (yet). Using the one packaged with LinkServer v25.9.134 (see below) Updating my LPC-Link2 with LPCScrypt worked fine. Not an expert on WMIC, but according to the information it is gone in 25H2, chatGTP suggested to copy wmic.exe and wmic.exe.mui from an older Windows version to 25H2. NXP is aware of the issue, and there might be an updated LPCScrypt in a next LinkServer release. Re: LPCScrypt not running on Windows 11 25H2 Hello @mathiasmonse  Thanks for your question. If WMIC support is removed, yes, you can try to install it. Or  use an earlier Windows version or to run LPCScrypt on Linux or macOS. BR Alice Re: LPCScrypt not running on Windows 11 25H2 This has been resolved with LPCScrypt 2.1 which appears to be in the latest release of LinkServer.
View full article
PortPinMode of mcal port module could not be select in EB tresos 30.0 I find EB tresos 30.0 is very different from 29.0. Everything go smoothly in 29.0, but has many problem on 30.0. As for the configuration item "PortPin Mode" of port module, I could not see any option except GPIO. Such as this one for UART TX pin, I could not modify it to UART TX option. What's the reason for this? How to solve it? Re: PortPinMode of mcal port module could not be select in EB tresos 30.0 Could any one give some advice?
View full article
NXP LPSPI構成S32K344 EVB チームの皆さん、こんにちは。 現在、NXP RTD 4.0.0を使用してS32K344 EVK上でLPSPI通信を行う作業に取り組んでいます。 LPSPIに必要な設定は完了しており、EVK上でSPIループバック通信を開発しようとしています。 しかしながら、現在、データは送信されているものの、RXバッファに期待されるデータが受信されないという問題に直面しています。 ご参考までに、以下の資料を添付いたしました。 プロジェクトのソースコード 関連する構成の詳細 添付のプロジェクトと設定を確認し、問題を特定する手助けをしてもらえますか? 具体的には、以下の点でご協力いただけるとありがたいです: LPSPIマスター/スレーブ構成 LPSPIのピン構成と信号ルーティング TX/RXバッファ構成 LPSPIの送受信におけるAPIの使用方法 S32K344 EVKでのループバック通信に必要な追加設定 私の方で追加の情報やログが必要な場合はお知らせください。 ありがとうございます ラキー Re: NXP LPSPI Configuration S32K344 EVB こんにちは、 @rakYps21さん コードと設定を確認しましたが、問題は見つかりませんでした。また、FRDM-A-S32K344ボードにもプロジェクトを書き込んでみたところ、以下のスクリーンショットに示すように、マスター側とスレーブ側の両方のRXバッファには、両方の送信で期待されるデータが格納されていました。 あなたはS32K3x4EVBボードを使用していると理解しています。どのEVBバリアントを使っているのか教えていただけますか? また、可能であれば、ボードにMCUの写真を載せてもらえますか?デバイスのマーキングとマスクセットを確認したいです。 BR、VaneB Re: NXP LPSPI Configuration S32K344 EVB こんにちは、 @VaneB さん。 ご承認いただき、またそちら側で設定テストを実施していただき、ありがとうございます。 現在、 FRDM オートモーティブ S32K344MINI-EVBボードHDQFP172 MCUを使っています。 また、基板に取り付けられたMCUの画像も参考までに共有しました。 ご確認をお願いいたします。 私の方から何か追加情報が必要な場合は、お知らせください。 よろしくお願いいたします。 ラキー Re: NXP LPSPI Configuration S32K344 EVB こんにちは、 @rakYps21さん 画像を共有していただきありがとうございます。 どうやら私たちは非常に似たような設定を使っているようですね。両方のセットアップが揃っているか確認するために、下記のようにあなたのセットアップ上のSPI信号が接続されており、FRDM-A-S32K344改訂A回路図で指定されたピン割り当てと一致している かを再確認 してもらえますか? Re: NXP LPSPI Configuration S32K344 EVB こんにちは、 @VaneB さん。 私のセットアップにおけるSPI信号接続とピン割り当てを二重に確認しましたが、FRDM-A-S32K344の仕様どおりに設定されています。 すべて、あなたが言及した構成と一致しています。 ご回答と今後のご指導をお待ちしております。 よろしくお願いします、 ラキー Re: NXP LPSPI Configuration S32K344 EVB @VaneBまた、参考までにセットアップの画像や物理的な接続の画像を教えていただけますか? ご回答と今後のご指導をお待ちしております。 BR、 ラキー Re: NXP LPSPI Configuration S32K344 EVB こんにちは、 @rakYps21さん 写真では接続が少し判別しにくかったため、下のFRDM-A-S32K344画像に鮮明さのために異なる色でマーキングしました: CLKは茶色、 PCSは赤、 MOSIはオレンジ、 MISOは黄色です。 また、キャプチャした信号も接続して、SPI通信が期待通りに動作しているか確認できるようにしています。 Re: NXP LPSPI Configuration S32K344 EVB @VaneBサポート、本当にありがとうございます。 現在は期待通りに動作しています。 LPSPIはこのFRDM-A-S32K344 EVBの内部ループバックをサポートしていますか?
View full article
当使用 FRDM-MCXN947 的 I3C 接口进行 I2C 通信时,时钟拉伸功能失效。 您好,我目前遇到一个问题:我想使用 FRDM-MCXN947 的 I3C 接口进行 I2C 通信,但我连接的从设备在数据准备期间会出现时钟拉伸,因此我必须等待从设备释放 SCL 信号才能开始数据传输。 我尝试使用 MCXNP184M150F70RM 参考,引用文件中的可配置寄存器(例如 MCONFIG[SKEW] = 0、MCONFIG[HKEEP] = 0b11、MCONFIG[MSTENA] = 0b11),但似乎不起作用。我该如何解决这个问题? #FRDM-MCXN947 #I3C 通信与控制(I3C | I2C | SPI | FlexCAN | 以太网 | FlexIO) MCX N Re: When using the FRDM-MCXN947's I3C interface for I2C communication, the Clk stretching capability 嗨@kevin_Jhuang 寄存器设置目前在 I3C_MasterInit() 之前应用,因此可能会被 SDK 初始化覆盖。 请启用: masterConfig->disableTimeout = true; 然后在 I3C_MasterInit() 之后配置 MSTENA = 3、HKEEP = 3 和 SKEW = 0。请先清除相应的寄存器字段,然后再写入数据,不要使用 |=。 初始化完成后,请读取 MCONFIG 以验证设置是否仍然有效。同时提供时钟拉伸故障后立即捕获的 MSTATUS 和 MERRWARN 值。 请确认 SCL 和 SDA 是否配置为开漏工作状态,以及是否安装了外部上拉电阻。 BR 哈里 Re: When using the FRDM-MCXN947's I3C interface for I2C communication, the Clk stretching capability 嗨,哈里: 非常感谢您的回复。为了测试,我再次尝试设置 MCONFIG。 1.在测试中,disableTimeout 设置为 true。 2. 该图像显示了当前的寄存器设置,包括 MCONFIG、MSTATUS 和 MERRWARN 的值,以及 I2C 总线信号。(配置 A 和配置 B 的区别在于 MSTENA 的设置:配置 A:MCONFIG[MSTENA] = 3,配置 B:MCONFIG[MSTENA] = 1)。 3. 按照示例,应将 SDA/SCL IO 引脚设置为 openDrainEnable = kPORT_OpenDrainDisable,并连接上拉电阻(4.7K)。应该在场。 目前看来,I2C总线扩展功能似乎无法实现。 Re: When using the FRDM-MCXN947's I3C interface for I2C communication, the Clk stretching capability 根据以上回复,配置B图 谢谢
View full article
NCF[5]の推奨リカバリメカニズムを実装する方法 現在、FCCUを構成しており、NXPの障害マップ文書に基づいて、障害NCF[4]に対する推奨回復メカニズム(割り込みサービスルーチンで開始されるSBC開始POR回復に続く割り込み)を実装しようとしています。 私はS32K312マイクロコントローラとFS65 SBCを併用しています。コントローラーからSPIコマンドを使ってFS65 SBCにソフトウェアリセットを行い、すべての電源レールを再初期化することは可能かどうか、教えていただけますか?もし可能なら、正しい実装についてアドバイスをいただけますか? SBC_FS65_FS_SF_OUTPUT_REQUEST_ADDRレジスタのrstbビットを有効にしようと試みましたが、SBCのリセットは確認できませんでした。 この復旧メカニズムを適切に実装する方法を教えてください。 BRサンディープ・シン   Re: How to implement recommended recovery mechanism for NCF[5] こんにちは、ピーター。 上記の回復メカニズムは、S32K3リファレンスマニュアル(Rev 8, 2024年1月)に添付されたNXPの故障マップ文書に記載されています。 さらに、私たちのCASEでは電源がSBC FS65で構成されており、これはMCUの電源供給に使われているため、MCUをリセットするだけではSBCが生成する電源を安定させることはできません。 よろしくお願いします、 サンディープ・シン Re: How to implement recommended recovery mechanism for NCF[5] こんにちは、 その提案には少し戸惑っています。 割り込みサービスルーチンで開始された、SBC 開始の POR リカバリに続く割り込み。 この推奨されている復旧メカニズムは、技術的に妥当とは思えません。 NCF[4]は、MCUコア電源に影響を与える違反を含む電圧モニター故障を表します。コア電圧が有効な動作範囲を超えると、コアの正しい実行、フラッシュアクセス、SRAMアクセス、割り込みサービスルーチン自体を仮定できなくなります。したがって、ISRにSBCとのSPI通信を確立し、回復を開始することに依存することは、信頼できるセーフティ反応を提供しません。 このような障害はハードウェアセーフティパスを通じて処理されるべきです: PMC → FCCU → MC_RGM → リセット これはR3 FCCU反応に対応し、完全にハードウェアベースでソフトウェア実行に依存せずにチップ機能リセットを開始するものです。S32K3セーフティマニュアルには、R3故障に関するまさにこの挙動が説明されています。 完全なISRおよびSPIトランザクションに対して、明示的に有効なMCU実行を保証する未公開の仕組みや早期警告電圧閾値がない限り、提案された割り込みベースの復旧はアーキテクチャ的または機能安全の観点から正当化されません。 NCF[4]を割り込み後にSBC主導のPORで処理し、電圧違反後に有効なソフトウェア実行を保証するアーキテクチャ上の前提を添えて、正確な文書と改訂版を提供していただけますか? この点が明確になるまでは、割り込みによるリカバリの実装はお勧めしません。 よろしくお願いいたします。 ピーター Re: How to implement recommended recovery mechanism for NCF[5] こんにちは、 上記の回復メカニズムは、S32K3リファレンスマニュアル(Rev 8, 2024年1月)に添付されたNXPの故障マップ文書に記載されています。 はい、これはあくまで推奨事項です。セーフティに関わるシステムでは絶対に使いません。 さらに、私たちの場合は電源がSBC FS65で構成されており、これはMCUの電源供給に使われているため、MCUをリセットするだけではSBCが生成する電源を安定させることはできません。 安定はしませんが、リセットすればMCUは安全な状態になります。つまり、破損した可能性のある命令は実行されません。 もし電源に一度だけのイベント情報(例えばシールドの弱さによるインダクタンス)がある場合、SBCは正しい電圧でMCUを供給しますが、MCUの実行は損なわれます。したがって、割り込みからリセットを呼び出すのは私には意味が分かりません。 アップデート: この問題についてセーフティチームに相談していました。 また、過電圧や低電力レールでの低電圧警告にはNCF[4]が呼ばれます。 電圧降下の場合はPOR(電源リセット)が実行されます。 LVD(低電圧検出)→警告→割り込み LVR(低電圧リセット)-> POR HVD -> 通知 -> FCCU NCF4 過電圧/合否判定障害はFCCU NCF4を介して伝播する。 LVDは早期警告通知です。 LVRはFCCUを完全に迂回し、直接PORに向かいます。 よろしくお願いいたします。 ピーター
View full article
i.MX95 NPU 的 ReLU6 输出值超过 6 时,是否会没有错误或警告? 你好, 我们正在尝试了解 ReLU6 在 i.MX95 Neutron NPU 上的表现。 据我们所知,ReLU6 的输出应该始终保持在 0 到 6 之间。我们注意到 对于 SSD MobileNet V1 模型,NPU 的检测精度低于 CPU,因此我们 开始检查中间层输出。对于使用 ReLU6 的层,板上的值 超过了 6(最高可达约 25),而 CPU 上的同一层(相同模型,相同输入)始终 正如预期的那样,分数保持在0-6分之间。 我们在运行时没有在板上看到任何相关的错误或警告。在模型转换过程中, neutron-compiler 确实会显示一些关于量化的通用警告,但没有一个警告是错误的。 似乎与这一点有关。 您能帮我们理解一下吗? 1.在这个NPU上,ReLU6的输出值是否可以超过6? 2. 如果不是,编译器或运行时在这种情况下难道不应该显示错误或警告吗? 环境: - 板:i.MX95 EVK - 电路板支持包。:LF_6.18.20_2.0.0 - eIQ Neutron SDK:3.2.3 - 型号:SSD MobileNet V1(uint8,Arm ML-Zoo) 谢谢! Re: Is it expected that a ReLU6 output can exceed 6 on the i.MX95 NPU, with no error or warning? 您好, 感谢您对恩智浦半导体产品的关注, Neutron Supported Operators markdown 中列出了 ReLU6 作为支持的运算符,我想确认一下该层是否已更改为 ReLU,能否请您分享一下重现步骤以及您得到的二进制文件? 您可以尝试使用eIQ Model Zoo mobilenetv1并将其转换为 Neutron。 此致 Re: Is it expected that a ReLU6 output can exceed 6 on the i.MX95 NPU, with no error or warning? 您好, 感谢您的快速回复。 1)确认仍然是 ReLU6,而不是 ReLU 不,这一层没有改成 ReLU。neutron-compiler 自带的 NeutronIR(--dump-neutron-ir-final-file) 它仍然显示 FusedActivation = "Relu6" - 这不是我们对文件的解释。看 请参阅 evidence/01_confirm_still_relu6/ 获取确切的模型、命令和输出。 2) 重现步骤以及我们得到的二进制文件 有关确切的命令、编译后的模型、输入,请参阅 evidence/02_reproduction_npu_exceeds_bound/。 脚本、控制台日志和原始输出张量。在 i.MX95 EVK 板上: 最小值=-15 最大值=96 ReLU6 上限(原始数据):超出上限 12 个元素:720000 个元素中有 4650 个(0.65%) CPU 上的同一层保持在 0-6 的范围内,符合预期(实际最大值=5.999,而 NPU 的实际最大值=24.664)。 3) 回复:尝试 eIQ Model Zoo mobilenetv1 我们试过了(mobilenet_v1_0.25_128_quant.tflite,来自您的 配方.sh)。它的28个中没有一个 CONV_2D/DEPTHWISE_CONV_2D 算子实际上融合了 ReLU6 作为激活函数,因此该模型不 重现(或排除)我们报告的问题。 作为参考,所有这些操作均使用 eIQ Neutron SDK 3.2.3。贯穿始终(编译器和板载运行时)。我们 怀疑问题出在 neutron-compiler 本身:用 ReLU6 编译这一层时,已将其更改为普通层。 ReLU 生成的微代码与实际生成的微代码完全相同的字节,因此上限似乎并未被纳入考虑范围。 完全没有生成代码。 请您确认一下,如果还有其他需要我们提供的信息,请与我们联系。 谢谢! Re: Is it expected that a ReLU6 output can exceed 6 on the i.MX95 NPU, with no error or warning? 嗨@YoshihiroFurudera , 目前尚未收到专家方面的最新消息,他们仍在调查此事。我会尽快分享最新消息。 在此期间,能否请您创建一个支持工单,并在工单中引用此帖子?https://support.nxp.com/s/?language=en_US 此致, Re: Is it expected that a ReLU6 output can exceed 6 on the i.MX95 NPU, with no error or warning? 您好,我来跟进一下这个问题是否有任何进展。谢谢!
View full article
i. MX6ULLのイーサネット切断は、接合温度が95°Cを超えると切断されます こんにちは、NXPさん、        弊社はi.mx6ull 08ABバージョンで製品を設計しましたが、以下の問題が見つかりました。 1>部品番号: MCIMX6Y2CVM08AB        2>質問: 接合温度が95°Cを超えると、一部の基板でイーサネット切断の問題が発生します。 この問題を解決するためのヒントはありますか? どうもありがとうございました。 i.MX6UL Re: i.MX6ULL ethernet disconnect when joint temperature is higher than 95℃ お客様は何台のボードでこの問題を感じていますか?彼らはどのBSPバージョンをテストしたのですか? Re: i.MX6ULL ethernet disconnect when joint temperature is higher than 95℃ テスト1 同じ条件:周囲温度65℃、ボード6枚がアイドル状態。 ボード1:93.82℃ ボード2:91.88℃ ボード3:96.35℃ ボード4:91.92 C ボード5:91.81 C ボード6:93.46℃ テスト2 室温25℃の場合: ボード3は65℃を示しており、その他はすべて60℃前後である。 テスト3 いくつかのタスクを実行した後、ボード3とボード6がイーサネット接続を失いました(ENET1は外部YT8512H PHYでping失敗)。 その時、3番ボードの温度は99℃、6番ボードの温度は97.2℃だった。 ABAクロスバリデーション ホットボード3からMCIMX6Y2CVM08ABを別のキャリアボードに交換しました。高温はチップから新しい基板に伝わりました。 質問 なぜこの特定のMCIMX6Y2CVM08ABは、同じ条件下で他のものよりも約5℃高い温度を示すのでしょうか? 温度が97°Cを超えるときに基板3と6で観察されるイーサネットpingの故障について何かアドバイスはありますか?
View full article
MCXN947 DLL 自动调整功能无法正常工作 你好, 我正在使用 FlexSPI 连接 MCXN947,并搭配 OctalRAM (IS66WVO32M8DALL-200BLI)。 FlexSPI 根时钟通过 PLL1 以 150 MHz 的频率提供,由于 RAM 以 DDR 模式运行,因此我的输出时钟频率为 75 MHz。 `flexspi_device_config_t` 具有以下参数: flexspi_device_config_t psram_config = { .flexspiRootClk = 150000000U, .isSck2Enabled = false, .flashSize = OCTALRAM_ISSI_SIZE, .CSIntervalUnit = kFLEXSPI_CsIntervalUnit1SckCycle, .CSInterval = 2, .CSHoldTime = 2, .CSSetupTime = 2, .dataValidTime = 2, .columnspace = 4, .enableWordAddress = false, .AWRSeqIndex = HYPERRAM_CMD_LUT_SEQ_IDX_WRITEDATA, .AWRSeqNumber = 1, .ARDSeqIndex = HYPERRAM_CMD_LUT_SEQ_IDX_READDATA, .ARDSeqNumber = 1, .AHBWriteWaitUnit = kFLEXSPI_AhbWriteWaitUnit2AhbCycle, .AHBWriteWaitInterval = 0, .enableWriteMask = true, }; 为了初始化 FlexSpi,我使用了 SDK FLEXSPI_DRIVER,版本 2.6.0。 当我使用自动调整功能(如手册第 10.3.15.6 节“采样 DLL 配置”中所述)配置延迟单元时,使用以下值: • SLVDLYTARGET=0x0F(分频器 16/32 * 根时钟 = 3.33 ns) • REFPHASEGAP=0x02 • DLLEN=0x01 • OVRDEN=0x01 在等待 ASLVLOCK 和 AREFLOCK 锁定位之后,我得到 ASLVSEL 为 0x01,AREFSEL 为 0x00。因此,RAM 的读取和写入功能无法工作,因为设置的延迟时间约为 120 ps! /* Configure DLL. */ configValue = FLEXSPI_CalculateDll(base, config); base->DLLCR[index] = configValue; /* DLL neu kalibrieren */ base->DLLCR[0] |= FLEXSPI_DLLCR_DLLRESET_MASK; base->DLLCR[0] &= ~FLEXSPI_DLLCR_DLLRESET_MASK; /* Exit stop mode. */ base->MCR0 &= ~FLEXSPI_MCR0_MDIS_MASK; /* Lock abwarten */ while ((base->STS2 & (FLEXSPI_STS2_AREFLOCK_MASK | FLEXSPI_STS2_ASLVLOCK_MASK)) != (FLEXSPI_STS2_AREFLOCK_MASK | FLEXSPI_STS2_ASLVLOCK_MASK)) { } SDK_DelayAtLeastUs(10U, CLOCK_GetCoreSysClkFreq()); 即使我使用不同的 SLVDLYTARGET 值,ASLVLOCK 和 AREFLOCK 的输出也不会改变。 但是,如果我使用寄存器 OVRDEN=0x01 和 OVRDVAL=0x1b 将延迟时间设置为固定值(对应于大约 3.36 ns 的延迟时间),则从 RAM 读取和写入数据都不会出现任何问题。 但是,由于根时钟大于 100 MHz,NXP 建议使用 DLL 的自动调整功能。 很遗憾,它似乎无法确定正确的延迟时间! 通信与控制(I3C | I2C | SPI | FlexCAN | 以太网 | FlexIO) 核心与内存 MCX N Re: MCXN947 DLL auto-adjusted function not working 嗨@IbhDaniel 谢谢你的帖子! MCXNx4 参考手册指出,串行根时钟是 FlexSPI 内核时钟(见表 79)。时钟使用情况)。就你的情况而言,这个时钟配置为 150 MHz。 我还看到您已经实现了 DLL 采样配置,自动校准路径似乎是正确的方法。设置 SLVDLYTARGET = 0x0F 和 DLLEN = 0x01 配置正确。唯一发现的问题是 OVRDEN = 0x01 而不是 0x00,这会禁用自动校准输出路径,并导致 ASLVSEL = 0x01 和 AREFSEL = 0x00,而不管 SLVDLYTARGET 值如何。 我只想确认以上分析是否适用于您的实现。请您确认一下,您的配置中是否使用了以下设置:MCR0[RXCLKSRC] = 3h(闪存提供的读取选通信号和来自 DQS 焊盘的输入)? Re: MCXN947 DLL auto-adjusted function not working 嗨,卡洛斯, 谢谢你的回复。 抱歉,这是我的笔误,我把 OVRDEN 位设置为 0 了。在 MCU 寄存器的截图中,您也可以看到 OVRDEN 的值被设置为 0。 我正在使用 OctalRam IS66WVO32M8DALL-200BLI,如果我理解正确的话,这个模块会将 DQS 信号发送到 MCU。 Re: MCXN947 DLL auto-adjusted function not working 嗨@IbhDaniel , 请您确认一下,您的配置中是否使用了 MCR0[RXCLKSRC] = 3h(从 DQS 焊盘读取闪存提供的选通输入)? 这一点很重要,因为只有当 DQS 信号来自外部 DQS 垫时,才支持自动调整/校准。如果选择了不同的 RXCLKSRC 设置,则自动延迟调整机制将无法按预期运行。 Re: MCXN947 DLL auto-adjusted function not working 我再次检查了一下,MCU 中的 MCR0[RXCLKSRC] 位设置为 3h。 Re: MCXN947 DLL auto-adjusted function not working 嗨@IbhDaniel 感谢您的确认,我会和内部团队一起审核。这可能需要一些时间。感谢您的耐心等待。 在此期间,请使用您找到的手动校准变通方法。 由此造成的不便,我们深表歉意。 Re: MCXN947 DLL auto-adjusted function not working 嗨@IbhDaniel , 请问您能否分享一下您的 flexspi_config_t 文件? 这样做是为了重现你遇到的情况。 另外,尝试在 UpdateDllValue 之后和 FLEXSPI_SetFlashConfig() 之后添加 SDK_DelayAtLeastUs 为 10us。 BR Re: MCXN947 DLL auto-adjusted function not working 嗨,卡洛斯, 以下是我在 `flexspi_config_t` 结构中使用的参数信息: flexspi_config_t config; /* Get FLEXSPI default settings and configure the flexspi. */ FLEXSPI_GetDefaultConfig(&config); config.rxSampleClock = kFLEXSPI_ReadSampleClkExternalInputFromDqsPad; /*Set AHB buffer size for reading data through AHB bus. */ config.ahbConfig.enableAHBPrefetch = true; config.ahbConfig.enableAHBBufferable = true; config.ahbConfig.enableAHBCachable = true; config.ahbConfig.enableReadAddressOpt = true; for (uint8_t i = 1; i < FSL_FEATURE_FLEXSPI_AHB_BUFFER_COUNT - 1; i++) { config.ahbConfig.buffer[i].bufferSize = 0; } config.ahbConfig.buffer[0].masterIndex = 4; /* DMA0 */ config.ahbConfig.buffer[0].bufferSize = 512; /* Allocate 512B bytes for DMA0 */ config.ahbConfig.buffer[0].enablePrefetch = true; config.ahbConfig.buffer[0].priority = 0; /* All other masters use last buffer with 512B bytes. */ config.ahbConfig.buffer[FSL_FEATURE_FLEXSPI_AHB_BUFFER_COUNT - 1].bufferSize = 512; #if !(defined(FSL_FEATURE_FLEXSPI_HAS_NO_MCR0_COMBINATIONEN) && FSL_FEATURE_FLEXSPI_HAS_NO_MCR0_COMBINATIONEN) config.enableCombination = true; #endif FLEXSPI_Init(BUNNY_FLEXSPI, &config); 以下是“SDK_DelayAtLeastUs”和“FLEXSPI_SetFlashConfig”函数的代码: SDK_DelayAtLeastUs(10U, CLOCK_GetCoreSysClkFreq()); /*! * @brief Delay at least for some time. * Please note that, if not uses DWT, this API will use while loop for delay, different run-time environments have * effect on the delay time. If precise delay is needed, please enable DWT delay. The two parmeters delayTime_us and * coreClock_Hz have limitation. For example, in the platform with 1GHz coreClock_Hz, the delayTime_us only supports * up to 4294967 in current code. If long time delay is needed, please implement a new delay function. * * @Param delayTime_us Delay time in unit of microsecond. * @Param coreClock_Hz Core clock frequency with Hz. */ void SDK_DelayAtLeastUs(uint32_t delayTime_us, uint32_t coreClock_Hz) { uint64_t count; if (delayTime_us > 0U) { count = USEC_TO_COUNT(delayTime_us, coreClock_Hz); assert(count <= UINT32_MAX); #if defined(SDK_DELAY_USE_DWT) && defined(DWT) /* Use DWT for better accuracy */ MSDK_EnableCpuCycleCounter(); /* Calculate the count ticks. */ count += MSDK_GetCpuCycleCount(); if (count > UINT32_MAX) { count -= UINT32_MAX; /* Wait for cyccnt overflow. */ while (count < MSDK_GetCpuCycleCount()) { } } /* Wait for cyccnt reach count value. */ while (count > MSDK_GetCpuCycleCount()) { } #else /* Divide value may be different in various environment to ensure delay is precise. * Every loop count includes three instructions, due to Cortex-M7 sometimes executes * two instructions in one period, through test here set divide 1.5. Other M cores use * divide 4. By the way, divide 1.5 or 4 could let the count lose precision, but it does * not matter because other instructions outside while loop is enough to fill the time. */ #if (__CORTEX_M == 7) count = count / 3U * 2U; #else count = count / 4U; #endif DelayLoop((uint32_t)count); #endif /* defined(SDK_DELAY_USE_DWT) && defined(DWT) */ } } /*! * brief Configures the connected device parameter. * * This function configures the connected device relevant parameters, such as the size, command, and so on. * The flash configuration value cannot have a default value. The user needs to configure it according to the * connected device. * * param base FLEXSPI peripheral base address. * param config Flash configuration parameters. * param port FLEXSPI Operation port. */ void FLEXSPI_SetFlashConfig(FLEXSPI_Type *base, flexspi_device_config_t *config, flexspi_port_t port) { uint32_t configValue = 0; uint8_t index = (uint8_t)port >> 1U; /* PortA with index 0, PortB with index 1. */ /* Wait for bus to be idle before changing flash configuration. */ while (!FLEXSPI_GetBusIdleStatus(base)) { } /* Configure flash size and address shift. */ #if defined(FSL_FEATURE_FLEXSPI_SUPPORT_ADDRESS_SHIFT) && (FSL_FEATURE_FLEXSPI_SUPPORT_ADDRESS_SHIFT) base->FLSHCR0[port] = config->flashSize | FLEXSPI_FLSHCR0_ADDRSHIFT(config->addressShift); #else base->FLSHCR0[port] = config->flashSize; #endif /* FSL_FEATURE_FLEXSPI_SUPPORT_ADDRESS_SHIFT */ /* Configure flash parameters. */ base->FLSHCR1[port] = FLEXSPI_FLSHCR1_CSINTERVAL(config->CSInterval) | FLEXSPI_FLSHCR1_CSINTERVALUNIT(config->CSIntervalUnit) | FLEXSPI_FLSHCR1_TCSH(config->CSHoldTime) | FLEXSPI_FLSHCR1_TCSS(config->CSSetupTime) | FLEXSPI_FLSHCR1_CAS(config->columnspace) | FLEXSPI_FLSHCR1_WA(config->enableWordAddress); /* Configure AHB operation items. */ configValue = base->FLSHCR2[port]; configValue &= ~(FLEXSPI_FLSHCR2_AWRWAITUNIT_MASK | FLEXSPI_FLSHCR2_AWRWAIT_MASK | FLEXSPI_FLSHCR2_AWRSEQNUM_MASK | FLEXSPI_FLSHCR2_AWRSEQID_MASK | FLEXSPI_FLSHCR2_ARDSEQNUM_MASK | FLEXSPI_FLSHCR2_ARDSEQID_MASK); configValue |= FLEXSPI_FLSHCR2_AWRWAITUNIT(config->AHBWriteWaitUnit) | FLEXSPI_FLSHCR2_AWRWAIT(config->AHBWriteWaitInterval); if (config->AWRSeqNumber > 0U) { configValue |= FLEXSPI_FLSHCR2_AWRSEQID((uint32_t)config->AWRSeqIndex) | FLEXSPI_FLSHCR2_AWRSEQNUM((uint32_t)config->AWRSeqNumber - 1U); } if (config->ARDSeqNumber > 0U) { configValue |= FLEXSPI_FLSHCR2_ARDSEQID((uint32_t)config->ARDSeqIndex) | FLEXSPI_FLSHCR2_ARDSEQNUM((uint32_t)config->ARDSeqNumber - 1U); } base->FLSHCR2[port] = configValue; /* Configure DLL. */ FLEXSPI_UpdateDllValue(base, config, port); /* Step into stop mode. */ base->MCR0 |= FLEXSPI_MCR0_MDIS_MASK; /* Configure write mask. */ if (config->enableWriteMask) { base->FLSHCR4 &= ~FLEXSPI_FLSHCR4_WMOPT1_MASK; } else { base->FLSHCR4 |= FLEXSPI_FLSHCR4_WMOPT1_MASK; } if (index == 0U) /*PortA*/ { base->FLSHCR4 &= ~FLEXSPI_FLSHCR4_WMENA_MASK; base->FLSHCR4 |= FLEXSPI_FLSHCR4_WMENA(config->enableWriteMask); } #if !((defined(FSL_FEATURE_FLEXSPI_HAS_NO_FLSHCR4_WMENB)) && (FSL_FEATURE_FLEXSPI_HAS_NO_FLSHCR4_WMENB)) else { base->FLSHCR4 &= ~FLEXSPI_FLSHCR4_WMENB_MASK; base->FLSHCR4 |= FLEXSPI_FLSHCR4_WMENB(config->enableWriteMask); } #endif /* Exit stop mode. */ base->MCR0 &= ~FLEXSPI_MCR0_MDIS_MASK; /* Wait for bus to be idle before use it access to external flash. */ while (!FLEXSPI_GetBusIdleStatus(base)) { } } 非常感谢您的大力支持! 顺祝商祺! 丹尼尔
View full article
MCXN947 DLLの自動調整機能が動作しません こんにちは、 私はFlexSPI経由でMCXN947とOctalRAM(IS66WVO32M8DALL-200BLI)を使用しています。 FlexSPIのルートクロックはPLL1を介して150MHzで供給され、RAMはDDRモードで動作するため、出力クロックレートは75MHzになります。 `flexspi_device_config_t`には以下のパラメータがあります。 flexspi_device_config_t psram_config = { .flexspiRootClk = 150000000U, .isSck2Enabled = false, .flashSize = OCTALRAM_ISSI_SIZE, .CSIntervalUnit = kFLEXSPI_CsIntervalUnit1SckCycle, .CSInterval = 2, .CSHoldTime = 2, .CSSetupTime = 2, .dataValidTime = 2, .columnspace = 4, .enableWordAddress = false, .AWRSeqIndex = HYPERRAM_CMD_LUT_SEQ_IDX_WRITEDATA, .AWRSeqNumber = 1, .ARDSeqIndex = HYPERRAM_CMD_LUT_SEQ_IDX_READDATA, .ARDSeqNumber = 1, .AHBWriteWaitUnit = kFLEXSPI_AhbWriteWaitUnit2AhbCycle, .AHBWriteWaitInterval = 0, .enableWriteMask = true, }; FlexSpiの初期化には、SDK FLEXSPI_DRIVERバージョン2.6.0を使用しています。 自動調整機能(マニュアル10.3.15.6節「サンプリングのためのDLL構成」)でディレイセルを以下の値で設定すると、 • SLVDLYTARGET=0x0F(分算器16/32 * root_clock = 3.33 ns) • REFPHASEGAP=0x02 • DLLEN=0x01 • OVRDEN=0x01 ASLVLOCKとAREFLOCKのロックビットを待った後、ASLVSELには0x01、AREFSELには0x00が返されました。その結果、設定された遅延時間が約120psであるため、RAMの読み書き機能は動作しません。 /* Configure DLL. */ configValue = FLEXSPI_CalculateDll(base, config); base->DLLCR[index] = configValue; /* DLL neu kalibrieren */ base->DLLCR[0] |= FLEXSPI_DLLCR_DLLRESET_MASK; base->DLLCR[0] &= ~FLEXSPI_DLLCR_DLLRESET_MASK; /* Exit stop mode. */ base->MCR0 &= ~FLEXSPI_MCR0_MDIS_MASK; /* Lock abwarten */ while ((base->STS2 & (FLEXSPI_STS2_AREFLOCK_MASK | FLEXSPI_STS2_ASLVLOCK_MASK)) != (FLEXSPI_STS2_AREFLOCK_MASK | FLEXSPI_STS2_ASLVLOCK_MASK)) { } SDK_DelayAtLeastUs(10U, CLOCK_GetCoreSysClkFreq()); SLVDLYTARGETに異なる値を使用しても、ASLVLOCKとAREFLOCKの出力は変わりません。 しかし、レジスタOVRDEN=0x01とOVRDVAL=0x1bを使用して遅延時間を固定値(約3.36ナノ秒の遅延時間に相当)に設定すると、RAMからの読み書きは問題なく動作します。 しかし、ルートクロックが100 MHzを超えるため、NXPはDLLの自動調整機能の使用を推奨しています。 残念ながら、正しい遅延時間を判断できないようです! 通信・制御(I3C |I2C |SPI |FlexCAN |イーサネット |FlexIO) コアとメモリ MCX N Re: MCXN947 DLL auto-adjusted function not working こんにちは、 @IbhDanielさん 投稿ありがとうございます! MCXNx4リファレンスマニュアルによると、シリアルルートクロックはFlexSPIコアクロックであることが示されています(表79参照)。時計の使用状況)。あなたの場合、このクロックは150 MHzに設定されています。 また、DLLサンプリング構成を実装しており、自動キャリブレーションパスが正しいアプローチのようです。設定値SLVDLYTARGET = 0x0FおよびDLLEN = 0x01は正しく構成されています。唯一特定された問題は、OVRDENが0x00ではなく0x01であり、これにより自動キャリブレーション出力経路が無効化され、SLVDLYTARGET値に関係なくASLVSEL=0x01、AREFSEL=0x00となります。 上記の分析結果が貴社の実装にも当てはまるかどうか確認させてください。以下を確認してください:MCR0[RXCLKSRC] = 3h(フラッシュメモリ提供の読み取りストロボとDQSパッドからの入力)があなたの構成で使用されているか? Re: MCXN947 DLL auto-adjusted function not working こんにちは、カルロスさん。 ご返信ありがとうございます。 すみません、誤字で、OVRDENビットを0に設定しました。MCUレジスタのスクリーンショットを見ると、OVRDENが値0に設定されているのもわかります。 私はOctalRam IS66WVO32M8DALL-200BLIを使っています。もし理解が正しければ、このモジュールはDQS信号をMCUに送っているようです。 Re: MCXN947 DLL auto-adjusted function not working 再度確認したところ、MCUのMCR0[RXCLKSRC]ビットは3時間に設定されています。 Re: MCXN947 DLL auto-adjusted function not working こんにちは、 @IbhDaniel さん。 あなたの構成でMCR0[RXCLKSRC] = 3h(DQSパッドからのフラッシュメモリ提供の読み取りストロボ入力)が使われているか確認していただけますか? この点は重要です。なぜなら、自動調整・キャリブレーションはDQS信号が外部DQSパッドから送信される場合にのみサポートされるからです。RXCLKSRCの設定が異なると、自動遅延調整機構は期待どおりに動作しません。 Re: MCXN947 DLL auto-adjusted function not working こんにちは、 @IbhDanielさん 確認ありがとうございます。社内チームと検討いたします。これには時間がかかる場合があります。ご理解とご協力に感謝いたします。 それまでの間は、手動キャリブレーションで見つけた回避策をご利用ください。 ご迷惑をおかけして申し訳ございません。 Re: MCXN947 DLL auto-adjusted function not working こんにちは@IbhDaniel。 flexspi_config_tを教えていただけますか? これは、あなたが直面している現象を再現するためのものです。 また、UpdateDllValue と FLEXSPI_SetFlashConfig() の後に SDK_DelayAtLeastUs を 10us 追加してみてください。 BR Re: MCXN947 DLL auto-adjusted function not working こんにちは、カルロスさん。 `flexspi_config_t`構造体で使用するパラメータに関する情報は以下のとおりです。 flexspi_config_t config; /* Get FLEXSPI default settings and configure the flexspi. */ FLEXSPI_GetDefaultConfig(&config); config.rxSampleClock = kFLEXSPI_ReadSampleClkExternalInputFromDqsPad; /*Set AHB buffer size for reading data through AHB bus. */ config.ahbConfig.enableAHBPrefetch = true; config.ahbConfig.enableAHBBufferable = true; config.ahbConfig.enableAHBCachable = true; config.ahbConfig.enableReadAddressOpt = true; for (uint8_t i = 1; i < FSL_FEATURE_FLEXSPI_AHB_BUFFER_COUNT - 1; i++) { config.ahbConfig.buffer[i].bufferSize = 0; } config.ahbConfig.buffer[0].masterIndex = 4; /* DMA0 */ config.ahbConfig.buffer[0].bufferSize = 512; /* Allocate 512B bytes for DMA0 */ config.ahbConfig.buffer[0].enablePrefetch = true; config.ahbConfig.buffer[0].priority = 0; /* All other masters use last buffer with 512B bytes. */ config.ahbConfig.buffer[FSL_FEATURE_FLEXSPI_AHB_BUFFER_COUNT - 1].bufferSize = 512; #if !(defined(FSL_FEATURE_FLEXSPI_HAS_NO_MCR0_COMBINATIONEN) && FSL_FEATURE_FLEXSPI_HAS_NO_MCR0_COMBINATIONEN) config.enableCombination = true; #endif FLEXSPI_Init(BUNNY_FLEXSPI, &config); 以下は、「SDK_DelayAtLeastUs」関数と「FLEXSPI_SetFlashConfig」関数のコードです。 SDK_DelayAtLeastUs(10U, CLOCK_GetCoreSysClkFreq()); /*! * @brief Delay at least for some time. * Please note that, if not uses DWT, this API will use while loop for delay, different run-time environments have * effect on the delay time. If precise delay is needed, please enable DWT delay. The two parmeters delayTime_us and * coreClock_Hz have limitation. For example, in the platform with 1GHz coreClock_Hz, the delayTime_us only supports * up to 4294967 in current code. If long time delay is needed, please implement a new delay function. * * @Param delayTime_us Delay time in unit of microsecond. * @Param coreClock_Hz Core clock frequency with Hz. */ void SDK_DelayAtLeastUs(uint32_t delayTime_us, uint32_t coreClock_Hz) { uint64_t count; if (delayTime_us > 0U) { count = USEC_TO_COUNT(delayTime_us, coreClock_Hz); assert(count <= UINT32_MAX); #if defined(SDK_DELAY_USE_DWT) && defined(DWT) /* Use DWT for better accuracy */ MSDK_EnableCpuCycleCounter(); /* Calculate the count ticks. */ count += MSDK_GetCpuCycleCount(); if (count > UINT32_MAX) { count -= UINT32_MAX; /* Wait for cyccnt overflow. */ while (count < MSDK_GetCpuCycleCount()) { } } /* Wait for cyccnt reach count value. */ while (count > MSDK_GetCpuCycleCount()) { } #else /* Divide value may be different in various environment to ensure delay is precise. * Every loop count includes three instructions, due to Cortex-M7 sometimes executes * two instructions in one period, through test here set divide 1.5. Other M cores use * divide 4. By the way, divide 1.5 or 4 could let the count lose precision, but it does * not matter because other instructions outside while loop is enough to fill the time. */ #if (__CORTEX_M == 7) count = count / 3U * 2U; #else count = count / 4U; #endif DelayLoop((uint32_t)count); #endif /* defined(SDK_DELAY_USE_DWT) && defined(DWT) */ } } /*! * brief Configures the connected device parameter. * * This function configures the connected device relevant parameters, such as the size, command, and so on. * The flash configuration value cannot have a default value. The user needs to configure it according to the * connected device. * * param base FLEXSPI peripheral base address. * param config Flash configuration parameters. * param port FLEXSPI Operation port. */ void FLEXSPI_SetFlashConfig(FLEXSPI_Type *base, flexspi_device_config_t *config, flexspi_port_t port) { uint32_t configValue = 0; uint8_t index = (uint8_t)port >> 1U; /* PortA with index 0, PortB with index 1. */ /* Wait for bus to be idle before changing flash configuration. */ while (!FLEXSPI_GetBusIdleStatus(base)) { } /* Configure flash size and address shift. */ #if defined(FSL_FEATURE_FLEXSPI_SUPPORT_ADDRESS_SHIFT) && (FSL_FEATURE_FLEXSPI_SUPPORT_ADDRESS_SHIFT) base->FLSHCR0[port] = config->flashSize | FLEXSPI_FLSHCR0_ADDRSHIFT(config->addressShift); #else base->FLSHCR0[port] = config->flashSize; #endif /* FSL_FEATURE_FLEXSPI_SUPPORT_ADDRESS_SHIFT */ /* Configure flash parameters. */ base->FLSHCR1[port] = FLEXSPI_FLSHCR1_CSINTERVAL(config->CSInterval) | FLEXSPI_FLSHCR1_CSINTERVALUNIT(config->CSIntervalUnit) | FLEXSPI_FLSHCR1_TCSH(config->CSHoldTime) | FLEXSPI_FLSHCR1_TCSS(config->CSSetupTime) | FLEXSPI_FLSHCR1_CAS(config->columnspace) | FLEXSPI_FLSHCR1_WA(config->enableWordAddress); /* Configure AHB operation items. */ configValue = base->FLSHCR2[port]; configValue &= ~(FLEXSPI_FLSHCR2_AWRWAITUNIT_MASK | FLEXSPI_FLSHCR2_AWRWAIT_MASK | FLEXSPI_FLSHCR2_AWRSEQNUM_MASK | FLEXSPI_FLSHCR2_AWRSEQID_MASK | FLEXSPI_FLSHCR2_ARDSEQNUM_MASK | FLEXSPI_FLSHCR2_ARDSEQID_MASK); configValue |= FLEXSPI_FLSHCR2_AWRWAITUNIT(config->AHBWriteWaitUnit) | FLEXSPI_FLSHCR2_AWRWAIT(config->AHBWriteWaitInterval); if (config->AWRSeqNumber > 0U) { configValue |= FLEXSPI_FLSHCR2_AWRSEQID((uint32_t)config->AWRSeqIndex) | FLEXSPI_FLSHCR2_AWRSEQNUM((uint32_t)config->AWRSeqNumber - 1U); } if (config->ARDSeqNumber > 0U) { configValue |= FLEXSPI_FLSHCR2_ARDSEQID((uint32_t)config->ARDSeqIndex) | FLEXSPI_FLSHCR2_ARDSEQNUM((uint32_t)config->ARDSeqNumber - 1U); } base->FLSHCR2[port] = configValue; /* Configure DLL. */ FLEXSPI_UpdateDllValue(base, config, port); /* Step into stop mode. */ base->MCR0 |= FLEXSPI_MCR0_MDIS_MASK; /* Configure write mask. */ if (config->enableWriteMask) { base->FLSHCR4 &= ~FLEXSPI_FLSHCR4_WMOPT1_MASK; } else { base->FLSHCR4 |= FLEXSPI_FLSHCR4_WMOPT1_MASK; } if (index == 0U) /*PortA*/ { base->FLSHCR4 &= ~FLEXSPI_FLSHCR4_WMENA_MASK; base->FLSHCR4 |= FLEXSPI_FLSHCR4_WMENA(config->enableWriteMask); } #if !((defined(FSL_FEATURE_FLEXSPI_HAS_NO_FLSHCR4_WMENB)) && (FSL_FEATURE_FLEXSPI_HAS_NO_FLSHCR4_WMENB)) else { base->FLSHCR4 &= ~FLEXSPI_FLSHCR4_WMENB_MASK; base->FLSHCR4 |= FLEXSPI_FLSHCR4_WMENB(config->enableWriteMask); } #endif /* Exit stop mode. */ base->MCR0 &= ~FLEXSPI_MCR0_MDIS_MASK; /* Wait for bus to be idle before use it access to external flash. */ while (!FLEXSPI_GetBusIdleStatus(base)) { } } サポートいただき、本当にありがとうございます! よろしくお願いいたします。 ダニエル
View full article
How to implement recommended recovery mechanism for NCF[5] I am currently configuring the FCCU and attempting to implement the recommended recovery mechanism for fault NCF[4] based on the NXP fault map document (Interrupt followed by SBC-initiated POR recovery initiated in the interrupt service routine). I am using the S32K312 microcontroller alongside the FS65 SBC. Could you please clarify if it is possible to issue a software reset to the FS65 SBC via SPI command from the controller to re-initialize all power rails? If so, could you advise on the correct implementation? I attempted to enable the rstb bit in the SBC_FS65_FS_SF_OUTPUT_REQUEST_ADDR register, but I did not observe an SBC reset. Please let me know how to properly implement this recovery mechanism. BR Sandeep Singh   Re: How to implement recommended recovery mechanism for NCF[5] Hi Peter, The recovery mechanism mentioned above is documented in NXP's Fault Map document, which is attached to the S32K3 Reference Manual (Rev 8, 01/2024). Additionally, since the power supplies are built up by the SBC FS65 in our case which are used to power up MCU, resetting the MCU alone will not stabilize the power supplies generated by the SBC. Best regards, Sandeep Singh Re: How to implement recommended recovery mechanism for NCF[5] Hello, I am bit confused by the recommendation. Interrupt followed by SBC-initiated POR recovery initiated in the interrupt service routine" This recommended recovery mechanism does not appear technically valid to me. NCF[4] represents voltage-monitor faults, including violations affecting the MCU core supply. Once the core voltage is outside its valid operating range, correct execution of the core, flash accesses, SRAM accesses, and the interrupt service routine itself can no longer be assumed. Therefore, relying on an ISR to establish SPI communication with the SBC and initiate recovery does not provide a trustworthy safety reaction. Such faults should be handled through the hardware safety path: PMC → FCCU → MC_RGM → reset This corresponds to an R3 FCCU reaction, which is entirely hardware-based and initiates a chip functional reset without relying on software execution. The S32K3 Safety Manual describes exactly this behavior for R3 faults. Unless there is an undocumented mechanism or a guaranteed early-warning voltage threshold that explicitly ensures valid MCU execution for the complete ISR and SPI transaction, the proposed interrupt-based recovery is not justified from an architectural or functional-safety perspective. Could you please provide the exact document and revision that requires NCF[4] to be handled by an interrupt followed by an SBC-initiated POR, together with the architectural assumption guaranteeing valid software execution after the voltage violation? Until this is clarified, I would not recommend implementing the recovery through an interrupt. Best regards, Peter Re: How to implement recommended recovery mechanism for NCF[5] Hello, The recovery mechanism mentioned above is documented in NXP's Fault Map document, which is attached to the S32K3 Reference Manual (Rev 8, 01/2024). Ok, it is just recommendation. I will in no cases use that in safety critical systems. Additionally, since the power supplies are built up by the SBC FS65 in our case which are used to power up MCU, resetting the MCU alone will not stabilize the power supplies generated by the SBC. It will not stabilize, but reseting will put MCU in the safe state. So no potentially corrupted instruction are executed. If you have one time event in power supply (like inductance due to weak shielding) then SBC will still supply MCU with correct voltage, but the MCU execution is compromised. Therefore calling reset from interrupt makes no sense to me. Update: Ok, I was consulting this issue with safety team. And the NCF[4] is called in case of overvoltage, or low voltalge warning on low power rail. In case of voltage drop the POR (power on reset) is executed. LVD (Low Voltage Detect)-> warning -> interrupt LVR (Low Voltage Reset)-> POR HVD -> notification -> FCCU NCF4 Overvoltage / Go-Nogo faults propagate via FCCU NCF4. LVD is an early-warning notification. LVR bypasses FCCU entirely and goes directly to POR. Best regards, Peter
View full article
i.MX6ULL ethernet disconnect when joint temperature is higher than 95℃ Hi NXP,        We has designed our production with i.mx6ull 08AB version, and found a question shown below.        1>Part No.: MCIMX6Y2CVM08AB        2>Question:             When the joint temperature is higher than 95℃, some boards will occur the ethernet disconnection issue.         Do you have some tips for us to fix this problem ?         Thanks very much. i.MX6UL Re: i.MX6ULL ethernet disconnect when joint temperature is higher than 95℃ how many boards do your customer find this issue? any what bsp version did they test?  Re: i.MX6ULL ethernet disconnect when joint temperature is higher than 95℃ Test 1 Same condition: 65C ambient, 6 boards idle. Board 1: 93.82 C Board 2: 91.88 C Board 3: 96.35 C Board 4: 91.92 C Board 5: 91.81 C Board 6: 93.46 C Test 2 At 25C room temperature: Board 3 shows 65C, all others around 60C. Test 3 After running some tasks, Board 3 and Board 6 lost Ethernet connectivity (ENET1 with external YT8512H PHY, ping failed). At that moment, Board 3 temperature was 99C, Board 6 was 97.2C. ABA cross-validation We swapped the MCIMX6Y2CVM08AB from the hot Board 3 onto another carrier board. The high temperature followed the chip to the new board. Questions Why does this specific MCIMX6Y2CVM08AB read about 5C higher than others under identical conditions? Any suggestion for the Ethernet ping failure observed on Boards 3 and 6 when temperature rises above 97C?
View full article