CC430 Temperutre Sensor Reading

When reading from teh internal temperature sensor, there are three devices active which need calibration. First, the ADC itself, which has an offset and gain error, then there is a reference error(that applies to each reference voltage separately)(both, ADC and reference, are merged into one calibration value for each reference voltage). Then, when the ADC is calibrated and correctly reports the voltage it is reading, there is the temperature sensor itself, which also has an offset and gain error. And here the bandwidth of possible gains and offsets is very large.
So in the foprmula that calculates the temperature form the ADC reading, you'll have to use device-dependent factors too, and these can be very differend between devices.
I don't know for the CC430. The 5438 has calibration values for both in its TLV structure. Using them (and the correct formula), instantly delivers good results.

05 | Tommy said:

Is it possible that the calibration Data of the Bad µC are not OK?

Hello,

I think in these µC is a problem with the calibration Data:

The ADC Result on a Temperature of 22°C is 08 80h.

That shows me that the ADC Result shows a Temperature higher than 30°C in relation to the calibration data (Ref Voltage = 1.5V).

Is this OK?

Having identical vlaues fdor all three calibration points looks indeed odd.

What does the 'good' chip show there?

Hi,

on the good module the calibration data are:

Well, it definitely looks liek the calibration data has been damaged (or was never written correctly).

I wonder how this could have happened. A problem in the factory process? Such things shouldn't happen.

A latchup effect inside the device which wasn't detected during calibration, so wrong calibration data was written for all 30° points? If so, then you're likely unable to get any meaningful reading from the sensor at all.
Try to read the ADC12 sampling result for different references and temperatures around 30°. It's possible that you'll read the save value ever and ever again, only changeing when raising somewhat above 30°. This would indicate an internal latchup that may be caused by a device defect. If so, I wonder how this is possible and why this wasn't detected when calibrating

I guess that's a question for one of the internal TI engineers.

Priya, if you're reading this, yould you please forward this thread to one of the engineers? It could point to a possible problem in the QC/calibration process (surely a rare one, but well...)

Hi,

when I take the bad µC in a room with about 30°C the ADC read is about 0x089Fh.

The calibration data on this µC (Ref = 1.5V / 30°C) is 0x0430h.

05 | Tommy said:

when I take the bad µC in a room with about 30°C the ADC read is about 0x089Fh.

The ADC readout is defferent to the reference voltage

Then it isn't the temperature sensor that failed, it is the calibration process that failed. For calibration, the device needs to be measured one on 30° and once on 80°. Maybe something failed when measuring the 30° values.

It would be interesting to know whether the two processor you have are from the same wafer (at the beginning of the TLV structure). But it probaly won't bring us further. I'd suggest returning the device to TI for replacement and investigation. But contact someone before doing so.

Something like that should not happen. Something went wrong during production.

Anyway, you can do your own calibration and use these values. As all had to do on the older MSP series without any calibration information.

The Lot / Waver ID on the good chip is: 46B01BCAh

The Lot / Waver ID on the bad chip are: 46894DA6h / 46894DA7h and may be more

Well, this almost identical ID on the bad chips may indicate a problem during production/calibration process. Are the good and the bad ones the same silicon revision? The difference in the ID to the good chip might indicate that they are form an older stepping and/or production process.
Anyway, contact someone (either the one you bought the chhips from or someone directly at TI) and return them for exchange.

The good chip has the revision "D" and the bad ones has the revision "E".

Strange. The wafer number is higher on the D types than on the E type. I'd expect it the other way. Or did I miss something?

not for my understanding.

I hope, that somebody from TI will find an answere, soon.

Tommy,

interesting that all calibration values are the same, 0x0430. We sometimes leave some cal values out, but they would be 0xFFFF.

Couple of questions, sorry if I missed them from the thread:

* How many Rev E devices have you tested with? Are they from the same lot? Are the values the same on all of the devices?

* Which IDE/programming tool are you using? Could you please describe your procedure prior to reading the cal values? I know most likely this won't be the case, but is it possible at all that during your programming/debugging flow something accesses/modifies these address locations unknowingly?

I have asked our engineers to check if they have specific information on that wafer lot. Separately, I'm also acquiring some Rev E devices to verify the information as well. Once we have more information I'll update you on the thread and via email as well.

@Jens-Michael,

sorry I'm not Priya, but she sends her regards :).

Thanks & Regards,

Dung

Hi Dung,

I checked the Calibratioin data on about 5 devices.

The lots I found were 46894DA6 and 46894DA7.

No. The values are around the 0x0430 the highest is 0x044F and the lowest is 0x040f. But for all reference voltages the calibration data are nearly the same (+-1).

On all devices the calibration value is about 0x430.

I use IAR 5.10 . To get the Values I switch to debug mode, open them memory view and read the values on the address 0x1A0A for the Lot and on the addresses 0x1A1A; 0x1A1E and 0x1A22 for the calibration data on 30°C.

I don´t think that I can access these calibration data by programming the µC.

Thanks for your time.

Dung Dang said:

sorry I'm not Priya, but she sends her regards

Dung Dang said:

interesting that all calibration values are the same, 0x0430

Personally, I didn't use the reference values in my previous projects because there were none in the 1x series. So I had to calibrate my devices anyway (and due to external components tolerance, it is still needed). But if there are such values, you should be able to trust them.

Hi all,

We have exact same problem with our CC430F5137 Rev. E devices.
Any updates on this issue?

best regards,
Gregor Bader 

Gregor,

we are still looking at our test data to investigate the root-cause. In the meanwhile, could you please do me a favor and copy the entire block of flash content from 0x1A00 to 0x1AFF on your 'faulty' devices? 

It should look like this, for example:

06 06 48 1f 61 37 12 12 08 0a 83 4d 89 46 14 00 1d 00 f8 fe 11 10 03 80 01 00 13 04 f3 09 13 04 77 07 13 04 f9 05 12 06 4e 7c 43 7c 48 7c 02 57 08 8a 0c 86 0e 2c 40 92 00 1e 00 23 00 09 00 0f 00 03 00 1f 10 41 02 30 02 38 01 3d 00 44 00 40 01 48 02 42 03 a0 01 10 04 51 02 52 02 53 0e 5f 02 62 04 61 12 68 02 85 04 47 0c 90 14 d1 1c a8 10 80 04 b1 50 bc a8 40 90 91 d0 60 61 bc 46 62 63 50 51 b0 68 80 00 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff 20 01 00 a5 2e 01 00 11 10 01 ed 96 1c 01 00 26 10 01 1c 96 1c 01 a5 90 10 01 a0 96 12 01 24 77 10 01 02 96 12 01 25 40 14 01 89 22 94 01 d3 ff 58 01 fc 5a 82 01 03 00 c2 1a 20 01 ff ff

Please either list them here, or email me offline.

Thanks & Regards,

Dung

Hi Dung,

Files attached from 3 devices 0x1A00 - 0x1AFF.

best regards,
Gregor 

Gregor,

thanks for the info. I'll update you once we finish analyzing the cal test data.

Regards,

Dung

Hi,

Any update on this?

best regards,
Gregor 

Any Updates?

Same problem.

Hi guys,

sorry for the slow update,  we were finalizing the description of the behavior and prepared it for the erratasheet update, which will become online shortly. Here's the summary:

it has been found that this is an error during the calibration process where the same incorrect value is stored for all 30C temp values [85C values are still  valid]. This erroneous procedure only occurred to a certain number of devices (basically belonging to certain Lot Trace Codes) of CC430 RevE and MSP430F552x RevE. This problem has been fixed for the subsequent devices. 

For the affected devices, if you want to perform a quick fix, you can recalibrate them [for 30C only] in your application in a known temperature environment. 

Alternatively, please contact your sale reps for possible exchange with newer devices.

Thanks & Regards,

Dung