[参考译文] IWRL6432：IWRL6432 software reset？

你好。

您可能需要在触发复位之前添加一些延迟。   有关如何创建 CLI 软复位、请参阅雷达工具箱上的此基本信息页面。  这适用于6843器件、因此可能存在一些差异、但思路和实现方式应相似。  在该页面中、您将看到在复位前调用了一个 task_sleep (time)函数。  尝试添加它、然后查看它是否消除了挂起。

此致、

桑托什

你好

按照描述的方法，雷达仍然冻结。

你好。

让我来看看这个、我将在星期五回复您。

此致、

桑托什

您好

是否有任何新进展？

你好。

很抱歉响应延迟。  我仍在研究这一问题。  我将在星期三之前提供最新情况。

此致、

桑托什

你好。

为了进一步说明、您将器件挂起的具体意思是什么？  假设您意味着器件刚卡住、如果您尝试了调试代码、那么您是否能够隔离电路板在终端处卡住的位置？  该功能应该能够在没有计时延迟的情况下对器件进行软复位。

此致、

桑托什

你好。

您是否尝试过通过可视化工具刷写应用图像？  这可能是在调试模式下运行时遇到的问题、因此请尝试在器件上运行 appimage 并查看问题是否仍然存在。

此致、

桑托什

根据上述方法、在软件复位后雷达仍然没有电

你好。

当您发送用于软复位的 CLI 命令时、您是否能够进行调试并确切地查看正在发生的情况？  这将有助于在执行软复位后了解器件在何处卡住。  软复位后、您是否看到任何错误消息或输出？

此致、

桑托什

您好

软件复位后不打印串行端口

我懂了。  如果您在调试模式下运行程序、然后发送 CLI 进行重置、您可以看到程序中卡住的位置、它将为我提供更多关于为什么失败的信息。  我提出这个问题的原因是、在器件复位后、您通常必须重新发送配置、因此可能是器件处于"挂起"状态、等待一组新的配置。

此致、

桑托什

您好！

在调试模式下发送 CLI 复位后、没有响应。 当我再次发出命令时、我没有回复。

您好！  

桑托什目前不在办公室。 他 明天应该回来、可以继续支持您的问题。 感谢您的耐心等待。  

谢谢！  

约什

你好。

为了确保您的器件实际正在执行软复位、您可以利用 SOC_getRstReason 并检查它是否返回 SOC_RESET_REANY_SOFT、以确保进行软复位。  您能告诉我您是否遇到了这种情况吗？  我将继续深入研究这一点、因为我已经能够在主循环中自行调用 SOC_triggerSoftReset 时触发软复位、而无需任何 CLI。   

此致、

桑托什

大家好。

我在主循环中直接调用 SOC_triggerSoftReset 后、雷达串行端口没有输出、并且对数据发送没有响应。 在复位之前调用 SOC_getRstReason 会返回 SOC_RESET_RELAY_STC_PORZ。 我在 mmWave_demo 项目中执行了此操作。

你好。

我 已 重新创建您的设置并研究此问题。  请在下周一周三之前给我进一步研究这一问题。

此致、

桑托什

你好。

我只是想为您提供最新信息。  我已经注意到、在调试模式中、如果你执行一个 CPU 复位并在一个软复位后重新载入代码、getReason 函数将返回 SOFT_RESET。  我正在测试它在作为 appimage 运行时是否需要此复位、并将相应地提供更新。  请告诉我、如果执行 CPU 复位并重新加载代码会更改 rstReason 以反映软复位。

此致、

桑托什

大家好。

在调试模式下,通过 CLI 发送软复位后,将不会对调用 getReason ()作出反应,只有 getReason ()可以在软复位前被调用。 在复位之前调用 SOC_getRstReason 会返回 SOC_RESET_RELAY_STC_PORZ。 这相当于雷达在软复位后直接崩溃、我对软复位的理解是雷达将在复位后重新启动程序、而且我们已经在6843和1843上实现了软复位。

你好。

我们已经确定在 FreeRTOS 项目中使用 SOC_triggerSoftReset 函数时存在问题。  我正在寻找解决方案、请在下周一之前给我提供、以便向您提供解决方案。

此致、

桑托什

你好。

我再次看过这个线程、并且意识到你好像在尝试复制6843的软复位。  该实验本质上是通过软件执行完全复位、因此称为"软复位"。  您尝试使用该功能的软复位适用于引导加载程序。  我现在意识到、您似乎对软件重置更感兴趣。  这可能是一个简单得多的过程、因此让我来研究一下 、并在星期三之前与您联系并提供修复。

此致、

桑托什

你好。

我只是想提供另一个更新 、因为我收到了新信息。  经过一些研究,看起来我所提到的基础实验正在执行软件触发的热复位,其功能更类似于调用 SoC_triggerWarmReset ()。  但是、我们目前正在努力解决一些已知问题、因此我会继续跟进、以了解更多问题。  我认为这些问题不存在于 NoRTOS 工程或不使用 SBL 的空工程中。  您是专门尝试在 mmw_demo 示例工程中触发此复位、还是仅用于测试通过软件复位的能力？

此致、

桑托什

大家好。

我在 NoRTOS 测试项目中使用了 SOC_triggerSoftReset (在基于 RTOS 的系统中、该项目是软件复位、但不是 MMW_DEMO)。 我们正在基于 mmw_demo 项目开发一个新项目、因此软复位对于我们的整个项目至关重要。

我懂了。

我们仍在研究 FreeRTOS 环境中针对 SoC_triggerSoftReset 的解决方案、我将继续提供更新。  感谢您的耐心。

此致、

桑托什

大家好。

在这个问题上是否有任何新的进展？

祝你一切顺利。

你好。

我们目前正在测试一个潜在的解决方案、我将在本周结束前提供最新情况。

此致、

桑托什

你好。

我在研究一个解决方案时、您能否更详细地说明如何尝试使用软复位以及您试图在应用中利用软复位的目的、以便我们可以确定软复位是需要执行的适当类型的复位、还是热复位可以实现相同的功能？

此致、

桑托什

大家好。

当我在 MMWAVE_L_SDK_05_03_00_02中使用 MMW_demo 工程时，雷达在通过 CLI 命令调用 SOC_triggerSoftReset ()或 SOC_triggerWarmReset ()函数后直接崩溃，当我发送 CLI 命令时没有响应。 要正常运行，您需要再次打开电源或按重置键。 我发现、在没有 RTOS 系统的项目中、它可以正常重置。 仅在具有 RTOS 系统的项目中发生崩溃。

你好。

我知道您正在尝试重置器件、但您喜欢使用软复位而不是热复位吗？  我 想更好地了解用例、以便通过电子邮件进行联系。

此致、

桑托什