Memory Problems with KE06Z

[codyhubman]

I am using the MKE06Z128 44 pin chip to replace the current processor for our company. I have been trying to understand memory issues and where my problems may lie. 

Currently I have strange problems with certain global variables in my include files. They "appear" to randomly change values or they initialize back to 0 or exhibit some unwanted characteristic. I have been suspicious that it is a memory issue but I am having a really difficult time verifying that. I have noticed some (Common) notes in the .map file as well as one of my global variables jumping to an insanely high value amidst one of these random events.  

The memory usage is what is shown after compile and then the mapfile_memory shows the section of concern. The variables LINKTOTAL, STOPDISPLAY, and so on are the types giving me the most grief. It appears to be any variable declared in my includes but not local.

A final note is it seems like the local stack doesn't seem to have issues it is only when using global variables in my include file. Sorry if my terminology isn't up to par this was my best attempt. I really want to get back to developing but I don't want to continue (and can't really) until I understand this memory issue. 

[jingpan]

Hi,

I think you'd better start from a KE06 example project. Then you can copy your own code to this project. Please download KE06 SDK form Welcome | MCUXpresso SDK Builder . When you select SDK version, please select 2.3.1 or 2.3.0. Because higher verion SDK do not support KDS anymore.

Regards,

jing

[codyhubman]

I might have one installed already. I haven't used processor expert and have setup the drivers I have used by myself. I do have the ke06z linker file and chose it as my development board during setup. At this point I think I am having an issue with a pointer overwriting memory I don't want it to. Everything else indicates I should have enough memory.

[jingpan]

  Hi,

You can use watchpoint function to trace the buffer/stack overflow.

[jingpan]

Hi,

The linker put global data into .data segment and .bss segment. Those data with initial value is put in .data segment. The data hasn't initial value is put in .bss segment.

When power on, the data in RAM is uncertain. They often appear zero, but it is not guaranteed. In KDS startup file (startup.c or startup_MKE06Z4.s) it write 0 to fill the bss segment. Then it copy initial data to .data segment.

For example, in startup_MKE06Z4.s

    ldr    r1, =__etext                   //data segment start address in Flash
    ldr    r2, =__data_start__      //data start address in RAM
    ldr    r3, =__data_end__       //data end address in RAM

    subs    r3, r2
    ble     .LC0                            //get data length

.LC1:
    subs    r3, 4
    ldr    r0, [r1,r3]
    str    r0, [r2,r3]                      //copy data segment
    bgt    .LC1                            //loop
.LC0:

Pleas pay attention to __etext, __data_start__, __data_end__ . These address value is defined in .ld file. You can check these address value and compare all the data when simulation on your board.

Regards,

Jing

[codyhubman]

So I did check those values as far as I know. I'm curious if you might know why there are differences in the origin and length of these two. The left is the MAP file and the right is the LINKER file. 

I am curious why the values of m_text and m_data are different between the two separate files.

In my memory the available space starts at the 0x1FFFF800  and ends right before the upper block of SRAM around 0X20000000.

Aside from this region it appears to have a lot of "junk/random values" or things I can't read. I have one large(ish) global variable. Is there any possible way to know if the memory is corrupted or lost? Would the random values in memory indicate that? The text appears in the flash region of my memory and looks to have a lot of available space. 

I also noticed it looks like the processor isn't even trying to use the upper block of SRAM but that might be a misinterpretation.

I don't see how I could be hitting a ceiling for RAM

[codyhubman]

Update:

I found out it was going to thee KE06Z64 linker instead of the KE06128 linker. I changed the linker files and got that squared away. I still keep seeming to drop into the handler when running my code. I seen something about faults caused by issues from the boundary of the Lower SRAM and the Upper SRAM.

In my memory I noticed before and after that boundary had abstract values. However, On the boundary of 0x20000000 there is a bunch of "?" marks that appear for a little before and after. Is this potentially why my program crashes and ends up in the default handler?

SECOND UPDATE:

The GOOD

So I was having issues with trying to define a new section of memory for the upper SRAM for the KE06z to split the blocks of memory. Previously m_data existed at 0x1FFFF000 and I gave it a length of 0x1000. The SRAM blocks are split into 4 kbytes for LSRAM and 12 kbytes for USRAM. Instead I decided to use only the upper section of SRAM so I set the origin for m_data to 0x20000000 and gave it a length of 0x00003000. This solved the issues for the size of the memory constraint for my data structures. I was correct that the amount of data I needed was well under the given space. 

The BAD

I am still having issues with global variables taking on strange values and exhibiting unwanted behavior. My code is working intermittently. Is there anything else I can check for memory understanding? I checked the address they are defined as in the map file and monitor that address as the code progresses but I am unable to figure out why the address value randomly decides to change. Is there a way to know if it is being overwritten. How would I know everything is writing over itself?

[BlackNight]

Hi Cody,

you have to be very careful if you want to combine the 4K+12K memory blocks in one (I don't recommend doing this). The thing is that they are accessed by two memory controllers, and if have a object placed by the linker over that boundary you will get a hard fault in the best case. There is a discussion on this topic at the end of this article: FreeRTOS Heap with Segmented Kinetis K SRAM | MCU on Eclipse 

Bottom line: you better keep them separate to avoid any issues.

I hope this helps,

Erich

[codyhubman]

I tried to create a linker to divide the sections. In the mean time 12kbytes is enough for me to use so I out the origin of m_data and 0x20000000 and gave it the 12kbyte length 0x3000. I can always try using attribute to stick it in a certain part of memory. I have been resorting to several of your blogs to solve this.

I am confident now my issue isn't lack of memory. I am still overwriting parts of memory and pushing my structure beyond the intended bounds. I am assuming this might be an issue with a pointer somewhere.