This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

_free_box failing, memory pool filling up

Hi,

I am using RL-ARM 4.01 on a STMicro Cortex-M3 (uVision V4.00a), and having some trouble with mailboxes. The key issue is that _free_box is failing (have verified this in debug), and as a result I run out of memory in the memory pool very quickly.

I have looked through the docs for gotchas about this, and double-checked that the memory pool is byte-aligned (I am using os_mbx_declare and _declare_box to set things up), and also have made sure that I am attempting to free the message from the same memory pool from which it was allocated.

But when I check the return value of _free_box, it is returning non-zero every time, indicating that it has failed. Has anyone seen this, or have an idea of what might be going on?

thanks,
-David Merrill

  • I got it working, though I don't totally understand the solution. Turns out the way I was extern-ing the mailbox and memory pool into my various libraries was incorrect in some way. I had previously been putting the following at the top of my files:

    extern OS_MBX Outbox_mailbox;
    extern void * Outbox_mpool;
    

    ...but when I changed this to the following, it started working properly:

    extern OS_MBX Outbox_mailbox;
    extern u32 Outbox_mpool[];
    

    I'm considering the case closed with respect to debugging, but I am curious why the first declaration messed things up, while the new one works.

    thanks,
    -David

  • I had previously been putting the following at the top of my files:

    Therein lies a considerable problem. You should only ever be adding a declaration to one file: the header file exporting the interface of the C file defining the things in question. As a rule of thumb you should never put 'extern' in a *.c file, nor 'static' in a header file.

    Among the things this avoids is a conflict between the actual definition of a variable (or function) in one module and the declarations seen in the others; which has a considerable probability of causing just the kind of problem you've been discussing here. So don't do that.