Multi Source Translation Content

取消
显示结果 
显示  仅  | 搜索替代 
您的意思是: 

Multi Source Translation Content

讨论

排序依据:
カスタムモデルをS32K3xx MBDT 1.5.0から1.8.0へ移行中ハードウェア設定エラー NXPサポートチームの皆さん、こんにちは。 既存のSimulinkモデルをModel-Based Design Toolbox for S32K3xxバージョン1.5.0からバージョン1.8.0へ移行する際のご協力をお願いしています。 当社のモデルはカスタムIOCツールボックスを組み込み、以前はMBDT 1.5.0で動作していました。MATLAB/Simulink R2024bを使用して1.8.0にアップグレードした後、エンジニアはモデルのハードウェア設定を開く際にエラーに直面しました。 再現手順は以下のとおりです。 1. S32K3xxバージョン1.8.0用のMBDTをインストールする。 2. 既存のデモモデル、IOC_DemoPrj.slxを開きます。 3. ハードウェア→ハードウェア設定を選択します。 設定パラメータダイアログが開かず、次のエラーが表示されます。 出力引数「out」(およびその他の引数)に値が割り当てられていません 「mbd_s32k3.nxp.target.get_target_memory_entries」を使用した実行において 関数。 このダイアログには、getTargetHardwareDetailWidgets.p への参照も含まれています。メッセージ全文については、添付のスクリーンショットをご覧ください。 私たちはCASE #09014041でMathWorksのテクニカルサポートに連絡しました。彼らはMBDTアドオンがNXPが開発しているため、NXPに相談するよう勧めました。根本原因はまだ確認されていません。 以下の点についてご協力いただけますか? 1. 移行手順:MBDT 1.5.0から1.8.0へのモデル移行にはどのような手順が適用されていますか?移行ガイドや変換ユーティリティが利用可能で、直接アップグレードは可能ですか? 2. エラー診断:このget_target_memory_entriesエラーは既知の問題ですか?適用可能なパッチや回避策はありますか? 3. 既存構成:モデルのハードウェア、ターゲットメモリ、またはペリフェラルの設定は変換または再生が必要ですか?もしそうなら、ハードウェア設定が開けない場合、どのように実行すればよいでしょうか? 4. カスタムIOCツールボックス:これらのバージョン間で、カスタムブロックの更新、モデルコールバック、ビルド統合が必要な変更点は?関連するインターフェースと推奨変更点をご確認ください。 5. 診断情報:移行、インストール/パス、カスタムツールボックス統合の問題かを判断するために、どのようなモデルファイル、設定ファイル、ログ、インストールの詳細が必要ですか? 私たちの目標は、既存のIOC機能を維持しつつ、MBDT 1.8.0でモデルを成功裏に設定・構築・実行するために必要な変更を行うことです。 ありがとう。
查看全文
更正 i.MX8DXL EVK (J20) 上 TAMPER_OUT0/TAMPER_IN4 活动防篡改循环的 snvs_cfg 值 您好, 我正在通过 U-Boot 验证 i.MX8DXL EVK (MCIMX8DXL-WEVK) 上的外部主动篡改循环。 根据电路板原理图,我已经确认 J20(防篡改接头,1x3)的接线方式如下: - 引脚 1 = TAMPER_IN4(网络 SNVS.TAMPER_IN4,焊球 AJ13) - 引脚 2 = 接地 - 引脚 3 = TAMPER_OUT0(网络 SNVS.TAMPER_OUT0,引脚 AP22) 这些是专用的 SNVS 引脚,不像 TAMPER_OUT1-4/IN0-3 那样与 SAI2/SAI3 共享。 可用的 U-Boot 命令:tamper_pin_cfg、snvs_cfg(及其子寄存器 hp.lock、hp.secvio_intcfg、hp.secvio_ctl、lp.lock、lp.secvio_ctl、lp.tamper_filt_cfg、lp.tamper_det_cfg、lp.tamper_det_cfg2、lp.tamper_filt1_cfg、lp.tamper_filt2_cfg、lp.act_tamper1_cfg 至 lp.act_tamper5_cfg、lp.act_tamper_ctl、lp.act_tamper_clk_ctl、lp.act_tamper_routing_ctl1、lp.act_tamper_routing_ctl2)、snvs_sec_status、snvs_clear_status。 由于 TAMPER_OUT0/TAMPER_IN4 构成一个有效的防篡改对,我的问题是: 1. lp.act_tamperN_cfg 通道(1-5)中,哪个对应于 TAMPER_OUT0? 2. 要检查 lp.act_tamper_routing_ctl1/routing_ctl2 路由 TAMPER_OUT0 的模式与 TAMPER_IN4 的匹配度,需要检查哪些值? 3. 要使该通道启用模式时钟,lp.act_tamper_clk_ctl 的值是多少? 4. lp.act_tamper_ctl 的全局值是多少才能启用此通道的主动篡改检测? 目标:将跳线连接到 J20 引脚 1-3 时,snvs_sec_status 应显示为安全状态;断开跳线时,应触发违规。 i.MX8DXL 是否有针对外部主动防篡改验证的参考测试程序或应用说明? 谢谢您!
查看全文
about imx6q ddr stresstest I am running a DDR stress test on the i.mX6Q and need to know which Excel file to use. I have obtained `MX6Q_SabreSD_DDR3_register_programming_aid_v2.5.xlsx`; does this appear to be the correct file? I am currently using Samsung K4B4G16 256M×16 chips (4 chips totaling 2GB), but the test fails to complete, returning the error "No chip select is enabled." How can I resolve this issue? Thanks. Re: about imx6q ddr stresstest Hi @GavinChen  This RPA table is right for i.MX6Q. please share your RPA able. B.R
查看全文
RT685 DSPイメージは、MacOS上で新たに組み込まれたZephyr sysbuildの代わりにキャッシュバイナリを使用しています プラットフォーム:MacOS 15.6.1 (24G90) VS Code(バージョン:1.112.0)(ユニバーサル) MCUXpresso for VS Code: 26.8.29 Zephyr toolchain: zephyr-sdk-1.0.1, zsdk nxp-v4.4.1.1 用途: amp_blinkyをZephyr-freestandingとしてインポート 基板: MIMXRT685-EVK 説明: 私はMacOSで開発環境を設定していますが、同じ手順はLinuxマシンでも問題なく動作していました。ビルドとフラッシュは MCUXpressoで重大な警告やエラーを出さなかったが、ARMコアとDSPコアの両方でアプリケーションは正常に動作していた。その後、remote/srcとremote/prj.confのコードを編集し、クリーンビルド後にフラッシュしました。しかし、DSPコアは編集前に前の画像を実行していました。 以下に、興味深い行動例をいくつか示します。 Armコアコードの編集も試みましたが、その変更は成功裏に適用されました。 DSPコアコードの変更は「作業なし」と表示される代わりに、非純粋なビルドを引き起こすことがあります。 cmakeでCCACHEを無効にすると問題が解決するようです。 今のところ、コンパイラがsysbuildを実行する際にDSPイメージの変更を無視し、キャッシュされたバイナリを使っているというCAHCE関連の問題のように思えます。これは再構築されているにもかかわらずです。おそらくnxp_zephyr/zephyr/samples/boards/nxp/adsp/rtxxx/common/src/dspimgsが原因です。Sは更新されていません。また、Linuxマシンでは気づかなかったので、MacOSだけの問題かもしれません。 これは既知の問題ですか?CCACHEを無効にする以外の、より洗練された解決策はありますか? よろしくお願いいたします。 ユエ ゼファー・オス・エッジ  i.MX RT600 Re: RT685 DSP image uses cached binary instead of newly built in Zephyr sysbuild on MacOS こんにちは、シェリーさん。 ご返信ありがとうございます! build/remote/zephyの3つのDSP BINのタイムスタンプ、最終的なArm BIN、そしてdspimgsを確認しました。build/amp_blinky/CMakeFiles/app.dir/.../adsp/rtxxx/common/src/の項目S.obj、すべて純正または非純正のビルドで更新されていました。 また、推奨されている CMake 設定を置き換えて試してみました。 set_source_files_properties ( " ${CMAKE_CURRENT_LIST_DIR} /src/dspimgs.S" オブジェクトに依存する ${HIFI4_BUILD_DIR}/zephyr.elf )   with   設定(HIFI4_BIN_DEPS) 「${HIFI4_BUILD_DIR}/zephyr.elf」 「${HIFI4_BUILD_DIR}/zephyr.reset.bin」 「${HIFI4_BUILD_DIR}/zephyr.text.bin」 「${HIFI4_BUILD_DIR}/zephyr.data.bin」 ) set_source_files_properties ( " ${CMAKE_CURRENT_LIST_DIR} /src/dspimgs.S" プロパティ オブジェクトに依存する " ${HIFI4_BIN_DEPS} " ) dsp-load.cmakeでは、そして変更を検証しました `ninja -C build/amp_blinky -t query build/.../dspimgs.S.obj`   しかし残念ながら、この問題は依然として解決していません。次に、以下のように別のテストを行いました。 remote/src/main.c に` printk ( " TESTCCACHE " );` を追加する ビルド `strings build/.../dspimgs.S.obj | grep TESTCCACHE` を実行します。 呼び出し:'strings build/remote/zephyr/zephyr.text.bin build/remote/zephyr/zephyr.data.bin |grep TESTCCACHE' ステップ3では何も返されなかったが、ステップ4では文字列が見つかった。次に、CCACHEを無効にして再度テストを実行したところ、どちらのテストでもTESTCCACHEが検出されました。CCACHEが有効になっている場合、dspimgs.S.objのタイムスタンプは正しいバイナリをロードせずに更新されたようです。 この件について、ご意見をいただければ幸いです。 よろしくお願いいたします。 ユエ Re: RT685 DSP image uses cached binary instead of newly built in Zephyr sysbuild on MacOS @YueZ様、 ご質問ありがとうございます。 今のところ、私たちの側ではこの問題が既知のものではありません。 根本原因を特定するために、以下の出力が一貫して更新されているか確認していただけますか? リモートビルドプロセスによって生成されるDSP BINです。 dspimgs.S から生成されたオブジェクトファイル。 実際にデバイスにプログラムされている最後のArm BINです。 DSP BINは更新されているが、オブジェクトファイルはdspimgsから生成されていない場合Sは更新していないため、ビルドシステムがDSP BINのタイムスタンプを更新しなかった可能性があります。その結果、依存関係チェックでdspimgs.Sの再コンパイルがスキップされた可能性があります。 DSPIMGsを担当する CMake 構成に以下のコンテンツを追加することをお勧めします。DSP BINの変更が再構築を引き起こすようにするために: セット(DSP_BIN_DIR ${CMAKE_BINARY_DIR}/../リモート/ゼファー) set_properte(ソース ${CMAKE_CURRENT_SOURCE_DIR} /src/dspimgs.S プロパティ オブジェクト_依存 ${DSP_BIN_DIR} /zephyr_reset.bin ${DSP_BIN_DIR} /zephyr_text.bin ${DSP_BIN_DIR} /zephyr_data.bin ) (実際のファイルパスが正しいかどうかも確認してください。) ご質問がありましたら、お気軽にお問い合わせください。   よろしくお願いいたします。 シェリー Re: RT685 DSP image uses cached binary instead of newly built in Zephyr sysbuild on MacOS こんにちは、シェリーさん。 はい、 CCACHE_RECACHE=1は機能します。 ちなみに、CMakeListsでUSE_CCACHEを0に設定してCCACHEを無効にしています。CCACHE_DISABLEについては、動作させるにはwest workspace端末で明示的に設定しなければならず、MCUXpresso for VS Codeを使うにはあまり理想的ではありません。CCACHE_RECACHEも同じで、CMakeListsに追加しても使えません。 よろしくお願いいたします。 ユエ Re: RT685 DSP image uses cached binary instead of newly built in Zephyr sysbuild on MacOS @YueZ様、 CCACHE_RECACHE=1を試してみていただけますか?   ccache を完全にバイパスし、キャッシュエントリの読み書きを行わずに完全な再構築を実行する CCACHE_DISABLE とは異なり、CCACHE_RECACHE=1 はすべての出力の再生成を強制し、新しく構築された結果でキャッシュを更新します。 CCACHE_RECACHE=1 にすることで問題が解消される場合、根本原因はおそらく古いキャッシュの内容にあると考えられます。問題が解決しない場合は、特定のキャッシュされたエントリではなく、ccache自体に問題がある可能性が高いと考えられます。 よろしくお願いいたします。 シェリー  
查看全文
1080p RTSP IPカメラ用のNXP i.MX プロセッサの推奨 こんにちは、皆さん 1080p RTSP IPカメラストリームを処理できる、最も安価なNXP i.MX プロセッサーを誰か教えてもらえますか? 私の要望は以下の通りです。 1つのRTSP IPカメラ入力 2 1080p解像度 3 約25~30 FPS 4 この問題を安定して扱える、最も低コストで i.MX プロセッサ/ボードを探しています 主な目的は、可能な限り低いハードウェアコストで1080pのRTSPカメラストリームを受信し、処理/表示することです。 もし同じようなケースで低コストの i.MX プロセッサを試したことがある方がいれば、ぜひおすすめや体験を共有してください。 よろしくお願いします! Re: Recommendation for NXP i.MX Processor for 1080p RTSP IP Camera こんにちは、 IPカメラを使った純粋な受信・表示アプリケーションとしては、i.MX8MMを検討してください。なぜなら、1080p60デコード対応の専用ハードウェアVPUが含まれているからです。 よろしくお願いいたします。
查看全文
MCXN947 DLL auto-adjusted function not working Hello, I'm using the MCXN947 via FlexSPI with an OctalRAM (IS66WVO32M8DALL-200BLI). The FlexSPI root clock is supplied at 150 MHz via PLL1, and since the RAM operates in DDR mode, I have an output clock rate of 75 MHz. The `flexspi_device_config_t` has the following parameters: 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, }; To initialize FlexSpi, I use the SDK FLEXSPI_DRIVER, version 2.6.0. When I configure the delay cells using the auto-adjusted function (as described in the manual under section 10.3.15.6, “DLL configuration for sampling”) with the following values: • SLVDLYTARGET=0x0F (divider 16/32 * root_clock = 3.33 ns) • REFPHASEGAP=0x02 • DLLEN=0x01 • OVRDEN=0x01 After waiting for the ASLVLOCK and AREFLOCK lock bits, I get 0x01 for ASLVSEL and 0x00 for AREFSEL. Consequently, the RAM's read and write functions do not work, since the set delay time is approximately 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()); Even if I use different values for SLVDLYTARGET, the output of ASLVLOCK and AREFLOCK does not change. However, if I set the delay time to a fixed value using the registers OVRDEN=0x01 and OVRDVAL=0x1b (corresponding to a delay time of approximately 3.36 ns), reading from and writing to RAM works without any problems. However, since the root clock is greater than 100 MHz, NXP recommends using the DLL's auto-adjustment feature. Unfortunately, it doesn't seem to be able to determine the correct delay time! Communication & Control(I3C | I2C | SPI | FlexCAN | Ethernet | FlexIO) Core and Memory MCXN Re: MCXN947 DLL auto-adjusted function not working Hi @IbhDaniel  Thank you for the post! The MCXNx4 Reference Manual indicates that the serial root clock is the FlexSPI core clock (see Table 79. Clock Usage). In your case, this clock is configured to 150 MHz. I also see that you have implemented the DLL sampling configuration, and the auto-calibration path appears to be the correct approach. The settings SLVDLYTARGET = 0x0F and DLLEN = 0x01 were configured correctly. The only issue identified was OVRDEN = 0x01 instead of 0x00, which disables the auto-calibration output path and causes ASLVSEL = 0x01 and AREFSEL = 0x00 regardless of the SLVDLYTARGET value. I would just like to confirm that the above analysis applies to your implementation. Could you please verify that: MCR0[RXCLKSRC] = 3h (Flash-memory-provided read strobe and input from DQS pad) is being used in your configuration? Re: MCXN947 DLL auto-adjusted function not working Hi Carlos, Thanks for your reply. Sorry, that was a typo on my part, I set the OVRDEN bit to 0. In the screenshot of the MCU register, you can also see that OVRDEN was set to value 0. I’m using the OctalRam IS66WVO32M8DALL-200BLI, if I understand correctly, this module sends the DQS signal to the MCU.
查看全文
关于 imx6q DDR 压力测试 我正在对 i.mX6Q 进行 DDR 压力测试,需要知道应该使用哪个 Excel 文件。 我已获取到 `MX6Q_SabreSD_DDR3_register_programming_aid_v2.5.xlsx` 文件;请问这是否是正确的文件? 我目前使用的是三星 K4B4G16 256M×16 芯片(4 颗芯片共 2GB),但测试未能完成,并返回错误“未启用芯片选择”。 我该如何解决这个问题? 谢谢。 Re: about imx6q ddr stresstest 嗨@GavinChen 此 RPA 表适用于 i.MX6Q。 请分享您的RPA能力。 B.R
查看全文
Migrating custom model from S32K3xx MBDT 1.5.0 to 1.8.0, Hardware Settings error Hi NXP Support Team, We need your assistance migrating an existing Simulink model from Model-Based Design Toolbox for S32K3xx version 1.5.0 to version 1.8.0. Our model incorporates our custom IOC toolbox and previously worked with MBDT 1.5.0. After upgrading to 1.8.0 while using MATLAB/Simulink R2024b, our engineer encounters an error when opening the model’s Hardware Settings. The steps to reproduce are: 1. Install MBDT for S32K3xx version 1.8.0. 2. Open our existing demo model, IOC_DemoPrj.slx. 3. Select HARDWARE → Hardware Settings. The Configuration Parameters dialog fails to open and displays this error: Output argument "out" (and possibly others) not assigned a value in the execution with "mbd_s32k3.nxp.target.get_target_memory_entries" function. The dialog also references getTargetHardwareDetailWidgets.p. Please see the attached screenshot for the full message. We contacted MathWorks Technical Support under case #09014041. They advised us to consult NXP because the MBDT add-on is developed by NXP; the root cause has not yet been confirmed. Could you please help us with the following? 1. Migration procedure: What is the supported process for migrating a model from MBDT 1.5.0 to 1.8.0? Is a migration guide or conversion utility available, and can we upgrade directly? 2. Error diagnosis: Is this get_target_memory_entries error a known issue? Are there any applicable patches or workarounds? 3. Existing configuration: Does the model’s hardware, target memory, or peripheral configuration need conversion or regeneration? If so, how should we perform this when Hardware Settings cannot open? 4. Custom IOC toolbox: Which changes between these versions could require updates to our custom blocks, model callbacks, or build integration? Please identify the relevant interfaces and recommended changes. 5. Diagnostic information: What model files, configuration files, logs, and installation details would you need to determine whether this is a migration, installation/path, or custom toolbox integration issue? Our goal is to retain the existing IOC functionality and make the changes necessary to configure, build, and run the model successfully with MBDT 1.8.0. Thanks.
查看全文
i.MX8DXL EVK (J20) の TAMPER_OUT0/TAMPER_IN4 アクティブタンパーループ用の正しい snvs_cfg 値 こんにちは、 U-Boot を介して、i.MX8DXL EVK (MCIMX8DXL-WEVK) 上の外部アクティブタンパーループを検証しています。 基板の回路図から、J20(TAMPERヘッダー、1x3)の配線が以下のようになっていることを確認しました。 - ピン 1 = TAMPER_IN4 (ネット SNVS.TAMPER_IN4、ボール AJ13) - ピン2 = GND - ピン3 = TAMPER_OUT0 (ネットSNVS.TAMPER_OUT0、ボールAP22) これらは専用のSNVSピンであり、TAMPER_OUT1-4/IN0-3のようにSAI2/SAI3と共有されていません。 使用可能な U-Boot コマンド: tamper_pin_cfg、snvs_cfg (サブレジスタ hp.lock、hp.secvio_intcfg、hp.secvio_ctl、lp.lock、lp.secvio_ctl、lp.tamper_filt_cfg、lp.tamper_det_cfg、lp.tamper_det_cfg2、lp.tamper_filt1_cfg、lp.tamper_filt2_cfg、lp.act_tamper1_cfg ~ lp.act_tamper5_cfg、lp.act_tamper_ctl、lp.act_tamper_clk_ctl、lp.act_tamper_routing_ctl1、lp.act_tamper_routing_ctl2 を含む)、snvs_sec_status、snvs_clear_status。 TAMPER_OUT0/TAMPER_IN4はアクティブなタンパーペアを形成するため、私の質問は次のとおりです。 1. どのlp.act_tamperN_cfgチャネル(1-5)がTAMPER_OUT0に対応しているか? 2. lp.act_tamper_routing_ctl1/routing_ctl2ルートTAMPER_OUT0のパターンの値をTAMPER_IN4と比較してチェックする価値は? 3. このチャネルのパターンクロックを可能にするlp.act_tamper_clk_ctlの値は何? 4. このチャネルのアクティブ改ざん検出を可能にするグローバルなlp.act_tamper_ctl価値は何でしょうか? 目標:J20ピン1~3間のジャンパーを閉じるとsnvs_sec_statusでセキュアと表示され、ジャンパーを開くと違反が発生するようにする。 i.MX8DXLにおける外部アクティブタンパー検証に関するリファレンステスト手順またはアプリケーションノートはありますか? よろしくお願いします!
查看全文
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。
查看全文
RT685 DSP image uses cached binary instead of newly built in Zephyr sysbuild on MacOS Platform: MacOS 15.6.1 (24G90) VS Code (Version: 1.112.0 (Universal)) MCUXpresso for VS Code: 26.8.29 Zephyr toolchain: zephyr-sdk-1.0.1, zsdk nxp-v4.4.1.1 Application: amp_blinky imported as zephyr-freestanding Board: MIMXRT685-EVK Description: I am setting up dev environment on MacOS, same steps were working fine on my Linux machine. While build and flash threw no critical warning/error with MCUXpresso, application was running fine on both Arm and DSP cores. Then I edited the code under remote/src and remote/prj.conf, and flash it after a pristine build. However, the DSP core still ran the previous image before editing. Below are some of the interesting behaviors: I tried to edit the Arm core code too, but that change was applied successfully. Changes in the DSP core code can trigger a non-pristine build instead of showing "no work to do." Disabling CCACHE in cmake seems to solve the issue So far to me, it looks like a cahce-related issue that the compiler ignores the changes in the DSP image while running sysbuild, and uses the cached binary, regardless it has been rebuilt. It is probably caused by nxp_zephyr/zephyr/samples/boards/nxp/adsp/rtxxx/common/src/dspimgs.S isn't updated. Also, it might be a MacOS-only issue since I didn't notice it on my Linux machine. Is this a known issue? Is there an elegant solution instead of disabling CCACHE? Best Regards, Yue ZEPHYR-OS-EDGE  i.MXRT 600 Re: RT685 DSP image uses cached binary instead of newly built in Zephyr sysbuild on MacOS Dear @YueZ , Thank you for your questions. So far, this is not a known issue on our side. To help identify the root cause, could you please check whether the following outputs are updated consistently? The DSP BIN generated by the remote build process. The object file generated from dspimgs.S. The final Arm BIN that is actually programmed onto the device. If the DSP BIN has been updated, but the object file generated from dspimgs.S has not, one possible reason is that the build system did not update the DSP BIN timestamp. As a result, the dependency check may have skipped recompiling dspimgs.S. We recommend adding the following content to the CMake configuration responsible for dspimgs.S to ensure changes in the DSP BIN trigger a rebuild: set(DSP_BIN_DIR ${CMAKE_BINARY_DIR}/../remote/zephyr) set_property(SOURCE ${CMAKE_CURRENT_SOURCE_DIR}/src/dspimgs.S PROPERTY OBJECT_DEPENDS ${DSP_BIN_DIR}/zephyr_reset.bin ${DSP_BIN_DIR}/zephyr_text.bin ${DSP_BIN_DIR}/zephyr_data.bin ) (Please also verify that the actual file path is correct.) Please let us know if you have any questions.   Best Regards, Shelly Re: RT685 DSP image uses cached binary instead of newly built in Zephyr sysbuild on MacOS Hello Shelly, Thanks for your reply! I checked the timestamps of the three DSP BINs under build/remote/zephy, the final Arm BIN, and the dspimgs.S.obj under build/amp_blinky/CMakeFiles/app.dir/.../adsp/rtxxx/common/src/, they were all updated by either pristine or non-pristine build. I also tried the recommended CMake configuration by replacing  set_source_files_properties( "${CMAKE_CURRENT_LIST_DIR}/src/dspimgs.S" OBJECT_DEPENDS ${HIFI4_BUILD_DIR}/zephyr.elf )   with   set(HIFI4_BIN_DEPS "${HIFI4_BUILD_DIR}/zephyr.elf" "${HIFI4_BUILD_DIR}/zephyr.reset.bin" "${HIFI4_BUILD_DIR}/zephyr.text.bin" "${HIFI4_BUILD_DIR}/zephyr.data.bin" ) set_source_files_properties( "${CMAKE_CURRENT_LIST_DIR}/src/dspimgs.S" PROPERTIES OBJECT_DEPENDS "${HIFI4_BIN_DEPS}" ) in dsp-load.cmake, and verified the change by `ninja -C build/amp_blinky -t query build/.../dspimgs.S.obj`   But unfortunately, the issue persists. Then I did another test as below: add `printk("TESTCCACHE");` to remote/src/main.c build call `strings build/.../dspimgs.S.obj | grep TESTCCACHE` call `strings build/remote/zephyr/zephyr.text.bin build/remote/zephyr/zephyr.data.bin | grep TESTCCACHE` Step 3 returned nothing while step 4 found the string. Then, I ran the test again with CCACHE disabled, and TESTCCACHE was found in both. It looks like dspimgs.S.obj did get its timestamp updated without loading the correct binaries when CCACHE is enabled. I would appreciate any thoughts on this. Best Regards, Yue Re: RT685 DSP image uses cached binary instead of newly built in Zephyr sysbuild on MacOS Hello Shelly, Yes, CCACHE_RECACHE=1 works. BTW, I disable CCACHE by setting USE_CCACHE to 0 in CMakeLists. As for CCACHE_DISABLE, I have to explicitly set it in a west workspace terminal to make it work, which isn't quite ideal for using MCUXpresso for VS Code. The same thing goes for CCACHE_RECACHE, that I cannot use it by adding to CMakeLists. Best Regards, Yue Re: RT685 DSP image uses cached binary instead of newly built in Zephyr sysbuild on MacOS Dear @YueZ , Could you please try: CCACHE_RECACHE=1 ?   Unlike CCACHE_DISABLE, which completely bypasses ccache and performs a full rebuild without reading or writing any cache entries, CCACHE_RECACHE=1 forces regeneration of all outputs and updates the cache with the newly built results. If the issue disappears with CCACHE_RECACHE=1, it would indicate that the root cause is likely old cache contents. If the problem persists, it would suggest that the issue is related to ccache itself rather than a specific cached entry. Best Regards, Shelly  
查看全文
针对1080p RTSP IP摄像机,推荐使用NXP i.MX处理器 大家好, 请问哪位可以推荐一款价格最低、能够处理 1080p RTSP IP 摄像头视频流的 NXP i.MX 处理器? 我的要求是: 1 个 RTSP IP 摄像头输入 2. 1080p分辨率 3. 大约 25–30 帧/秒 4. 寻找能够可靠处理此任务的最低成本 i.MX 处理器/主板 主要目标是以尽可能低的硬件成本接收和处理/显示 1080p RTSP 摄像头流。 如果有人针对类似用途测试过低成本的 i.MX 处理器,请分享您的推荐和经验。 谢谢您! Re: Recommendation for NXP i.MX Processor for 1080p RTSP IP Camera 你好, 对于使用 IP 摄像机的纯粹接收/显示应用,您可以考虑 i.MX8MM,因为它包含一个专用的硬件 VPU,能够解码 1080p60。 顺祝商祺!
查看全文
imx6q DDRストレステストについて i.mX6QでDDRストレステストを実行しているのですが、どのExcelファイルを使用すればよいか知りたいです。 `MX6Q_SabreSD_DDR3_register_programming_aid_v2.5.xlsx`というファイルを入手しましたが、これは正しいファイルでしょうか? 現在、Samsung K4B4G16 256M×16チップ(合計2GBのチップ4個)を使用していますが、テストが完了しず、「チップセレクトが有効になっていません」というエラーが表示されます。 この問題をどう解決すればいいでしょうか? ありがとう。 Re: about imx6q ddr stresstest こんにちは、 @GavinChen さん。 このRPAテーブルはi.MX6Qに適しています。 あなたのRPAに関するご意見をお聞かせください。 B.R
查看全文
FlexIO BiSS-C 主设备:MA 时钟计数无法适应 ACK 周期,CRC 在 2.5 MHz 时校验失败 我正在使用 MIMXRT1186 和 SDK 的flexio_biss_polling_transfer示例与 BiSS-C 绝对编码器(24 位 ST + 16 位 MT)进行通信。 问题: 在500 kHz时,CRC 校验通过,位置数据正确。 在2.5 MHz 频率下,CRC 校验总是失败。编码器的 ACK 周期约为11.8 µs ,这在 2.5 MHz 频率下大约相当于30 个 MA 时钟周期。 示波器观察显示,FlexIO 主设备从帧的开头就发送固定数量的 MA 时钟,而没有根据 ACK 周期进行调整。这 30 个 ACK 低电平位被采样到 64 位接收移位器中,从而将实际的 START + SCD 数据推出了移位窗口。FLEXIO_BISS_CalFrameHeadLen()返回值介于 12 和 34 之间,并且BISS_VerifyFrame()校准失败。 我对BiSS-C的理解是: 该协议要求 MA 在 ACK 期间继续运行,因为编码器需要这些时钟来推进其内部状态机,最终结束 ACK 并发送 START 位。因此,正确的主控行为是: MA 从帧的开始就持续发送时钟信号,包括在 ACK 期间。 主监视器 SL。 主控器持续统计已发送的 MA 时钟数。当 SL 变为高电平(ACK 结束,START 位到达)时,主设备会记录 ACK 消耗了多少个时钟周期,然后计算完成帧还需要多少个时钟周期。 我的问题: FlexIO 的定时器使用固定的timerCompare值一次性发送预定义数量的时钟信号。FlexIO 是否有任何机制支持上述自适应行为,即根据帧期间的 SL 边沿动态调整剩余的 MA 时钟信号数量? 具体来说: FlexIO 的定时器能否使用 SL 边沿作为触发信号来停止、RESET 或重新加载定时器,以便主设备能够确定 ACK 何时结束,然后发送剩余的时钟信号? 如果 FlexIO 无法做到这一点,NXP 建议采用什么方案来实现支持长 ACK 周期的 BiSS-C 主设备(例如,eFlexPWM、LPSPI 或基于 FPGA 的解决方案)? 设置: MCUXpresso SDK for MIMXRT1186 驱动程序: fsl_flexio_biss.c / .h 示波器监测 MA (D02) 和 SL (D00) 谢谢您的指导。 回复: FlexIO BiSS-C master: MA clock count cannot adapt to ACK period, CRC fails at 2.5 MHz 亲爱的@rejust , 感谢您的回复。这对其他面临同样问题的人会非常有帮助。   顺祝商祺! 雪莉     回复: FlexIO BiSS-C master: MA clock count cannot adapt to ACK period, CRC fails at 2.5 MHz 更新:NXP 已发布官方示例来解决此问题。 AN15161 — MCX A366 上 FlexIO 实现的 BiSS-C 接口 项目:an-mcxa366-bissc-interface-using-flexio(NXP 应用代码中心)
查看全文
OTP_CFG_ASIL.WD_DIS = 1 の場合、FS85 が INIT_FS で永久に停止してしまうのですが、これは想定される動作でしょうか? こんにちは、 FS85(フェイルセーフSBC)を搭載したボードを起動しており、フェイルセーフの状態マシンは決してINIT_FSを離れません(FS_STATES)。FSM_STATEは6/INIT_FSのままで、MCUが設定されたウィンドウ期間に連続的なウォッチドッグリフレッシュを送信します。 データシート(Rev 9、§14.3、p.18)によると、 「最初の正常なウォッチドッグ更新でINIT_FSが閉じられます。」弊社側では、OTP_CFG_ASIL.WD_DIS = 1(OTPによってウォッチドッグ監視が無効になっている)となっています。 スタック状態にある間もレジスタ読み取りをサポートする(ウォッチドッグ評価ロジックがそもそも実行されないことと完全に一致する): FS_I_WD_CFG.WD_ERR_CNT = 0、 WD_RFR_CNT = 0(決して動かない) FS_DIAG_SAFETY.BAD_WD_DATA = 0、 WDタイミング不良 = 0 (ラッチしない) FS_STATES.REG_CORRUPT = 0、 OTP_破損 = 0(INIT_FSレジスタ/register_NOTの不一致を除外) 質問: WD_DIS = 1が構造的にINIT_FSを離れられないのは予想・文書化されているのでしょうか(WDがOTP無効になっていると閉じる「良いウォッチドッグ更新」イベントがINIT_FS生成されないため)?あるいは、OTPによってウォッチドッグが無効になっている場合に、INIT_FSを閉じてNORMAL_FSにアクセスするための、文書化された別の手順はありますか? データシート セクション 14.1/14.3VALID_WD = 0 は OTP によって WD が無効になっているときに発生すると記述されていますが、INIT_FS -> WAIT_ABIST2 遷移の結果については明示的に述べられていません。何かご説明や、関連するアプリケーションノートの参考になることを教えていただけると助かります。 ありがとう、ソフィー FS85&FS84 Re: FS85 stuck in INIT_FS forever when OTP_CFG_ASIL.WD_DIS = 1 — is this expected? こんにちは、ソボ 良い一日! 調査の過程で似たような事件に関する情報を見つけ、その調査を担当した同僚と共に検討しています。ただし、事件の性質上、より自由かつ安全に情報を共有するためには、公式ウェブサイトでチケットを提出していただく必要があります。 ご理解いただきありがとうございます。 良い一日をお過ごしください。幸運を祈ります。
查看全文
S32K344 Kicad symbols and footprints Hello, Is there a KiCad library available for the S32K344 MCU family, including schematic symbols, footprints and 3D models (STEP)? Thank you. Re: S32K344 Kicad symbols and footprints Thanks. So I figure that I have to design the kicad symbol, footprint and 3D models by myself. Re: S32K344 Kicad symbols and footprints Hi @manu_fenixecu  In case of S32K3, we provide 3D STEP files and symbols and footprints for CADENCE Allegro. It can be found in Hardware Design Package: https://www.nxp.com/webapp/Download?colCode=S32K3_HW-DesignPackage Regards, Lukas
查看全文
请问LS1021A的IFC接口的ip_clk频率范围是多少? 你好, 我在规格书(例如数据手册、ARM 文档和检查清单)中找不到 LS1021A 的 IFC 接口的 ip_clk 频率范围。请问您能告诉我吗? 提前感谢! 顺祝商祺! 杰森 QorIQ LS1设备 Re: Could you please tell me the ip_clk frequency range for IFC interface of LS1021A? LS1021A 上 IFC ip_clk 没有单独指定的最小/最大频率范围。ip_clk 是内部 IFC 模块时钟,等于处理器的平台时钟;它不是接口引脚时钟。数据手册明确指出 IP_CLK 是内部信号,不能通过接口引脚使用。 对于标准的LS1021A时钟配置: 参考手册将平台 PLL 描述为生成 300 MHz 平台时钟,并且有记录的 RCW 示例使用 SYSCLK = 100 MHz 和 SYS_PLL_RAT = 3,产生 ip_clk = 300 MHz。
查看全文
Could you please tell me the ip_clk frequency range for IFC interface of LS1021A? Hi, I can't find the  ip_clk frequency range for IFC interface of LS1021A in the spec such as datasheet, ARM and checklist. Could you please tell me it? Thanks in advance! Best regards! Jason QorIQ LS1 Devices Re: Could you please tell me the ip_clk frequency range for IFC interface of LS1021A? There is no separately specified minimum/maximum frequency range for IFC ip_clk on LS1021A . ip_clk is the internal IFC module clock , equal to the processor’s platform clock ; it is not an interface pin clock. The datasheet explicitly says that IP_CLK is internal and unavailable on the interface pins. For the standard LS1021A clock configuration: The reference manual describes the platform PLL as generating a 300 MHz platform clock , and a documented RCW example uses SYSCLK = 100 MHz with SYS_PLL_RAT = 3 , producing ip_clk = 300 MHz .
查看全文
FreeMasterにGUI Guiderを統合することは不可能です 親愛なるみんな FreeMASTERのウェブページには、GUI GiiderがFreeMAsterでウィジェット作成をサポートしていることが示されていますが、利用可能なFreeMasterバージョン2.01および動画もサポートしています。 https://community.nxp.com/t5/MCUXpresso-Training-Hub/FreeMASTER-Gui-Guider-integration/ta-p/1924225 GUI GuiderをFreeMASTERに統合する方法を示してください。ただし、GUI Guider 2.01には「FreeMASTERサーバーへのリンク」もFreeMASTER構成への参照もありません。さらに、NODE RedはFREEMasterではサポートされていません(ライトバージョンのみサポートされています)。つまり、FreeMasterできれいなウィジェットを作る方法はありません 正しいのでしょうか? 尊重する パオロ FreeMASTERでGUI Guiderを使用することは可能ですか?また、どのように使用すればよいですか?適切な動画やアプリのノートを教えてもらえますか? ありがとう パオロ
查看全文
当 OTP_CFG_ASIL.WD_DIS = 1 时,FS85 一直卡在 INIT_FS 状态——这是预期行为吗? 您好, 我们正在启动一块带有 FS85(故障保护 SBC)的板子,但故障保护状态机永远不会离开 INIT_FS(即使 MCU 在配置的窗口周期内发送连续的看门狗刷新,FS_STATES.FSM_STATE 也无限期地保持在 6 / INIT_FS)。 根据数据手册(修订版 9,第 14.3 节,第 18 页): “第一次成功的看门狗刷新会关闭 INIT_FS。”就我们而言,OTP_CFG_ASIL.WD_DIS = 1(OTP 已禁用看门狗监控)。 支持在卡住时读取寄存器(这与看门狗评估逻辑根本不运行的情况完全一致): FS_I_WD_CFG.WD_ERR_CNT = 0, WD_RFR_CNT = 0(永不移动) FS_DIAG_SAFETY.BAD_WD_DATA = 0, WD 时序错误 = 0(永不锁定) FS_STATES.REG_CORRUPT = 0, OTP_CORRUPT = 0(排除 INIT_FS 寄存器/寄存器非值不匹配的情况) 问题: WD_DIS = 1 是否会在结构上阻止离开 INIT_FS(因为当 WD 被 OTP 禁用时,永远无法生成关闭 INIT_FS 的“良好看门狗刷新”事件)?或者,当 OTP 禁用看门狗时,是否有其他已记录的路径可以关闭 INIT_FS 并到达 NORMAL_FS? 数据手册第 14.1/14.3 节状态 VALID_WD = 0“当 WD 被 OTP 禁用时”,但没有明确说明 INIT_FS -> WAIT_ABIST2 转换的后果。如有任何说明或相关应用笔记的链接,敬请指正。 谢谢你,索菲。 FS85&FS84 Re: FS85 stuck in INIT_FS forever when OTP_CFG_ASIL.WD_DIS = 1 — is this expected? 你好 sobo 再会! 在调查过程中,我发现了一个类似案例的信息,我正在与负责审查该案例的同事一起审查;但是,鉴于该案例的性质,您需要在我们的官方网站上开一个工单,以便我们能够更自由、更安全地共享信息。 感谢您的理解。 祝你今天过得愉快,一切顺利。
查看全文