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.

ZIGNV_ADDRESS_SPACE clarification/question

Other Parts Discussed in Thread: CC2530, Z-STACK, REMOTI, TIMAC

Hi All,

I am trying to gain a better understanding of the relationship between the code banks and the size of the part.

I built the SampleApp application include the latest Z-Stack 2.4 which is currently for the CC2530 that has  a 256 KB flash. However, I tried to rebuild the same project for a 128 KB flash part with no code changes nor project settings changes except for changing the General Options>>Target>>Device Information>>Device to point to the 128 KB device description file. I then end up with the following error:

Error[e16]: Segment ZIGNV_ADDRESS_SPACE (size: 0x3000 align: 0) is too long for segment definition. At least 0x2fb7 more bytes needed. The problem occurred while processing the segment placement command "-Z(CODE)ZIGNV_ADDRESS_SPACE=_ZIGNV_ADDRESS_SPACE_START-_ZIGNV_ADDRESS_SPACE_END", where at the moment of placement the available memory ranges were "CODE:3f7b7-3f7ff"
   Reserved ranges relevant to this placement:
   CODE:3c412-3f7b6     BANKED_CODE
   CODE:3f7b7-3f7ff        ZIGNV_ADDRESS_SPACE
   BIT:0-7                           BREG
   BIT:80-97                      SFR_AN
   BIT:a0-af                       SFR_AN
   BIT:b8-c7                      SFR_AN
   BIT:e8-ef                       SFR_AN
   BIT:f8-ff                          SFR_AN

Any insight into what changes I would need to make to have the project support a different sized part (ie changes to code model, data model, or code banks) would be greatly appreciated!

  • Hi,

     

    Although it's for the much simpler RF4CE stack, RemoTI, it still is of help. Please see chapter 8 of:

    http://focus.ti.com/lit/ug/swru224a/swru224a.pdf

     

    Hope this helps,

    Torbjørn

  • Hi Torbjorn,

    Thank you so much for that document. It was really helpful. However, I am still having a similar error.

    I set my

    HAL_NV_PAGE_END = 63

    HAL_NV_PAGE_CNT = 2.

    Therefore, my NV memory space should start on the 14th page of the last bank which is

    -D_ZIGNV_ADDRESS_SPACE_START = 0x3E800

    and then I set

    -D_ZIGNV_ADDRESS_SPACE_END=(_ZIGNV_ADDRESS_SPACE_START+0xFFF)

    where the 0xFFF is due to each page being 0x800 bytes.

    and I left

    -Z(CODE)ZIGNV_ADDRESS_SPACE=_ZIGNV_ADDRESS_SPACE_START-_ZIGNV_ADDRESS_SPACE_END

     

    However, I still get the same error:

    Error[e16]: Segment ZIGNV_ADDRESS_SPACE (size: 0x1000 align: 0) is too long for segment definition. At least 0x1000 more bytes needed. The problem occurred while processing the segment placement command "-Z(CODE)ZIGNV_ADDRESS_SPACE=_ZIGNV_ADDRESS_SPACE_START-_ZIGNV_ADDRESS_SPACE_END", where at the moment of placement the available memory ranges were "-none-"
       Reserved ranges relevant to this placement:
       CODE:3e642-3f8af     BANKED_CODE
       BIT:0-7              BREG
       BIT:80-97            SFR_AN
       BIT:a0-af            SFR_AN
       BIT:b8-c7            SFR_AN
       BIT:e8-ef            SFR_AN
       BIT:f8-ff            SFR_AN

    Does that mean the NV memory space I have allocated is too small? Or does that mean something is still wrong in my settings?

    It also seems that as I increase the number of NV pages, the error of "At least X more bytes needed" seems to increase. When I declared 4 pages, it needed 0x2000 more bytes, 3 pages = 0x1800 more bytes, 2 pages = 0x1000 more bytes and 1 page = 0x800 more bytes.

    I also tried to change "-Z(CODE)ZIGNV_ADDRESS_SPACE=_ZIGNV_ADDRESS_SPACE_START-_ZIGNV_ADDRESS_SPACE_END" to END - START since I thought this was a simple subtraction and it seemed like you would get a negative value since END > START, but I got a different error.

  • With regard to the specific problem posted, the linker control file is placing the NV pages in a bank that does not even exist on the F128 part. There are no Z-Stack sample applications for the F128 part because none will fit, not even an End Device, anymore, I would suspect. Take a look at the f8w2530.xcl:

    C:\Texas Instruments\ZStack-CC2530-2.4.0-1.4.0\Projects\zstack\Tools\CC2530DB\f8w2530.xcl

    To see an example of a linker control file for a part smaller than the F256, you'll have to look at the TIMAC or RemoTI installer like Torbjørn recommends:

    C:\Texas Instruments\RemoTI-CC253xDK-1.2.1\Projects\RemoTI\common\cc2530\ti_51ew_cc2530f128.xcl

  • From what I am understanding, it seems that the "code" lives in pages 0 through (16 - 1 - NV pages)... so does that mean you are saying "There are no Z-Stack sample applications for the F128 part because none will fit"..... Are you trying to say that the sample application is too large to fit into that space?

    Also, if the above assumption is correct, do you think any application (even the most basic) using Z-Stack will be too large to fit into an F128 part?

    Thanks so much again for your help.

  • Since the flash pages are 2K, there would be 128 in the F256 part - there are 16 pages per bank, and 8 banks in the F256.

    Compile the Z-Stack sample application that does about what you want to do and compile it and look at the bottom of the output .map file - you will see that the only builds that have a chance of fitting in the 128K part are the EndDevice targets. Take GenericApp, for example - functionality like LCD and MT task need to be removed to make it fit, and just barely, with SECURE=1:

     115 096 bytes of CODE  memory
          32 bytes of DATA  memory (+ 61 absolute )
       4 796 bytes of XDATA memory
         192 bytes of IDATA memory
           8 bits  of BIT   memory
         112 bytes of CONST memory

    Actually, you can put MT task back in:

     128 225 bytes of CODE  memory
          32 bytes of DATA  memory (+ 68 absolute )
       5 358 bytes of XDATA memory
         192 bytes of IDATA memory
           8 bits  of BIT   memory
         143 bytes of CONST memory

     

  • Hi Diry Harry,

    Thanks for the response, and it makes a lot more sense now. I did have another quick question I hope you could help with.

    In the fw82530.xcl included under the Tools directory in the Z-Stack 2.4 download, there following is included:

    -D_ZIGNV_ADDRESS_SPACE_START=(((_NR_OF_BANKS+1)*_FIRST_BANK_ADDR)-0x3800)

    -D_ZIGNV_ADDRESS_SPACE_END=(_ZIGNV_ADDRESS_SPACE_START+0x2FFF)

    -Z(CODE)ZIGNV_ADDRESS_SPACE=_ZIGNV_ADDRESS_SPACE_START-_ZIGNV_ADDRESS_SPACE_END

    Could you tell me where _NR_OF_BANKS and _FIRST_BANK_ADDR are defined. I've searched though the files and could not find it. Thanks so much.

  • It should be defined by the IAR project when you select Project-->Options-->General Options-->Device Information-->Device

  • Hi Dirty Harry,

    Back to earlier response about the EndDevice being the only project that will fit......

    I just built the older SampleApp projects from Z-Stack 1.4.3 for the CC2430 and got the following sizes:

    Coordinator - 97 KB; EndDevice - 75 KB; Demo - 94 KB

    And all the SampleApp projects from the new Z-Stack 2.4 are around 130-140 KB... So basically, my main question was, are these code size differences due mainly to the newer Z-Stack?

    We are trying to build a simple application such as the SampleApp which utilizes the Z-Stack to send messages and utilizes a simple set of peripherals.. in our case, a SPI interface.. which is why I am trying to determine if it is true that the Z-Stack has grown extensively, so that I can validate my request to obtain the larger part?

    Thanks so much again for your time and help.

  • ZigBee has not just grown, but metamorphosized. You last saw her as the ZigBee 2006 catepillar, and she is now the ZigBee 2007 / ZigBee PRO butterfly  ;)

    Z-Stack 1.4.3 is the last ZigBee 2006 stack that TI will produce, and ZigBee is no longer even certifiying products for ZigBee 2006. So TI does not make a ZigBee 2006 stack for the newer generation CC253x parts, but only the new ZigBee 2007/PRO stack (latest available is 2.4.0) ... you've been gone awhile, we've missed you. Don't worry - the CC253x parts are bigger, better, and I believe less expensive in quantity than the old CC243x parts. The IAR is very greatly improved. Finally, the "Network Processor" model is very well developed and recommended for development to offload the burden of the complex ZigBee/MAC system from the application code - so an application processor like an MSP430 talks to the CC2530ZNP via SPI/UART/USB - you'll see a lot of threads on the E2E.

  • Hi DMMT

    Im running into the same issues as you were in this post. Have you found a way to work around this problem?

    I also have a doubt regarding the NV Start and End Addresses

    -D_ZIGNV_ADDRESS_SPACE_START = 0x3E800

    Doesn't setting the value to 0x3E800 put the start address to memory location 256000, which is beyond the limit of the 128 KB flash? Shouldn't it be set to 0x1E800?

    Regards

    Varun