Real-time embedded

alphacat · Feb 11, 2010

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.

dougy83 · Feb 12, 2010

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.

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?

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).

alphacat · Feb 12, 2010

dougy83 said:
Most likely it is a bug. I guess it could also be caused by bad power supply, decoupling, noise/spikes/glitches, etc.

dougy83 said:
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).

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?

dougy83 · Feb 12, 2010

alphacat said:
In the code, I use functions like Osal_mem_alloc (a function that allocates space in memory - is it RAM memory?).

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?

It's possible that it's trying to allocate memory that's not available, yes.

alphacat · Feb 12, 2010

Thank you very much for your help.

Could allocating memory that's not available cause a code to stop running?

dougy83 · Feb 12, 2010

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.

alphacat · Feb 12, 2010

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.

dougy83 · Feb 12, 2010

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.)?

alphacat · Feb 12, 2010

dougy83 said:
* did you check for a NULL pointer returned from Osal_mem_alloc and gracefully handle that condition?

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?

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.)?

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?

dougy83 · Feb 12, 2010

alphacat said:
No I did not, What could happen if it returns a NULL but the code behave as if it havent?

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?

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?

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).

alphacat · Feb 12, 2010

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?

dougy83 · Feb 12, 2010

alphacat said:
Thank you so much friend.
You really helped me out.

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?

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;
}

alphacat · Feb 13, 2010

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.

alphacat · Feb 17, 2010

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?

dougy83 · Feb 17, 2010

alphacat said:
... the if (ptr=NULL) condition

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?

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.

Real-time embedded

alphacat

New Member

dougy83

Well-Known Member

alphacat

New Member

dougy83

Well-Known Member

alphacat

New Member

dougy83

Well-Known Member

alphacat

New Member

dougy83

Well-Known Member

alphacat

New Member

dougy83

Well-Known Member

alphacat

New Member

dougy83

Well-Known Member

alphacat

New Member

alphacat

New Member

dougy83

Well-Known Member

Similar threads

Real-time embedded

New Member

Well-Known Member

New Member

Well-Known Member

New Member

Well-Known Member

New Member

Well-Known Member

New Member

Well-Known Member

New Member

Well-Known Member

New Member

New Member

Well-Known Member

Similar threads

Privacy & Transparency

Privacy & Transparency