[参考译文] MCU-PLUS-SDK-AM243X：看门狗不工作

您好、Felix、

我将在本月31日之前回来讨论此项目、请允许我花些时间分析主题并回复。

谢谢、

G Kowshik

Kowshik、您好！

我尝试了两种方法：手动设置-没有任何 SYSCFG。 并仅使用 SYSCFG 对其进行设置。 这两种方法都不起作用。 我已经测试了您的建议、但它不起作用。

在找到使用 TI-Watchdog 的解决方案之前、我希望保持打开状态。

此致

Felix

您好、Felix、

好的、我将尝试在评估板上测试这个、并在9月5日之前回来测试这个项目。 此外、我希望您检查位置"  C：\ti\mcu_plus_sdk_am243x_08_03_00_18\examples\drivers\watchdog\watchdog_interrupt "下的 AM243x 示例代码

让我们知道这是否有效、因为如果这也不起作用、那么我们还需要其他一些东西来找出根本原因。  

谢谢

您好、Ming、

因此、我尝试接收提到的中断、但这也不起作用。

我甚至看到了原因：您可以注册并通过 open 函数传递的 callbackFxn 永远不会被调用、因为即使在 SDK 源代码内部、它也不会应用于任何内容。 代码甚至不包含触发中断的提示、TRM 或我也找不到中断。

源代码如下所示：

那么、实际上、当配置为 NMI 时、除了清除 WD 状态之外、什么情况都不会发生？

那么、我如何使用这个看门狗实现来实现看门狗功能呢？

您好、Felix、

请尝试导入并构建 watchdog_interrupt_am243x-evm_r5fss0-0_nortos_ti-arm-clang 示例。 然后将输出文件加载到 AM243x EVM 上。 在 watchdogCallback()中设置断点，然后运行程序。 您应该在大约10秒内进入中断点、因为观察 GoG 计时器被设置为10000ms (10秒)。 我已经在 AM243x EVM 上使用 AM243x MCU+ SDK 08.03.00.18进行过测试。 它工作正常。

此致、

Ming

您好、Ming、

我刚才在示例中看到、您对看门狗的硬件中断进行硬编码。 文档中的任何地方都没有对此进行说明、看门狗的 API 也没有对此进行说明。 API 提供回调函数、但实际上似乎未使用。

是否会更新有关此主题的文档？ 我们不使用任何示例、也不使用任何 EVM 板。 我们依赖 API 和文档。

接下来我将使用 Hwi 进行尝试、并保持此线程更新。

此致、

Felix

你好 、Felix Heil

您能向我们展示一下您在谈论什么硬编码吗？ 中断编号根据 TRM 针对外设的中断映射进行硬编码。 您可以在 TRM 的2161页中找到它  

谢谢

"硬编码"可能有点错误。 我的意思是、您只需创建该硬件中断、文档中未提及该中断。 这是示例中的"硬编码"、但没有其他解释。

这个示例在我们的板上工作、但是一旦我尝试在我们的应用中像示例那样实施它、它就不起作用。 由于我们有一个不同的初始化、我认为 HWI 创建得太晚了、因此我将其直接放在 Drivers_open 之后、就像在示例中所做的那样。 但这并没有解决这个问题。 永远不会发生中断。 我将其设置为1000ms、10000ms、就像示例一样、但没有。

我在 SYSCFG 中将其设置为触发 NMI 中断 WDT8、依此类推：

我们将在 C++上下文中创建硬件中断：

    HwiP_Params             hwiPrms;
    int32_t                 status = SystemP_SUCCESS;
    static HwiP_Object       gRtiHwiObject;
    /* Register interrupt */
    HwiP_Params_init(&hwiPrms);
    hwiPrms.intNum      = CONFIG_WDT0_INTR;
    hwiPrms.callback    = &wdCb;
    hwiPrms.args = reinterpret_cast<void*>(this);
    status              = HwiP_construct(&gRtiHwiObject, &hwiPrms);
    
    ...
    
    void wdCb(void *callbackFxnArgs)
{
}

我们永远不会清除看门狗。 因此、我希望不会为窗口提供服务、并且会发出中断。 但不是。

我尝试手动设置它。 我注意到、在时钟启用之前创建硬件中断时、一旦我们调用 SOC_moduleClockEnable、中断就会直接出现。 直接连接。 因此、两者之间没有时间间隔、窗口将被忽略。
如果我在时钟启用后更改中断结构、则不会发出中断。
这是可复制的。

我出了什么问题？

编辑：中断终于发生了。 但在设置1000 ms 之后、在设置了大约100秒之后。 我正在进一步调查。 频率/时钟配置似乎有某种错误？

Edit2：好的，第二次尝试没有在相同的行为下解决。 同样、不会产生中断。

您好、Felix、

我现在知道这个问题、您可能无法正确地重置所需的 Watchog 实例、原因可能是中断编号的配置错误。 我知道、除了在 TRM 中没有有关中断编号的详细文档外、您还将讨论如何从 SysConfig 生成中断编号。 感谢您将此事告知我们、我已开始就该问题向专家进行内部沟通、我应该在下周一之前做些什么。  

感谢您的耐心等待。  

您好、Felix、

首先、根据 AM243x TRM 中的12.5.2.1 RTI 概述、WDT8专用于 R5f0_0、WDT9专用于 R5F0_1、以此类推。  CONFIG_WDT0_INTR (始终为0)将是所有看门狗计时器的中断。

根据 上一帖子中的 example.syscfg 文件、"WDT Expiring time in millisecond (ms)"设置为10000ms、即10秒。 您应该能够在10秒后获得中断。 您可以将其减少到1000ms (1秒)吗？

我在您的代码中注意到的另一件事是：

hwiPrms.args = reinterpret_cast (本)；

我不确定它在做什么。 您现在可以将其注释掉吗？

此致、

Ming

嗨、Ming、Hey Kowshik、

因此、正如 Ming 所说的、设置为0的 INTR 应该是合适的。 我还尝试将其设置为1000ms 和许多其他值。 我还删除了 hwiPrms.args 分配、但它仅是负责中断回调的 c++对象。
回调本身是一个 static-link-time-member-function、因此 C 上下文可以访问它。 我们还将其用于 IPC/RPMessage、其工作方式符合预期。

我今天在休假后还注意到、我再次触发中断。 但不会超过预期的时间间隔、而是完全随机变化、例如15秒到更晚。 我现在只能复制一次，但时间似乎有所不同，因为这需要11分钟和~10秒。

是否可能存在中断问题？ 由于该示例似乎也不使用 FreeRTOS 任务、是一个非 RTOS 示例、但我们确实使用任务。 我还通过 readelf 检查了其他第三方库的看门狗符号、在联系它们之后、我也会排除这种情况、因为它们都不使用任何看门狗实例。

我还检查了 TI8_CFG 寄存器：

DWWD 寄存器表示违反了窗口、这应该会触发中断、但没有引发中断。

现在、经过14分钟和~10秒后、又触发了另一个中断、但除了 DWDCNTR 改变外、没有寄存器。

您好、Felix、

很抱歉没能及时回来。

这里有三个不同之处：

1.您使用的是客户电路板、而我们使用的是 AM243x EVM

2.您使用的是 FreeRTOS，而我们使用的是 NORTOS

3.您使用的是 C++，我们使用的是 C

我们能否逐一消除可能出现的问题？

首先、您能否在 AM243x EVM 上重复看门狗中断(NORTOS)？

如果是、您能否在客户电路板上重复相同的测试？

我将尝试修改相同的 FreeRTOS 测试？

此致、

Ming

目前、我们很难在这里收集 EVM、但我已经在我们的板上对其进行了测试、示例在那里工作正常。

是的、我还认为 C++可能是这里的原因、但由于它对我们使用的所有其他 SDK 驱动程序的工作方式相同、因此我怀疑问题是由它引起的。

此致、

Felix

您好、Felix、  

正如我们在呼叫中讨论 的那样、您将尝试增加 SVC 和 IRQ 堆栈、而我将尝试 FreeRTOS 版本的看门狗示例。

此致、

Ming

您好、Ming、

因此、我尝试增大尺寸：

不幸的是，问题仍然存在。

我还注意到、在使用 WD 进行调试时、我需要经常对器件进行电源复位。 通常、我在 CCS 中使用 CPU 复位、但使用 WD 时、这似乎不能正确复位器件。 我找不到这个问题的根源。

此致

Felix

您好、Felix、

糟糕的是、堆栈大小的增加没有帮助。 我将尽快尝试 FreeRTOS 版本的看门狗示例。 将在下周初让您了解。

此致、

Ming

您好、Felix、

我能够使看门狗示例在 FreeRTOS 下工作。 我所做的是从适用于 AM243x 的 MCU+ SDK 08.03.00.18中获取 FreeRTOS 空示例、并将看门狗测试添加到其中。 它按预期工作。 随附的内容、请从工作区中找到更新后的 FreeRTOS 空示例文件夹的 zip 文件。

e2e.ti.com/.../1638.empty_5F00_am243x_2D00_evm_5F00_r5fss0_2D00_0_5F00_freertos_5F00_ti_2D00_arm_2D00_clang.zip

此致、

Ming

您好、Ming、

是的、我可以确认该示例适用于我。 有趣的是、在加载示例之前、我始终需要对器件重新供电。 否则不会调用 wd-CB。 但是、无论如何、这对于我们的实施来说并不像这样有效。 无论是否重置、回调都不会被调用。 现在、我将逐步比较我们的设置中可能不同的内容

好的、那么我看到的差异和我尝试的差异：

我们直接通过所有可用的优先级使用多个不同的任务。 示例只有一个任务。
2.我们的启动例程在非任务上下文中调用 System_init()；Board_init()；和 Drivers_open()；Board_driversOpen()。 该示例调用示例中任务内的最后两个。 在 FreeRTOS 启动时、我还尝试在任务上下文中调用的单独函数中移动这些函数。 不会改变任何东西。 请注意、调用它的上下文中的任务稍后会永久挂起、因为它只是一个初始化任务。 但我想这不应该推测？
3.由于我们将函数放置在 GPMC-region 中、因此我们大量使用链接器、在该区域我们使用 PSRAM 来减少内部 SRAM 的使用量并增加 RAM。 SDK 的初始化函数位于 PSRAM 中、而 wd-callback 也是如此。 我直接链接了 wd-callback 并在 SRAM 中创建了 hwi、而不是 PSRAM。 生成的文件也是如此。 没有帮助。
我们使用了一个 C++成员函数。 我创建了一个 C 函数、如在示例中的回调函数。 也没有帮助。
我们通过 CCS-Console 提供输出、示例没有。 通过 SYSCFG 禁用 CCS 输出也不能解决问题。
6.我们不是直接在 TAS 循环内构建 Hwi 对象，而是在 C++构造函数内构建 Hwi 对象。 我把它直接移动到了打开函数的位置。 这也不有帮助

相同之处：
1、时钟和 WD 的 SYSCFG 设置与示例中的设置完全相同

我的另一个想法：sysfw 是否涉及该主题？ 由于我们需要修改 sysfw 位(只有一个通过 rm 的引脚不同)并再次编译它。 不确定这是否会干扰到这里？ 该引脚仅用于 GPIO。

注意：中断会发生、但它始终需要7-15分钟、而不是声明的1秒。

您好、Felix、

1.我觉得这应该可以

2.只要对 Drivers_open()的调用在 Hwip_construct()之前，它就应该是可以的。

3.这可能是一个问题，但您尝试将它们放入 OCRAM 中，但仍然没有帮助，因此可以排除这种问题

4、我觉得也可以排除这种情况。

5.这不是问题。

6.您也可以尝试两种方法来排除它。

我不确定 SYSFW 的更改。 但是，我没有在 Watchdog_open()和 Hwip_construct()中看到任何 SysFW API 调用。

是否可以在08.03.00.18开始使用 SysFW 的情况下尝试代码而不进行更改？

最后一个问题、看门狗中断是否总是发生、但需要7-15分钟才能到达、或者有时会发生、有时甚至不会发生？

此致、

Ming

您好、Ming、

遗憾的是、我无法解决该问题。

我尝试将其从 C 语言环境中移出尽可能好、但它也不能修复它。 我还检查了我们是否在某个地方阻止任何中断、但情况并非如此。 但我们大量使用操作系统机制。 我们还暂停任务并使用互斥量、事件和邮箱。 不确定这是否可能会以某种方式相互推断。 至少 FreeRTOS 的文档指出、暂停所有任务只会暂停调度程序而不会锁定任何中断。

今天、中断似乎永远不会再次发生。

我们可能需要一个调试会话来检查此处的内容。

此致

Felix

您好、Felix、

我的同事将很快安排与您进行调试会话。

此致、

Ming

您好、Felix、

我需要可用于通话的利益相关者的电子邮件 ID。 适合您的时隙。

谢谢