[参考译文] CC1352P7：MAC 协处理器 NPI 链路丢失数据包-使用集成 CC1352P7无线电的 BeaglePlay

附录：

在我关于未来计划的第1项中：我预计、由于 TI Launchpad 采用了 ACM 串行器件、BeaglePlay UART 驱动程序中的任何错误都将被绕过、但当然数据丢失的发生级别可能高于低级 UART 驱动程序。 因此、我可能还会在另一个 Linux Box (x86)或 RasPi 上完全运行 host_collector 和更高级别。

您好、Joshua、

再次感谢您提供的信息。 自8.30.01.01版本的 SDK 以来、15.4已使用与我们全新的记录器工具兼容的日志：

https://dev.ti.com/tirex/explore/content/simplelink_cc13xx_cc26xx_sdk_8_30_01_01/docs/ti154stack/html/ti154stack-guide/debugging-index.html?highlight=logging#ti-log-driver

从您的设置中获取此类日志实际上会帮助我们确定应用程序中可能出现的问题。 您可以在 SysConfig 中启用它们、如下所示：

我们将获取您可以提供的所有数据。 此外、BeaglePlay 上正在运行什么分配？

此致、

Arthur

Arthur、

此处执行以下操作：

1.) SDK 7.41并未消除协处理器硬故障。 我有一个长时间运行的测试设备运行7.41 SDK 协处理器、它在周末崩溃了。

症状包括：

• 使用复位线路重置处理器不会使其恢复。
• 读取存储器内容不会发现任何闪存损坏、唯一的变化是为 NV 存储保留的区域。
• 与调试器运行协处理器会使系统运行。
  • 停止并断开调试器、然后使用复位线路复位处理器不会导致运行。
• 通过重新编程进行下电上电可执行恢复功能。
  • 我本来只打算进行一次电源循环、但我在 Beagle Play 中实施了一些代码、以便设置新的未编程设备、无意中激活、对处理器进行编程。

我已经禁用了自动重新编程、因此希望下次我能获得更好的数据、但我希望您可以提供一些建议、说明这可能发生的原因以及我们如何识别问题。

2.) BeaglePlay 分配为：

picte_name="Debian GNU/Linux 11 (斗牛场)"
Debian"GNU/Linux" NAME=
版本_ID="11"
VERSION="11 (靶心)"
version_codename=靶心
ID=
home_url="">https://www.debian.org/"
support_url="">www.debian.org/support"
BUG_REPORT_URL="">https://bugs.debian.org/"

1)查看此处的数据、它可能确实特定于 BeaglePlay。 您使用的复位过程是否与 https://github.com/beagleboard/cc1352-flasher?中使用的复位过程相同

3)我建议使用 ITM 输出接收器或其他 UART 为两者都启用它。 然而、只有当您计划使用外部 LP-CC1352P7时、该操作才简单。 您也可以尝试将一根导线焊接到 CC1352P7 JTAG 连接器的 SWO 引脚、并 ITM 将 JTAG/UART 输出映射到该引脚。

请记住、我们已经开发了新的日志框架、以便尽可能减少固件的占用空间(例如、使用.out 文件中的数据来解释调试消息、因此您无需通过接收端发送整个字符串)。

Arthur、

我使用旧版本的 cc1352刷写器启动了该工程、但它似乎工作方式相同、我在正确编程时没有遇到任何问题。

我在应用程序中添加了一些代码来获取复位和引导线 GPIO、并将其保持在正确的状态、以确保1352没有看到虚假复位或引导引脚错误的状态。

我的外部 LaunchPad 可以正常工作、因此我可能会为 ITM 输出选择这条路由。

不过有一个问题、有关 simplelink Academy 培训的链接不起作用、它只是加载一个空白页面。
您发送的此链接引用了该链接：
https://dev.ti.com/tirex/explore/content/simplelink_cc13xx_cc26xx_sdk_8_30_01_01/docs/ti154stack/html/ti154stack-guide/debugging-index.html?highlight=logging#ti-log-driver

不起作用的链接：
dev.ti.com/.../nodeContent

Joshua、

实际上、我注意到链接也不起作用。 我将看到这是什么。  

另外、在您之前的3)  

我仍然认为这可能是相关的,因为链接列表问题只影响 SPI 驱动器,从我可以收集.

此致、

Arthur

我已打开 UART2和15.4堆栈的日志记录。 我使用以下命令行运行了 tilogger：
tilogger --elf .\SensoNext_CP_bb_83.out iTM COM12 12000000 stdout

的、可产生以下输出：

信息：ITM 串行 Rx：串行端口\\.\COM12 @ 12000000已打开

我看不到任何超过此值的输出、并且该应用程序完全正常工作。 我探测了 SWD、TDI、TDO 和 TCK 线、没有看到任何活动。

除了 SysConfig 的功能之外、是否还必须进行一些额外的初始化？

您能告诉我更多有关 TI154STACK-4439的信息吗？  它显示"信标响应损坏、有16个以上的间接待处理消息"。 这仅限于损坏的信标响应、还是存在更深层次的情况、损坏的信标响应只是可观察到的症状？ 也就是说、这可能是一种更通用的越界写错误、它破坏了信标响应、但可能会产生其他影响？

您好、Joshua、

此票证与以下 E2E 主题有关： (+) CC2652R：如果存在16条或更多间接待处理消息、信标响应将消失- Zigbee 和 Thread 论坛- Zigbee 和 Thread - TI E2E 支持论坛

您是否在调试会话运行时尝试记录？ 我注意到、当没有运行调试会话时、可以通过 ITM 获取日志(我已启用所有调试级别)：


请注意以下几点：

• ITM 输出引脚映射到 DIO18 (LP-CC1352P7上的 SWO 引脚)。 SWO 引脚连接到 XDS110的 SWO 输入
  
• COM 端口实际上是用于此目的的辅助端口：
  

此致、

Arthur

Arthur、

我没有正确设置 SWO 引脚。 我不会尝试在执行此操作时运行调试会话。 现在我看到 SWO 引脚上发生了一些事情、但日志记录不起作用。

两点观察结果：

1.) SDK 安装目录 simplelink_cc13xx_cc26xx_SDK_8_30_01_01/tools/log/tiutils/Readme.html 中的文档

说明要使用哪个 COM 端口、这与您刚才所说的相反。 我已经尝试了两个端口、都不起作用、根据您的信息、我当前使用的是 AUX UART。

2.) 我正在使用命令行

 tilogger --elf .\SensoNext_CP_bb_83.out iTM COM13 12000000 stdout

其中 COM13是辅助数据端口。 stdout 应该可以正常工作、对吧？ 我宁愿不必为此设置 Wireshark。

我的程序是：

• 将固件加载到目标器件中。
• 启动 tilogger
• 复位目标器件
• 在 Beagle Play 上启动主机收集器和应用程序。
• 一切都正常工作、但没有日志输出。

我的另一个观察结果是、当 LaunchPad 作为协处理器运行时、NPI 数据包损坏的干扰仍然发生、表明问题可能出在 cc1352中。  这三次事件都是在夜间发生的,所以这不是一件经常发生的事情。 您的想法？

另一个问题：

XDS110是否需要进行任何配置？

您好、Joshua、  

我也会尝试使用 stdout 输出、但作为补充问题、您正在使用哪个命令提示符？ Powershell、Powersheel 7还是标准 CMD.exe？  

此外、您是在 SysConfig 中选择了 ITM 接收器吗？

在配置方面、除了在 LP-CC1352P7上的"SWO"引脚上放置跳线外、无需进行任何配置。
在本文档发布时、您所说的是在使用 UART 传输接收端时正确的。 在这种情况下、您确实必须使用应用 UART。 但是、使用 ITM 时、您必须使用辅助 UART。 有关此日志模块的培训将在月底之前完成。

最后、关于干扰主题、感谢您检查 Launchpad 是否也发生了这种情况。 您是否知道它是否总是发生在相同类型的数据包(例如、长度等)上？ 此外、您的网络中是否仍使用相同的参数？

• 9个传感器
• 每90秒发送一次数据
• 跟踪间隔为300秒

如果我们需要重现问题、这可能最终有所帮助。

此致、

Arthur

Arthur、

我使用的是 Powershell、我选择了 ITM output。

测试网络有两个、每个都有大约6个有源传感器。 我有几个,但由于高数据速率,我耗尽电池相当快,所以有几个已经掉线,但问题仍然发生.

参数：

6个传感器

每100mS 发送一次数据。

跟踪间隔：

您好、Joshua、

感谢您提供数据。 我们可以尝试设置类似的设置。

我已经尝试使用 stdout、我正在获取与 Wireshark 中相同的日志：  

同样、确保已填充 SWO 跳线、并且日志级别均已启用。

请告诉我它是否有效。

此致、

Arthur

Arthur,我得到了日志工作,但它崩溃后几行输出:

(.venv) PS C：\Users\josh\Documents\SensoNEXT\sensonext\SensoNext_CP_bB_830\Release> tilogger --elf .\SensoNext_CP_bb_83.out iTM COM31 12000000 stdout
信息：ITM 串行 Rx：串行端口\\.\COM31 @ 12000000已打开
COM31 | 6.875004750 | Mod_Log 模块_Module_154_RAC.MAC | Log_info   |/home/developer/.conan/data/ti154stack/7.30.00.16/library-lprf/eng/build/c90184d484f3f95c6a6179391966efa64b8ab8fe/source/ti/ti154stack/low_level/cc13xx/mac_radio.c：1550 | Low_Level_在 RAT=52224时通电
COM31 | 6.877647083 | Mod_Log Module_154_COM.MAC Low_Level_| Log_info   |/home/developer/.conan/data/ti154stack/7.30.00.16/library-lprf/eng/build/c90184d484f3f95c6a6179391966efa64b8ab8fe/source/ti/ti154stack/low_level/cc13xx/mac_radio.c：1551 | Rollover=0、Trigger=0
COM31 | 6.877650583 | Logo Mod_Log Module_154_RatCount=0   | Log_info |/home/developer/.conan/data/ti154stack/7.30.00.16/library-lprf/eng/build/c90184d484f3f95c6a6179391966efa64b8ab8fe/source/ti/ti154stack/low_level/cc13xx/mac_radio.c：1552 | Low_Level_ Count=0
线程 COM31中出现异常：
回溯(最近一次呼叫)：
 文件"C：\Program Files\Python38\lib\threading.py"、第932行、位于_bootloader_inner 中
   self.run()
 文件"C：\Program Files\Python38\lib\threading.py"、第870行、正在运行
   self._target (* self._args、** self._kwargs)
 第69行为文件"C：\Users\josh\Documents\SensoNEXT\TILogger\.venv\lib\site-packages\tilogger_iTM_transport\iTM_transport.py"
   logger.log (数据包)
 日志中的文件"C：\Users\josh\Documents\SensoNEXT\TILogger\.venv\lib\site-packages\tilogger\logger.py"、第79行
   self.format_doby_packet (packet)
 文件"C：\Users\josh\Documents\SensoNEXT\TILogger\.venv\lib\site-packages\tilogger\logger.py"、第135行、格式为_doby_packet
   packet._str_data = elf_str.string % tuple (values)
ValueError：索引47处的格式字符"l"(0x6c)不受支持

我关闭 UART2和15.4栈的"调试"和"详细"级别、现在似乎可以运行。 显然、其中一个生成的调试消息的格式不正确、但我没有带宽来尝试准确确定哪一个。

我还有另一个意见。 只打开 ITM 日志记录(我之前的帖子中对此进行了详细配置)就会"修复" UART CRC 错误。 我只能假定运行日志记录会改变某种时间、或者可能与发送 ITM 消息相关的东西会改变某种东西。 无论如何、我的测试设备已经运行了好几天、没有出现单个 CRC 错误、而另一个测试设备(在其他方面几乎相同)的运行时间为每小时~1次。

另一个器件在 BeaglePlay 上运行板载协处理器、而我的测试器件运行外部 Launchpad。 这是因为 Beagle Play 设计师没有将 SWO 引脚连接到标记连接连接器。 这是令人费解的为什么他们没有,这将是有用的。

下一步是在另一台设备上运行启用日志记录的二进制文件、并使板载1352处于启用状态。 我将无法观看日志输出、但我应该能够查看校验和错误是否消失、这将使人们相信、这是关于启用日志记录或 ITM 的某种信息、这将"修复"此问题。

作为参考、以下是日志的配置方式：

TI 15.4 Stack 日志记录已启用。

•  TI 15.4 Stack 应用程序级别日志配置
  • 启用模块=是
    • 启用级别调试=关闭
    • 启用级别详细=关闭
    • 启用级别信息=关闭
    • 启用级别警告=开启
    • 启用电平错误=开启

•  TI 15.4 Stack 低级 MAC 日志配置
  
  • 启用模块=是
    • 启用级别调试=关闭
    • 启用级别详细=关闭
    • 启用级别信息=关闭
    • 启用级别警告=开启
    • 启用电平错误=开启
•  TI 15.4 Stack 低级 TX 日志配置
  
  • 启用模块=是
    • 启用级别调试=关闭
    • 启用级别详细=关闭
    • 启用级别信息=关闭
    • 启用级别警告=开启
    • 启用电平错误=开启
•  TI 15.4 Stack 低级 RX 日志配置
  
  • 启用模块=是
    • 启用级别调试=关闭
    • 启用级别详细=关闭
    • 启用级别信息=关闭
    • 启用级别警告=开启
    • 启用电平错误=开启

UART2日志配置：

• Uart2日志配置
  
  • 启用日志=是
    • 启用级别调试=关闭
    • 启用级别详细=关闭
    • 启用级别信息=关闭
    • 启用级别警告=开启
    • 启用电平错误=开启

15.4和 UART 的接收端均设置为 ITM。 ITM 日志记录配置为默认值、无需修改。

我有更多的数据。 运行启用日志记录的 Mac 协处理器二进制文件时、具有内部 cc1352的设备仍会生成校验和错误。 我考虑了我在另一台设备上的设置未遇到问题、并意识到与我第一次在外部运行时(它确实遇到了 CRC 错误)还有一个区别。

首次设置为在外部运行时、我使用了 LaunchPad 中内置的 UART 转 USB-CDC 转换器。 因此、通过 USB 端口进行连接：cc1352 -> Launchpad CDC Device -> Beagle Play。 此设置确实会遇到 CRC 错误。

这次、如果没有出现 CRC 错误、设置将使用 FTDI 232 TTL 电缆。 因此、连接如下：

cc1352 -> FTDI TTL 232 3.3伏电缆-> Beagle 通过 USB 端口播放。 在运行的许多天内、此设置未遇到任何 CRC 错误。

因此、似乎故障在某种程度上在于 Beagle Play 驱动程序。 这个故障如何影响 LaunchPad CDC 器件对我来说是一个难题。

您好、Joshua、

这是非常有趣的。 我现在能想到的唯一区别是,那些 FTDI TTL 设备(至少是基于 CP2xx 的设备)已知在超时之前等待1毫秒64字节。  CP210x USB 通信

但值得在 BeaglePlay 上探索 UART 桥接器的实现。

此致、

Arthur

Arthur、

我使用的电缆是正版 FTDI 器件、不是克隆设备、也不是 SiLabs CP210x USB 器件。 在我的经验,他们是最好的业务对于这种类型的设备,这并不是说,它可能没有一些白化合物。 但是、FTDI 线缆似乎可以正常工作、Beagle 上内置的 UART 和 LaunchPad 上的 UART 都无法正常工作。

我们没有时间或资源来调试 BeaglePlay UART 驱动程序、是否能够解决这个问题？

您好、Joshua、

今天下午、我将与栈的开发人员讨论这种情况。 他们可能会有其他见解。 至于 UART 问题、我同意需要时间来弄清楚这是怎么回事。

此致、

Arthur

您好、Joshua、

因此、我请了 AM62x 的主管团队、他们向我指出了最新版本的 TI AM62 Processor SDK 中处理过的勘误表：

现在的问题是 您可能必须基于最新的 SDK 重建自己的 Debian 映像。

下面提供了一些用于构建您自己的映像或下载默认 BeaglePlay 映像的链接： BeagleBoard.org / image-builder·GitLab

SDK-AM62X 软件开发套件(PROCESSOR-SDK-LINUX)|德州仪器 TI.com

但我认为我们没有处理这个问题。

此致、

Arthur

早上好、Arthur、

您知道 Debian 发行版何时会使用此 SDK 重建吗? 我现在运行的是11.7、由于一些论坛帖子表明连接到1352的 UART 的映射发生了变化、现在无法对其进行配置、因此我推迟了更新。

我们正在尝试为大型客户发布基于此的产品、而用于配置、构建和测试 Linux 发行版的资源在所需的时间范围内根本不可用。

此致、

Josh

您好、Joshua、

事实上,我今天又尝试了12.7次,没有任何效果...

我尚不知道何时可以重建该板、但我可以尝试联系 BeagleBoard 人员以了解他们的计划、甚至可以获得新的分配。

此致、

Arthur

Arthur、

看起来您是我所谈论的主题的参与者：
https://e2e.ti.com/support/wireless-connectivity/sub-1-ghz-group/sub-1-ghz/f/sub-1-ghz-forum/1439500/cc1352p7-cannot-write-to-on-board-cc1352p7-of-beagleplay

当您尝试12.7时、是否能够将 UART 配置为能够与1352通信、或者它是否仍按照我链接的线程中的引用进行损坏？

此致、

Josh

您好、Joshua、

实际上、我也无法让 UART 正常工作。 我正在 BeagleBoard GitLab 上进行跟踪。 让我询问一下 BeagleBoard。

此致、

Arthur

Arthur、

有什么要报告的吗？ 如果我们能解决这些问题、或在可能的时候提出一些想法、那将是非常有益的。

您好、Joshua、

本周我将与 BeagleBoard 开会、尝试了解 Debian 12.7的使用情况、并了解更多细节(如果可能、甚至可以使用新的内核/驱动程序)。 我会让你知道的。

此致、

Arthur

您好、Joshua、

我们再次设法在 Debian 12.7上运行的 BeaglePlay 上获得了 CC1352P7的链接。  

以下是相关说明：

• 复制该文件： openbeagle.org/jkridner/BeagleBoard-DeviceTrees/-/raw/update-no-bcfserial-overlay-5.10-unified/src care/arm64/overles/k3-am625-beagleplay-bcfserial-no-firmware.dts
   /opt/source/dtb-6.6-Beagle、src、ARM64/overlays
• 运行以下脚本 /opt/source/dtb-6.6-Beagle/build_n_install.sh
• 编辑 /boot/firmware/extlinux/extlinux.conf 以加载 BCF-noserial dtbo、如下所示：
  

  menu title BeaglePlay eMMC (extlinux.conf) (swap enabled)
  
  timeout 50
  
  default eMMC disable BCFSERIAL
  
  label eMMC disable BCFSERIAL
      kernel /Image
      append root=/dev/mmcblk0p3 ro rootfstype=ext4 rootwait net.ifnames=0
      fdtdir /
      fdtoverlays /overlays/k3-am625-beagleplay-bcfserial-no-firmware.dtbo
      #initrd /initrd.img
  
  label copy eMMC to microSD
      kernel /Image
      append root=/dev/mmcblk0p3 ro rootfstype=ext4 rootwait net.ifnames=0 init=/usr/sbin/init-beagle-flasher
      fdtdir /
      initrd /initrd.img
  
  label eMMC (debug)
      kernel /Image
      append console=ttyS2,115200n8 earlycon=ns16550a,mmio32,0x02800000 root=/dev/mmcblk0p3 ro rootfstype=ext4 rootwait net.ifnames=0
      fdtdir /
      #initrd /initrd.img
  
  label eMMC (default)
      kernel /Image
      append root=/dev/mmcblk0p3 ro rootfstype=ext4 resume=/dev/mmcblk0p2 rootwait net.ifnames=0 quiet
      fdtdir /
      #fdtoverlays /overlays/<file>.dtbo
      #initrd /initrd.img

现在、您可以在 Debian 12.7上使用 CC1352P7、采用较新的6.6 ti 内核。

此致、

Arthur

这是一个好消息。 这个6.6内核是否修复了 UART 的勘误表、或者这仍然是另一个步骤？

Josh

您好、Joshua、

补丁确实存在于 Debian 12.7发行版中使用的内核中： linux/drivers/tty/serial/8250/8250_OMAP-Lc、位于 v6.6.32-ti-arm64-R10·BeagleBoard/Linux·GitHub

• 串行：8250_OMAP：勘误表 i2310 - ti-linux-kernel/ti-linux-kernel 的实现-此存储库包含一个 Linux 内核、该内核已与基于 kernel.org 上的开源 Linux 内核的出色 TI 开源补丁集成。 需要将对此内核的贡献发送到开源社区进行审核。
• 串行：8250_OMAP：修复带有 RX FIFO 级别检查的勘误表 i2310 - ti-linux-kernel/ti-linux-kernel -此存储库包含一个 Linux 内核、该内核已与基于 kernel.org 上的开源 Linux 内核的出色 TI 开源补丁集成。 需要将对此内核的贡献发送到开源社区进行审核。

请告诉我它是如何为您工作的。

此致、

Arthur

Arthur、

我遇到了一些麻烦,这样做。

/dev/ttyS4出现、但当我尝试打开它时、我得到：

Debian@BeagleBone：/dev$ python -m serial.tools.minitrem

－－可用端口：
--输入端口索引或全名：/dev/ttyS4
无法打开端口"/dev/ttyS4 "：无法配置端口：(5、"输入/输出错误")
Debian@BeagleBone：/dev$

有没有其他的配置我需要做,我不记得做它的旧发行版,我没有在我的笔记中关于这一点。

Josh

似乎已将端口重新分配为/dev/ttyS1

您好、Joshua、

我今天尝试了分发(使用 cc1352r-Flasher 和--play 标志)、它工作正常。 明天我会再试一次这个明智的项目。

顺便说一下、在我们的会议结束后、BeagleBoard 基于 Debian 12.9发布了一个新版本的发行版、其中我概述的过程不是必需的、至少是您必须手动导入文件的部分。 您仍然需要使用"禁用 BCFSERIAL"配置。

即： BeaglePlay Debian 12.9 2025年03月01日 Minimal Flasher (V6.12.x-ti)- BeagleBoard

此致、

Arthur

Arthur,我运行12.7发行夜间,不幸的是仍然看到校验和错误。 在大约10小时的运行时间内只有一个。 报告的错误如下所示：

__MAIN__-警告-收集器日志：7708.894：错误：UART：chksum 错误
__MAIN__-警告-收集器日志：7708.894：错误：错误：incoming-msg msg (0x71b94) nbytes=89 len = 84 [ 0xFE 0x54 0x42 0x85 0x02 0x01 0x00 0x00]
__MAIN__-警告-收集器日志：7708.894：00000000：Fe 54 42 85 02 01 00 00 00 00 00 02 bb aa |.TB…… |
__MAIN__-警告-收集器日志：7708.894：00000010：00 00 00 00 00 1c 3a-05 00 0b 00 BA AB AB |…… ：.... |
__MAIN__-警告-收集器日志：7708.895：00000020：F7 00 ea FD 33 33 33 33 33 33 05 03 38 |... 333333333...8|
__main__-警告-收集器日志：7708.895: 00000030: 30 23 00 21 00 00 00 1e-2a 1e 0A 18 08 01 12 09 |0#.!...* |
__MAIN__-警告-收集器日志：7708.895：00000040：12 05 2D 31 52 96 43 10-88 84 01 0e fe 54 42 85 |..-1R.C. TB。|
__main__-警告-收集器日志：7708.895：00000050：02 0A 00 00 00 00 00:00                     |……       |

您将注意到、在与失败消息关联的数据块期间、另一条消息(其标题突出显示)已进入。 这对我来说意味着、失败消息的一些字节在该块中的某个位置丢失、另一条消息开始并作为前一条消息的一部分被读取。

您是否预计12.9发行版对 UART 有任何进一步的更改？ 我计划今天旋转它、看看它是否能满足我的需求。

Arthur、它看起来不像 dts 文件创建的文件。 dtbo 不存在于/boot/firmware/overlays 或/boot/firmware/ti 中

此外、当我像以前一样添加 dts 文件、并通过在/opt/source/dtb-6.12-Beagle/build_n_install.sh 中运行脚本进行编译时 、它也不会将 dtbo 放置在任何这些位置。 因此、当使用 eMMC 禁用 BCFSERIAL 进行引导时、引导消息中存在错误：

输入选项：1.
1：     eMMC 禁用 BCFSerial
正在检索文件：/Image
附加：root=/dev/mmcblk0p3 ro rootfstype=ext4 rootwait net.ifnames=0
正在检索文件：/ti/k3-am625-beagleplay.dtb
正在检索文件：/overlays/k3-am625-beagleplay-bcfserial-no-firmware.dtbo
加载叠加/overlays/k3-am625-beagleplay-bcfserial-no-firmware.dtbo 失败
##展开的设备树 blob 为88000000
  使用位于0x88000000的 FDT blob 进行引导
工作 FDT 设置为88000000
  正在将设备树加载到000000008ffed000、结束000000008ff64c ...确定
工作 FDT 设置为8ffed000

正在启动内核...

有什么想法在这里发生了什么？

事实证明、在12.9中、DTS 文件现在是 dtso 文件。 一旦重命名了覆盖文件并重新构建了所有内容、它就能正常工作。

Josh

Arthur、

除了 dtbo 文件不像他们说的那样存在的问题,还有其他问题,我认为与我的更改无关。 12.9发行版在大约1/3的时间引导期间挂起。

下面是一些错误输出、但我有几个不同的故障、这是最常见的故障：

[  OK  ] Created slice system-serial\x2dget▒[    5.001562] systemd[1]: Created slice system-serial\x2dgetty.slice - Slice /system/serial-getty.
▒▒slice - Slice /system/serial-getty.
[    5.022992] Unable to handle kernel paging request at virtual address 77d1cb19d1b2fcd5
[    5.023011] Mem abort info:
[    5.023014]   ESR = 0x0000000096000004
[    5.023017]   EC = 0x25: DABT (current EL), IL = 32 bits
[    5.023023]   SET = 0, FnV = 0
[    5.023026]   EA = 0, S1PTW = 0
[    5.023029]   FSC = 0x04: level 0 translation fault
[    5.023033] Data abort info:
[    5.023035]   ISV = 0, ISS = 0x00000004, ISS2 = 0x00000000
[    5.023039]   CM = 0, WnR = 0, TnD = 0, TagAccess = 0
[    5.023043]   GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0
[    5.023048] [77d1cb19d1b2fcd5] address between user and kernel address ranges
[    5.023056] Internal error: Oops: 0000000096000004 [#1] PREEMPT_RT SMP
[    5.023065] Modules linked in: ip_tables
[    5.023081] CPU: 3 UID: 0 PID: 1 Comm: systemd Not tainted 6.12.13-ti-arm64-r24 #1bookworm
[    5.023090] Hardware name: BeagleBoard.org BeaglePlay (DT)
[    5.023095] pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)
[    5.023102] pc : ___slab_alloc+0x118/0xa00
[    5.023122] lr : ___slab_alloc+0x68/0xa00
[    5.023130] sp : ffff8000823bb690
[    5.023132] x29: ffff8000823bb690 x28: 00000000000081a4 x27: 77d1cb19d1b2fccd
[    5.023142] x26: ffff00007fb9f630 x25: fffffdffc007b480 x24: ffff800081a89650
[    5.023151] x23: ffff800080334e78 x22: 000000000000000e x21: 0000000000000cc0
[    5.023160] x20: 00000000ffffffff x19: ffff000000401500 x18: 0000000000000014
[    5.023169] x17: 0000000041e9975a x16: 000000007a164e86 x15: 00000000f6382bd3
[    5.023179] x14: 0000000000000002 x13: 0000000000000028 x12: 0101010101010101
[    5.023188] x11: 7f7f7f7f7f7f7f7f x10: fefefefefefefeff x9 : ffff8000812d0d10
[    5.023197] x8 : 0101010101010101 x7 : ffff0000006bdc80 x6 : fefeff6479646471
[    5.023206] x5 : 000000000000000e x4 : ffff00007fb9f668 x3 : f00ea61853aa3f62
[    5.023215] x2 : 0000000000000008 x1 : 000000000000f003 x0 : d5fcb2d119cbd177
[    5.023225] Call trace:
[    5.023229]  ___slab_alloc+0x118/0xa00
[    5.023238]  __slab_alloc.constprop.0+0x5c/0x88
[    5.023247]  __kmalloc_node_track_caller_noprof+0xa4/0x368
[    5.023256]  kstrdup+0x54/0x98
[    5.023266]  kstrdup_const+0x48/0x60
[    5.023274]  __kernfs_new_node+0x5c/0x218
[    5.023285]  kernfs_new_node+0x70/0xa0
[    5.023293]  __kernfs_create_file+0x38/0x100
[    5.023302]  cgroup_addrm_files+0x158/0x300
[    5.023311]  css_populate_dir+0x100/0x1d8
[    5.023319]  cgroup_mkdir+0x1d0/0x588
[    5.023329]  kernfs_iop_mkdir+0x68/0xa8
[    5.023337]  vfs_mkdir+0x1a0/0x240
[    5.023347]  do_mkdirat+0x148/0x178
[    5.023353]  __arm64_sys_mkdirat+0x38/0x58
[    5.023359]  invoke_syscall+0x70/0x100
[    5.023369]  el0_svc_common.constprop.0+0x48/0xf0
[    5.023378]  do_el0_svc+0x24/0x38
[    5.023385]  el0_svc+0x30/0x118
[    5.023397]  el0t_64_sync_handler+0x100/0x130
[    5.023406]  el0t_64_sync+0x190/0x198
[    5.023417] Code: f9405e63 8b020360 f9400741 dac00c00 (f8626b62)
[    5.023426] ---[ end trace 0000000000000000 ]---
[    5.023445] Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b
[    5.023450] SMP: stopping secondary CPUs
[    5.023464] Kernel Offset: disabled
[    5.023467] CPU features: 0x00,00000080,00200000,4200421b
[    5.023474] Memory Limit: none
[    5.312147] ---[ end Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b ]---

我的计划是使用12.7 minimal。

您好、Joshua、

很遗憾、我看到的和您一样... 我将通知 BeagleBoard。

此致、

Arthur

Arthur、

这里的另一个突出事实是、当我在外部 Launchpad 上运行收集器时、发生了相同的字节丢失和校验和错误问题、这与 Sitara 中存在错误的低级 UART 不一致。 相反、它似乎是由内部 UART 和 LaunchPad 使用的 USB 转串行实现驱动程序共有的更高级别的内容。

您还将记得、当我通过外部 FTDI 电缆连接 Launchpad 时、问题没有发生、这意味着用于与 FTDI 电缆通信的驱动器不会出现该问题、而与 Launchpad 调试器中的 CDC ACM 实现进行通信的驱动器会出现该问题。

您好、Joshua、

没错、尽管 XDS 和 Sitara UART 出现相同的症状、但我当时认为它们有相同的根本原因。

现在、从您的最新消息中观察到了一个有趣的情况：

请注意标题如何"填充"上一条消息(考虑32位对齐)。 这可能只是巧合、但您是否在上一个日志记录会话中观察到了类似的内容？

此致、

Arthur

Arthur、这里还有四个晚上发生的事情：

在这个示例中、标头具有32位对齐方式重复。

16433.846: ERROR: uart: chksum error
16433.846: ERROR: ERROR: incoming-msg msg(0x145175) nbytes=89 len=84 [ 0xfe 0x54 0x42 0x85 0x02 0x06 0x00 0x00]
16433.846: 00000000: fe 54 42 85 02 06 00 00-00 00 00 00 00 02 bb aa |.TB.............|
16433.846: 00000010: 00 00 00 00 00 00 27 92-72 00 0b 00 ba ab ba ab |......'.r.......|
16433.847: 00000020: cf 00 df a9 33 33 33 33-33 33 33 33 05 03 03 06 |....33333333....|
16433.847: 00000030: fb 2c 00 21 00 00 00 1e-2a 1e 0a 18 08 01 12 09 |.,.!....*.......|
16433.847: 00000040: fe 54 42 85 02 02 00 00-00 00 00 00 00 02 bb aa |.TB.............|
16433.847: 00000050: 00 00 00 00 00 00 4a a0-72                      |......J.r       |

在这个示例中、在标头的中间插入了一个额外的00字节。

33826.407: ERROR: uart: chksum error
33826.407: ERROR: ERROR: incoming-msg msg(0x2ac53f) nbytes=89 len=84 [ 0xfe 0x54 0x00 0x42 0x85 0x02 0x02 0x00]
33826.407: 00000000: fe 54 00 42 85 02 02 00-00 00 00 00 00 00 02 bb |.T.B............|
33826.408: 00000010: aa 00 00 00 00 00 00 7d-ca 97 00 10 00 ba ab ba |.......}........|
33826.408: 00000020: ab 9c 00 d1 c6 33 33 33-33 33 33 33 33 05 03 03 |.....33333333...|
33826.408: 00000030: 74 6f 98 01 21 00 00 00-1e 2a 1e 0a 18 08 01 12 |to..!....*......|
33826.408: 00000040: 09 05 2d 00 00 00 00 12-09 08 03 12 05 2d cb 27 |..-..........-.'|
33826.408: 00000050: 93 43 10 ad ab 1c 9b fe-52                      |.C......R       |

在这一个中、我们再次看到32位对齐。

39188.064: ERROR: uart: chksum error
39188.064: ERROR: ERROR: incoming-msg msg(0x31afa7) nbytes=89 len=84 [ 0xfe 0x54 0x42 0x85 0x02 0x02 0x00 0x00]
39188.064: 00000000: fe 54 42 85 02 02 00 00-00 00 00 00 00 02 bb aa |.TB.............|
39188.064: 00000010: 00 00 00 00 00 00 35 34-c2 00 07 00 ba ab ba ab |......54........|
39188.064: 00000020: 9c 00 d1 22 33 33 33 33-33 33 33 33 05 03 03 ed |..."33333333....|
39188.065: 00000030: 93 99 01 21 00 00 00 1e-2a 1e 0a 18 08 01 12 09 |...!....*.......|
39188.065: 00000040: fe 54 42 85 02 07 00 00-00 00 00 00 00 02 bb aa |.TB.............|
39188.065: 00000050: 00 00 00 00 00 00 be 3e-c2                      |.......>.       |

最后一个是对齐对象。

39188.064: ERROR: uart: chksum error
39188.064: ERROR: ERROR: incoming-msg msg(0x31afa7) nbytes=89 len=84 [ 0xfe 0x54 0x42 0x85 0x02 0x02 0x00 0x00]
39188.064: 00000000: fe 54 42 85 02 02 00 00-00 00 00 00 00 02 bb aa |.TB.............|
39188.064: 00000010: 00 00 00 00 00 00 35 34-c2 00 07 00 ba ab ba ab |......54........|
39188.064: 00000020: 9c 00 d1 22 33 33 33 33-33 33 33 33 05 03 03 ed |..."33333333....|
39188.065: 00000030: 93 99 01 21 00 00 00 1e-2a 1e 0a 18 08 01 12 09 |...!....*.......|
39188.065: 00000040: fe 54 42 85 02 07 00 00-00 00 00 00 00 02 bb aa |.TB.............|
39188.065: 00000050: 00 00 00 00 00 00 be 3e-c2                      |.......>.       |

32位对齐发生了很长时间、但并不是每次都发生、这与我在过去看到的结果也是一致的。

Josh

阿瑟,对这有什么想法吗?

Josh

Arthur、

我忘了问、为什么您认为 XDS 和 Sitara UART 问题是无关的？ 可观察到的症状似乎是相同的。

您好、Joshua、

对延迟深表歉意。 在 Sitara UART/XDS UART 上、它们不使用相同的驱动程序(CDC ACM/OMAP 串行)。

在主要问题上、我有另一个可以运行的提示/测试。 如果从 Docker 容器运行15.4网关堆栈、该怎么办？ 这是我实际运行 Wi-SUN /WSMS/15.4堆栈演示的方式(出于分发原因、需要进行离线安装等)。

通过将串行设备的完全控制授予容器、我们可以尝试查看是否有任何因素可能干扰串行设备。 我发现这种方法非常可靠。

不过、我知道这不是您可以选择的、但鉴于 BeaglePlay Debian 版本上预装了 Docker、这可能是值得尝试的。 如果问题仍然存在、我仍需要设置一个测试网络来自行观察问题。

此致、

Arthur

Arthur、

还有几个问题。

1.) 如何在容器中运行这将使您能够找到问题？ Docker 是否有某种串行超支或类似的工具？

2.) Sitara 和 XDS UART 与 FTDI 器件的一个共同点是缓冲器的大小、以及 UART 在遇到问题之前可能会取消服务的时间。

3.) 与点2相关、是否有办法调整 Sitara Rx 缓冲器的大小？

4.) 我缩小这个范围的另一个思路是用导线环回 UART、然后发送大量随机或图形化数据、并检查 RX 端是否有正确的数据。

Joshua、

1)它将允许我们,如果它更可靠的工作,开始怀疑系统中的其他东西。 如您所知,Debian 发行版附带大量在运行时启用的服务。

2)这是一个非常好的点,你在这里。 从 FTDI 的 usbserial 来看、有时看起来是64个、有时可能不是： v6.6.32-ti-ARM64-R10 BeagleBoard/Linux··GitHub 上的 linux/drivers/usb/serial/ftd_sio.c 

3)它似乎是硬编码: linux/drivers/tty/serial/8250/8250_OMAP-Lc at v6.6.32-ti-arm64-R10·BeagleBoard/Linux·GitHub 。 为了确定这一点、我建议在 Sitara 论坛上提问、因为这符合公众利益。

此致、

Arthur

我遇到了 ITM 日志记录的另一个问题。 我已将传感器代码移植到最新的8.30 SDK 中、部分原因是为了能够访问日志记录功能。 我发现的是：

• ITM 日志记录的启用方式与我在收集器 Mac 示例中所做的相同。  
• 使用同一引脚。  
• 目标板是外部电路板、因此我专门将 SWO 输出引脚(IOID 18)连接到我用于调试器的 LaunchPad 上的 SWO 引脚接头。
• 我用示波器探测了 SWO 引脚、看看看起来是正确的波形。
• 我正在使用命令行： tilogger --elf ..\sensonext\SSNDB_830\Release\SSNDB_830.OUT iTM COM31 12000000 stdout、其中 COM31是 XDS 辅助数据端口。
• 我看不到来自 tilogger 的输出。
• 我也尝试了 Wireshark 变体、它也不起作用。

是否还有其他需要配置的事项、即调试引脚中需要连接的另一个引脚？

我尝试打开 dmm_154sensor_remote_display_oad_app 的日志记录、并直接在1352R Launchpad 上运行它、但它仍然无法正常工作。 我在 SWO 引脚上看到数据、但记录器看不到。 将 PuTTY 连接到配置为12000000的辅助端口并且观察字符也不会显示任何内容。

我真的不明白为什么它不起作用,有什么想法?