I'm trying to use dynamic memory on str912fw44. The code compiles well but when it starts to debug, it gives some error : "*** error 34: undefined identifier Non-Aligned Access: Thumb Instruction at 0000C072H, Memory Access at 0000C230H ... *** error 65: access violation at 0x00080000 : no 'execute/read' permission"
The code I tried was :
ubyte *ptr; int main() { ptr=(ubyte*)calloc(10,sizeof(ubyte)); }
Tools : Keil uVision IDE, Keil Ulink2.
Could you please tell me what could be the problem ? I don't know where to look. How can I know the size of the memory area used as heap ?
"I don't know where to look. How can I know the size of the memory area used as heap ?"
If you need to ask those questions, then you're probably not ready to start using dynamic allocation!
Dynamic allocation has some serious implications for embedded systems - so you really need to understand what you're doing before you start!
In many cases, Dynamic Allocation is best avoided completely in embedded systems...
Thank you for your reply, Yes it is first time I am trying to use dynamic memory allocation but I have to learn anyway. In my app. I need to save a number to flash (number of panels connected to compose a led display) and then read it at every start to know how much area to use to hold the required data. And I will never free the allocated area till power off. It is all I need now. I saw stack and heap sizes are defined in str91x.s startup file, as far as I understand I am supposed to determine how much heap I need. It's default value is 0x00 in the file. Total RAM size is 96 KByte. How do I know if it is OK to assign 16K for my heap ?
I need to save a number to flash (number of panels connected to compose a led display) and then read it at every start to know how much area to use to hold the required data.
Allocate the maximum amount statically, and you don't have to worry about dynamic allocation, or what happens if the dynamic allocation fails (e.g. there isn't enough contiguous memory for a malloc/calloc() call to succeed).
Also, be aware that main() should not return unless there is actually something that will take control of the CPU after that happens (on the PC, that'll be the operating system, but on most microcontroller systems, there is no equivalent). main() usually needs to be an endless loop, or at least end with an endless loop.
Thank you very much. App data to be hold is very much for each panel, it is why I don't want to define a max statically. I dont use dynamic memory for something else, only one structure will be dynamic. Is it not safe ? Does anything else use the heap other than my "malloc/calloc" code ?
So what is the point in it being dynamic?!
You have to know its maximum size so that you can set the heap size - so why not just set the size statically in the first place?!
Thank you very much. App data to be hold is very much for each panel, it is why I don't want to define a max statically. I dont use dynamic memory for something else, only one structure will be dynamic.
There's no point in doing so. It makes no sense. Especially if that is the only place dynamic allocation is used.
Your program will have to deal with the maximum number of panels attached. That means that the heap must be able to hold the data for the maximum number of panels. The heap is allocated staticially anyway. If you are not using dynamic allocation anywhere else, then it makes no sense to do it here - just allocate memory for the maximum number of panels statically, get rid of the heap, and be done with it.
Is it not safe ?
Programs needs to be able to deal with malloc/calloc failing to work, for example. That means having to add extra code for error handling.
Not just extra code:
You need some way to alert somebody to the failure, so that it can be fixed. If it's an unattended system, how do you do that?
And when someone has been notified, there's all the training & support to enable them to do something about it.
etc...
Thank you all, Yes you are right, I just did not want to occupy much memory if not needed, because min values will be in use mostly, and max value will be for future needs. But, as you all say, for all reasons it is the best to use static allocation. Thank you again.
There's the rub: if it's going to be supported for "future needs", then that support has to be there from the start!
Of course, if you need to do a firmware update anyhow to support these "future needs" when they arise, then you can adjust the static allocation at that time...