Code Composer studio and RAM usage

[juani_c 66]

I'm testing Mahony's algorithms for attitude estimation and I'm using a Launchpad with a MSP430g2553. In the code I'm using there are two functions; one calculate the attitude from accelerometer and gyro data (IMU) and the other one add magnetometer data (AHRS).

I tested first the IMU and worked OK.

Then I tested the AHRS and I couldn't make it work. What I could find through debugging was this:

In the top of the program there are four variables q0=1, q1=0, q2=0 and q3=0 and in the algorithm there is a sqrt() function, it seems that for some reason the sqrt() function overwrite the values in q0, q1, etc. As the algorithm use then those values the final values is of course wrong.

I then tried the program with AHRS in a MSP-EXP430FR5739 and it worked OK.

According to CCS the Memory Allocation in the MSP430G2553 is RAM=344 FLASH=12.354

and in the MSP430FR5739 is RAM=518 FLASH=13.034.

 

It seems that the code need 518 bytes of RAM, higher than the 512 of the MSP430G2553, I asume that's the issue, correct?

If is that, why CCS shows only 344 bytes used? Is there some way to know when I'm running out of RAM (other than the thing don't working...)? some way to see it in CCS?

[abecedarian 330]

The FR5739 has a hardware multiplier and the G2553 doesn't.

 

That could account for the difference in RAM usage?

[chicken 630]

The compiler generates a .map file which contains detailed information about memory allocation. You find it in the Release or Debug folder.

[juani_c 66]

The FR5739 has a hardware multiplier and the G2553 doesn't.

 

That could account for the difference in RAM usage?

I wasn't using the HM. I enable it now and the code seems to use the same amount of memory. The execution is faster, from aprox. [90]ms to 13[ms] (@default DCO = ~625 KHz)

[juani_c 66]

The compiler generates a .map file which contains detailed information about memory allocation. You find it in the Release or Debug folder.

That file shows the same values that I see in the Memory Allocation.  The thing is why it shows me only 344 bytes, from that I get that I still have RAM to do other things...

[chicken 630]

If the overwritten variables are towards the end of the memory map, this indicates that your stack grows too big. If the overwritten variables are locally declared in a function, this can also indicate that your stack grows too big, i.e. starts to overlap with global variables.

 

Variables declared locally (e.g. within a function) are allocated dynamically on the stack and won't show up in the map file. Stack space is also used to temporarily save registers during function calls. Complex functions like sqrt probably use quite some space to save temporary results.

[juani_c 66]

The variables are globally decleared. Here are some screen captures of the before  

and after the sqrt() function, the stack is close so that's probably the problem.  Thanks!

 

[chicken 630]

One thing you can try, is to rewrite the MahonyAHRS functions to accept a pointer to a structure (3D vector matrix?) instead of 9 floats. Right now the 9 floats (36 bytes) will be copied to the stack for each function call.