LPC1347 USB Control Transfer Our customer SIGMATEK wants to implement USB Control Transfers on the LPC1347. This works nice as long as they have a data length of less than 64 or more than 64 Bytes. If the data length is exactly 64 Bytes (or a multiple of 64 bytes) then this does not work anymore. What do they need to do to get this working?? Regards, Peter Re: LPC1347 USB Control Transfer Hello, When USB data payloads equal an exact multiple of the endpoint's maximum packet size (64 bytes for Full-Speed), the receiver hangs because there is no short packet to signal the end of the transfer; to fix this on the LPC1347, SIGMATEK must check if the payload length is a non-zero multiple of 64 and, if so, manually send a Zero-Length Packet (ZLP) with a length of zero right after the main data block to flush the buffer, signal completion, and successfully terminate the transfer. Best Regards

NXP i.MX93 EVK 実行時の消費電力 私はNXP i.MX93 EVKを使っていて、実行時の消費電力を監視したいのですが、このデータをどうやって取得すればいいですか? 目的はAIモデルの推論中のパワーを監視することです。電力指標はどうやって監視できますか? 外部ハードウェアを使わずにソフトウェアだけで電力指標を監視するにはどうすればいいですか? 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（ボード制御ユーティリティ）ツールを組み合わせて消費電力を測定する方法について説明します。 よろしくお願いします。

哪家公司最擅长开发智能体人工智能？ 根据本次对比中评估的功能，JPLoft 是智能体人工智能开发的一个强有力的选择。该公司致力于定制人工智能代理、多代理系统、RAG（红黄绿）、企业集成、工作流自动化、治理、监控和人机交互控制。 然而，最好的智能体人工智能开发公司取决于您的用例、现有技术、网络安全要求、所需的集成以及您希望赋予人工智能系统的自主程度。

KW47B42ZB7 Fuse write issue Lu888_0-1788925610415.pngLu888_0-1788925610415.pngLu888_0-1788925610415.png As shown, I cannot write to fuse 0xa, but I have successfully written to fuse 0x1f. I don't know why Re: KW47B42ZB7 Fuse write issue Hi @Christine_Li , Does it mean that the fuse-program command of blhost cannot be used to program the lifecycle in kw47？ Re: KW47B42ZB7 Fuse write issue Hi, @Lu888  Thanks for creating case to us. From your provided info, I think you can execute fuse-read command means you are not in "After OEM Open" state. But according to: KW47SRM.pdf The reason is: The RO in the following table indicates that user cannot use MGMT_FUSE_PROGRAM to write the lifecycle fuses, instead, he can use MGMT_ADVANCE_LIFECYCLE or MGMT_SET_RETURN_FA_MODE. Christine_Li_0-1788944686191.pngChristine_Li_0-1788944686191.pngChristine_Li_0-1788944686191.png If you want to change lifecycle, you can use this command: MGMT_ADVANCE_LIFECYCLE in SB3 file. Christine_Li_1-1788944712390.pngChristine_Li_1-1788944712390.pngChristine_Li_1-1788944712390.png Best regards, Christine. Re: KW47B42ZB7 Fuse write issue Hi, @Lu888  Can you please help to check what is your board's lifecycle currently? You can use below command on your board which already been executed previous commands: Christine_Li_0-1789109774271.pngChristine_Li_0-1789109774271.png blhost -p com4 fuse-read 0xa 4 I want to know whether your board already been changed into OEM-Closed. Because I found  that according to this AN： KW47 Managing Lifecycles you are using correct commands to change lifecycle. Which is conflict with my previous comment. Best regards, Christine.

S32E2 IPCF latency timings between M33 and R52 I am working with S32E2 and configuring the IPCF framework and here is my setup Device: S32E288 IPCF transport: Shared Memory + MRU notification Communication: M33 ↔ R52 IPCF channel type: Managed channel 1 IPCF channel configured Interrupt mode (not polling) Ping/Pong RTT test implemented Communication is functioning correctly in both directions. I use STM to measure the timing ticks between the 2 cores. Measurement flow: R52: timestamp send PING   M33: receive PING immediately send PONG from RX callback   R52: receive PONG compute RTT The values computed for a STM running on 24Mhz are close to 200us RTT(Round trip time). My transport overhead is about 30us but the transfer itself takes up bulk of the time. I have tried various things like increasing MRU IRQ notification but has not improved the timings. Having optimisation in code from -o0 to -o1 helped but -o2 didnt make any difference. The payload itself is 16 bytes. Questions: 1. what is expected IPCF latency for managed /unmanaged channels. 2. can we acheive a low double digit latency? If you need any more details, please reply back.

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.