Posts: 6
Registered: ‎10-06-2009

microblaze malloc error


Does anyone have any experience with the Impulse FishFinder Demo Example for the Avnet Xilinx Spartan 3A DSP 1800A video kit???


I'm getting a malloc error with the Impulse AVK FishFinder Lab.  Basically it's a passthru app for this stage.

HyperTerminal output:


Output resolution set to 1024x768P @60 Hz
Configuring PS-VIDEO for XGA input on DVI-digital (P1) connector ...
 init dvi input - mode[0]=<iic_dvi_in_digital>
 Loaded 2D FIR Gain with 1.0
 Loaded 2D FIR with Identity Coefficients
malloc failed!malloc failed!malloc failed!malloc failed!malloc failed!malloc fai
led!malloc failed! Loaded Gamma_IN for Gamma(1)
 Loaded Gamma_OUT for Inverse_Gamma(1)

---- Press Any Key To Continue ----

I can't seem to get past this malloc unless I take out some code and recompile.

Any hints or help would be appreciated!





Avnet Employee
Posts: 11
Registered: ‎04-23-2009

Re: microblaze malloc error



This is indeed a bug ... the BRAM used for the code is too small.


You can solve this problem with one of the following suggestions:

1.  Increase the size of the BRAM (probably not possible, since the only choice is 2x bigger)

2.  Load the code into external memory with JTAG debugger


The base address of the program will have to be changed to the address of the external DDR memory, then load the program with XMD Debug.



Posts: 1
Registered: ‎07-27-2018

Re: microblaze malloc error

[ Edited ]

An interface to the memory already existed in my block diagram copied from Getting Started With Microblaze with some PMods added, so I assumed that the DDR memory was already being used by the Microblaze processor, but 256 MB of memory shouldn't be struggling to deal with a 2KB array. Outside of the allocated array, the program is very small. Chase Login

Regular Visitor
Posts: 6
Registered: ‎08-20-2018

Re: microblaze malloc error

[ Edited ]

I'm working on some embedded software on the Arty board and programming in Microblaze. When I try to allocate an array of sixteen-bit numbers, length 512, it works just fine, but the same array set to length 1024 causes malloc to return NULL. After some experimentation and testing, I believe this is because the Microblaze processor has run out of internal memory. However, the Arty board is supposed to have 256MB of DDR memory. 

An interface to the memory already existed in my block diagram (copied from with some PMods added), so I assumed that the DDR memory was already being used by the Microblaze processor, but 256 MB of memory shouldn't be struggling to deal with a 2KB array. (Outside of the allocated array, the program is very small.) Is there something special I need to be doing to access the DDR memory from inside Microblaze?


with regards 

Google Earth  PutLocker  ViaMichelin

Posts: 1
Registered: ‎11-18-2018

Re: microblaze malloc error

Part of the installation instructions for the ELLCC cross development suite is compiling and running bzip2 for each target processor, as described here. This is working for all the current targets except Microblaze.

Part of the test is to run bzip2 against known files and compare the results to pre-compressed result files. The first test run for Microblaze generates an error:

Doing 6 tests (3 compress, 3 uncompress) ...
If there's a problem, things might stop at this point.
../../../bin/qemu-microblaze ./bzip2.microblaze -1  < sample1.ref > sample1.rb2

bzip2.microblaze: couldn't allocate enough memory
        Input file = (stdin), output file = (stdout)
make[1]: *** [test] Error 1

To try to debug the problem, I fired up QEMU in debug mode on the Microblaze binary:

dev% cd ~/ellcc/test/src/bzip2-1.0.6/
dev% ~/ellcc/bin/qemu-microblaze -g 1234 ./bzip2.microblaze -1 < sample1.ref > sample1.rb2

This causes QEMU to wait for debug commands by listening on port 1234. The bzip2 executable is held up from running. Then I start up GDB to debug the program:

dev% ~/ellcc/bin/ecc-gdb bzip2.microblaze

Now I can connect to the program:

(gdb) target remote :1234
Remote debugging using :1234
0x100000f0 in _start ()

The program has been paused at the symbol _start, which is the low level entry point of all programs. For the Microblaze, it is in the file crt1.s. This entry point sets up the basic environment for the program and enters the start up code, ultimately entering the main() function.

Looking at the bzip2 sources, I find the message “couldn’t allocate enough memory” In the outOfMemory() function in bzip2.c. To track down the problem, I need to find out the origin of that call. I’ll set a breakpoint there, continue the and see TubiTv

(gdb) break outOfMemory
Breakpoint 1 at 0x10004db4: file bzip2.c, line 877.

From here I can use the GDB “continue” command (shortened to “c”) to get to the outOfMemory() breakpoint:

(gdb) c

Breakpoint 1, outOfMemory () at bzip2.c:877
877        showFileNames();

Great! I’ll use the GDB “where” command to see the stack trace, and find out how the program got here:

(gdb) where
#0  outOfMemory () at bzip2.c:877

Not so great. For some reason there is no stack trace. This will make debugging this problem quite a bit harder. All I can find by looking at the source is that there is a call to malloc() that is failing.

I guess there are two options here. First I could try to debug why there isn’t a stack trace and be able to use GDB to get more information, or second I could try to debug the malloc() problem. I’ll file a bug report on the GDB problem and try to track the malloc() bug down with the debug capabilities that I have.

I’m not sure if malloc() is failing in general, or if it is being given an invalid input argument. Let’s try restarting the program and setting a breakpoint on the call to malloc().

The call to malloc() is in a function called myMalloc():

(gdb) list myMalloc
1702    /*---------------------------------------------*/
1703    static 
1704    void *myMalloc ( Int32 n )
1705    {
1706       void* p;
1708       p = malloc ( (size_t)n );
1709       if (p == NULL) outOfMemory ();

Let’s set a breakpoint on line 1708:

(gdb) break bzip2.c:1708
Breakpoint 1 at 0x10006e5c: file bzip2.c, line 1708.
(gdb) c

Breakpoint 1, myMalloc (n=268724702) at bzip2.c:1708
1708       p = malloc ( (size_t)n );
(gdb) print n
$1 = 268724702

That doesn’t look good. We’re trying to allocate way too much memory. Maybe a disassembly and register dump will help:

(gdb) disas
Dump of assembler code for function myMalloc:
   0x10006e48 <+0>:     addik   r1, r1, -20
   0x10006e4c <+4>:     swi     r15, r1, 0
   0x10006e50 <+8>:     swi     r19, r1, 4
   0x10006e54 <+12>:    add     r19, r1, r0
   0x10006e58 <+16>:    swi     r5, r19, 24
=> 0x10006e5c <+20>:    addik   r1, r1, -8
   0x10006e60 <+24>:    imm     2
   0x10006e64 <+28>:    brlid   r15, -25884     // 0x10030948 
   0x10006e68 <+32>:    swi     r5, r19, 12
   0x10006e6c <+36>:    addik   r1, r1, 8
   0x10006e70 <+40>:    lwi     r5, r19, 12
   0x10006e74 <+44>:    swi     r3, r19, 8
   0x10006e78 <+48>:    bneid   r3, 28  // 0x10006e94 <$tmp596>
   0x10006e7c <+52>:    swi     r5, r19, 16
   0x10006e80 <+56>:    brid    8       // 0x10006e88 <$BB43_1>
   0x10006e84 <+60>:    or      r0, r0, r0
   0x10006e88 <+0>:     brlid   r15, -8472      // 0x10004d70 
   0x10006e8c <+4>:     addik   r1, r1, -4
   0x10006e90 <+8>:     addik   r1, r1, 4
   0x10006e94 <+0>:     lwi     r3, r19, 8
   0x10006e98 <+4>:     add     r1, r19, r0
   0x10006e9c <+8>:     lwi     r19, r1, 4
---Type  to continue, or q  to quit---q
(gdb) info regi
r0             0x0      0
r1             0xf6ffeb38       0xf6ffeb38
r2             0x0      0
r3             0x0      0
r4             0xf6ffecac       -150999892
r5             0x8      8
r6             0xf6ffeeb8       -150999368
r7             0x4      4
r8             0x0      0
r9             0x0      0
r10            0x1003e278       268690040
r11            0xae     174
r12            0xae     174
r13            0x0      0
r14            0x100305a4       268633508
r15            0x10006e14       268463636
r16            0x0      0
r17            0x0      0
r18            0x0      0
r19            0xf6ffeb38       -151000264
r20            0x0      0
r21            0x0      0
r22            0x0      0
---Type  to continue, or q  to quit---


Posts: 1
Registered: ‎11-30-2018

Re: microblaze malloc error

It is important to know that the website of Liteblue USPS would be helpful for the seeker when it comes to handling the services of liteblue login