• State TI Thinks Resolved
  • Locked Locked
  • Replies 5 replies
  • Answers 1 answer
  • Subscribers 52 subscribers
  • Views 1086 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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/CC2640R2F: Fixed allocation in memory map for simpleBlePeripheral

sailendra marripudi
Intellectual 260 points
Part Number: CC2640R2F

Tool/software: TI-RTOS

Hi ,

I'm using Simple BLE Peripheral with Stack as Library configuration on CC2640R2F with BLE Stack v3.1.0. (RTOS in FLASH)

I checked the map file generated and found that there are fixed allocated memory ranges

[0x20000000-0x200000c7] --> Ram Vector Table
[0x20000430-0x2000043f]  --> dmaSPI0RxControlTableEntry
[0x20000440-0x2000044f]  --> dmaSPI0RxControlTableEntry
[0x20000500-0x2000050f]  --> dmaSPI1RxControlTableEntry
[0x20000510-0x2000051f]  --> dmaSPI1RxControlTableEntry

because of these my RWDATA Block where my .data and .bss sections are placed only after 0x20000520 leaving the range from 0x200000c8 to 0x2000042F empty.

Can I keep some of my .data objects in that 0x200000c8 to 0x2000042F ? as this is not at all used.(I also verified with debugger that this section was always remained 0).

  • 0
    TI__Mastermind 20480 points
    What is the map file reporting at between 0x200000c8 to 0x2000042F? This is 367 bytes and that's a pretty big chuck for the CC2640R2F. I don't think you can rely on the debugger to show that this is "empty". My initial guess it's part of .bss.

    Can you post your .map file?
  • 0 in reply to Tom Kopriva
    TI__Mastermind 20480 points
    This memory section is pretty close to what TI-RTOS (in ROM) uses. Using the kernel in ROM, you should see 0x20000100 - 0x20000208 being used, but that doesn't span to 0x2000042F.
    See the memory map section here: software-dl.ti.com/.../memory_management.html. Here you can see, .data and .bss is right next to it.
  • 0 in reply to Tom Kopriva
    Intellectual 260 points

    Hi Tom,

    I have gone through the memory management document provided, but then in my map file there are fixed ranges which I did not understand.
    I have checked the map file and nothing was allocated from 0x200000c8 to 0x2000042F.

    .data and .bss was allocated only after 0x20000520 followed by heap and then stack.

    I have changed the linker file to place some of .data objects in this address range and it worked. So just want to confirm if those areas are not used by TI code.

    And one more thing is that why these are placed in Fixed location in RAM
    [0x20000430-0x2000043f] --> dmaSPI0RxControlTableEntry
    [0x20000440-0x2000044f] --> dmaSPI0TxControlTableEntry

    there is a gap here.

    [0x20000500-0x2000050f] --> dmaSPI1RxControlTableEntry
    [0x20000510-0x2000051f] --> dmaSPI1TxControlTableEntry

    Can I modify some file to keep these in an order?

  • 0 in reply to Tom Kopriva
    Intellectual 260 points
    Hi Tom,

    I Checked both RTOS IN ROM and also RTOS in FLASH. Both the cases there are some fixed allocations from
    [0x20000430-0x2000043f] --> dmaSPI0RxControlTableEntry
    [0x20000440-0x2000044f] --> dmaSPI0RxControlTableEntry
    [0x20000500-0x2000050f] --> dmaSPI1RxControlTableEntry
    [0x20000510-0x2000051f] --> dmaSPI1RxControlTableEntry

    Do you know from where these are getting linked? and can I change their location?
  • 0 in reply to sailendra marripudi
    TI__Mastermind 20480 points

    They are fixed and cannot be changed if you want to use the SPI driver.

    The driver uses the uDMA controller, which works with a RAM based control table. These address are specific control table entries that are offset from a control table's base address. These entries configure the uDMA channels for those peripherals. Under normal uDMA usage, one would have to allocate at full 512 byte table (or 1024 for advanced features) even if you want to use just one channel. For the CC26xx devices, given the RAM constraints, we tried to just allocate the channels needed, while allowing the remaining RAM to be used elsewhere.