This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

[参考译文] RTOS/CC2630:升级 Z-Stack 1.22a 中的 TI-RTOS:段放置失败

Guru**** 2544120 points
Other Parts Discussed in Thread: Z-STACK, CC2630

请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

https://e2e.ti.com/support/wireless-connectivity/zigbee-thread-group/zigbee-and-thread/f/zigbee-thread-forum/738787/rtos-cc2630-upgrade-ti-rtos-in-z-stack-1-22a-section-placement-failed

器件型号:CC2630
Thread 中讨论的其他器件:Z-stack

工具/软件:TI-RTOS

大家好。

我在我们的 z-stack 项目中将 TI-RTOS 从2.11.01.09升级2.14.04.31

到目前为止、我修复了由此产生的所有问题、但只有一个问题:

ERROR[Lp011]:段放置失败
无法在<[0x0001ffac-0x0001FFFFFF]>(总空间0x54)中完成估计最小总大小为0x58字节的"Place at"指令。
ERROR[Lp015]:段放置失败:[0x0001ffac-0x0001FFF]中的内容过量

使用我找到的.map 文件、该存储器部分对应于 ccfg:

"A1": 0x58
.ccfg const 0x0001ffac 0x58 ccfg.o [1]
- 0x00020004 0x58 

然后、我看到了这些版本之间的情况(可能在 tirtos 2.13.00.06中?) ccfg_t 结构添加了另一个 uint32、我强烈怀疑这是我的链接器错误的原因。

现在我对如何处理有些不确定。 注释掉其中一个 uint32会解决这个问题、但我认为这不是最好的选择... 我可以在某个地方将 ccfg 的大小重新指定为现在正确的0x58字节吗?

提前感谢!

Stephanie

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。
    您好 Stephanie、

    在技术堆栈内升级 TI-RTOS 版本相当困难、不建议: e2e.ti.com/.../

    我将从外部与您联系以获得进一步的支持。

    此致、
    Ryan
  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。
    感谢 Ryan 的回复!
    我注意到、升级相当困难。 我今天花了半天的时间来完成它:-)
    感谢您的链接、它非常有洞察力! 我将不得不探讨前面的选项。
    由于其他限制、现在升级到 cc2652并不是一个真正的选择。

    我不得不说、对于 zstack1.22或更新版本的 tirtos 没有进行更多更新、这有点令人失望...

    您说不建议更新 tirtos、但可能-对吧? 我的意思是、除了 ccfg 大小问题之外、它似乎可以正常工作。

    我将进一步研究我们的选择,并就如何在星期一继续工作与我的上司进行磋商。
  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。
    更新 TI-RTOS 是可能的、但我自己从未完成过、因此我不知道需要执行哪些步骤。 请保持联系、并告知我们可以采取哪些措施来获得进一步支持。

    此致、
    Ryan
  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    嗯、这些步骤主要是调整 custom_argvars:将 XDCPATH、DRIVERLIB 和 DRIBERLIBCORE 更改为 tirtos214路径、以及将 XDCROOT 更改为更新的 xdctools-path (我一开始就忘记了)。

    batmon 中发生了一些更改(已重命名一个函数并删除了一些函数)、由于此函数已被删除、因此迫使我从 PWRMON_init 中删除对 AONBatMonMeasureCyclSet 的调用。

    现在,阻止固件链接的唯一问题是,在某个地方,ccfg 的大小限制为0x54字节:/

    因此、从技术上讲、更新到较新的 TI-RTOS 版本应该是可以的、但不建议这样做、因为没有"指南"可以这么做。 我的意思是、它会带来一些错误修复

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。
    我必须纠正以下问题:
    >现在,阻止固件链接的唯一问题是,在某个地方,ccfg 的大小限制为0x54字节:/
    在 tirtos'.lds 文件中、设置了0x1FFFA8 - 0x1FFFF 的存储器范围、但链接器会以某种方式尝试将 ccfg 置于0x1FFAC - 0x1FFFF 的范围内
  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。
    您好、Stephanie、

    TI 已决定不花费精力验证/认证 CC2630/2650的更新 Z-Stack HA 1.2.2a。 客户可以自行完成此操作、但 TI 不提供任何指南或对此类定制解决方案提供额外支持。 展望未来、我们建议客户升级到 Z-stack 或 SIMPLELINK-CC26X2-SDK/SIMPLELINK-CC13X2-SDK 解决方案、但我们知道、由于各种原因、这可能不适合每个人的需求。

    我提供的堆栈是否离线解决了 CCFG 问题? 除了您已认识和解决的问题之外、还有其他更明显的差异吗?

    此致、
    Ryan
  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    感谢你的答复。

    这是我所期望的。 但是、鉴于我们从当地 FAE 收到的有关 CC1352/CC2652时间表的信息、我无法理解这一决定。 我想,我们仍然必须了解如何处理。

    堆栈确实解决了 ccfg 问题/已编译、但我尚未成功移植和运行我们的应用程序。