CCS/MSP430F6720: Can variable value change when being passed to a different variable?

The RAM usage is only 44%, while FLash is indeed being pushed to the limit, > 99%.

Could you explain this a little more? If the error is caused by EMI, I would assume other parts of the code will be affected as well, and the control that is sitting right next to the one with high error rate will be affected at the same rate.

Thanks.

There are temporal variables are used. What would be solution if error was caused by such operation?

Also BIT7 occassionally flips from 1 to 0, but we don't have operations like &= ~BIT7;

char sensorType = 1;
int sensorValue = 0x0172;
xbeeSendIntAT(1, 0, 1, sensorType | BIT7, sensorValue);

In test setup, sensorValue is assigned/hard coded as in the following code:

char sensorType = 1;
int sensorValue = 0x0172;
xbeeSendIntAT(1, 0, 1, sensorType | BIT7, sensorValue);

then it is passed to tempArray[2], further transmitted out via UART and checked on the receiving end.

Hi,

OK, we return to the original point.

Let us clarify your problem, please check every item carefully.

1. When you send a word to PC. You sometimes find that the data sent and the PC receives are different.

2. The only difference lies on bit7 in the lower byte.(0 to 1 or 1 to 0)

3.  However, you find that the checksum is right when checked by PC.

If so, we can reach a conclusion, the data is changed before it is send into xbeeSendByte()

There are two reasons: hardware and software.

hardware:  EMI, MSP430 bug

software: pointer

Anyway the problem is happen in MSP430. Can you define a constant value of sensorValue which is saved in flash and more reliable? And compare it after generating the checkSum. If it can response to the error, we can know that the data is changed in RAM and happened before generating the checkSum.

The problem is so strange. So doing experiment and make assumption with solid evidence. All your reply is only in word, please attach some test result.

Eason

Your summary is right, I will add/edit to for the sake of completeness.

1. Data are sent to PC via a xbee radio connected to UART on MSP430. The xbee part is important. We didn't test wired connection, and I don't think hardwired connection will generate such errors as well.

4. frameID, the message count received on PC is also correct.

The following code is used in one of the test and resulting data received and plotted image are attached.

int readTemperature() {
	sdReadCount++;      // declared in header to generate artificial swing
	if(sdReadCount > 59) {
        sdReadCount = 0;
        return 400;
	} else {
        return 370;
    }
}

int readCO2() {
    return 5000;
}

int readRPM() {
    return 120;
}

// Following code running in main clycle, once per second
sensorvalue = readTemperature();
xbeeSendIntAT(1, 0, 1, 1, sensorvalue);

sensorvalue = readCO2();
xbeeSendIntAT(1, 0, 1, 10, sensorvalue);

sensorvalue = readRPM();
xbeeSendIntAT(1, 0, 1, 4, sensorvalue);

Please note, in the ~ 12 hours when a good radio put in, no spikes were detected. It is a short period of time, not conclusive but indicative enough. Once the bad radio is put back in, spike start to show up. Changing of value from 370 to 498, and 400 to 272.

Please note the circled spikes from 120 to 248

Please note the tiny downward spike, 5000 to 4872

Please note message 37, 38, 39; Those are from an earlier session of test.

Message 37: scout report that temperature is 0190
one second later:
Message 38: scout report that temperature is 01F2 while the actual value should be 0172. Observations: 1) this 01F2 value came out of nowhere. 2) frameID byte correctly incremented by 1. 3) checksum byte adds up. 

200 mini second later:
Message 39: scout report alarm is cleared, with latest reading(should be the same as in message 38) at 01F2, again, the correct value should be 0172, because 01F2 is greater than threshold 017C. If the current reading as seen in monitor.c is 01F2, monitor.c won't think alarm is cleared.

The conclusion so far is, a compromised xbee radio caused this error, but how exactly this happens is unknown. Also the problem is not limited to this particular radio. We have data from field test that "Good" radios can also cause such errors but at a much lower rate.

this was not clear to us at the time. We evaluated a wide range of possibility, eventually narrowed down to the radio with fixed sensorValue in firmware, and swapping of radios etc.

Please note the lonely upward spike here. this test lasted more than 2 weeks.

Rotor speed data during the same period of time. Two upward spikes from 119 to 247. Please ignore the downward spikes, motor slowed down during normal operation.

For the record, the problem is further narrowed down to either Xbee radio itself or the communication between MSP430 and Xbee radio via UART.

We were able to catch a bout of errors on the receiving end. In the attached image, the last column indicates whether the message is valid or not judged by whether checksum matches. Red marks wrong byte(s), with correct values in following line. Double error in both sensor value bytes and checksum byte did happen. in this case, the message appear to be correct on receiving end while it is actually incorrect.

So far the most prone bit seems to be either BIT7 or BIT3. The problem could happen between two xbee radios or xbee radio and MSP430, but shouldn't have happened in memory.