MSP430G2553: Temperature sensor calibration constant possibly incorrect

Hi Michal,

Can you send a good quality photo of the top of one of the bad devices?  Also from that particular batch of units, all have the same issue and if so would you happen to know how many of those devices from from lot you purchased?

Hi Dennis,

There were 20 devices in that order (it was June 2022) and they were waiting on our shelf until now, we were using older inventory. We have assembled only three units with these devices, and two of these seem to behave correctly, while just one shows that lowered temperature. I cannot say anything about the remaining devices.

Here is a photo of the suspected device:

And this is an unused device freshly taken out from the tube in which they were all shipped:

Best regards,

Michal

Hi Dennis,

Could you recommend any action? Just replace the device with next one from the same purchase and test?

Best regards,

Michal

Hi Michal,

I apologize for the delay.  No, I wouldn't spend the time replacing the device.  It sounds like the issue is related to the lot, so another device from same lot will most likely have same issue.  I'm working with the production team to locate the production history on this lot.  This may take a day or two.

Hi Michal,

According to our production/test records, this device lot was produced on Oct 7, 2021 and tested with same production SW running since May 2016 ( No updates/changes to this program.)

Is it possible to check devices that have never been programmed?

To further muddy the waters, I checked the G2553 (19AQKHK A) sitting in the (ancient) Launchpad I have:

010e0: c3 7f e3 02 00 00 57 80 b9 01 00 00 fe 08 ff ff

Showing zeros for both of the T85 values.

Hi Dennis,

Thank you for the update. I think I have to order a ZIF socket to test the remaining unused devices in our G2 Launchpad. It is more reasonable than start mounting them on remaining bare PCBs.

Hi David,

Interesting.  Since you say it is ancient, it is possible the Launchpad was shipped with pre-release silicon.  This means it may not have had the full production testing in place at that time, but was determined to be ok to build Launchpads with.  This is common when a new device is about to be released.  We want to have Launchpads, docs, etc., the day of the official release, so this means the Launchpads were built 6-8 weeks before the official release and hence "pre-leased" silicon.

Hi David,

Out of curiosity, can you take a photo of the LP, specifically the markings on the MSP package?

Thanks.

I included what seemed to be the date code. They are such low contrast that it required a lot of work to find just the right angle to be able to read. Getting a photo of that...

Yes, the reason for the photo is when I looked up the lot id you provided, it came back with a completely different part - TPS62125DSGR.  I was hoping a photo would help.

Hi David,

I have managed to test the remaining 16 devices from that purchase without programming them, applying the following procedure:

1. Mount the device in a ZIF TSSOP-28 to DIP-28 adapter inserted into the DIP-20 socket of a G2 Launchpad.

2. Power it on and take control using "Attach to running target" in IAR EW IDE.

3. Export the contents of INFO A segment to a TXT file and enter the four temperature sensor calibration constants into a spreadsheet.

4. Import a piece of code into RAM from a TXT file. The code stops WDT, verifies TLV checksum, switches DCO to 12 MHz (as in our standard applications) and reads the temperature sensor using 1.5 V and 2.5 V internal references, trying both at 2.0 MHz and 1.5 MHz ADC10CLK (SMCLK/6, SMCLK/8), i.e., with 32 us and 43 us sampling times, respectively. Each result is averaged over 64 reads and stored as multiplied by 16 (i.e., with 4 fractional bits).

5. Set PC to the code RAM, put a breakpoint at the end, and run the code.

6. Enter the results into the spreadsheet to convert them into temperatures.

At the end, all devices returned into their tube in the same order (hopefully) -- in case some of them need further testing.

The tests took a few hours (the relatively cheap ZIF adapter I could order immediately did not contact reliably in all pins and I lost much time reinserting the devices and restarting the debugger until I turned the adapter 180 degrees) and the ambient temperature changed a bit in the meantime, but:

1. For most devices, the results were quite consistent. The extended sampling time did not seem to have significant impact.

2. A couple of devices (#09, #12, #13) have shown noticeably higher temperatures (by 2 or 3 degrees Celsius) which cannot be attributed to ambient temperature changes (devices #09 to #16 were tested without long breaks between them). One device (#10) shown noticeable difference (ca. 2 degrees) between the results for 1.5 V and 2.5 V reference.

3. Anyway, the results for none of the tested devices were as bad as the device described in the original post.

The table below summarizes the results. Two PDIP-20 devices from different lots (used to test the code on the day before) are included for comparison.

Should I post the complete TLV dumps?

Best regards,

Michal

Michal,

You certainly have gone above and beyond collecting this data - thank you very much for your time and effort.

Regarding the TLV dumps, hold for now. I'm sharing this data with our production test team and let's see what they come back with.

Here is a thought...when you perform the ADC measurement, what state is the CPU in?  Active mode or sleeping?  If not in sleep mode, can see if you can modify your code so the CPU and clocks are off to minimize system noise.

Hi Michal,

Do you have any sense of the temperature accuracy or temperature spread in the previous products you built?

Hi Dennis,

Unfortunately, no. The temperature of the critical part of the product is sensed using an external thermistor connected to one of ADC10 inputs. The internal temperature sensor serves as a protection against using the product far beyond recommended conditions, so we do not require great accuracy here. I simply have never observed a temperature reading such obviously different from the ambient temperature as in the device which gave origin to this thread. And I have always used the 2.5 V reference only (because of the range of our other analog signals), so I cannot say anything about 1.5 V readings.

Actually, our main concern is if the temperature sensor calibration data is the only problem with this device.

Hi Michal,

I wouldn't be concerned about the MSP430 operation (ADC, temp sensor).  In this case it appears the calibration values were programmed incorrectly, on at least 3 devices.  Looking back at historical production data, the team doesn't show any reported issues or changes to the production code that might account for the behavior you are seeing.  The team also indicated that the production calibration can vary by 2-3 degC.

Since there are other devices in the same lot# that appear to have reasonable calibration values, I would suggest you keep monitoring the situation and notify me if you find additional devices that are way out of calibration.