-1

我正在尝试在 STM32L0 Cortex M0+ 控制器上测试 ThreadX 的示例/演示代码。特别是在 GitHub 上找到的 sample_thread.c 代码。我使用了皮质 M0 端口的示例代码并编译了代码。在这一点上,一切都很好,或者我认为,端口看起来已经正确映射到我的控制器;即内存起始地址和RAM 是正确的。

我遇到的问题是,在为线程分配空间时,我在某些动态内存分配功能期间遇到了硬故障。我发现硬故障是在函数 _tx_byte_pool_search() 中触发的,它发生在检查块指针时,在一个实例中:

*next_block_link_ptr =  *this_block_link_ptr;

执行此行时,其中一个块指针以内存区域外的无效地址结束,通常为 0xAAAAAAAA。我试图了解 ThreadX 究竟是如何构建这些内存块的,但我不应该这样做。此功能应该按预期工作,但事实并非如此。所以我在想我做错了什么,但是已经没有想法可以检查了。如果有更多经验的人可以提供一些有用的方向或想法。

我在 _tx_initialize_low_level.S 中设置了启动代码,以提供 first_unused_memory 的地址,该地址用于 tx_application_define()。我认为这个地址基本上是内存分配工作所需要的。也许我错过了一些东西。

谢谢大家的帮助。

4

1 回答 1

0

您描述的问题暗示了如何将内存分配给程序的不同部分的不匹配。正如您所做的那样,我首先要检查的两点是链接描述文件,以及分配的 RAM 末端的位置是否已正确定义。问题也可能在其他地方,但这些可能是原因。

首先确保链接器文件与您的系统匹配。请查阅处理器参考手册和数据表。您没有提到您使用的是哪个工具链,链接器命令文件(或链接器脚本文件)格式会因工具链而异。

其次,已用内存的结束位置和空闲内存的开始位置应与您的系统相匹配。您可以查看通常存储在映射文件中的链接器输出,以了解应用程序正在使用多少内存。确保这是传递给 tx_application_define 的内容。

处理第二点的更好方法是根本不使用此参数,而是为每个元素(线程控制块、其他控制块、线程堆栈等)静态分配内存(作为全局变量)。基本示例使用这种复杂的内存分配方式有两个原因:足够灵活,无需修改即可在许多不同的架构中运行,以及在少量代码中显示尽可能多的 API;作为演示很有趣,但不是使用系统的首选方式。

于 2021-08-03T09:17:23.320 回答