[参考译文] CC3235MODSF：ti_sysbios_KNL_Task_unblockI__E 中的硬故障

另一个观察结果：在由 MQTT 任务产生的出现故障的信标之前发布信标的调用、并附加了堆栈帧快照。 我推测这之前的通话造成了导致下一次开机自检呼叫故障的损坏。  我已经尝试过几次、到目前为止始终运行 MQTT 任务、然后出现下一个调用错误。

e2e.ti.com/.../mqtt_5F00_call.docx

因此、我再次跟踪存储器、用于在故障发生时发布的信标。 它位于存储器位置0x200144FC、在名为 g_cb 的全局结构中位于偏移252、在故障发生时设置为 NULL。 为了确定这是自世界开始以来的情况、还是我以某种方式践踏它、我为写入该地址设置了数据断点。 数据断点在初始化 memset()期间被命中，之后立即被命中，但该值保留为 NULL。 所以、当它最终被使用时、NULL 值引发了升级为硬故障的存储器故障。 我是否在初始化期间遗漏了会导致该信标不被初始化的内容？ 我已经随附了另一份文档、其中包含了堆栈框和相关内存的照片、供您查看。

e2e.ti.com/.../g_5F00_cb_5F00_memory.docx

您好、John：

我以前没有钻过这么低的、但我可以反映出我看到的情况。

基本上、驱动程序深度18中有一个队列机制来管理来自不同客户端的请求、其中一个就是您正在处理的套接字连接。

在队列初始化期间、根据所使用的操作系统、您将获得已捕获的数据。 基本上、如果您查看偏移量、会发现使用 SYSBIOS 初始化的元素为__f4.__f0、后者保存此链接列表中的指针。 当单元格空闲时、您会看到与初始化值匹配的指针、当它被占用时、您会看到已分配的其他指针。

看到与我捕获的情形相同。

您可以在第1个元素上看到下一个和 prev、指针不同于已初始化的指针(意味着已分配它)。 在本例中、与本例中为 NULL 的偏移值相同、但在本例中也为 NULL、因此、我认为这不是您的问题。

布置信标后、这些指针会返回其默认值、如下方的黄色部分所示。

总而言之、我不知道原因、但你似乎在尝试布置一个免费的信标。

此致、

Shlomi.

拉瓦伦斯让我将 SDK 版本添加到 TT 中。 即6.10.0.5

谢谢、这没有太大关系。

尊敬的 Shlomi：

感谢你的评分 我明白你在说什么。 不过、我的一个缺点是我不会尝试向信标发布消息。  堆栈跟踪中从 sl_Task 向下的一切都是 TI 简单链接代码。 它在管理信标和同步、所以我的问题是、为什么简单链接尝试发布到一个空闲的信标？ 我可能还会做错事,但我不知道会是什么。

您好、John：

当然、我会更深入地研究一下、并尝试理解。

您是否在没有修改的情况下使用 TI EVM 和代码？ 如果是、什么示例以及什么 IDE 和操作系统？

我想看看我能不能复制我的结局

谢谢。

Shlomi.

尊敬的 Shlomi：

谢谢！ 我们使用的是 TI SDK 6.10.0.5。 我知道的唯一修改是我们将 HTTP 缓冲区的大小增加到了2K 以解决我们相当大的令牌问题。 我们将使用 IAR 8.42.1作为 IDE、使用 tirtos 作为操作系统。

此致、

John

谢谢。

我正在使用 CCS、但不确定它是否相关。

您是否还能在 g_cb 控制块发生时告知以下情况：

• FreePoolIdx
• PendingPoolIdx
• ActivePoolIdx
• ActiveActionBitmap
• RxDoneCount

RxIrqCount 并不是这个控制时钟的一部分、但它也是一个全局变量。

Shlomi.

以下是您所请求的数据：

FreePoolIdx = 0x01

PendingPoolIdx = 0x12

ActivePoolIdx = 0x00

ActiveActionBitmap = 0x01

RxDoneCount = 0x24

RxIrqCount = 0x24

正如另一项信息、下面是一个不会引起问题的良好信标的内存视图、而下面是一个导致故障的视图：

00 00 00 | 01 00 00 | 01 00 | 00 00 | b4 46 01 20 | b4 46 01 20 Good、没问题
|           |            |       |       |            |
00 00 00 00 | 00 00 00 | 00 10 | 07 00 | 00 00 00 | 01 00 00 00故障、指针明显错误
事件的执行     | EVENT_ID | MODE| CNT | NEXT PTR  | PREV PTR

我已经能够进一步确定当 SEM_post 尝试取消阻止任何被被被正在被布置的信号量解除阻止的任务时、发生硬故障的问题。 我从 sl_Task ()中捕获了两个场景,因为这是一个出错的场景。 在工作情况下、调用堆栈与此类似(在调用任务取消阻塞代码之前、因为没有必要阐明我的观点)：

R0包含指向正在操作的同步对象的指针、如下所示：

从下面的观察窗口可以看到、它指向 g_CB 对象池中的第一个同步对象。

然后、在第二种我们出现故障的情况下、会出现不同的情况。 下面是我们即将发生故障时的堆栈跟踪。 也在 sl_Task ()之外:

显然正在处理套接字连接事件。 同步对象指针在 R0中的值为0x200144FC：

这指向 g_CB 数据结构中的第六个同步对象的*中间*：

由于该指针的偏移量并不指向池中任何同步对象中的信标、因此它会为指向信标的指针加载一个零、然后对其进行取消推论并尝试使用该零点。 太棒了！

我已经非常深入地研究了所涉及的代码、但我还没有能够辨别为什么会发生这种情况。 希望你们知道这个东西比我更好,可以帮助我找出为什么发生这种情况。

您好、John：

感谢您提供的信息！

这真的很奇怪。

我提到过的机制是一个池的链接列表。 每次使用信标时、它都会从列表中删除、发出信号时、它会返回到空闲列表。 不存在"内存"意味着、除非您正在进行操作、否则我希望链接中的第一个单元格是下一个要分配的单元格。

看着我需要的全局变量、它的行为似乎是可以的。  

• RxDoneCount 和 RxIrqCount 相等、这意味着没有挂起的命令或事件。 一切都得到了处理
• 如 ActiveActionBitmap 所示，有一个正在进行中的请求  
•  PendingPoolIdx 指示没有挂起的请求 (0x12表示无挂起)
• ActivePoolIdx 表示使用列表中的第一个项目
• 列表中的下一个空闲项是0x1、如 FreePoolIdx 所示

其他快照显示指向同步对象的指针存在未对齐情况。 错位是3*uint32，但我也不希望使用列表中的第6项。 在好的情况下、您会看到项目#0按预期使用、但在坏的情况下、它指向第6个项目、因为 nextIndex 为7、0xFC 偏移量也指示它。 我还可以看到项目6中的指针被初始化为原始值，这些值清楚地表明该项目已发布(未使用)。

它看起来不像内存损坏、因为我希望附近的内存损坏、但事实并非如此。

是否始终在插座连接期间发生？

它是否始终指向列表中的第6项？

是否要求使用 FreeRTOS 重新编译并重新测试太多？

此致、

Shlomi.

只是为了进行添加、您是否还能说明调用异步连接事件时每个变量的值是什么？

sl_drv_sync_obj_signal (&G -> ObjPool[g_pcb->FunctionParams.AsyncExt.ActionIndex].SyncObj)

• G_PCB 地址
• G_PCB->ObjPool 地址
• G_PCB->FunctionParams.AsyncExt.ActionIndex 值
• g_pcb->ObjPool[g_pcb->FunctionParams.AsyncExt.ActionIndex].SyncObj 地址

尊敬的 Shlomi：

我已收集您请求的信息。

问： 是否始终在套接字连接期间发生？

答：是的

问： 它是否始终指向列表中的第6项？

答:是的,它始终指向池中第6项的中间。

问： 是否要求使用 FreeRTOS 重新编译并重新测试太多？

答:我不知道,我从来没有研究过这个。 是否有任何指南可以帮助我解决此问题？

以下是您在连接事件调用 SL_DRV_SYNC_OBJ_SIGNAL 时请求的数据：

• G_PCB 地址：0x20014400
• G_PCB->ObjPool 地址：0x2001440c
• G_PCB->FunctionParams.AsyncExt.ActionIndex 值：0x00
• g_pcb->ObjPool[g_pcb->FunctionParams.AsyncExt.ActionIndex].SyncObj 地址：0x2001440c

监视窗口中的结构如下所示：

它真的没有意义,因为你可以看到它指向池的第一个元素。

有时它会发生变化、但代码中不清楚。

根据之前的捕获、SEM_post 中的 r0已损坏、但在连接事件中不存在、因此它必须介于二者之间。

您能否进入并查看它发生了什么变化？

而是需要以汇编方式完成。 也许有些优化改变了行为、但我不确定。

尊敬的 Shlomi：

在连接事件处理程序中的这条指令处、指针在 R2中看起来正确为0x20004400：

然而、到目前为止、我们还有几个指令、R3现在指向0x200044F0、这是索引6同步对象中的下一个指针。  

实际上、真正让我放弃的是该 LDRB.W 指令、它要加载 R3中远离 R3的0x118字节。 此时 R3 = 0x20004400、这是合理的、但0x118指向 索引6处同步对象中的 prev 指针！ 该值为0x20004514、因此 R3变为0x14。  

然后、0x14乘以0x0c、变为 F0。 这被添加到0x200044F0中、它是第六个同步对象的一部分。 之后的0x0C 被添加到它中、并成为我们冒犯的指针0x200044FC。 这条指令上的内容有什么问题吗？ 也许右括号应该在->SD 之后？

您好、John：

我的组装件与您在这里展示的不同。

不确定 R2和 R3应该是什么、所以难以评论。

simplelink 库是否经过优化编译？

Shlomi.

尊敬的 Shlomi：

我们将使用 SDK 6.10.0.5及其随 SDK 提供的预编译库。  

John

John：

我是在周末、所以周日可以继续。

Shlomi.

您好！

我设法使用 IAR 对其进行测试、在本例中、它能够正常工作。

我认为这是因为您一方的 IAR 汇编实现出于某种原因而与我方不同。

请参阅实现：

以及 g_PCB：

装配体上的一切都是有意义的、而在您的情况下、一切都是有意义的。

此致、

Shlomi.

在 e2e.ti.com/.../cc3235modsf-continue-crash-issue 上继续学习主题

谢谢、最后结束本次课程。

John：

请在 IAR 中查看我的汇编代码。

我们之间的区别在于汇编代码。

不知道为什么在你的情况下它是错误的。

Shlomi.

您好 Shlomi：

毫无疑问，在这两种情况下，大会是非常不同的。 我使用的 IAR 版本8.42.1未进行优化。 您正在使用哪个版本和设置？

John

我尝试了从无优化到高优化的每一级优化、并且仍然看到所有这些优化都有相同的误差。

最接近我的反汇编获得匹配你的是当我设置优化级别"低". 除了您正在使用哪个版本的 IAR、了解您正在使用哪个版本的 SDK 可能会有所帮助？ 与 IAR 8.42.1一起、我使用的是 SDK 6.10.0.5

您能否共享您的编译器设置和编译器可执行文件名。

当然、我的编译器可执行文件为：

用于 ARM 的 IAR C/C++编译器
8.42.1.233 (8.42.1.233)
C：\Program Files (x86)\IAR Systems\Embedded Workbench 8.4\arm\bin\iccarm.exe
2019年11月26日15：24：32、27010048字节

我将附加一个文本文件、其中包含来自"关于"菜单的产品信息的完整输出

对于编译器设置、我认为最相关的选项似乎是优化、预处理器和额外选项。 如下所示。 如果您需要其他设置、请告诉我。

e2e.ti.com/.../IAR_5F00_about.txt

您好 Shlomi：

因此,我采用了 _SlSocketHandleASYNC_Connect ()函数,并使其尽可能简单。 我只剩下锁定和解锁调用、我将对象单次调用更改为具有硬编码索引0、而不是 g_cb 结构中的索引。 因此、调用现在如下所示： sl_drv_sync_obj_signal (&G -> ObjPool[0]。SyncObj)；

硬故障消失了。 我缓慢地恢复了所有内容、直到将同步对象信号恢复为原始形式之后、故障才恢复。 然后返回硬故障。 我捕获了成功和失败情况下生成的代码。 如下所示。 成功案例是第一、失败是第二。 一开始我以为可以解决这个问题、然后继续使用我们的网关进行集成、这让我感到非常兴奋。 不幸的是,在 sl_Task ()的其他地方发生了一个非常类似的硬错误;

您好、John：

我正在使用 IAR 8.32.2、但我很难相信它与 IAR 版本相关。 我还使用低优化。

如果您查看我拥有的汇编代码、您会发现与您的汇编代码的主要区别是 FunctionParams.AsyncExt.ActionIndex 的偏移是如何计算的。 在本例中、它是0x348、在本例中、由于某种原因、它是0x118。 如果我回头看一下您 在观察点中显示的 g_PCB 位置、我可以看到在您的示例中、它也是0x348 (0x20014748-0x20014400 = 0x348)！！！ 那么、它是如何计算为0x118的？

这就是当您将它硬编码为0并绕过此偏移计算时它暂时工作的原因。

不确定如何进行、但我会建议：

• 确保最后一个组装件中的 R1为36。 这是 ObjPool 中每个单元的大小、以便 MUL 函数跳转到列表中的正确位置(通过 g_pcb->FunctionParams.AsyncExt.ActionIndex 将36相乘)
• 显式分解 ObjCool 中的偏移并查看汇编如何更改。 可表示为：
  

  _SlFunctionParams_t* pFuncParms;
  AsyncExt_t*          pAsyncExt;
  
  pFuncParms = &g_pCB->FunctionParams;
  pAsyncExt = &pFuncParms->AsyncExt;
  
  SL_DRV_SYNC_OBJ_SIGNAL(&g_pCB->ObjPool[pAsyncExt->ActionIndex].SyncObj);

此致、

Shlomi.

尊敬的 Shlomi：

我执行了您建议的操作并更改了代码以访问 ActionIndex：

    pFuncParms  = &g_pCB->FunctionParams;
    pAsyncExt   = &pFuncParms->AsyncExt;
    index       = pAsyncExt->ActionIndex;

我尝试将索引设置为 uint8_t 和 unit32_t、以防万一。 这并不重要。 最终结果仍然是同一个已改编的指针。 但是，它确实表明，这个问题似乎是上述三者的第一个陈述。 它应该加载&g_pcb + 0x33c。 但是、生成的代码正在加载&g_pcb + 0x10C。 我从2007年开始使用 IAR ARM Workbench、这是我第一次可以回忆起它似乎生成了格式错误的代码。

John

我快速思考过、将上面的代码更改为：

    addr        = (uint32_t *)(&g_pCB + 0x000000CF);
    index       = *addr;

硬编码偏移0x000000CF 是 g_PCB 结构中 ActionIndex 的偏移。 这起作用、不再是硬故障。 我越来越相信这是一个代码生成问题。

John

我同意、这很奇怪。

我不确定我们还能做些什么。

我可能会尝试查看另一个位置 、其中 g_pcb->FunctionParams.AsyncExt.ActionIndex 被起诉、并查看汇编代码是否看起来相同。

如果是、我不明白它是如何工作的。

Shlomi.

尊敬的 Shlomi：

我已经通过 IAR 提交了一个请求单、看看他们对此有何看法。 我会一直提醒您。

John

谢谢 John、如果您有更多详细信息、请告诉我。