| View previous topic :: View next topic |
| Author |
Message |
Martin Berriman
Joined: 08 Dec 2005
Posts: 66
Location: UK
|
| Dynamic memory problem |
 Posted: Wed Jan 31, 2007 5:17 am |
 |
|
I have come across a peculiar problem when using dynamic memory allocation (using Ver 3.249).
I am using a PIC18F4620 which has 3986 bytes of SRAM. Currently my compiled program uses 5% of available RAM (192 bytes or 240 bytes worst case). I have a routine that uses malloc to allocate 1352 bytes and then reads data from a FRAM into the allocated space. This has worked well up to now.
As I continued to develop my program, the above routine suddenly stopped working. It would still work when running under the debugger - (that is, if I include '#device ICD=true' it works fine but if I leave this out it does very odd/unpredictable things).
Now I have managed to figure out that it is having a problem freeing the allocated RAM. If goes into the free routine (in stblibm.h) and sets the pointer to NULL but then when the free routine calls the traverse routine, it gets stuck in an infinite loop - it therefore appears at first sight like a bug in the CCS dynamic memory library.
My thoughts so far are:
1) As the program has grown, perhaps it is now being forced to split the allocated RAM and perhaps the stdlibm.h routines have a bug somewhere.
2) Perhaps I should allocate smaller amounts of RAM and then read the data in a number of stages - seems a shame not to make use of the RAM I have available though to speed things up.
I see little point in posting code as it works when run in the debugger - it seems like the additional code that is added when debugging prevents the problem - more likely is that different/other problems are then in the code but ones which I have not noticed yet.
Any suggestions are gratefully received. In the meantime I will continue to experiment...  |
|
 |
Martin Berriman
Joined: 08 Dec 2005
Posts: 66
Location: UK
|
|
| Posted: Wed Jan 31, 2007 5:27 am |
|
|
Hmmm - Bad form to answer your own post I know but I have just spotted another post that has got me wondering:
Other Post
According to the datasheet,
| Code: | The memory space is divided into as many as
16 banks that contain 256 bytes each; PIC18F2525/
2620/4525/4620 devices implement all 16 banks |
So is the stdlibm.h library definitely limited to blocks of 256 bytes? - Strange how it has been working - can anyone explain why it has been working? |
|
|
libor
Joined: 14 Dec 2004
Posts: 288
Location: Hungary
|
|
| Posted: Wed Jan 31, 2007 7:58 am |
|
|
| I think these dynamic memory functions use indirect addressing (i.e. instructions working with data addressed by the FSR0-FSR2 register pairs, each pair holding the full 12-bit address as a linear continuous area). There is no banking issue with the indirect addressing. |
|
|
Martin Berriman
Joined: 08 Dec 2005
Posts: 66
Location: UK
|
|
| Posted: Wed Jan 31, 2007 8:15 am |
|
|
| libor wrote: | | I think these dynamic memory functions use indirect addressing (i.e. instructions working with data addressed by the FSR0-FSR2 register pairs, each pair holding the full 12-bit address as a linear continuous area). There is no banking issue with the indirect addressing. |
Thanks for that. I think from looking at the LST file, you are right. I have also looked at the stdlibm.h file and see:
| Code: | #elif defined(__PCH__)
typedef struct nodet {
long size;
long next; }node_t;
#endif |
so it obviously can handle larger amounts of ram otherwise why use a long for the size.
It therefore looks like there is a bug in stdlibm.h but I do not have the time at the moment to try and find it so for now I have changed to use statically defined arrays within each function during compile. At this point I should know what the maximum size of each will be so this will be a suitable solution. It works at least... 
Maybe I'll come back and investigate further when time allows...
CCS Technical Support does not monitor this forum on a regular basis. Please do not post bug reports to this form. All bug reports should be emailed to support@ccsinfo.com. Thank you. |
|
|
|
FAQ 
Search
Register
Profile 
Log in to check your private messages 
Log in
