Heap and stack collision
09/08/19 13:19

I am using the following function readAccelerometer to store the z axis acceleration value in a linked-list.

void readAccelerometer(xTimerHandle xTimer)
     (void) xTimer;
     Retcode_T returnValue = RETCODE_FAILURE;
/* read and print BMA280 accelerometer data */
     Accelerometer_XyzData_T bma280 = {INT32_C(0), INT32_C(0), INT32_C(0)};
     memset(&bma280, 0, sizeof(CalibratedAccel_XyzMps2Data_T));
     returnValue = Accelerometer_readXyzGValue(xdkAccelerometers_BMA280_Handle,&bma280);
     if (RETCODE_OK == returnValue) {
     memset(&acelBuffer, 0x00, sizeof(acelBuffer));
     sprintf(acelBuffer, "%d,%f\n",count, (float) bma280.zAxisData);
     struct node *link = (struct node*) malloc(sizeof(struct node));
     link->next = head;
     head = link;
Now I use the following timer task
applicationTimer = xTimerCreate((const char *) "readAcclerometer", milli_second(4), AUTO_Reload, NULL, readAccelerometer);

So, the timer task calls the function each 4 milli_second. Now I call the timer task to and record the data for 1 second with the following code


And its working fine. If I print the data of the linked-list, I can see 250 datas being printed.
But If now I increase the duration to 2 seconds. I am getting the 
"Heap and stack collision Error"

I have tried changing the configTOTAL_HEAP_SIZE(( size_t )(65 * 1024 )) in the FREERTOS file; but it did not work. 
Can anyone help me with this?
0 (0 Votes)
RE: Heap and stack collision
09/08/19 14:38 as a reply to Ankit Chanda.
I was defining the list in the following way:-

struct node {
    char first[100];
    struct node *next;

With further inspection, I have noticed that if I reduce the size of the character array of the list, say char first[20], I can store more value to it without getting heap and stack collision. So somwhere, there is a limit to the memory of the list. Is it anyway possible to increase that? 
0 (0 Votes)
RE: Heap and stack collision
12/08/19 06:28 as a reply to Ankit Chanda.
Hi Ankit,
there are several things I can recomend You when working with the XDK:
  1. When using FreeRTOS (and many other embedded stacks and libraries), it is not recomended to use the C-Standard malloc() and free() methods. If you really need dynamic memory allocation, please use the pvPortMalloc() and vPortFree() methods which will use the allocated FreeRTOS heap http://https://www.freertos.org/a00111.html.
  2. I would recommend to use static or quasi-static allocation by means of a queue https://www.freertos.org/a00018.html in this case. This way you will get a nice error or warning in the case the memory is already reserved.
  3. Use less memory. A one-axis data point is 16 to 32 bit value (2 to 4 bytes). You don't need to stringify it to store it, as it consumes more space.



0 (0 Votes)
RE: Heap and stack collision
12/08/19 07:42 as a reply to Francisco Llobet Blandino.
Thanks a lot for the response. In that case, if I am storing only z axis accelerometer data, with a sampling speed to 500 sps; I am storing around 2kb of data per second and in one minute it will be 120kb. And as I am storing this data to a list in the heap memory; basically I am occupying the RAM. Then, if I am not wrong, it will slow down the process speed as the ram size of xdk itself is 120kb.
Now other option can be storing it to sd card. But if I am using a csv file; to store it with this speed, I have checked, that its not possible. Because everytime I try to store a variable, I have to open the csv file and then store it. This lower downs the speed. The maximum speed achievable in that case is around 200 sps. 
Any idea how can I store the z-axis accelration data at a speed of 500 sps? 
Thank you.
0 (0 Votes)
RE: Heap and stack collision
12/08/19 08:32 as a reply to Ankit Chanda.

Hi Ankit,

not all the 128kB RAM is available for the user. A good logging/cacheing application will need more design and it is out of scope of a free advisory, but I will give some further recomendations:

Try cacheing as much data as possible before sending it out via the serial port or logging it into sd-card memory. Some 1s-2s of data can stay in RAM and can be written in bulk into the SD-card thus reducing the amount of write operations. The best options is to use an amount of data that fills and is aligned to the block size of the medium.

I also see that the data retrieval is happening in the timer-task context which should have a high priority. Depending of what you execute, this will block lower prioritized tasks or services.

Try to have an application with a data acquisition process triggered by a timer and a data forwarder or storage process which will take care of streaming or storing the information.

Best Regards,



0 (0 Votes)