Kinetis MicrocontrollersのトピックRe: KL17Z32VLH4 : SRAM location in memory map

KL17Z32VLH4 : SRAM location in memory map

loblick — Thu, 27 Feb 2020 21:44:18 GMT

Hello,

I'm working with a KL17Z32VLH4 and I have some trouble like unexpected reset.

I supposed that was a stack issue and I began to check memory map and stack amount.

I see something curious in the linker file with m_data area :

m_data (RW) : ORIGIN = 0x1FFFF800, LENGTH = 0x00002000

1/ SRAM_L and SRAM_U are not splitted in m_data

2/ m_data begin at 0x1FFFF800

Moreover, the KL17P64M48SF2 datasheet which apply to my Kinetis says that :

- SRAM_L area is 0x1FFF_F000 to 0x1FFF_FFFF

- SRAM_H area is 0x2000_0000 to 0x2000_2FFF

- KL17Z32VLH4 had 8K SRAM (0x2000)

Thus, I think that m_data should be in SRAM_L area and I have to correct linker file like this :

m_data (RW) : ORIGIN = 0x1FFFF000, LENGTH = 0x00001000

Does anybody confirm I'm right?

Thank you very much.

Re: KL17Z32VLH4 : SRAM location in memory map

nxf56274 — Fri, 28 Feb 2020 02:14:55 GMT

Hi,

Valid address ranges for SRAM_L and SRAM_U are then defined as:
• SRAM_L = [0x2000_0000–(SRAM_size/4)] to 0x1FFF_FFFF
• SRAM_U = 0x2000_0000 to [0x2000_0000+(SRAM_size*(3/4))-1]
SRAM_L = (0x20000000-0x2000/4) ~ 0x1fffffff = 0x1FFFF800~0x1fffffff

So you do not need modify.

Have a great day,
TIC

-------------------------------------------------------------------------------
Note:
- If this post answers your question, please click the "Mark Correct" button. Thank you!

- We are following threads for 7 weeks after the last post, later replies are ignored
Please open a new thread and refer to the closed one, if you have a related question at a later point in time.
-------------------------------------------------------------------------------

Re: KL17Z32VLH4 : SRAM location in memory map

loblick — Fri, 28 Feb 2020 05:37:51 GMT

Hello,

Thank you for your quick ansewer. Obviously, I was wrong.

I had others questions : what about stack pointer? Could be located absolutely in lower RAM? Or could it be in upper RAM?

if so, what happen when stack area was located around 0x2000_0000? Does it could crash ARM core sometime when data are missaligned (id. if a 32 bits value is located from 0x1FFFF_FFFE to 0x2000_0001?)

Have a great day too.

Loïc

Re: KL17Z32VLH4 : SRAM location in memory map

nxf56274 — Mon, 02 Mar 2020 01:29:11 GMT

Hi,

The top stack pointer address is 0x2003_0000. The size of stack is 0x400. So the stack ranges from (0x2003_0000-0x400) to 0x2003_0000. The stack poniter should be in the range.

Have a great day,
TIC

-------------------------------------------------------------------------------
Note:
- If this post answers your question, please click the "Mark Correct" button. Thank you!

Re: KL17Z32VLH4 : SRAM location in memory map

loblick — Thu, 19 Mar 2020 17:07:01 GMT

Hello,

I have modified my linker file as follow and my microcontroller stop to crash.

If I underdstand well, stack area is from 0x1FFFF_FE00 to 0x2000_0000.

Am I right?

/* Highest address of the user mode stack */
_estack = 0x20000000; /* end of m_data */
__SP_INIT = _estack;
__stack = _estack;

/* Generate a link error if heap and stack don't fit into RAM */
__heap_size = 0x100; /* required amount of heap */
__stack_size = 0x0200; /* required amount of stack */

/* Specify the memory areas */
MEMORY
{
m_interrupts          (RX) : ORIGIN = 0x00000000, LENGTH = 0x00000100
m_cfmprotrom          (RX) : ORIGIN = 0x00000400, LENGTH = 0x00000010
m_header              (RX) : ORIGIN = 0x00000410, LENGTH = 0x00000050
m_text                (RX) : ORIGIN = 0x00000460, LENGTH = 0x00007BA0
m_data                (RW) : ORIGIN = 0x1FFFF800, LENGTH = 2K
m_data_0x20000000     (RW) : ORIGIN = 0x20000000, LENGTH = 6K
}

...

/* User_heap_stack section, used to check that there is enough RAM left */
._user_heap_stack :
{
    . = ALIGN(4);
    PROVIDE ( end = . );
    PROVIDE ( _end = . );
    PROVIDE ( __end__ = . );
    __heap_addr = .;
    __HeapBase = .;
    . = . + __heap_size;
    __HeapLimit = .;
    . = . + __stack_size;
    . = ALIGN(4);
} > m_data