MSP430FR5849: Signed vs unsigned SPI data

How many bytes are each data point? If more than one, how are you combining them into a single value? What type are you using to store the data? (i.e., is there a risk of overflow?)

Have you tried running some of the data by hand to see where things might be going pearshaped?

Can you share an example?

Currently we are storing in an integer. It's possible that the integer isn't big enough but we are also moving to a 16bit integer given what I've discussed with other engineers. We are now going to be working with 2 bytes per data point, but our 1st byte consists of access to all 8 bits and the 2nd byte only consists of access to the 4 most significant bits [7:4] and the last 4 [3:0] are "reserved" meaning we can't access them. We are currently working on combining the data bytes now put we have previously thrown away one and sacrificed accuracy for speed. Now that we can have more accuracy we are currently working on using the 2 bytes that we can get. It could also help to know that the data is also left justified, in case that has any affect on the two's compliment. The lab test cases are no were near what would cause an overflow at this time. In the past we were saving the data and would run the math in excel which resulted in our expected values.  

There is some confusion on types here. An "integer" is probably 16 bits, so moving to a "16 bit integer" is probably no change.

It is unclear where "We are now going to be working with 2 bytes per data point, but our 1st byte consists of access to all 8 bits and the 2nd byte only consists of access to the 4 most significant bits [7:4] and the last 4 [3:0] are "reserved" meaning we can't access them. " comes from. Is this the return from the accelerometer? Can you share with us the accelerometer you are using? Can you share a small example which shows the issue?

I suspect an issue creating a 16 bit integer from your 2 spi bytes.

The data is certainly more than a single byte, received a byte at a time. This should be stored into something with type "unsigned char". Then it can be combined with another byte.

The key is to keep the compiler from sign extending a byte to an int. It can do this even if you don't specifically cast it to an int.

ADXL373 from Analog Devices. See pages 35 and 36. We are only using the x axis. 

Example data from centrifuge:
0C
0C
0C....

We then left shift 4 because we are only looking at the high byte.
0C0
0C0
0C0...

0C0 => 192 LSB(Dec)
192/5 = 38 G

Based on our RPM calculations we were spinning at a rate that would result in 38 G hence why we saw 38 G's.

The actual code that isn't working for you would keep us from guessing. Including how you read the data and what you do with it.

And none of this explains why there should be an issue summing values.