Multi Source Translation Content

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

Multi Source Translation Content

讨论

排序依据:
PTN5150AHXMP IBIS 型号 您好, 我是 Krithikka Jayamurthi,我需要 IBIS 模型文件来进行信号完整性仿真。 Re: PTN5150AHXMP IBIS model 你好, Krithikka, 目前还没有针对该设备或其系列部件创建 IBIS 仿真模型。 USB Type-C 接口上的 CC 线以相对较低的信号速度运行(USB PD BMC 信号速度为 300 kbps),这意味着它们通常不会受到高频信号完整性问题的影响,而这些问题通常是导致需要 IBIS 型号的原因。通常情况下,数据手册中的标准 I²C 电平或低速 I/O 特性(电气规格:VOL/VOH、IOL/IOH、上升/下降时间、电容)足以评估 CC 引脚上的信号质量。 如果您对信号完整性的担忧具体与 USB 数据路径(USB 2.0 D+/D−)有关,请注意 PTN5150AHXMP 本身并不路由或缓冲 USB 数据线 - 它纯粹是一个 CC 逻辑控制器。USB 数据信号完全绕过设备,直接在连接器和插座处处理。 BRs,托马斯
查看全文
SC16IS740 Maximum Crystal Frequency Dear NXP Technical Support Team, We are using the SC16IS740 with a 3.3 V supply. Could you please confirm the maximum external crystal oscillator frequency that can be connected directly between XTAL1 and XTAL2? The datasheet mentions: Applies to external clock, crystal oscillator max 24 MHz. Thank you for your support. Regards, Abishek Re: SC16IS740 Maximum Crystal Frequency Hello AbishekDevan Good day! Yes, you are correct; the limit with an external crystal is 24 MHz. Have a great day and best of luck.
查看全文
S32E2 IPCF 延迟时间介于 M33 和 R52 之间 我正在使用 S32E2 并配置 IPCF 框架,以下是我的设置。 设备:S32E288 IPCF 传输:共享内存 + MRU 通知 通信:M33 ↔ R52 IPCF通道类型:管理通道 配置了 1 个 IPCF 通道 中断模式(非轮询) 已实施 Ping/Pong RTT 测试 双向沟通正常。 我使用STM来测量两个核心之间的时序滴答数。 测量流程: R52: 时间戳 发送 PING   M33: 收到 PING 立即从 RX 回调发送 PONG 请求   R52: 收到 PONG 计算 RTT 计算得出,运行在 24Mhz 的 STM 的 RTT(往返时间)接近 200us。我的传输开销大约是 30 微秒,但传输本身占用了大部分时间。我尝试过各种方法,例如增加 MRU IRQ 通知,但并没有改善时序问题。代码优化级别从 -o0 到 -o1 有所提升,但 -o2 没有任何效果。有效载荷本身为 16 字节。 问题: 1. 托管/非托管通道的预期 IPCF 延迟是多少? 2. 我们能否实现两位数的低延迟? 如果您需要更多详细信息,请回复。
查看全文
LPC1347 USB 控制传输 <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> 我们的客户 SIGMATEK 希望在 LPC1347 上实现 USB 控制传输。 只要数据长度小于 64 字节或大于 64 字节,这种方法就很好用。 如果数据长度正好是 64 字节(或 64 字节的倍数),则此方法不再有效。 他们需要做些什么才能让这个功能正常运行? 此致, Peter Re: LPC1347 USB Control Transfer 你好, 当 USB 数据有效载荷恰好等于端点最大数据包大小(全速为 64 字节)的倍数时,接收器会挂起,因为没有短数据包来表示传输结束;为了在 LPC1347 上解决此问题,SIGMATEK 必须检查有效载荷长度是否为 64 的非零倍数,如果是,则在主数据块之后立即手动发送长度为零的零长度数据包 (ZLP),以刷新缓冲区、表示完成并成功终止传输。 此致
查看全文
PTN5150AHXMP IBISモデル こんにちは、 私はKrithikka Jayamurthiです。信号整合性シミュレーションを行うためにIBISモデルファイルが必要です。 Re: PTN5150AHXMP IBIS model こんにちは、クリティッカさん。 この装置やそのファミリ部品については、IBISシミュレーションモデルは作成されていません。 USB Type-Cインターフェース上のCCラインは比較的低い信号速度(USB PD BMC信号は300 kbps)で動作するため、IBISモデルに通常求められる高周波信号の整合性問題には一般的に影響されません。データシートの標準I²Cレベルまたは低速I/O特性評価(電気仕様:VOL/VOH、IOL/IOH、昇降時間、静電容量)で、通常はCCピンの信号品質を評価するのに十分です。 もし信号の整合性に関する懸念がUSBデータパス(USB 2.0 D+/D−)に特化している場合、PTN5150AHXMP自体はUSBデータラインをルーティングやバッファリングするものではなく、純粋にCCロジックコントローラであることにご注意ください。USBデータ信号はデバイスを完全にバイパスし、コネクタとレセプタクルで直接処理されます。 BRs、トーマス
查看全文
NXP i.MX93 EVK 运行时功耗 我正在使用NXP i.MX93 EVK,想要监控运行时功耗,请问如何获取这些数据? 议程是监测人工智能模型推理过程中的功率使用情况。如何监测功率指标? 如何仅使用软件(无需任何外部硬件)来监测功率指标? Re: NXP i.MX93 EVK POWER consumption at runtime i.MX93 EVK 包含板载功率监控电路,并支持通过软件工具进行功率测量。 针对 i.MX93 EVK,NXP 提供了 AN13917:i.MX 93 功耗测量, https://docs.nxp.com/bundle/AN13917/page/topics/power_measurement_of_the_imx_93_processor.html 它描述了如何使用板载测量电路和 BCU(板载控制实用程序)工具来测量功耗。 谢谢!
查看全文
KW47B42ZB7 熔丝写入问题 Lu888_0-1788925610415.pngLu888_0-1788925610415.pngLu888_0-1788925610415.png 如图所示,我无法写入熔丝 0xa,但已成功写入熔丝 0x1f。我不知道为什么 Re: KW47B42ZB7 Fuse write issue 嗨@Christine_Li , 这是否意味着不能使用 blhost 的 熔丝-program 命令来对 kw47 的生命周期进行编程? Re: KW47B42ZB7 Fuse write issue 你好, @Lu888 感谢您向我们提交案件。 根据你提供的信息,我认为你可以执行 fuse-read 命令,这意味着你不在“OEM 打开后”状态下。 但根据: KW47SRM.pdf 原因如下: 下表中的 RO 表示用户不能使用 MGMT_FUSE_PROGRAM 来写入生命周期熔丝,而是可以使用 MGMT_ADVANCE_LIFECYCLE 或 MGMT_SET_RETURN_FA_MODE。 Christine_Li_0-1788944686191.pngChristine_Li_0-1788944686191.pngChristine_Li_0-1788944686191.png 如果要更改生命周期,可以使用以下命令: SB3 文件中的 MGMT_ADVANCE_LIFECYCLE。 Christine_Li_1-1788944712390.pngChristine_Li_1-1788944712390.pngChristine_Li_1-1788944712390.png 顺祝商祺! Christine。 Re: KW47B42ZB7 Fuse write issue 你好, @Lu888 请问您能否帮忙查看一下您主板目前的生命周期? 您可以在已经执行过先前命令的板上使用以下命令: Christine_Li_0-1789109774271.pngChristine_Li_0-1789109774271.png blhost -p com4 熔丝-read 0xa 4 我想知道你的主板是否已经更换为 OEM-Closed 版本。 因为我发现根据这篇AN: KW47 生命周期管理 你使用的命令是正确的,可以用来改变生命周期。这与我之前的评论相矛盾。 顺祝商祺! Christine。
查看全文
关于使用S32K388主从模式的咨询 6953956c0a213afc6de89697c3d0e88f.png6953956c0a213afc6de89697c3d0e88f.png 我们这里有一个要求,即两个 S32k388 使用 SPI 通信相互通信。两者之间可以既是主人又是奴隶吗?例如,当我使用芯片 A 作为主机时,IOMUX 表中的 I 项描述了 MISO 的主机输入。如果芯片 A 用作从设备,那么这个 O 项是否描述了 MISO 的从设备输出?我们当前项目中的引脚是固定的。例如,SOUT:MOSI 上使用 PTA18+ GPIO_ALT_FUNC_4 ,SIN:MISO 上使用 PTA20+239+ GPIO_ALT_FUNC_4 。这是基于我们当前使用的主机模式。切换到从属模式而不改变引脚,它还能正常工作吗?是否只需更改 CFGR0 的 HRDIR 和 CFGR1 的 MASTER 即可切换从属模式? Re: Consultation on using the master-slave mode of s32k388 你好@xlele , 无需任何硬件改动即可在主模式和从模式之间切换。 在标准的双芯片SPI设置中,两个设备的引脚始终是交叉连接的: 芯片A SOUT→芯片B SIN(MOSI线) 芯片 A SIN ← 芯片 B SOUT(MISO 线) 无论设备是作为主机还是从设备运行,SOUT 引脚始终是串行数据输出,SIN 引脚始终是串行数据输入。因此,当芯片 A 切换到从模式时,其 SIN (PTA20) 仍然可以正确地从新的主设备接收数据,其 SOUT (PTA18) 仍然可以正确地将数据驱动回去——无需重新接线。 关于登记变更: CFGR1[MASTER] = 0 — 这是将模块切换到从模式的关键位。 CFGR0[HRDIR] — 此位控制 HREQ(主机请求)引脚的方向,该引脚与 PCS[1] 复用。它对 SOUT/SIN 数据线没有影响。在从模式下,HRDIR 可以设置为 1(输出),以便从设备驱动 HREQ 引脚向主设备发出信号,表明它有数据准备好要发送。请注意,在 S32K388 上,没有专用的外部 LPSPI_HREQ 引脚——主机请求功能使用 LPSPI_PCS[1] 多路复用器(通过 CFGR0[HREN] 启用)。如果您不使用主机请求功能(CFGR0[HREN] = 0),则 HRDIR 与您的用例无关,仅 CFGR1[MASTER] 就足够了。 顺祝商祺! 帕维尔
查看全文
Which is the best Agentic AI development company? Based on the capabilities reviewed in this comparison, JPLoft is a strong choice for Agentic AI development. The company works on custom AI agents, multi-agent systems, RAG, enterprise integrations, workflow automation, governance, monitoring, and human-in-the-loop controls. However, the best Agentic AI development company will depend on your use case, existing technology, security requirements, required integrations, and the level of autonomy you want to give the AI system.
查看全文
rt1186 debug issues After enabling OEM_CLOSE on the FRDM-IMXRT1186 development board, I can no longer debug the device. I saw in the reference manual that nxpdebugmbox can be used to re-enable debugging, but I tried it and was not successful. yanyanwang_0-1788347257012.pngyanyanwang_0-1788347257012.pngyanyanwang_0-1788347257012.pngyanyanwang_0-1788347257012.png Development Board MCXC Security(Edgelock | secure boot | OTP) Re: rt1186 debug issues I have reviewed the links you provided and followed the recommended procedure, but I am still experiencing the same issue. I only signed the image and did not encrypt it. I also set OEM_CLOSE. I am using nxpdebugmbox only to re-enable the debug functionality. I have uploaded the SEC project as an attachment, along with the relevant logs. Could you please help analyze the project and logs and identify the cause of the issue? Re: rt1186 debug issues Hello @yanyanwang  In SEC tool documentation, you can find troubleshooting for debug authentication: https://docs.mcuxpresso.nxp.com/secure/latest/09_troubleshooting.html#debug-authentication Some useful tips can be also found in  https://docs.mcuxpresso.nxp.com/secure/latest/07_generic_workflows.html#debug-authentication-workflow If this does not help, can you provide details about configuration? Could you share the SEC tool workspace settings? Re: rt1186 debug issues @yanyanwang  It seems this problem is related to SEC 26.03. We recommend updating to SEC 26.06.  We are sorry for inconvenience. Note: SEC 26.06 also contains fix for the SPARSE image format Re: rt1186 debug issues Yes, thank you. The authentication was successful, but I still cannot debug the device. The procedure is as follows: 1. Use the SEC tool to perform the authentication. 2. The authentication is successful. 3. Then click the Debug button to start debugging. 4. However, the debugging attempt fails.
查看全文
Consultation on using the master-slave mode of s32k388 6953956c0a213afc6de89697c3d0e88f.png6953956c0a213afc6de89697c3d0e88f.png We have a requirement here, which is for two S32k388s to communicate with each other using SPI communication. Can either one be the master or slave? For example, when I use chip A as the host, the I item in the IOMUX table describes the host input of MISO. If chip A is used as a slave, does this O term describe the slave output of MISO? The pins in our current project are fixed. For example, SOUT: PTA18+GPIO_ALT_FUNC_4 is used on MOSI, SIN: PTA20+239+GPIO_ALT_FUNC_4 is used on MISO. This is based on the current host mode we are using. Can it still work normally when switching to slave mode without changing the pins? Is it sufficient to switch slave mode by simply changing the HRDIR of CFGR0 and the MASTER of CFGR1? Re: Consultation on using the master-slave mode of s32k388 Hello @xlele , You do not need any hardware changes to switch between master and slave mode. In a standard two-chip SPI setup, the pins are always cross-connected between the two devices: Chip A SOUT → Chip B SIN (MOSI line) Chip A SIN ← Chip B SOUT (MISO line) The SOUT pin is always a serial data output and SIN is always a serial data input, regardless of whether the device is operating as master or slave. So when Chip A switches to slave mode, its SIN (PTA20) still correctly receives data from the new master and its SOUT (PTA18) still correctly drives data back — no rewiring needed. Regarding the register changes: CFGR1[MASTER] = 0 — this is the key bit to switch the module into slave mode. CFGR0[HRDIR] —  this bit controls the direction of the HREQ (Host Request) pin, which is multiplexed with PCS[1]. It has no effect on the SOUT/SIN data lines. In slave mode, HRDIR can be set to 1 (output) so that the slave drives the HREQ pin to signal the master that it has data ready to transmit. Note that on S32K388, there is no dedicated external LPSPI_HREQ pin — the host request function uses the LPSPI_PCS[1] mux (enabled via CFGR0[HREN]). If you are not using the host request feature (CFGR0[HREN] = 0), HRDIR is not relevant to your use case and CFGR1[MASTER] alone is sufficient. Best regards, Pavel
查看全文
rt1186 调试问题 在 FRDM-IMXRT1186 开发板上启用 OEM_CLOSE 后,我无法再调试该设备。我在参考手册中看到可以使用 nxpdebugmbox 重新启用调试功能,但我尝试后没有成功。 yanyanwang_0-1788347257012.pngyanyanwang_0-1788347257012.pngyanyanwang_0-1788347257012.pngyanyanwang_0-1788347257012.png 开发板 MCXC 安全(Edgelock | 安全启动 | OTP) Re: rt1186 debug issues 我已查看您提供的链接并按照推荐的步骤操作,但我仍然遇到同样的问题。 我只对图像进行了签名,并没有对其进行加密。我还设置了 OEM_CLOSE。 我使用 nxpdebugmbox 只是为了重新启用调试功能。 我已将高效密码学标准\\(SEC\\)项目及其相关日志作为附件上传。请您帮忙分析项目和日志,找出问题的原因吗? Re: rt1186 debug issues 你好@yanyanwang 在 高效密码学标准\\(SEC\\) 工具文档中,您可以找到有关调试身份验证的故障排除信息: https://docs.mcuxpresso.nxp.com/secure/latest/09_troubleshooting.html#debug-authentication 您还可以在以下位置找到一些有用的技巧: https://docs.mcuxpresso.nxp.com/secure/latest/07_generic_workflows.html#debug-authentication-workflow 如果这样还是不行,能否提供详细的配置信息?能否分享一下高效密码学标准(SEC)工具的工作区设置? Re: rt1186 debug issues @yanyanwang 这个问题似乎与 高效密码学标准\\(SEC\\) 26.03 有关。我们建议更新至高效密码学标准(SEC) 26.06版本。 给您带来的不便,我们深表歉意。 注:高效密码学标准(SEC) 26.06 还包含对 SPARSE 映像格式的修复。 Re: rt1186 debug issues 是的,谢谢。身份验证成功,但我仍然无法调试设备。 具体步骤如下: 1. 使用高效密码学标准(SEC)工具执行身份验证。 2. 身份验证成功。 3. 然后点击调试按钮开始调试。 4.然而,调试尝试失败了。
查看全文
Guideline for Porting a New YOLO Variant - YOLO26 on Ara2 This slides firstly introduce the YOLO26 model, and NXP Ara2 Model Zoo, Ara2 SDK/Runtime. Then it explains the CNN model compilation flow with Ara2 toolchain in SDK package, how to compile the newly added model - Yolo26n, how to setup the inference environment in i.MX95FRDM+Ara2-240 board. Finally present the inference result. Patches and user guide are provided in attachment as well.
查看全文
S32K312: SWT0機能リセットエスカレーション、破壊リセットステータス、およびSRAM保持 NXPチームの皆様、こんにちは。 私はS32K312 Cortex-M7を使い、S32 Design StudioとAUTOSAR RTD 7.0.1 / AUTOSAR 4.9を使って作業しています。 現在、MC_RGMのリセット動作、特にSWT0機能リセット、機能リセットエスカレーション、破壊的リセット、SRAM保持、SBAF/リカバリ動作、およびPower IPリセットAPIのテストを行っています。 1. SWT0機能リセットエスカレーション 私はSWT0タイムアウトを使用して機能リセットを生成しています。 私のMC_RGMの設定は以下のとおりです。 MC_RGM_FRET_FRET((uint32)15U) MC_RGM_DRET_DRET((uint32)0U) 機能リセットカウンタが増加していることを確認しました。 SWT0機能リセット#1 -> FREC = 1 SWT0機能リセット#2 -> FREC = 2 ... SWT0機能リセット#14 -> FREC = 14 次のSWT0リセット後、FRECはクリア/リセットされますが、期待される動作は確認できませんでした。 DES[MC_RGM_FRE] = 1 私の質問は以下のとおりです。 SWT0_RSTは、S32K312のMC_RGM機能リセットエスカレーションカウンタ(FREC)に参加しますか? FRECがFRET=15に達したとき、MC_RGM_FREを生成し、DES[MC_RGM_FRE]を設定すべきでしょうか? エスカレーション直後、FES、DES、FREC、FRET、Power_Ip_GetResetReason() には具体的にどのような値が期待できるでしょうか? SWT0がFRETエスカレーションに参加するために、追加の設定は必要ですか? SBAFやリカバリーハンドリングはFRETのエスカレーションに支障をきたすことはありますか? SWT0/FRETの上昇に関連する既知の不具合やS32K312の挙動はありますか? アプリケーションを継続的に実行すると、15回目の機能リセット後にアプリケーションやデバッガが停止し、期待される破壊的なリセットを観察できません。これがリセットシーケンス、SBAFリカバリ、またはデバッガに関連しているかどうかを知りたいです。 2.すべてのSWT0機能リセットを破壊的なものにしたい テスト目的で、以下のことも達成したいと考えています。 SWT0タイムアウト ↓ 機能リセット ↓ 即時破壊リセット 15回も機能リセットを待つ代わりに。 以下の設定で実現できますか: FRET = 1U; 具体的には: FRET = 1 の場合、最初の適格な SWT0 機能リセットが破壊的なリセットにエスカレートしますか? MC_RGMの追加設定は必要ですか? SWT0は、このエスカレーションの対象となる情報源として確実に認められるのでしょうか? SBAFや回復行動はこれに影響を与えるのでしょうか? これはRTD 7.0.1の設定で直接サポートされていますか? 3. SRAMデータは、機能リセットのたびに消去されます。 私の理解では、S32K3xxリファレンスマニュアルでは、SRAMやシステムメモリは機能リセット後も保持されるべきです。 SRAMテスト変数を作成しました。 #define SRAM_TEST_ADDR ((volatile uint32_t *)0x204007d4U) そして、それを使って機能リセット後のデータ保持状況を確認する。 しかし、機能リセット後にSRAMデータが消去/ゼロに書き換えられていることを確認しました。 私の質問は以下のとおりです。 機能リセットの際にハードウェアがSRAMを保持し、その後ソフトウェアによって上書きされるのでしょうか? S32K312において、機能リセット後も内容が確実に保持されるSRAM領域はどれですか? 関数リセットを通じてその内容を保持するために、SRAMに変数を配置する推奨される方法は何ですか? 専用の.noinitファイルを使うべきでしょうか?または、保持されたSRAMセクション? データ保持に必要なMC_RGM/SRAMの特定の構成はありますか? 機能リセット間でアプリケーションデータを保持するための推奨されるRTD 7.0.1の方法は何ですか? 4. 直接ソフトウェア破壊的リセット また、Power IPを使って直接的なソフトウェア破壊リセットもテストしています: Power_Ip_Init(&Power_Ip_HwIPsConfigPB); gVar= Power_Ip_GetResetReason(); for (count = 0; count < 10125000; count++); Power_Ip_PerformReset(&Power_Ip_HwIPsConfigPB); 現在のMC_RGM構成には以下が含まれます。 static const Power_Ip_MC_RGM_ConfigType Power_Ip_MC_RGM_ConfigPB = ヤージュ (MCU_DEST_RESET) ... MC_RGM_FRET_FRET((uint32)15U) MC_RGM_DRET_DRET((uint32)0U) }; 破壊的なリセットが発生するが、デバッガーは通信を繰り返し失い、再確立する。 次のようなメッセージを見かけます。 情報: DAP IDCODE = 0x6BA02477 情報:DAPの電源投入に成功しました。DP CTRL/STAT = 0xF0000000 複数回繰り返され、続いて次のもの: 割り込みコマンドを受信しました。執行を停止します。 理解したいのは以下の点です。 破壊的なリセット中に、DAPの再接続が繰り返し発生することは想定されていますか? 破壊リセットシーケンス中にCortex-M7に具体的に何が起こるのでしょうか? 破壊的なリセット後、CPUはいつ再び使用可能になりますか? 単一のソフトウェア破壊リセットをデバッグする推奨される方法は何ですか? 5. Power_Ip_PerformReset() 前のブレークポイント挙動 直前にブレークポイントを確実に到達することはできません: Power_Ip_PerformReset(&Power_Ip_HwIPsConfigPB); APIの前に遅延を設定し、デバッガがアクセスを得るのに十分な時間があると期待していました。 場合によっては、ターゲットを手動で一時停止してから実行を再開した後に初めてブレークポイントに到達することがあります。 理解したいのは以下の点です。 リセットAPIの前に遅延があるのに、なぜデバッガはブレークポイントを見逃すのでしょうか? これは、ターゲットが繰り返しリセットされ、デバッガーがDAP経由で再接続されることに関係していますか? 破壊的なリセットの直前や直後にCPUをキャッチする推奨される方法はありますか? RTDのDISABLE_DEBUGGER_TRAPオプションはこの動作に関係していますか? 6. Power IPの初期化とPower_Ip_SetMode() 私のRTDは以下を提供します: void Power_Ip_Init( const Power_Ip_HwIPsConfigType *HwIPsConfigPtr); void Power_Ip_SetMode(const Power_Ip_ModeConfigType *ModeConfigPtr); void Power_Ip_PerformReset( const Power_Ip_HwIPsConfigType *HwIPsConfigPtr ); Power_Ip_ResetType Power_Ip_GetResetReason(void); Power_Ip_RawResetType Power_Ip_GetResetRawValue(void); 現在使用しているもの: Power_Ip_Init(&Power_Ip_HwIPsConfigPB); そして: gVar = Power_Ip_GetResetReason(); 私のモード設定はPOWER_IP_RUN_MODEです。 以下の点についてご説明をお願いします。 Power IPリセットAPIを使用する前に、Power_Ip_Init(&Power_Ip_HwIPsConfigPB)は正しい初期化方法でしょうか? ソフトウェアの機能的/破壊的リセットテストにはPower_Ip_SetMode()が必要ですか? 選択したモードがPOWER_IP_RUN_MODEなら、このリセットテストでPower_Ip_SetMode()を省略してもいいですか? RTD 7.0.1を使って、ソフトウェアの機能リセットとソフトウェア破壊リセットの設定をどうすればよいですか? 環境 MCU:S32K312 コア:Cortex-M7 S32DS:S32 Design Studio AUTOSAR:4.9 RTD: 7.0.1 リセット元: SWT0 フレット: 15 DRET: 0 試験用の申請書を全部ご用意できます、Power_Ip_PBcfg.c。リンカー構成、MC_RGMレジスタキャプチャ、および必要に応じてデバッガーログ。 よろしくお願いします。 Re: S32K312: SWT0 Functional Reset Escalation, Destructive Reset Status and SRAM Retention こんにちは、 @Sharif417 さん。 1. SWT0機能リセットエスカレーション SWT0_RSTdoes S32K312 FRECに参加し、FRECが15に達するとDES[MC_RGM_FRE]が設定されます。Power_Ip_GetResetReason()を呼び出して「MCU_MC_RGM_FRE_RESET」を返すことで読み取れるはずです。 降格されていない機能リセット源(MCRGM.を通じて)はFERD は FREC のインクリメンションの対象となります。 Power_Ip_Init()はMC_RGMをクリアするので覚えておいてください。DES(値を保存した後)なので、電源モジュールを初期化する前にレジスタ値を取得するか、リセット理由を読み込むようにしてください。 回復モードは、閾値が>8の場合、回復モードがデフォルトで「8」に設定されているため、これに影響を与える可能性があります。sBAFはFRETではなくDRETにも干渉することがあります .「0」の場合、0xFに変わるのがわかります:   Julin_AragnM_0-1788816978772.pngJulin_AragnM_0-1788816978772.pngJulin_AragnM_0-1788816978772.pngJulin_AragnM_0-1788816978772.pngJulin_AragnM_0-1788816978772.pngJulin_AragnM_0-1788816978772.pngJulin_AragnM_0-1788816978772.pngJulin_AragnM_0-1788816978772.png アプリケーションを継続的に実行すると、15回目の機能リセット後にアプリケーションやデバッガが停止し、期待される破壊的なリセットを観察できません。これがリセットシーケンス、SBAF復旧、またはデバッガに関連しているのか知りたいです。 デバッガを接続したままにしようとする代わりに、15回目の機能リセット後に接続を試みるか、UARTなどでリセット理由を印刷してみることはできますか? 2. すべてのSWT0機能リセットを破壊的なものにしたい はい、FRET=1であれば、すべての機能リセットで破壊リセットを発行するのに十分です。 追加のMC_RGMは不要です。 sBAF/リカバリーモードはこれに影響を与えないはずです。 はい、POWER モジュール -> 「モジュール設定」 -> 「McuResetConfig」 -> 「機能リセットエスカレーション閾値」で直接設定できます 3. SRAMデータは、機能リセットのたびに消去されます。 その通りです。SRAMは機能リセット後も保持されます。 S32K3は、派生モデルによって、スタンバイRAMとして16KB、32KB、または最大64KBを提供する場合があります。 スタンバイRAMを通じて変数を配置・使用する方法の例をいくつか見つけることができます: [RTD600 MCAL & IP]S32K3 低消費パワーマネージメントANおよびデモ S32K3の低消費電力管理ANとデモ 例:S32K312スタンバイモード、スタンバイRAMおよびPAD(DS3.5 RTD300を維持) スタンバイRAMがクリア/書き換えられる理由は、デフォルトのstartup_cm7.sによるものです。S32DSによって提供される機能は、リセット理由(POR、破壊的、機能的)に関係なく、SRAM全体を初期化します。機能リセットが発生した際に、割り当てられたスタンバイRAMをSRAMの初期化がスキップするように修正する必要があります。以下のコミュニティ投稿を参照してください: S32K311 スタンバイ RAM 保持。 4. 直接ソフトウェア破壊的リセット はい、MCUが機能的/破壊的リセットを発行されると、デバッグサブシステムとクロックはすべて再初期化されるため、デバッガは再びDAPアクセスを再交渉しなければなりません。 破壊的なリセットを行うと、一部のモジュールを除いて、チップの大部分がリセットされます。機能リセットを行うと、すべての通信ペリフェラルやコアがリセットされます。通信プロトコルの健全性は保証されておらず、リセット後に再初期化されることが前提とされています。 接続を維持しようとする代わりに、デバッガの「ターゲットにアタッチ」オプションを使うことができます: Julin_AragnM_1-1788817136992.pngJulin_AragnM_1-1788817136992.pngJulin_AragnM_1-1788817136992.pngJulin_AragnM_1-1788817136992.pngJulin_AragnM_1-1788817136992.pngJulin_AragnM_1-1788817136992.pngJulin_AragnM_1-1788817136992.pngJulin_AragnM_1-1788817136992.png 5. Power_Ip_PerformReset() 前のブレークポイントの動作 おそらく再接続のウィンドウを見落としているだけです。for()ループを使う代わりに、フラグはデバッガで再接続した後に手動で変更する変数であるwhile(flag)を使い、「Expressions」タブから使うことができます。 6. Power IPの初期化とPower_Ip_SetMode() はい、Power APIを使用する前にPower_Ip_Init()を呼び出す必要があります。 そうすることをお勧めします。リセットはPower_Ip_PerformReset()を通じて行うことができますが、破壊的リセットか機能リセットのどちらかをMcuResetConfigコンテナ内で設定できます。代わりに、機能リセット用と破壊リセット用2つのパワーモードを宣言できます。次に、Power_Ip_SetMode(Functional_Reset) または Power_Ip_SetMode(Destructive_Reset) を呼び出します。 省略しても構いませんが、すべてのモジュールが正しくゲート化・設定されているか確認するためにPower_Ip_SetMode(RUN_MODE)を呼び出すと良いでしょう。もしプロジェクトに不要であれば省略しても構いません。 A6.2を参照してください。 簡単なテストを作成し、FRET=1を設定し、Power_Ip_SetMode( ) APIを通じて機能リセットを行うと報告FRE_RESET確認できました: Julin_AragnM_2-1788817284857.pngJulin_AragnM_2-1788817284857.pngJulin_AragnM_2-1788817284857.pngJulin_AragnM_2-1788817284857.pngJulin_AragnM_2-1788817284857.pngJulin_AragnM_2-1788817284857.pngJulin_AragnM_2-1788817284857.pngJulin_AragnM_2-1788817284857.png よろしくお願いします、 ジュリアン Re: S32K312: SWT0 Functional Reset Escalation, Destructive Reset Status and SRAM Retention こんにちは、ジュリアンさん。 ご説明いただきありがとうございます。 S32K312で再度テストを行ったので、2つの点について明確にしておきたいと思います。完全なプロジェクトフォルダを添付しておきますので、設定を確認して動作を再現できます。 1. SWT0機能リセットエスカレーション 設定しました: FRET = 15U;DRET = 0U; そして、 125ミリ秒のタイムアウトを設定したSWT0を使用して、機能リセットを生成します。 機能リセットのたびに FREC が増加しているのが観察できます: SWT0 reset #1 -> FREC = 1 SWT0 reset #2 -> FREC = 2 ... SWT0 reset #14 -> FREC = 14 しかし、次のSWT0機能リセットが発生し、 FRET = 15の閾値に達したときに、期待される破壊的リセット状態を観察することができません。 DES[MC_RGM_FRE] = 1 また、15回目の機能リセット後もMCUは動作を続け、予想される破壊的なリセット動作は見られません。私のSRAMテストパーティションに保存されているSRAMデータも、そのままの状態を保っています。 以下の方法でリカバリ動作を無効にしました。 IP_DCM_GPR->DCMRWP1 |= (3 << 22); 添付のプロジェクトを確認して、もう少し詳しく教えていただけますか: 15回目のSWT0機能リセット後、 DES[MC_RGM_FRE] = 1が観測されないのはなぜですか? FRECがFRET = 15に達した後、MCUは確実に破壊的なリセットに入るべきでしょうか?破壊的なリセットが発生した場合、なぜテストパーティションにSRAMの内容が保持されるのでしょうか? 他にMC_RGM/SBAFの設定で見落としているものはありますか? 2. 機能リセットおよび破壊リセット後のSRAM保持 専用のSRAMパーティション/セクションを作成し、その領域にテストデータを保存しました。 SWT0機能リセットを繰り返してもSRAMの値が保持されることを確認しました。これは想定どおりです。 しかし、FRETエスカレーションによって破壊的なリセットが発生すると予想される15回目の機能リセット後でも、SRAMの値は依然として残っています。 また、直接的なソフトウェア破壊リセットも試しましたが、リセット後もSRAM値は保持されていました。 したがって、私の見解は以下のとおりです。 SWT0 functional reset ↓ SRAM value retained 15th functional reset / expected FRET escalation ↓ SRAM value still retained Direct software destructive reset ↓ SRAM value also retained このSRAMの挙動がS32K312上で予想されるものなのか、また私のSRAMテスト領域が破壊的なリセットを経ても保持されるメモリ領域にある可能性があるのか、教えていただけますか? リンカー構成、RTD構成、MC_RGM構成、SWT0構成、テストアプリケーションを含む S32K312プロジェクトフォルダ全体を添付していますので、実際のメモリ配置とリセット設定を確認できます。 再開まで今しばらくお待ちください。 Re: S32K312: SWT0 Functional Reset Escalation, Destructive Reset Status and SRAM Retention こんにちは、 @Sharif417 さん。 1. SWT0機能リセットエスカレーション 1. 15回目のSWT0機能リセット後、DES[MC_RGM_FRE] = 1が観測されないのはなぜですか? 前述したように、Power_Ip_Init() APIはDESレジスタをクリアするため、リセット理由はPower_Ip_GetResetReason()を使用して読み取る必要があります。 2. FRECがFRET = 15に達した後、MCUは確実に破壊リセットに入るべきか?破壊的なリセットが発生した場合、なぜテストパーティションにSRAMの内容が保持されるのでしょうか? はい。FRECがFRTで設定された閾値に達している限り、MCUは破壊的なリセットを発行すべきです。破壊的なリセットが行われていないか、変数の位置が間違っているかのどちらかです。 3. 他にMC_RGM/SBAFの設定で不足しているものはありますか? いいえ。機能リセットエスカレーションの場合、FRETを設定するだけで十分です。 2. 機能リセットおよび破壊リセット後のSRAM保持 1. このSRAMの挙動がS32K312上で予想されるものか、またSRAMテスト領域が破壊的なリセットを経ても保持されるメモリ領域にある可能性があるのか、明確にしていただけますか? しかし、そうあるべきではありません。破壊的なリセットイベントの後、すべてのSRAMコンテンツは失われます。 直接的なソフトウェア破壊リセットをどのようにテストしているのか教えてもらえますか? プロジェクトで Power_Ip_PerformReset() API を使用している場合、それは破壊的ではなく機能的なリセットとして構成されています。 Julin_AragnM_0-1788891886849.pngJulin_AragnM_0-1788891886849.pngJulin_AragnM_0-1788891886849.pngJulin_AragnM_0-1788891886849.pngJulin_AragnM_0-1788891886849.pngJulin_AragnM_0-1788891886849.png 実は、値を保存してUARTで共有してテストしました。FRDM-A-S32K312はSW2で機能リセットを発行し、FRETは15に設定され、15回のSW機能リセット後にMCU_MC_RGM_FRE_RESETが生成されるのが見えます。これはRTD 6.0.0で発生しています。以下のログをご覧ください。 [RESET] Reason : MCU_F_EXR_RESET (RGM_FES F_FR0) [RESET] FRE Counter: 0 [RESET] Reason : MCU_SW_FUNC_RESET (RGM_FES F_FR29) [RESET] FRE Counter: 1 [RESET] Reason : MCU_SW_FUNC_RESET (RGM_FES F_FR29) [RESET] FRE Counter: 2 [RESET] Reason : MCU_SW_DEST_RESET (RGM_DES F_DR29) [RESET] FRE Counter: 0 [RESET] Reason : MCU_SW_FUNC_RESET (RGM_FES F_FR29) [RESET] FRE Counter: 1 [RESET] Reason : MCU_SW_FUNC_RESET (RGM_FES F_FR29) [RESET] FRE Counter: 2 [RESET] Reason : MCU_SW_FUNC_RESET (RGM_FES F_FR29) [RESET] FRE Counter: 3 [RESET] Reason : MCU_SW_FUNC_RESET (RGM_FES F_FR29) [RESET] FRE Counter: 4 [RESET] Reason : MCU_SW_FUNC_RESET (RGM_FES F_FR29) [RESET] FRE Counter: 5 [RESET] Reason : MCU_SW_FUNC_RESET (RGM_FES F_FR29) [RESET] FRE Counter: 6 [RESET] Reason : MCU_SW_FUNC_RESET (RGM_FES F_FR29) [RESET] FRE Counter: 7 [RESET] Reason : MCU_SW_FUNC_RESET (RGM_FES F_FR29) [RESET] FRE Counter: 8 [RESET] Reason : MCU_SW_FUNC_RESET (RGM_FES F_FR29) [RESET] FRE Counter: 9 [RESET] Reason : MCU_SW_FUNC_RESET (RGM_FES F_FR29) [RESET] FRE Counter: 10 [RESET] Reason : MCU_SW_FUNC_RESET (RGM_FES F_FR29) [RESET] FRE Counter: 11 [RESET] Reason : MCU_SW_FUNC_RESET (RGM_FES F_FR29) [RESET] FRE Counter: 12 [RESET] Reason : MCU_SW_FUNC_RESET (RGM_FES F_FR29) [RESET] FRE Counter: 13 [RESET] Reason : MCU_SW_FUNC_RESET (RGM_FES F_FR29) [RESET] FRE Counter: 14 [RESET] Reason : MCU_MC_RGM_FRE_RESET (RGM_DES F_DR6) [RESET] FRE Counter: 0 [RESET] Reason : MCU_SW_FUNC_RESET (RGM_FES F_FR29) [RESET] FRE Counter: 1 RTD 7.0.1では、あなたが言及したのと同じ挙動が見えます(FREが破壊リセットを主張しなかったり、デバッグャが切断されたりするなど): [RESET] Reason : MCU_SW_DEST_RESET (RGM_DES F_DR29) [RESET] FRE Counter: 0 [RESET] Reason : MCU_SW_DEST_RESET (RGM_DES F_DR29) [RESET] FRE Counter: 0 [RESET] Reason : MCU_SW_FUNC_RESET (RGM_FES F_FR29) [RESET] FRE Counter: 1 [RESET] Reason : MCU_SW_FUNC_RESET (RGM_FES F_FR29) [RESET] FRE Counter: 2 [RESET] Reason : MCU_SW_FUNC_RESET (RGM_FES F_FR29) [RESET] FRE Counter: 3 [RESET] Reason : MCU_SW_FUNC_RESET (RGM_FES F_FR29) [RESET] FRE Counter: 4 [RESET] Reason : MCU_SW_FUNC_RESET (RGM_FES F_FR29) [RESET] FRE Counter: 5 [RESET] Reason : MCU_SW_FUNC_RESET (RGM_FES F_FR29) [RESET] FRE Counter: 6 [RESET] Reason : MCU_SW_FUNC_RESET (RGM_FES F_FR29) [RESET] FRE Counter: 7 [RESET] Reason : MCU_SW_FUNC_RESET (RGM_FES F_FR29) [RESET] FRE Counter: 8 [RESET] Reason : MCU_SW_FUNC_RESET (RGM_FES F_FR29) [RESET] FRE Counter: 9 [RESET] Reason : MCU_SW_FUNC_RESET (RGM_FES F_FR29) [RESET] FRE Counter: 10 [RESET] Reason : MCU_SW_FUNC_RESET (RGM_FES F_FR29) [RESET] FRE Counter: 11 [RESET] Reason : MCU_SW_FUNC_RESET (RGM_FES F_FR29) [RESET] FRE Counter: 12 [RESET] Reason : MCU_SW_FUNC_RESET (RGM_FES F_FR29) [RESET] FRE Counter: 13 [RESET] Reason : MCU_SW_FUNC_RESET (RGM_FES F_FR29) [RESET] FRE Counter: 14 [RESET] Reason : MCU_SW_FUNC_RESET (RGM_FES F_FR29) [RESET] FRE Counter: 0 これにより、RTD 6.0.0とRTD 7.0.1の間にPower ドライバにいくつかの違いがあり、それがこれらの症状の原因になっているのではないかと考えています。これが設定の問題なのかバグなのか特定できていません。分析の時間をいただき、必要なら社内チームに連絡してください。 よろしくお願いします、 ジュリアン Re: S32K312: SWT0 Functional Reset Escalation, Destructive Reset Status and SRAM Retention こんにちは、ジュリアンさん。 ご説明いただきありがとうございます。 ご要望通り、現在使用している ソフトウェアの破壊リセットテストコード/プロジェクト を含むZIPファイルを添付しました。 FRET エスカレーションが RTD 6.0.0で正しく動作するとおっしゃっていましたが、テストで使った RTD 6.0.0の動作するコードやプロジェクト を共有していただけますか? あなたのRTD 6.0.0の動作コードを参考に、私のRTD 7.0.1プロジェクトと比較して、動作の違いを理解したいと考えています。 また、 RTD 6.0.0とRTD 7.0.1の間でパワードライバーに違いや問題がある可能性があるとおっしゃっていましたが、分析が終わったら RTD 7.0.1 の問題についての調査結果を教えていただけますか? 再開まで今しばらくお待ちください。 よろしくお願いします、 シャリフ Re: S32K312: SWT0 Functional Reset Escalation, Destructive Reset Status and SRAM Retention こんにちは、@Sharif417 さん。 Power_Ipドライバーのソースコードを調べたところ、Power_Ip_MC_RGM_GetResetReason()APIで機能リセットエスカレーションカウンタの修正が適用されているのが見えました。そこに3つ目の節が追加され、DESがビットを設定していてFRETレジスタが現在非ゼロを読み取っている場合にFESも入ります。 RTD 6.0.0: /* If the fields of Destructive Event Status Register (DES) are set then the status of FES register must be ignored */ if (((uint32)0U == ActiveValue) || (MCU_POWER_ON_RESET == ResetReason)) { ... } RTD 7.0.1: /* If the fields of Destructive Event Status Register (DES) are set then the status of FES register must be ignored */ /* If functional reset escalation to destructive reset is disabled, then the status of FES register must be ignored if the fields of Destructive Event Status Register (DES) other than DES[F_POR] are set. */ /* If functional reset escalation to destructive reset is enabled and if the fields of Destructive Event Status Register (DES), other than DES[F_POR], are set, then based on these fields user should check if the cause of the destructive reset was due to functional reset escalation or if it was triggered directly by a destructive reset source, in which case FES needs to be ignored */ if (((uint32)0U == ActiveValue) || (MCU_POWER_ON_RESET == ResetReason) || (((uint32)0U != DesResetStatus) && ((uint32)0U != Power_Ip_pxMC_RGM->FRET))) { ... } これがFESフラグが上書きされる理由です。私の理解が正しければ、ハードウェアは破壊的リセットを正しく実行しているにもかかわらず、リセットモジュールは代わりに機能的リセットを報告している。これは、15回目の機能リセット直後のIP_MC_RGM->DESレジスタを読むことで確認できます: Julin_AragnM_0-1788976448272.pngJulin_AragnM_0-1788976448272.pngJulin_AragnM_0-1788976448272.pngJulin_AragnM_0-1788976448272.png 有効な方法は、3番目の節を変更して、MCU_MC_RGM_FRE_RESETイベントがすでに起こっているかどうかを確認することかもしれません。 /* ----------------------------------------------------------------------- * Enter the FES block if: * a) DES is empty (no destructive reset logged), OR * b) DES has only the Power-On Reset bit, OR * c) DES has bits set AND FRE escalation is configured (FRET != 0) * AND the DES reason is NOT already MCU_MC_RGM_FRE_RESET * ----------------------------------------------------------------------- */ if (((uint32)0U == ActiveValue) || (MCU_POWER_ON_RESET == ResetReason) || (((uint32)0U != DesResetStatus) && ((uint32)0U != Power_Ip_pxMC_RGM->FRET) && (MCU_MC_RGM_FRE_RESET != ResetReason))) RTDドライバの修正はサポートされていないことを覚えておいてください。正しい方法は、SWチームからの公式修正を待つことです。この件については社内チームに報告し、もしあれば彼らからのフィードバックも伝えます。この問題をご指摘いただきありがとうございます。 最後に、あなたのプロジェクトについてですが、Power_Ip_PerformReset()を通じてリセットを発行しているのが見えます。先ほども述べた通り、リセット設定内で「機能リセット」が設定されており、ソフトウェア破壊リセットを発行するには「破壊的リセット」に変更する必要があります: Julin_AragnM_2-1788976691375.pngJulin_AragnM_2-1788976691375.pngJulin_AragnM_2-1788976691375.pngJulin_AragnM_2-1788976691375.png または、ModeSettingConf構造体を追加し、DEST_RESETを選択して、代わりにPower_Ip_SetMode()を呼び出します。 Julin_AragnM_3-1788976695121.pngJulin_AragnM_3-1788976695121.pngJulin_AragnM_3-1788976695121.pngJulin_AragnM_3-1788976695121.png よろしくお願いします、 ジュリアン Re: S32K312: SWT0 Functional Reset Escalation, Destructive Reset Status and SRAM Retention こんにちは、ジュリアンさん。 あなたの提案に基づき、Power_Ip_GetResetReason()だけに頼るのではなく、MC_RGM DESレジスタとFESレジスタを直接読み取ることで追加のテストを実施しました。 このテストでは、リセットタイプをFRET = 15のソフトウェア機能リセットとして設定しました。ソフトウェアの機能リセットのたびに、FRECカウンターは増加します。15回目のソフトウェア機能リセット後、main()のClock_Ip_Init()の前にブレークポイントを置き、MC_RGMレジスタを直接読み込みました。 volatile uint32_t regValueDes = 0U;volatile uint32_t regValueFes = 0U; regValueDes = IP_MC_RGM->DES;regValueFes = IP_MC_RGM->FES; gVar = Power_Ip_GetResetReason(); 完全なテストコードは以下のとおりです。 int main(void) { volatile uint32_t regValueDes = 0U; volatile uint32_t regValueFes = 0U; regValueDes = IP_MC_RGM->DES; regValueFes = IP_MC_RGM->FES; gVar = Power_Ip_GetResetReason(); Clock_Ip_Init(&Clock_Ip_aClockConfig[0]); Siul2_Port_Ip_Init( NUM_OF_CONFIGURED_PINS_PortContainer_0_BOARD_InitPeripherals, g_pin_mux_000InitConfigArr_PortContainer_0_BOARD_InitPeripherals); Power_Ip_Init(&Power_Ip_HwIPsConfigPB); gVar = Power_Ip_GetResetReason(); /* Disable recovery mode */ IP_DCM_GPR->DCMRWP1 |= (3 << 22); for (count = 0; count < 10125000; count++); Power_Ip_PerformReset(&Power_Ip_HwIPsConfigPB); } 15回目の機能リセット後、Clock_Ip_Init()の前にIP_MC_RGM->DESを直接読み取ります。しかし、DES[MC_RGM_FRE] = 1 は観測されませんでした。DESの値は0のままですが、FESにはリセット状態(私のテストでは0x20000001)が格納されます。 この観察結果に基づくと、問題はPower_Ip_MC_RGM_GetResetReason()やリセット理由の報告だけに限定されない可能性があると考えられます。クロックと電源の初期化前にMC_RGM DESレジスタを直接読み取っているため、破壊的なエスカレーションが発生した場合はDES[MC_RGM_FRE]がFRETエスカレーションを示すと予想していました。 そこで、15回目の機能リセット後にMC_RGMハードウェアレベルでFRETのエスカレーション自体が起きているのか確認していただけますか?もしこの時点で破壊的なエスカレーションが予想されるなら、なぜIP_MC_RGM->DESが0のままなのか教えていただけますか? また、あなたが指摘したPower_Ip_MC_RGM_GetResetReason()の問題に加えて、FREC/FRETのエスカレーション機構自体に関連する追加のRTD 7.0.1の問題や設定があるかどうかも確認していただけますか? この問題の調査にサポートいただき、ありがとうございます。 Re: S32K312: SWT0 Functional Reset Escalation, Destructive Reset Status and SRAM Retention こんにちは、 @Sharif417 さん。 破壊的なリセットは確かに起きていると信じています。以下のテスト手順に従ってください: FRET=1に設定し、機能リセットごとに機能リセットのエスカレーションが発生します。 2つの変数(1つはDESレジスタ用、もう1つはFESレジスタ用)と、変数を読み取る前にコアを停止するためのwhile()ループを宣言します。 int main(void) { volatile uint8_t debug = 1; while(debug); volatile uint32_t regValueDes = 0; volatile uint32_t regValueFes = 0; regValueDes = IP_MC_RGM -> DES; regValueFes = IP_MC_RGM -> FES; ... }​ コードでMCUをフラッシュした後、デバッグ変数を0に変更してプログラムが実行できるようにし、デバッガを切断します。 機能リセットを実行してください(あなたのプログラムや私が示した例を使ってください)。 「Attached to Running Target(走行中のターゲットにアタッチ)」を選択してMCUに接続します。 実行を一時停止し、デバッグ変数を0に設定し、DESおよびFES変数を読み取ります。 Julin_AragnM_0-1789079229563.pngJulin_AragnM_0-1789079229563.png この方法では、機能リセットを生成し、接続した後、機能リセットエスカレーション手順に関連するDES[MC_RGM_FRE]ビットが見えます。 なぜDES->0を読んでいるのか分かりませんが、デバッガが接続されたままであれば、リセットシーケンスに干渉しリセットが発生するのではないかと思います。私が共有した手順でテストしてみて、DESが実際に設定されているかどうかを確認することをお勧めします。 状況を随時お知らせください。 よろしくお願いします、 ジュリアン
查看全文
CircO2 Nitric Oxide Tablets Review: A Complete Buyer's Guide CircO2 is a nitric oxide support supplement made by Advanced Bionutritionals. Unlike a lot of pills you swallow with water, CircO2 comes in a quick-dissolving tablet (sometimes called a lozenge) that melts in your mouth. This is one of the things that makes it stand out from other CircO2 Tablets on the market. The main idea behind CircO2 Oxygen Booster and Circulation Support is simple: help your body make more nitric oxide, so your blood vessels can relax and widen. When that happens, blood (and the oxygen it carries) can move more freely through your body. That can mean more energy, warmer hands and feet, and better stamina during the day.   Re: CircO2 Nitric Oxide Tablets Review: A Complete Buyer's Guide CircO2 is a nitric oxide support supplement in USA, Canada, UK, Australia and New Zealand from Advanced Bionutritionals designed to promote healthy circulation. Unlike traditional supplements that you swallow with water, ORIGINAL CircO2 comes as a fast-dissolving tablet, or lozenge, that melts in your mouth. This convenient format helps set it apart from many other circulation-support tablets. The goal of CircO2 Oxygen Booster and Circulation Support is to support the body’s natural production of nitric oxide. Nitric oxide helps blood vessels relax and expand, which may allow blood and oxygen to circulate more efficiently throughout the body. By supporting healthy blood flow, CircO2 may help promote everyday energy, stamina, and circulation, including helping hands and feet feel warmer.
查看全文
S32k344 MBIST LBIST 我正在 Green Hills 的一个项目中实施 S32k344 BIST。由于我不使用 Tresos 或 NXP DS,所以我使用的是源代码形式的 SW32K3_SPD_1.0.6_D2512。我能够导入大部分 bist 函数,但有一些我不确定的定义(到处都找不到它们)。请问有人能回答以下问题吗? 1. 当 S32k344 处于锁定步进模式时,我可以运行 LBIST MBIST 吗? 2. 我通过检查代码猜测以下定义是否正确? #define BIST_MBIST_0 1U #define BIST_MBIST_1 2U #define BIST_MBIST_2 3U #define BIST_MBIST_3 4U #define BIST_MBIST_4 5U #define BIST_MBIST_5 6U #define BIST_MBIST_6 7U #define BIST_MBIST_7 8U #define BIST_MBIST_8 9U #define BIST_MBIST_9 10U #define BIST_MBIST_10 11U #define BIST_LBIST_0 0U 我使用的配置数据如下: static const BIST_CHANNEL_CONFIG_TYPE BistConfig[BIST_SAFETYBOOTCFG_NB] = { { (BIST_CHANNEL_TYPE)BIST_MBIST_0, (BIST_CONTROL_TYPE)((0x80100000U) | BIST_MBIST_PTR_VAL(BIST_MBIST_1)) }, { (BIST_CHANNEL_TYPE)BIST_MBIST_1, (BIST_CONTROL_TYPE)((0x80100000U) | BIST_MBIST_PTR_VAL(BIST_MBIST_2)) }, { (BIST_CHANNEL_TYPE)BIST_MBIST_2, (BIST_CONTROL_TYPE)((0x80100000U) | BIST_MBIST_PTR_VAL(BIST_MBIST_3)) }, { (BIST_CHANNEL_TYPE)BIST_MBIST_3, (BIST_CONTROL_TYPE)((0x80100000U) | BIST_MBIST_PTR_VAL(BIST_MBIST_4)) }, { (BIST_CHANNEL_TYPE)BIST_MBIST_4, (BIST_CONTROL_TYPE)((0x80100000U) | BIST_MBIST_PTR_VAL(BIST_MBIST_5)) }, { (BIST_CHANNEL_TYPE)BIST_MBIST_5, (BIST_CONTROL_TYPE)((0x80100000U) | BIST_MBIST_PTR_VAL(BIST_MBIST_6)) }, { (BIST_CHANNEL_TYPE)BIST_MBIST_6, (BIST_CONTROL_TYPE)((0x80100000U) | BIST_MBIST_PTR_VAL(BIST_MBIST_7)) }, { (BIST_CHANNEL_TYPE)BIST_MBIST_7, (BIST_CONTROL_TYPE)((0x80100000U) | BIST_MBIST_PTR_VAL(BIST_MBIST_8)) }, { (BIST_CHANNEL_TYPE)BIST_MBIST_8, (BIST_CONTROL_TYPE)((0x80100000U) | BIST_MBIST_PTR_VAL(BIST_MBIST_9)) }, //#endif { (BIST_CHANNEL_TYPE)BIST_MBIST_9, (BIST_CONTROL_TYPE)((0x80100000U) | BIST_MBIST_PTR_VAL(BIST_MBIST_10)) }, { (BIST_CHANNEL_TYPE)BIST_MBIST_10, (BIST_CONTROL_TYPE)(0x00100000U) }, { (BIST_CHANNEL_TYPE)BIST_LBIST_0, (BIST_CONTROL_TYPE)((0x00001108U) | BIST_LBIST_PTR_VAL(BIST_NIL)) } }; Re: S32k344 MBIST LBIST 你好, 1. 当 S32k344 处于锁定步进模式时,我可以运行 LBIST MBIST 吗? 是的。S32K344 锁步架构不会阻止 STCU2 LBIST/MBIST 的执行。BIST 机制是设备功能安全基础设施的一部分,旨在测试由 STCU2 管理的逻辑和存储器。The S32K3 功能安全 Manual explicitly lists both lockstep and STCU2 LBIST/MBIST as safety mechanisms of the 设备. 2. 我通过检查代码猜测以下定义是否正确? 对于 S32K344 来说,这些数值基本正确,但从功能安全角度来看,在功能安全启动配置中包含 MBIST_10 (HSE_ROM) 并非必需,建议直接使用经过验证的 SPD 配置。 顺祝商祺! Peter Re: S32k344 MBIST LBIST 彼得 非常感谢您的回复。我这几天一直被BIST测试问题困扰着。我正在使用 S32k344 白板进行测试,代码是用 Green Hills Multi IDE rev 8.1 版本 的。安全靴自检未通过。我确信核心和外设都满足最大时钟频率要求。我的核心时钟频率为 160MHz,来自外部晶振 16MHz 和 PLL,AIPS_PLAT_CLK 为 80MHz,AIPS_SLOW_CLK 为 40MHz,DCM_CLK 为 40MHz,LBIST_CLK 为 40MHz,QSPI_MEM_CLK 为 160MHz。当设备从 BIST 运行复位时,出现以下错误:DES 寄存器为 0x00408175,一些保留位被设置,FES 寄存器为 0x2000(这没有意义)。请问您能否回答以下问题? 1. 对于上面提到的所有时钟信号,是否应该通过 MC_CGM->MUX_0_DC_x 寄存器启用它们?我正在获得 信息相互矛盾,目前这些功能已启用。 2. 在参考手册的 STCU2 章节中,有这样一段话:“在 EMAC 时间戳存储器上运行 MBIST 时,应适当配置 MC_CGM.MUX_9_DC_0[DIV],以确保 EMAC_CLK_TS 至少是 AIPS_SLOW_CLK 频率的 1.5 倍。”那是不是意味着我必须配置时钟并在 MC_CGM->MUX_9_DC_0 寄存器中启用它? 3. 如果我想查看 SW32K3_SPD_1.0.6_D2512 软件包中的示例代码 S32_SPD_Demo,我猜我需要安装最新的 NXP Design Studio,将 spd zip 文件作为更新站点导入,还需要 RTD 软件包,是这样吗? 4. 我认为 MBIST 10 是 HSE_RAMS,MBIST 11 是 HSE_ROMS,请参阅 SPD 文档文件夹中的下表。 MBIST BIST ID BIST实例名称 RESET 功能域 安全靴 功能安全诊断 0 SYS0_RAMS 主要 ü ü 1 SYS1_RAMS 主要 ü ü 2 DMA_TCD_RAM 主要 ü ü 3 CM7_0_TOP 主要 ü ü 4 CM7_1_TOP 主要 ü ü 5 FLEX_CAN_RAMS 主要 ü ü 6 QSPI_PERI_RAMS 主要 ü ü 7 EMAC_TSN_RAM 主要 ü ü 8 EMAC_RAMS 主要 ü ü 9 b03_ETF_RAMS 主要 ü ü 10 HSE_RAMS 主要 ü ü 11 HSE_ROMS 主要   ü Re: S32k344 MBIST LBIST 我的问题有了新的进展,在我启用 STCU_RUNSW_REG 中的第 8 位和第 9 位以使用 PLL 之后,我一直看到 DES 寄存器为 0x11,FES 寄存器为 0x10。bist_get_exec_status(BIST_SAFETYBOOT_CFG) 返回值为 NOT RUN (0x03)。BIST ERR_STAT 寄存器中没有任何内容,END 标志也没有设置。FCCU NCF_S0 寄存器中的第 2 位已设置。BIST 似乎没有启动,但我确实看到了 RESET。我通过写入另一侧银行的闪存来捕获寄存器设置。 Re: S32k344 MBIST LBIST 我检查了所有可能的时钟,我相信它们是正确的。我还将寄存器中的配置数据与 NXP studio spd 示例项目中的值进行了比较,它们也是正确的。一条新信息。系统从 BIST RESET 后,我在 DCMROD3 寄存器中看到值 0x18。我该如何解决这个错误?谢谢。 XRen_Parker_0-1788544110794.pngXRen_Parker_0-1788544110794.pngXRen_Parker_0-1788544110794.pngXRen_Parker_0-1788544110794.pngXRen_Parker_0-1788544110794.pngXRen_Parker_0-1788544110794.png Re: S32k344 MBIST LBIST 你好, STCU 自检序列正在进入并到达 ST_DONE RESET 阶段。但是,STCU 还报告了一个不可恢复的故障 (STCU_URF),这就解释了为什么 SAF BIST 驱动程序随后报告 BIST_NORUN。因此,问题似乎是 STCU 执行/配置失败,而不是 BIST 从未触发信号的情况。 在 S32K3 上,同时看到破坏性复位和功能性复位指示通常表明您正在查看复位历史记录,而不是当前的复位源。 既然你在移植软件,我建议先从仅进行 MBIST 测试开始,看看它是否能从 PLL 源通过。 另外,我建议你再检查一下测试的时钟设置。 顺祝商祺! Peter Re: S32k344 MBIST LBIST 你好, 在 S32K344 上,RCCU 报告锁步不匹配,并且当连接到调试器时,经常会出现与 RCCU 相关的故障,而这些故障在独立执行中永远不会发生。 如果您按照示例中的设置进行操作,您将看到完整的 BIST(内置自测试)。 示例已测试,默认情况下完全可用。 但是您的端口报告 URF 故障,这说明并非所有部件都相同。 查阅STCU文档,用户可以设置指向测试的指针。 54.9.4 STCU2 配置 (CFG) petervlna_0-1788766597312.pngpetervlna_0-1788766597312.pngpetervlna_0-1788766597312.pngpetervlna_0-1788766597312.png 您可以先尝试减少测试用例,然后慢慢添加更多测试用例。 在 MBIST 和 LBIST 控制寄存器中,您可以设置哪个测试将是最后一个: petervlna_1-1788766735386.pngpetervlna_1-1788766735386.pngpetervlna_1-1788766735386.pngpetervlna_1-1788766735386.png 例如,通过指向 CFG 寄存器中的某个位置,您可以执行单个 MBIST 分区: petervlna_2-1788766853581.pngpetervlna_2-1788766853581.pngpetervlna_2-1788766853581.pngpetervlna_2-1788766853581.png petervlna_3-1788766973925.pngpetervlna_3-1788766973925.pngpetervlna_3-1788766973925.pngpetervlna_3-1788766973925.png 顺祝商祺! Peter Re: S32k344 MBIST LBIST 我尝试按顺序运行 mbist,也尝试过单独运行 mbist 测试 ID。结果相同,未观察到新的状态。能否在触发之前确认以下用于安全启动的 SCU2 寄存器设置?谢谢。 XRen_Parker_0-1788899133217.pngXRen_Parker_0-1788899133217.pngXRen_Parker_0-1788899133217.png Re: S32k344 MBIST LBIST 这是为社区中在 S32k344 微控制器中实现 LBIST/MBIST 时遇到困难的人们准备的。经过数日毫无进展后,我终于看到测试通过了。我通过对 SPD 驱动程序 1.06 进行自定义移植实现了这一点。驱动程序代码运行正常,只是需要将故障配置为不可恢复故障。以下是需要配置的时钟,如果其中任何一个没有正确设置,测试将失败,状态为 BIST_NORUN(0x03),因为测试序列是并发运行的,看不到其他状态,也没有设置完成位。 1. 配置 FXOSC 模块 CTRL 寄存器以使用外部振荡器或晶体,这是获得 160MHz(S32k344 的最大频率)的唯一方法。 2. 配置 PLL 电路的 PLLDIG 模块,通过配置 PLLDV 寄存器中的 rdiv、mfi 和 odiv2 位,确保输出最大频率。 3. 按照参考手册中的步骤,设置 MC_CGM_MUX_x 寄存器,为 core_clk 和 emac_clk 切换 PLL 时钟。 4. 配置 MC_CGM-MUX_0 和 MC_CGM-MUX_9 寄存器以获取以下时钟信号。 AIPS_PLAT_CLK 设置为 80 MHz AIPS_SLOW_CLK 设置为 40 MHz HSE_CLK 设置为 80 MHz DCM_CLK 设置为 40 MHz LBIST_CLK 设置为 40MHz QSPI_MEM_CLK 设置为 160MHz EMAC_CLK 设置为 80MHz 注意:不要设置 RUNSW 寄存器中的第 8 位和第 9 位,如果设置了它们,测试将失败。SPD驱动程序代码中没有实现这一点。我之所以提到这一点,是因为参考手册中存在相互矛盾的信息。
查看全文
PCF85263AT/AJ -- Minutes value displayed on the screen is showing an arbitrary value As part of the code migration task, we are facing an issue where the BSF flag is being set. Due to the BSF flag being set, the EMON bit in the Minutes register is also getting set. As a result, the Minutes value displayed on the screen is showing an arbitrary value. Additionally, the Year value is not being saved correctly and continuously shows 2000 even after setting the RTC date and time. I tried to test the condition mentioned below, but the problem still persists.  I set the flag register (0x43) to 0x00 and read it immediately; it showed 0x00. However, when I read the register again after 3 seconds, the value was set again to 0x08 (or 0x00).   Re: PCF85263AT/AJ -- Minutes value displayed on the screen is showing an arbitrary value Hello Ris_eek Good day! The BSF flag is not simply failing to clear. Instead, the RTC is detecting a new battery switch-over event and setting BSF again. According to the datasheet, BSF is set whenever the battery switch-over logic detects a power transition event The fact that it re-asserts after ~3 seconds means the VDD supply is repeatedly dropping below the battery switch-over threshold causing repeated VDD>VBAT>VDD transitions. Each transition re-sets the BSF. RafaR_0-1788887610951.pngRafaR_0-1788887610951.pngRafaR_0-1788887610951.pngRafaR_0-1788887610951.pngRafaR_0-1788887610951.png This constant voltage fluctuation causes the RTC to constantly reset, which is why it only shows the year 2000. I recommend checking if there's a problem with the power supply signal. I hope this information has helped you, please let me know if you need help with anything else. Have a great day and best of luck. Re: PCF85263AT/AJ -- Minutes value displayed on the screen is showing an arbitrary value Dear Rafar; Thanks for your mail.    In the hardware, the VDD (4.93 VDC) and VBAT (3.02 VDC) voltages are constant. As a precaution against voltage fluctuations, a 100 nF capacitor is connected across the battery supply. The Battery Switch Register (26h) is set to 0x00. Therefore, the BSM (Battery Switch Mode) is configured to switch at the Vth level. The Vth level is 1.5 V because the BSTH (Battery Switch Threshold Voltage) bit is set to 0. As per Figure 25, referenced in previous email: When VDD < Vth, the BSF is set to 1. When VDD > VBAT, the BSF should be cleared. However, under the power-ON condition, the measured voltage is VDD = 4.93 VDC, which is greater than VBAT = 3.02 V. Even then, the BSF is not cleared. Could you please clarify why the BSF remains set even though VDD is greater than VBAT? Re: PCF85263AT/AJ -- Minutes value displayed on the screen is showing an arbitrary value Hello Ris_eek Good day! The datasheet says the following: The assertion of the flag BSF (register Flags, address 2Bh) can be used to generate an interrupt at pins INTA and INTB. The interrupt can be generated as a pulsed signal or alternatively as a permanently active signal, which follows the condition of bit BSF. BSF remains set until cleared by command. The reference image I sent also indicates the following: "cleared via interface." It’s not automatically, you have to cleared I hope this information has helped you, please let me know if you need help with anything else. Have a great day and best of luck. Re: PCF85263AT/AJ -- Minutes value displayed on the screen is showing an arbitrary value Okay RafaR Thank you for this. But the BSF flag is cleared in software, but after some time, it is set again, as described in my previous post.
查看全文
i.MX8M Plus 上的 U-Boot 进行 SWUpdate A/B OTA 更新 您好,NXP团队: 我正在使用以下方法在i.MX8M Plus LPDDR4 EVK上实现 OTA: 约克托·沃诺斯 Linux 6.18.20 U-Boot 2026.04 SWUpdate 2026.05.1 当前进展 SWUpdate 已成功集成到 Yocto 中。 已成功生成 .swu 文件代码包,软件包. SWUpdate软件包安装正常。 硬件兼容性检查正在进行中。 使用 SWUpdate 成功更新了 /etc/ota-version。 原始文件处理程序正在运行。 现在我想实现生产级别的 A/B OTA,具备自动回滚和签名更新功能。 问题 请问NXP推荐的以下解决方案是什么? A/B 根文件系统分区布局。 基于 U-Boot 启动计数/启动限制的回滚。 SWUpdate 与 U-Boot 环境集成。 更正 fw_env.config / libubootenv 配置。 签名 .swu包裹核实。 防回滚/版本保护。 安全启动 + 软件更新集成。 目前,OTA 更新已完成,但 SWUpdate 报告: Cannot initialize environment from /etc/fw_env.config Cannot persistently store update state NXP是否有关于i.MX8M Plus上SWUpdate + A/B + U-Boot回滚 + 签名OTA的参考设计、应用笔记或示例? 谢谢。 i.MX 8M | i.MX 8M Mini | i.MX 8M Nano Yocto Project Re: SWUpdate A/B OTA with U-Boot on i.MX8M Plus 你好, 我们不提供开箱即用的标准 EVK A/B 更新框架。A/B 更新、回滚策略和断电故障保护启动选择是系统级功能,您必须使用 U-Boot + SWUpdate 来实现。最接近的参考文献有: AN12900 - 使用 CAAM 和 Mender 或 SWUpdate 的 Linux 安全 OTA 原型。 AN13872 - 启用 SWUpdate。 meta-swupdate-imx - 带有 SWUpdate 的 NXP Yocto 层。 顺祝商祺! Re: SWUpdate A/B OTA with U-Boot on i.MX8M Plus 嘿vp1 , 虽然我没有确切的答案,但我希望您知道 Torizon 现在支持任何 i。MX SoC。它已在全球许多关键的 i.MX8MPlus 产品中部署(主要在 Toradex 系统模块上)。它确实具有高度可靠的OTA升级功能(默认是OSTree,但可以更改)。 它包含开箱即用的安全启动、防回滚、漏洞管理(符合欧盟 CRA 标准)等功能。 该操作系统是免费开源的;如果您需要帮助,我们很乐意提供帮助。如果您想在 i.MX8M Plus LPDDR4 EVK 或您自己的硬件上进行尝试,请联系我们。 www.torizon.io 不好意思打个广告,我在Torizon工作,觉得这个话题可能跟我相关。
查看全文
Audifort评测:它真的能一夜之间消除耳鸣吗? Audifort评测:它真的能一夜之间消除耳鸣吗? 如果你每天都要忍受耳朵里持续不断的铃声、嗡嗡声或咔哒声,你就知道寻求缓解这种痛苦有多么令人绝望。在网上寻找解决方案时,您可能会遇到诸如液体营养滴剂之类的铺天盖地的广告。 奥迪福特 这暗示着可以立即见效或一夜之间缓解耳鸣。 简而言之,答案是否定的:Audifort 并不能在一夜之间消除耳鸣。 没有任何口服补品或天然滴剂能在 24 小时内立即治愈慢性耳鸣或重建受损的听觉神经。 但这并不意味着该公式毫无用处。如果将 Audifort 视为一种天然膳食补充剂而不是灵丹妙药,那么它提供的营养成分可以滋养内耳血管,并随着时间的推移镇静过度活跃的神经信号。 在此 Audifort 评测,我们超越销售营销,分析滴剂的实际作用原理、核心成分、合理的预期时间、潜在的副作用,以及如何避免虚假的在线信息。
查看全文
CircO2 一氧化氮片剂评测:完整购买指南 CircO2 是由 Advanced Bionutritionals 公司生产的一氧化氮支持补充剂。与许多需要用水吞服的药片不同,CircO2 采用速溶片(有时称为锭剂)的形式,可在口中融化。这是它与其他市面上的 CircO2 片剂相比脱颖而出的原因之一。 CircO2 氧气增强剂和循环支持剂背后的主要理念很简单:帮助你的身体产生更多的一氧化氮,从而使你的血管放松和扩张。这时,血液(以及血液携带的氧气)就能更自由地在体内流动。这意味着白天精力更充沛、手脚更温暖、耐力更好。   Re: CircO2 Nitric Oxide Tablets Review: A Complete Buyer's Guide CircO2 是 Advanced Bionutritionals 公司在美国、加拿大、英国、澳大利亚和新西兰销售的一种一氧化氮支持补充剂,旨在促进健康的血液循环。与需要用水吞服的传统补充剂不同, ORIGINAL CircO2是一种速溶片剂或锭剂,可在口中融化。这种便捷的形式使其有别于许多其他促进血液循环的片剂。 CircO2 氧气增强剂和循环支持剂的目标是支持人体自然产生一氧化氮。一氧化氮有助于血管放松和扩张,从而使血液和氧气更有效地在体内循环。CircO2 通过促进健康的血液流动,有助于提升日常精力、耐力和血液循环,包括帮助手脚感觉更温暖。
查看全文