• State TI Thinks Resolved
  • Locked Locked
  • Replies 7 replies
  • Answers 1 answer
  • Subscribers 55 subscribers
  • Views 1101 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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: Upgrade Ti-RTOS in Z-Stack 1.22a: section placement failed

Stephanie Werner
Expert 1665 points
Part Number: CC2630
Other Parts Discussed in Thread: Z-STACK,

Tool/software: TI-RTOS

Hello everyone.

I've been upgrading Ti-RTOS in our z-stack project from 2.11.01.09 to 2.14.04.31.

So far i fixed all the issues that arose from this but one: 

Error[Lp011]: section placement failed 
          unable to complete "place at" directives with a total estimated minimum size of 0x58 bytes in <[0x0001ffac-0x0001ffff]> (total space 0x54). 
Error[Lp015]: section placement failure: overcommitted content in [0x0001ffac-0x0001ffff]

Using the .map file i found out, that this memory section corresponds to the ccfg:

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

Then i saw, that between those versions (maybe in tirtos 2.13.00.06?) the ccfg_t struct had another uint32 added, which i strongly suspect is the reason for my linker error.

Now i'm a bit unsure on how to procede. Commenting out one of the uint32 would kinda resolve the issue, however i don't think this is the best option... can i somewhere re-specify the size of ccfg to the now correct 0x58 byte?

thanks in advance!

stephanie

  • 0
    TI__Guru**** 219527 points
    Hello Stephanie,

    Upgrading TI-RTOS versions inside of a technology stack is rather difficult and not recommended: e2e.ti.com/.../

    I will contact you externally for further support.

    Regards,
    Ryan
  • 0 in reply to Ryan Brown1
    Expert 1665 points
    Thank you Ryan for your reply!
    I noticed, that it's rather difficult to upgrade. I've spent half my workday today, to do it :-)
    Thank you for the link, it was very insightful! I will have to explore the options before me.
    Moving up to the cc2652 isn't really an option at the moment, due to other constraints.

    I have to say it's kinda disappointing that there haven't been more updates on the zstack1.22 or versions with newer tirtos...

    You say updating tirtos is not recommended, but it would be possible - right? I mean apart from the ccfg size issue it seems to work.

    I will have to further look into our options and consult with my superior on how we proceed on Monday.
  • 0 in reply to Stephanie Werner
    TI__Guru**** 219527 points
    Updating TI-RTOS is possible but I've never gone through it myself so I don't know what the necessary steps would be. Please stay in touch and let us know what can be done for further support.

    Regards,
    Ryan
  • 0 in reply to Ryan Brown1
    Expert 1665 points

    Well, the steps mostly have been adjusting the custom_argvars: Changing XDCPATH, DRIVERLIB and DRIBERLIBCORE to the tirtos214 paths, as well as changing XDCROOT to the newer xdctools-path (which i forgot at first).

    There have been some changes within batmon (a function had been renamed and a few functions removed), which forced me to remove a call to AONBatMonMeasurementCycleSet from PWRMON_init, since this function has been removed.

    Now, the only thing that keeps the firmware from linking is the issue, that somewhere the size for ccfg has been limited to 0x54 byte :/

    So technically, updating to a newer TI-RTOS version should be okay but is not recommended, because there's no "guideline" to do, it? I mean, it would bring some bugfixes

  • 0 in reply to Stephanie Werner
    Expert 1665 points
    i have to correct this:
    >Now, the only thing that keeps the firmware from linking is the issue, that somewhere the size for ccfg has been limited to 0x54 byte :/
    in tirtos' .lds files a memory-range of 0x1FFA8 - 0x1FFFF is set, but somehow the linker tries to place the ccfg within the range of 0x1FFAC - 0x1FFFF
  • 0 in reply to Stephanie Werner
    TI__Guru**** 219527 points
    Hi Stephanie,

    TI has decided to not spend the effort to verify/certify an updated Z-Stack HA 1.2.2a for the CC2630/2650. Customers can do this themselves but TI does not provide any guideline or offer additional support for such a custom solution. In moving forward we recommend that customers upgrade to the Z-STACK or SIMPLELINK-CC26X2-SDK/SIMPLELINK-CC13X2-SDK solutions but are aware that this may not fit everyone's needs for a variety of reasons.

    Did the stack I provided offline resolve the CCFG issue? Any more noticeable differences other than what you've recognized and resolved?

    Regards,
    Ryan
  • 0 in reply to Ryan Brown1
    Expert 1665 points

    Thank you for your reply.

    That's kind of what i expected sadly. I can't understand that decision though, given what information we received from our local FAE about the timetable of the CC1352/CC2652. I suppose we will still have to see how to procede.

    The stack did resolve the ccfg issue / compiled but i haven't yet managed to port and run our application.