topic Re: Not able to access RAM in MK65F180M using MQX in MQX Software Solutions

Not able to access RAM in MK65F180M using MQX

viveksrinivasan — Fri, 10 Apr 2015 00:38:14 GMT

Hello everyone,

We are trying to port our Bluetooth stack to MK65F180M using MQX.

From the IAR flash file, we understand that the below are the RAM and ROM memory locations;

ROM - 0x00000000 to 0x000FFFFF

RAM - 0x1FFF0000 to 0x2002FFF0

We were trying to use the hello example from the MQX. We were able to run that successfully.

When we look at the IAR MQX plugin we can see MQX memory allocations (Please see the attached file Mem_Alloc.pdf).

I can see that a maximum of 10 KB is used for the Kernel including the thread stack.

To make sure that the rest 245 KB is accessible to us, I wrote a small code to write to the free RAM locations. From 0x1FFF27c0 to 0x20000000 (free 55K) and from 0x20000001 to 0x2002FFF0 (Free 192K) (Please refer to the attached file Write_RAM.txt).

But when I execute the test application, control goes to _int_kernel_isr (I believe because of some hard fault) while trying to write to some random memory location (this address keeps changing every time I restart the application).

I’m not sure if something I do here is wrong. Also, when I look at the Flash file used in IAR, I can see certain RAM locations are used by the Kernel. For example.

define exported symbol __KERNEL_AREA_START = __ICFEDIT_region_RAM_start__;

define exported symbol __KERNEL_AREA_END = 0x20007FF0;

So, I’m a little bit confused about which part of the RAM is actually given to the USER. Please help me understand which part of the RAM can be used by the USER without any interference from the kernel. I have also attached the flash file that I’m using for your reference(initflash.icf).

Your help is much appreciated. Thank you.

Regards,

Vivek

Original Attachment has been moved to: Write_RAM.txt.zip

Original Attachment has been moved to: intflash.icf.zip

Re: Not able to access RAM in MK65F180M using MQX

RadekS — Fri, 17 Apr 2015 12:54:22 GMT

Two points:

You wrote memory from 0x1fff27c0 to 0x2002FFF0 in one loop. You used byte writes in C language – that is correct, but I would like to recommend check also assembler code. It is highly possible that compiler optimizes this code and you will write by words and in extreme case unaligned words. 0x20000000 is boundary between two memory controllers and any unaligned access across this boundary will cause bus fault. Therefore system allocates dummy data from 0x1ffffff4 to 0x20000004 for avoid placing any data across this boundary.
Be aware, memory marked as Free by allocator doesn’t mean that it is empty memory. At start of free block is stored allocators header with pointer to next free block,…

Therefore I would like to recommend start with your test with some minimal offset. I am not sure now how big is this header, but I suppose that 64bytes should by fine.

So, you could start from 0x1FFF2800 and continue to 0x2002FFF0 with exception around 0x20000000.

Anyway, in all cases it is bad idea to try rewriting memory which is currently available for allocator.

If you want testing memory, correct way should be allocate block as first and after that test it or test it prior you call allocator start (prior you call _mqx() function).

If you want allocate some memory for your own variables out of system, please modify your linker file.

I hope it helps you.

Have a great day,
RadekS

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

Re: Not able to access RAM in MK65F180M using MQX

viveksrinivasan — Wed, 22 Apr 2015 01:21:24 GMT

Hi RadekS,

Thanks a lot for your response. Sorry for my late response as I was busy with other work. I did some quick tests like you suggested and it seems working. Few things that I found from my testing.

1. The compiler did not optimize it to a word write.

2. I believe the offset of 64 bytes for allocator header and the offset for the dummy data between the boundaries of RAM did the trick.

Give me a couple more days to do further testing and if everything is OK then I will make this post answered.

Once again thanks a lot for you help.

Have a great day,

Vivek