Real-time embedded

Status
Not open for further replies.
A

alphacat

New Member
I have a major problem which I dont understand.

I got two Ucs that communicate with each other.

One of the Ucs has its entire code segment full, I cant even add an 'if else' line without the compiler issuing an error that says there isnt enough memory space.

The problem is that the code-loaded Uc sometimes stops functioning, meaning at the middle of its operation, the code stops running.
For example, every 5 seconds, its LED blinks, and when it stops functioning, its LED stops blinking.
I dont manage to always reproduce the situation where the code stops running so its very hard for me to know whether this is a bug in code.

Could it be due to memory space?

Thank you.
 
Last edited:
alphacat said:
I dont manage to always reproduce the situation where the code stops running so its very hard for me to know whether this is a bug in code.
Click to expand...
Most likely it is a bug. I guess it could also be caused by bad power supply, decoupling, noise/spikes/glitches, etc.


alphacat said:
Could it be due to memory space?
Click to expand...
The compiler's referring to program memory space, right? So unless the program is writing to its own program memory, it shouldn't be a problem with program memory space. If the problem is caused by "lack of ram", then it's a bug in the program (program shouldn't be trying to use more memory than it has available).
 
dougy83 said:
Most likely it is a bug. I guess it could also be caused by bad power supply, decoupling, noise/spikes/glitches, etc.
Click to expand...



In the code, I use functions like Osal_mem_alloc (a function that allocates space in memory - is it RAM memory?).
When you say a bug in code, you mean that I could be using too much of RAM space?
 
alphacat said:
In the code, I use functions like Osal_mem_alloc (a function that allocates space in memory - is it RAM memory?).
Click to expand...
I would assume that it would be trying to allocate RAM.

alphacat said:
When you say a bug in code, you mean that I could be using too much of RAM space?
Click to expand...
It's possible that it's trying to allocate memory that's not available, yes.
 
Thank you very much for your help.

Could allocating memory that's not available cause a code to stop running?
 
It depends on how the 'out-of-memory' error is handled (if at all). If it's not handled, it's possible that the code trying to access the memory could trash memory used for some other purpose; so it break things, for sure. If it is handled, it depends what the handler decides to do with the error.
 
Thank you again for your support.
You have taught me some important things.

I'm so frustrated.
The code is to be released in a matter of days and I dont understand the problem.

Every time I wrote a mechanism, I tested it and when i saw it works, I moved on.
Now that I tested everything and let it work for a long time, i suddenly saw this weird problem and i can't spot its source.

What I did now is removed some mechanisms that arent to be used in this release, and i did it to save on memory.
Now I let the system to run again and will see whether the code stops running again (hopefully not).

You got any advices for me please about how to handle this situation?

Thank you fellow.
 
Last edited:
If you're running out of memory (if that is the problem), it's either because there's not enough on the chip for your application, or you're not freeing your allocated memory once you've finished with it (or the memory pool is fragmented and the memory manager can't deal with it).

So the questions are:
* did you check for a NULL pointer returned from Osal_mem_alloc and gracefully handle that condition?
* did you call Osal_mem_free (with the same pointer returned from Osal_mem_alloc) when you had finished with the particular chunk of memory?
* did you free any other resources that you allocated (e.g. message buffers, etc.)?
 
dougy83 said:
* did you check for a NULL pointer returned from Osal_mem_alloc and gracefully handle that condition?
Click to expand...
No I did not, What could happen if it returns a NULL but the code behave as if it havent?
dougy83 said:
* did you call Osal_mem_free (with the same pointer returned from Osal_mem_alloc) when you had finished with the particular chunk of memory?
Click to expand...
Yes I checked it.
However, say that I allocate a memory for pointer A, and then write B = A.
Should I also free B's memory?
dougy83 said:
* did you free any other resources that you allocated (e.g. message buffers, etc.)?
Click to expand...
I'll check it out thank you.

The Osal_mem_alloc function receives an unsigned short integer.
If the compiler compiles a call to this function, doesnt it mean that you have 'unsigned short'-sized memory space available?
 
alphacat said:
No I did not, What could happen if it returns a NULL but the code behave as if it havent?
Click to expand...
You can trash memory that is used for something else.

alphacat said:
Yes I checked it.
However, say that I allocate a memory for pointer A, and then write B = A.
Should I also free B's memory?
Click to expand...
A pointer just holds the address of the memory (it points to (looks at) the allocated memory). If 2 people (A & B) are looking at the same rock, then person A throws it into the sea (person A can no longer see it as it's gone) does person B have to throw the rock also for it to be gone? (sorry, convoluted)


alphacat said:
The Osal_mem_alloc function receives an unsigned short integer.
If the compiler compiles a call to this function, doesnt it mean that you have 'unsigned short'-sized memory space available?
Click to expand...
The manual that I'm looking at is available from: https://www.electro-tech-online.com/custompdfs/2010/02/OSAL20API_F8W-2003-0002_.pdf, the 'unsigned short' parameter specifies the size of the block of memory that you want to reserve/allocate. This allows you to request up to 65536 bytes of memory; it doesn't mean that there is that much memory available. Also, as this is dynamic (i.e. runtime) memory allocation, the compiler doesn't know how much memory you are asking for (in fact it has no knowledge of what the call to osal_mem_alloc actually does).
 
Last edited:
Thank you so much friend.
You really helped me out.

Is there any way to know in advance how much memory bytes are left to allocate?
How do you calculate such thing?
 
alphacat said:
Thank you so much friend.
You really helped me out.
Click to expand...
While I'm glad you feel that way, I have no way of solving your specific problem; but I'll answer your questions as I can.

alphacat said:
Is there any way to know in advance how much memory bytes are left to allocate?
How do you calculate such thing?
Click to expand...
Assuming the uC uses a stack, you can subtract the size of the current stack (using the stack pointer) and the size of the heap (which you'd have to keep track of by adding the number of bytes allocated and subtracting the number freed and add any global variables that aren't in the stack) from the total number of bytes available. You may this to be unworkable.

If you want to find out if it's an out of memory allocation problem, try replacing all calls to osal_alloc_mem with the new function debug_osal_alloc_mem, shown below:
Code: 
void *debug_osal_alloc_mem(uint16 sz)
{
    void *ptr =  osal_alloc_mem(sz);
    if (ptr == NULL)
    {
        // so the memory _hasn't_ been allocated. So flash an LED or send a serial message
        serial_printf("Failed to allocate %d bytes\n", sz);

        // you may want to try the following to print out the return address (the address of the call to this function)
// use this line if function pointers are 16 bits
        serial_printf("osal_alloc_mem called from 0x%X\n", *((uint16*)(((char*)&sz)+sizeof(sz))));
// or use this line if function pointers are 32 bits
        serial_printf("osal_alloc_mem called from 0x%X\n", *((uint32*)(((char*)&sz)+sizeof(sz))));

        // you may want to halt execution here...
    }

    return ptr;
}
 
Got it.
I really thank you dear friend.

Yesterday I removed a mechanism which
1. took quite space in code segment.
2. used many dynamic memory allocations.

and then I burned the new code into several Ucs.

So far, the Ucs havent stopped working all of the sudden, so I hope it was indeed a memory leaking problem.

I'll have the option to use that debug_osal_alloc_mem function next week and will know whether its indeed a memory leaking problem after all.
 
Hey,

I changed each call to osal_mem_alloc by debug_osal_mem_alloc.
inside the if (ptr=NULL) condition, I wrote while(1) {RED_LED=1;}.
However, the code got stuck without turning on the red LED.

The thing is that the code doesnt get stuck when I remove a mechanism I wrote from the code.
This mechanism uses memory allocations, but i didnt write there any while or for loops which could have caused the code to get stuck (due to infinite loop).

What could cause a code to get stuck?
 
alphacat said:
... the if (ptr=NULL) condition
Click to expand...
that should be if (ptr == NULL)

If you can post the code that you think may be causing the problem it will be easier to fathom. if you're not happy doing that - as it's a work project - you can send me a PM, and I'll see if I can see anything obvious.

alphacat said:
What could cause a code to get stuck?
Click to expand...
Normally it's due to loops with incorrect logic, or just incorrect logic. Sometimes it can be caused by memory corruption (e.g. buffer under/overruns) and other things that haven't been taken into account.
 
Status
Not open for further replies.
Menu
Log in
Register
Cookies are required to use this site. You must accept them to continue using the site. Learn more…