MQX Software Solutions中的主题 Re: _mem_extend usage

_mem_extend usage

Ardoster — Fri, 18 Jan 2013 15:53:18 GMT

Due to memory problems, we have designed a new hardware with an external sram memory. So I'm trying now to move RAM usage from the internal memory to external memory. For now, I've configured the flexbus peripheral to access this memory through the address 0x9000 0000 and i've checked I can write and read from this memory.

Now, I'm trying to add the external memory to the default memory pool. I'm using the function _mem_extend().

_mem_extend((pointer)0x90000000, 0x20000)

But I continue having the same memory problems. Debugging a bit, I've checked the _mem_extend stops in the file mem_exti.c at

   if (mem_pool_ptr->VALID != MEMPOOL_VALID) {
      return(MQX_INVALID_COMPONENT_HANDLE);
   }/* Endif */

What's the problem? Any idea? I've no found relevant information about the _mem_extend usage.

Thanks for your help

Regards

Re: _mem_extend usage

Ardoster — Fri, 18 Jan 2013 18:31:14 GMT

Hi again

I think I've solved the problem using the next defines:

#define MQX_USE_MEM 1

#define MQX_USE_LWMEM 0

#define MQX_USE_LWMEM_ALLOCATOR 0

The problem is I was using light weight memory instead the normal module.

But I have now an aditional problem. What are the implications about changing from lightweight memory to normal memory? I ask because in my software, i've implemented an ftp server, and with these changes, I can't stablish a connection to it. Although I've availaible more memory.

Should I change the stack size in rtcs or the stack used for a socket????

Thanks for your help

Regards,

Re: _mem_extend usage

JuroV — Mon, 21 Jan 2013 08:46:45 GMT

Hello Ardoster,

there is not much to do with stack usage. I suggest you to define SRAM and UNCACHED pools in KERNEL_DATA in this situation. You can look for example at MK70F BSP files how the SRAM pool is created.

Re: _mem_extend usage

Ardoster — Tue, 22 Jan 2013 08:47:06 GMT

Thanks you for your reply

I can't find the SRAM define you are refering to. But I'll try using

#define MQX_USE_UNCACHED_MEM 1

Anyway, I'm not really very optimistic about this test.

Thanks you

Re: _mem_extend usage

JuroV — Tue, 22 Jan 2013 08:50:11 GMT

Hm, I am telling about

kernel_data->SRAM_POOL and kernel_data->UNCACHED_POOL. These should be somehow defined (not NULL).

Re: _mem_extend usage

Ardoster — Tue, 22 Jan 2013 09:49:35 GMT

Thanks you

I've made a search in the MQX path and I can't find the string "SRAM_POOL". I'm using MQX 3.7, so I think that maybe that entry is not implemented in my version.

In the other hand, I've tested with MQX_USE_UNCACHED_MEM with the same results. It must be something different, because aparently, no one socket is correctly working: no ftp, no telnet, no ping, etc.

Any suggestions???

Thanks you in advance

Re: _mem_extend usage

JuroV — Tue, 22 Jan 2013 10:35:54 GMT

Try to search for "UNCACHED_MEMORY_POOL" or "UNCACHED_POOL".

Re: _mem_extend usage

Ardoster — Tue, 22 Jan 2013 15:49:00 GMT

Well, yes. Uncached Pool is used when MQX_USE_UNCACHED_MEM.

I'm starting to think the memory extension is not being correctly done in _mem_extend().... altough I can see the memory access to the external sram memory using an oscylloscope.

Thanks you

Re: _mem_extend usage

Ardoster — Wed, 23 Jan 2013 11:47:52 GMT

Hi again.

I'm not been able to find what's the problem. But I've discovered that if I create my tasks in the internal memory, and the ftp server in the external memory (after calling _mem_extend() ), the application works correctly.

I've no explanation. But maybe this result could help someone else.

Thanks you for your help

Re: _mem_extend usage

ARQuattr — Thu, 25 Apr 2013 13:53:27 GMT

Hi, I am trying to do something very similar and am also having problems. I don't believe you stated your processor - I'm using the MCF52259 – although I'm not sure it's very relevant.

I have 128kB external SRAM wired to the 52259 (I also have a tower setup with the TWR-MEM board I can test with). I have used the _mem_extend(), but at 0x10000000 since that's where the existing linker put the MRAM (the hardware and project is based on the tower project).

I added the defines you showed and rebuilt everything, so it compiles but when it gets to the _mem_extend() it locks up. I'm going to try to debug this, (which is tough since I'm using a bootloader) but I wondered if you could give some pointers on what I might be missing.

Thanks,

Angelo

Re: _mem_extend usage

Ardoster — Thu, 25 Apr 2013 14:09:37 GMT

Yes, i'm using the same processor as you.

Maybe it's a silly question, but have you correctly configured the mini flexbus peripheral to map your external memory at your selected base address?

Regards,

Re: _mem_extend usage

ARQuattr — Thu, 25 Apr 2013 14:18:36 GMT

Thanks for your reply. Not a silly question at all, since I'm really in new territory here. Please ask away.

Since I'm using the same bsp as the 52259 tower board, I have the same linker (modified slightly for the bootloader) and the bsp_init.c is essentially the same (aside from setting up a few other I/O for this application). As far as I can tell none of these changes conflict with the flex bus.

The mcf5225_init() call includes these at the end:

/* init flexbus */

_bsp_flexbus_setup();

/* init MRAM */

_bsp_flexbus_mram_setup((uint_32)BSP_EXTERNAL_MRAM_BASE);

BSP_EXTERNAL_MRAM_BASE is set to 0x10000000 in the linker.

My call to _mem_extend is _mem_extend((pointer)0x10000000, 0x10000);

This is done in the main task. Should this be done in the mcf5225_init(), i.e. before the kernel starts?

Re: _mem_extend usage

ARQuattr — Fri, 26 Apr 2013 12:39:51 GMT

I moved my _mem_extend() call into mcf5225_init, and now it doesn't lock up, but I don't believe it's working. When I try to perform the operations that use the extra memory which caused me to add the external RAM, it locks up. Furthermore each time this code runs, it seems to mess up something in the Flash code space because I have to reflash through the bootloader every time. Not sure what that's about.

So I'm fairly certain I'm missing a step in getting the external memory in use by the kernel.

Re: _mem_extend usage

Ardoster — Fri, 26 Apr 2013 15:47:41 GMT

So, do you have to re flash every time you execute your program? That's

strange.

I'm not in the office, so I can't check the datasheet. The first to check

is if you're trying to map external memory in internal flash memory.

Later, you may try to check if you re getting the external memory using a

oscilloscope. So you could see the signals when accessing external memory.

And finally, you have to check if the operations you are trying to use the

extra memory, are effectively using it. When I did my tests, all the tasks

created before calling memextend, were still running in internal memory.

All the other tasks created after this call, were using the external

memory.

Try this and tell me.

Good luck

El 26/04/2013 14:40, "Angelo Quattrociocchi" <admin@community.freescale.com>

escribió:

**
image: Freescale Community<https://community.freescale.com/index.jspa> memextend usage created by Angelo
Quattrociocchi <https://community.freescale.com/people/ARQuattr> in *MQX
Software Solutions* - View the full discussion<https://community.freescale.com/message/326545#326545>

Re: _mem_extend usage

ARQuattr — Sun, 28 Apr 2013 02:21:55 GMT

Yes, I have to reflash each time. I was looking at the CSAR (sec. 19.3) in the data sheet and I thought I was setting this OK - I actually didn't change anything and the linker file already puts MRAM at 0x10000000 so I left that and just used the same address when calling _mem_extend. But again I'm not very confident in my understanding of all this.

I put the pins (MB_CS0#, MB_RW#, MS_OE#) on a logic probe and saw no activity.

Thanks again for your help.

Re: _mem_extend usage

Ardoster — Mon, 29 Apr 2013 07:27:44 GMT

The problem is effectively you're mapping on-chip flash memory instead external ram memory. You have to check the memory map overview in the MCF52259RM.pdf file. There, you can see the on-chip flash memory goes from 0x0000 0000 to 0x4000 0000. So, when you do _mem_extend((pointer)0x10000000, 0x20000) , your memory extension is useless.

You've to map the external ram above 0x8000 0000.

By the way: are you sure you are correctly configuring your mini-flex bus????

Regards,

Re: _mem_extend usage

ARQuattr — Mon, 29 Apr 2013 11:27:26 GMT

Hi, yes I thought that address seemed strange, but I assumed since that's the way the example projects came configured I should leave it. I will try moving it to x8000 0000. I noticed you used x9000 0000, was there a reason for this?

I have checked over the init functions for the flexbus and they appear to be OK. Again, these are the same functions that were included with the tower BSP but I didn't see any need to change anything there.

Re: _mem_extend usage

ARQuattr — Mon, 29 Apr 2013 12:16:51 GMT

I changed it to x80000000 but it behaved the same way. (Corrupts flash each time it runs, no activity on the flexbus)

The flexbus and mem_extend are setup with the following calls in bsp_init.c

_bsp_flexbus_setup();

_bsp_flexbus_mram_setup((uint_32)BSP_EXTERNAL_MRAM_BASE);

_mem_extend((pointer)BSP_EXTERNAL_MRAM_BASE, (uint_32)BSP_EXTERNAL_MRAM_SIZE);

static void _bsp_flexbus_setup (void)

{

VMCF5225_STRUCT_PTR reg_ptr = (VMCF5225_STRUCT_PTR)BSP_IPSBAR;

/* Enable Mini FlexBUS signals (used by external MRAM and CPLD) */

reg_ptr->GPIO.PASPAR = 0x20; /* enable CS1 operation for CPLD */

reg_ptr->GPIO.PTEPAR = 0xff;

reg_ptr->GPIO.PTFPAR = 0xff;

reg_ptr->GPIO.PTGPAR = 0xff; /* enable CS0 operation for MRAM */

reg_ptr->GPIO.PTHPAR = 0x5555;

}

static void _bsp_flexbus_mram_setup (const uint_32 base_address)

{

VMCF5XXX_MINIFB_STRUCT_PTR fb_ptr = &((VMCF5225_STRUCT_PTR)BSP_IPSBAR)->FB;

/* Enable external MRAM mapped on CS0 */

fb_ptr->CSAR0 = MCF5XXX_FBCS_CSAR_BA(base_address); /* CS0 base address */

fb_ptr->CSCR0 = 0x00000540; /* CS0 control (8bit data, 1 waitstate) */

fb_ptr->CSMR0 = 0x00070001; /* CS0 address mask and enable */

}

In the linker file there are these lines under 'SECTIONS':

___EXTERNAL_MRAM_BASE = 0x80000000;

___EXTERNAL_MRAM_SIZE = 0x00080000;

I have the external RAM tied to CS0. I didn't see anything that needed to change in the code, only the linker file was changed. Is that correct? Of course when you do this and go to recompile the BSP and application, it says there is nothing to be done because the code itself didn't change, so I made a dummy edit to force it to recompile. I'm not sure if this is normal, or I missed some definition somewhere.

Re: _mem_extend usage

Ardoster — Tue, 30 Apr 2013 11:19:44 GMT

Your code seems correct, so the problem must be other.

Anyway, i'm not sure you have to modify the linker file. In fact, i didn't modify it: if you modify it, you're telling your program there's ram memory at that base address... but that's not really true, because the ram memory is not available until you call _mem_extend().

I'm not sure I can continue helping you. I hope any other user more experienced than me could help you.

Sorry.

Re: _mem_extend usage

ARQuattr — Tue, 30 Apr 2013 12:00:44 GMT

Thanks. So do you use the same code to set up the flexbus? Or do you mind showing me the code you are using? If you use similar code, and didn't change the linker, where is the memory base address coming from?