We are running a survey to help us improve the experience for all of our members. If you see the survey appear, please take the time to tell us about your experience if you can.
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.