工具/软件：TI-RTOS
您好！
我将一些代码从 MSP432P401R 移植到 MSP432P401M、因此 SRAM 已从64KB 减少到32KB。 我避免了代码中的动态内存分配、但它在您的驱动程序和蓝牙堆栈中得到了广泛使用、之前我为堆分配了16KB、但不再有空间进行这种分配、因此必须将其减少到7KB。 这并不是非常相关的、但重点是 simplelink_msp432_sdk_bluetooth_plugin_1_25_00_42的错误处理不足、如果初始化失败、将会泄漏内存。
相关配置：我使用的是 sapParams.port.remote.STACKSIZE = 2048的 UART 传输。
我将要介绍几种不同的情况、但从代码调用的相关函数始终为 SAP_OPEN。
在代码中、它最初执行默认参数、回调配置。 如果失败、则不需要进行清理、因此没关系。 然后调用 SNP_OPEN、后者不分配存储器、但要求调用 SNP_CLOSE 以销毁其信标。 因此、如果在 portType 中传递的无效、我们将返回一个错误而不调用 SNP_Close。 这不会泄漏内存或无限循环、但仍然不理想。 最后、我们进入 NPIITASK_OPEN、 这是大多数问题发生的地方(NPI_TASK_POSIX.c)。
我们有同样的 SEM_init 调用、但主要问题是 npiTxQueue、 npiRxQueue、 npiSyncRxQueue、 npiSyncTxQueue 和 npiPacketQueue 全部打开(这会进行分配)、而不检查结果。 因此、其中一些可能已经分配、而另一些可能没有分配。 再往下一点、如果分配 npiTaskStack 失败、那么我们刚刚泄露了几 KB 的 RAM、我们永远不会回来。 即使 SAP_OPEN 失败、我们也可能调用 SAP_CLOSE、但这很容易出错、因为它假定 SAP_OPEN 成功、并且如果其中一个队列未能分配、则我们将尝试在-1上调用 MQ_FREE、然后尝试在其中调用 Memory_free、 这将导致各种问题。 因此、基本而言 、NPITEK_OPEN 迫切需要错误处理、并在发生故障时释放任何分配的资源。 此外、 npiTaskStack 似乎 是完全冗余的、甚至从未使用过？ pthread_attr_setstacksize 仍会导致 pthread_create 分配栈、因此我们刚刚浪费了更多的 RAM、完全没有理由。
转到 NPIL_openTL 、我们会发现内存泄漏(npirxBuf、 npiTxBuf)、如果其中一个缓冲区未能分配、可能会导致内存损坏(实际上、它将尝试覆盖0x00000000 、因为它是闪存、但仍然不是好的做法)以及 TransportOpen 内的无限循环。 transportOpen 为 我的 NPILLUART_openTransport 别名、因此我转到这里。
还有两个可能泄漏的队列(uartQueueRec、 uartQueueSend)、但更令人烦恼的是、pthread 调用的"错误处理"是无限循环。 我正在为电池供电设备编写固件、蓝牙主要便于配置。 如果失败了、这是一种耻辱、我想如果最糟糕的事情发生得更糟、我可以复位。 但是、如果初始化从未真正返回并阻止低功耗模式、我将很快耗尽电池、这会使整个器件无用。
很抱歉这个冗长的帖子、但我们能否在这个所谓的发布质量代码中得到一些错误处理？ 我没有列出所有泄漏等、但我觉得我已经说明了我的观点。 我已经在自己编译、所以我将仔细研究并修复影响我的问题、但我不能成为唯一受此困扰的人。 我们至少可以得到：
- NPILLUART_openTransport 的返回值、指示错误(清理任何分配的资源后)。 可能 SPI 也存在同样的问题。
- NPITEK_OPEN 和 SAP_OPEN 中的资源清理。
- 当 SAP_OPEN 未返回 SNP_SUCCESS 时、保证我们至少未泄露任何资源。
- 能够配置队列深度、以便我们可以调整更多资源受限设备的内存要求。 我想知道、只在 NPI_TASK_POSIX.c 中的队列上放置_npix_t 而不是指针是否有意义、以保存4x16x4 = 256字节。
