• State Resolved
  • Locked Locked
  • Replies 3 replies
  • Subscribers 78 subscribers
  • Views 1175 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.

CC430F6137 IAR RAM Memory Map Bug?

mark sonnentag
Expert 1890 points
Other Parts Discussed in Thread: CC430F6127, CC430F6137, CC430F5137

Hi,

The default IAR memory map files for the CC430F6137,CC430F6127 and CC430F5137 SoC set the RAM to 1C00-2BFD(almost 4 KB). However real adress of the RAM goes from 1C00 - 2BFF. Its not much but you still lose 2 Bytes.

The address range of the datasheet should be the correct one if the RAM has really 4 KB size. Am I missing something here?

Thank you.

  • 0
    Guru 227245 points

    I guess theses two bytes are used as a safety margin for the stack, so IAR can detect a stack underflow in debugger mode.
    Or something similar. However, it should be documented somewhere in the IAR compiler/linker description.
    Also, the 5x family supports moving the vector table to the end of ram. So these two bytes would hold the reset vector if you chose to use this option. Just a memory snippet.

    Since 0x2bfd is unlikely to be a simple typo, someone must have had a reason for this. And this reason should be noted somewhere.

  • 0 in reply to Jens-Michael Gross
    Expert 1890 points

    Hi Jens-Michael,

    thanks for your answer.

    There is data at 0x2BFE -0x2BFF.

    It is 0xb0 0x5b

    It doesnt matter how many times I let the compiler rebuild the project and flash the device. The data stays the same for the same device.

    However it is not the reset vector. The reset vector is in flash for this build

     

    You can set the boundaries of the RAM to 2BFF and neiher compiler nor the device complain about it(crash).

    However in this case those 2 bytes contain no data and arent ever accessed according the disassembly view.

     

    Also if you set the boundaries to the default values again then those 2 bytes are still 0x00 and stay this way for this device.

    It stays like that until remove the usb debugger and plug it back in. Then those bytes contain data again, however its not the old data.

     

    I have checked the manual of the compiler and linker. However I have not found any note about this behavior.

    But it seems like IAR really uses them to detect a stack underflow as you suggested.

    Its quite odd, but luckily I dont depend on those 2 bytes.

  • 0 in reply to mark sonnentag
    Guru 227245 points

    mark sonn said:
    Its quite odd, but luckily I dont depend on those 2 bytes.

    Indeed, if this is not documented, it shouldn't happen at all.
    Well, 2 bytes can be much. I started with the 1232 and its 128 bytes ram. I was indeed more than once trying to squeeze two more bytes from ram.
    The 1611 and its 10k then made this kind of hunt obsolete.

    P.s.: 5bb0 looks like a 'return' address to something. So maybe if you 'return' from main, it causes the processor to fetch these two bytes, which never were written to it, from ram and continue execution at 0x5bb0, which hopefully contains a JMP$ instruction or something similar.

**Attention** This is a public forum