NIOS 1 Memory Usage

Altera_Forum · ‎06-03-2004

I've got a NIOS system running but have questions about memory usage

(RAM). I've got 2 files that contain the issues. The 1st is the

memory map (.mn) generated by the compiler and the 2nd is a memory

dump captured using hyperterm. Before starting the CPU and capturing

the memory dump, I filled RAM with AAAAs.

The two mysteries

(1) The map indicates we have a total ram of 8192 (I am using all

decimal now) of which 5232 (about 63%) is allocated. That leaves about

2960 available. Included in the 5232 is a block of 1052 associated

with malloc. We suspect this is used for local variable storage that

exceeds the stack BUT what determines this block size?

Looking at our code, we cannot see where we need anywhere near this

amount of RAM for local variable storage. How we make it smaller?

--- ouput of copmiler map file

00040000 A na_ext_ram

00040000 A nasys_usersocket_1

00040000 A nasys_vector_table

00040100 A _nasys_data_destination

00040100 A nasys_data_mem

00040100 A nasys_vector_table_end

00040100 D _data

00040100 D nS

00040104 D x

00040124 D y

... Deleted variable listing for clarity

00040abc D testStr

00040ad8 D RAMLimit

00040adc d inited.0

00040ae0 d inited.1

00040ae4 d impure_data

00040dd0 D _impure_ptr

00040dd4 D __mb_cur_max

00040dd8 d lc_ctype.0

00040de0 d last_lc_ctype.1

00040de8 D __malloc_av_

000411f0 D __malloc_trim_threshold

000411f4 D __malloc_top_pad

000411f8 D __malloc_sbrk_base

000411fc D __malloc_max_sbrked_mem

00041200 D __malloc_max_total_mem

00041204 D __malloc_current_mallinfo

0004122c A __bss_start

0004122c A _nasys_uninitialized_storage

0004122c B _bss

0004122c D _edata

0004122c D _nasys_data_destination_end

0004122c b xAvg.48

00041234 b yAvg.49

0004123c b sAvg.50

00041244 B _nr_userisrtable

00041444 B atexit_func

00041448 B _main_return

0004144c B cwpUnderflowG

0004146c B errno

00041470 A _end

00041470 A _nasys_uninitialized_storage_end

00042000 A na_ext_ram_end

00042000 A nasys_data_mem_end

00042000 A nasys_stack_top

----------------

(2) When I run the program and dump the RAM, you can see that data

(non AA values) occur through the first 5232 locations. Then there are

some AA's followed by a large section of RAM with non AA's. In fact,

it appears something is using another 2004 of RAM out of the available

2960. This wipes out our growth capability. What is using up this RAM

and how do we prevent it?

Memory Dump-------------------

040000: 3641 000C 392F 000C 398A 000C 3641 000C

040010: 3641 000C 3641 000C 3641 000C 3641 000C

040020: 3641 000C 3641 000C 3641 000C 3641 000C

RAM contains mostly 0000s as expected.

040D10: 0000 0000 0000 0000 0000 0000 0AE4 0004

040D20: 0000 0000 0000 0000 0000 0000 0009 0001

040D30: 0000 0000 0000 0000 0000 0000 0D20 0004

040D40: 61FD 000C 621E 000C 624B 000C 6273 000C

Looks like this RAM contains the address of itself

Probably a Malloc event.

040DF0: 0DE8 0004 0DE8 0004 0DF0 0004 0DF0 0004

040E00: 0DF8 0004 0DF8 0004 0E00 0004 0E00 0004

040E10: 0E08 0004 0E08 0004 0E10 0004 0E10 0004

040E20: 0E18 0004 0E18 0004 0E20 0004 0E20 0004

This pattern continues

0411C0: 11B8 0004 11B8 0004 11C0 0004 11C0 0004

0411D0: 11C8 0004 11C8 0004 11D0 0004 11D0 0004

0411E0: 11D8 0004 11D8 0004 11E0 0004 11E0 0004

Here starts a lot of Zeros..

0411F0: 0000 0002 0000 0000 FFFF FFFF 0000 0000

041200: 0000 0000 0000 0000 0000 0000 0000 0000

041210: 0000 0000 0000 0000 0000 0000 0000 0000

Continuing till

041440: 0000 0000 0000 0000 20FB 0008 0000 0000

041450: 0000 0000 0000 0000 0000 0000 0000 0000

041460: 0000 0000 0000 0000 0000 0000 0000 0000

An then untouched memory.

041470: AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA

041480: AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA

041490: AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA

0414A0: AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA

Till this which looks like stack usage

041780: AAAA AAAA 4141 4141 0041 0000 0003 0000

041790: FFFF FFFF FFFF FFFF 0000 0000 0031 0000

0417A0: 0300 0004 5C75 000C FF20 0000 0000 0000

0417B0: 0000 0000 0000 0000 56EC 000C AAAA AAAA

0417C0: AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA

Up to the end of RAM or the Start of Stack.

041F40: 6DB0 3FE1 0000 0000 9800 40EA 5CBC 77C4

041F50: D662 3FEA 0000 0000 79B0 40F4 AAAA AAAA

041F60: AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA

041F70: AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA

041F80: AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA

041F90: AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA

041FA0: AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA

041FB0: AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA

041FC0: AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA

041FD0: AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA

041FE0: AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA

041FF0: AAAA AAAA AAAA AAAA AAAA AAAA AAAA 0862

--------------------------------

Altera_Forum · ‎06-07-2004

What version of Nios and Quartus are you using?

Altera_Forum · ‎06-08-2004

Quartus II V4.0 Build 214

SOPC V4.01 Vuild 214

NIOS 1 Version ??

Thanks

Altera_Forum · ‎06-08-2004

I believe that the answer is to use the new Nios II memories. Is it possible to switch to Nios II?

I'll try to get you more info on the problem.

Altera_Forum · ‎06-08-2004

Well. The design is complete. We've finished all the EMI and safety testing. And we're ready to go into production. The issue is what sort of future does the design have if we run out of RAM. And what's eatting up our RAM.

So the question is really to understand what's using RAM. Perhaps it's an OK situation.

If it's malloc and free used properly then perhaps we're OK.

I've got newer projects that I have swithced to NIOS II but I'm not to the point of comparison just yet.

THanks

George

Altera_Forum · ‎06-08-2004

I've emailed dvb asking if he can help you.

I'llwatch and see if he can. Otherwise I'll ask someone else.

Altera_Forum · ‎06-09-2004

The address from 0x41470 to 0x41fff is used for stack.

I did not see any strange value.

Altera_Forum · ‎06-09-2004

Hello --

I agree with Hao. This all looks fine.

From 0x41470 to 0x42000 is used by (a) stack space growing down from top, and (http://forum.niosforum.com/work2/style_emoticons/<#EMO_DIR#>/cool.gif heap space allocated by malloc up from the bottom.

Which part of memory is unaccounted for?

--> david

Altera_Forum · ‎06-09-2004

Hello:

A reference to malloc starts at 0x40DE8 in the variable listing. First question is what's causing this reference? The code doesn't call malloc directly. I can't find a call to malloc by grepng the objdump file.

It appears that malloc is reserving from 0x40DE8 to 0x411F0 about 0x400 or 1024(decimal) bytes of ram memory. How can we track this down??

Second question is that we reserved on chip RAM for the stack. We enabled the CWP manager. The design screen says we have 31 levels for the stack. If we trace our code we see calls 2 or 4 deep. But it looks like the stack has been saved to external RAM from 0x41FFF to 0x41780. Is this true and who did it?? That's 0x880 or 2176 (decimal) bytes that we can explain.

Thanks

George Martin

Altera_Forum · ‎06-09-2004

hmm.

If you're not calling malloc(), it should not get linked in.

Somebody must be calling malloc().

Are you using any unusual libraries?

If you're sure you know what you're doing, you can disable the CWP manager in the "Software" tab of the Nios configuration dialog. I generally advise against doing that, it can introduce some very hard-to-understand erroneous behaviors when your register window underflows.

--> dvb

Altera_Forum · ‎06-10-2004

Hi qmm50,

The SOPC builder always set stack_top at the end of data memory.

If you want to set stack at on chip ram. You need to mdofiy this file cpu_sdk\lib\nios_setup.s,

and rebuild the liberary.

Altera_Forum · ‎06-10-2004

Thanks to a ll replies.

1. malloc:

Help, who's calling malloc and how do we track that down? In the objdump file we can't find the call to malloc using grep. Yes we're using the standard libraries. We are using sin, cos and atan functions.

2. stack usage:

The code is not called more that 4 deep. The stack set in the hardware is 31 deep. From the memory dump it looks like the stack is being rolled out of the hardware and into the RAM. Disabling the CWP manager will probably just crash the system. but it's a test to run.

Altera_Forum · ‎07-13-2004

Did this get figured out?

Altera_Forum · ‎07-14-2004

No. None of the replys hold the answer or even a path to finding the answer.

George