• State Resolved
  • Locked Locked
  • Replies 6 replies
  • Subscribers 55 subscribers
  • Views 1582 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.

TIMAC memory allocation on CC2530-F256

GR56264
Prodigy 50 points

Other Parts Discussed in Thread: CC2530

Hi,

I have been working with the CC2530 chip with 256 kB of flash memory on IAR EW v7.51A. I downloaded and installed the TIMAC-CC2530-1.3.0 platform. So far, my program is about 64kB and is compiled in the banked configuration. However, whenever I try to add additional variables, I run into memory errors such as:

Error[e16]: Segment XDATA_I (size: 0x73 align: 0) is too long for segment definition. At least 0x1e more bytes needed. The problem occurred while processing the segment placement command "-Z(XDATA)XDATA_N,XDATA_Z,XDATA_I=_XDATA_START-_XDATA_END", where at the moment of placement the available memory ranges were "XDATA:1dab-1dff"
   Reserved ranges relevant to this placement:
   XDATA:100-27f        XSTACK
   XDATA:280-1dff       XDATA_Z
   BIT:0-7              BREG
   BIT:80-97            SFR_AN
   BIT:a0-af            SFR_AN
   BIT:b8-c7            SFR_AN
   BIT:d8-df            SFR_AN
   BIT:e8-ef            SFR_AN
   BIT:f8-ff            SFR_AN

In the run time model,
  // Map flash bank #1 into XDATA for access to "ROM mapped as data".
  MEMCTR = (MEMCTR & 0xF8) | 0x01

(hal_startup.c)

I can see that only bank 1 is mapped into the XDATA portion of memory. I have seven banks and so I was wondering if anyone knew how to map multiple banks into the XDATA portion of memory? Or, if anyone knew of any other way to allow my program to have a larger data memory space? So far, I have only done memory management in terms of placing variables in either the data or xdata portions of memory. I have not used or configured any of the banks  explicitly (aside from the default configurations from the sample program).

I'm new at this so any suggestions would be of great help and much appreciated.

Thank you in advance,

Regards,

GR

 

 

 

  • 0
    TI__Mastermind 19350 points

    Your linker warning is that you do not have enough RAM which is coming from XDATA in this 8051 SoC. The "default" IAR setting for constants is "RAM memory", which would make your situation worse. With the MAC project default setting and setup for "ROM mapped as data", there has been more XDATA space for you to use. A bank of memory is 32KB - I doubt that you will be exceeding that, no? So, to focus on your shortage of RAM - you will have to sacrifice space from somewhere. The first two places to consider are the dynamic heap memory, given to and managed by OSAL_Memory.c - you can use less heap by controlling this constant: MAXMEMHEAP  You might consider reducing the runtime "C" call-stack, but this would be a very distant 2nd choice for me and you will need to make careful measurements of your worst-case call depth and stack usage to be sure that you have not cut it too short - a horrible, "silent", run-time failure that is hard to diagnose when you are not looking for it. The setting is in Project-->Options-->General Options-->Stack/Heap-->XDATA which is set by the project to 0x180 --> 384 bytes. Note that heap sizes are all zero because the IAR library calls for malloc/free are not used but instead the OSAL_Memory.c API calls. Finally, perhaps analyze your huge useage of RAM and try to make some of the bigger useages temporary use by dymanic allocation and freeing?

     

  • 0 in reply to Dirty Harry
    Prodigy 50 points

    Hi,

    Thank you for your prompt reply. I was going through the .xcl file for the banked configuration and realized that only 7679 bytes of memory were allocated for the XDATA. I changed it to 64kB as specified in the CC2530 user guide. This in effect solved all my memory troubles. However, do you know of any hidden troubles that this change might cause? So far, there doesn't seem to be any issues but you never know.

    This is the only change:

    //    IXDATA
    //
    -D_IXDATA_START=0x0100
    -D_IXDATA_END=0xFD53
    //

    The D_IXDATA_END=0xFD53 used to be 0x1EFF.

    Regards,

    GR

     

     

  • 0 in reply to GR56264
    TI__Mastermind 19350 points

    Well, you "solved" all of your memory troubles for the compile and link, but don't bother running it, as it's going to crash and burn (if IAR even loads it) - the CC2530 only has 8KB of SRAM (refer to the data sheet), addressed 0x0000-0x1FFF. Refer to the CC253x User's Guide, Figure 2-1, and you'll see that the upper 256 bytes are burned by the 8051 IDATA. I don't know what version of the .xcl file you are looking at, but the one that you should have with the latest MAC release has this:

    // Reserving address 0x0 for NULL.
    -D_XDATA_START=0x0001
    -D_XDATA_END=0x1EFF

    As you see, the above correctly "reserves" the upper 256 bytes for the 8051 IDATA.

    You should thoroughly understand the 8051 architecture, the IAR environment, and the CC2530 completely before modifying the .xcl files.

  • 0 in reply to Dirty Harry
    Prodigy 50 points

    Hi,

    You are right, I was told that this change was safe in another forum but I guess it's not. I reverted everything back to the original .xcl files. In any case, I will try your previous suggestions.

    Thank you,

    GR

  • 0 in reply to GR56264
    Prodigy 50 points

    Just to append to the previous post. The other forum was not a TI forum, it was just a different site on the internet.

     

    Regards,

    GR

     

     

  • 0 in reply to GR56264
    TI__Mastermind 19350 points

    Thanks for taking the time to clarify where the confusing information came from, GR!