Temperature sensor (ATtinyX4) ... die heats up??

Go To Last Post
10 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I have an ATtiny that I talk to using I2C, and one of the things I do is ask it for the temperature.

I'm seeing odd behavior ... when I ask the temperature after the AVR has been idle for some time (an hour, say) it tells me one thing (say, 17 degrees C), but if I've been talking to it a lot via USI just a few seconds later, I get readings of maybe 3-5 degrees higher (like 22 degrees C). Let it sit idle, ask it again, it's back at a low temperature again; this is very repeatable. I haven't yet experimented to see how quickly the temperature rises or falls, or get very good offset calibration.

Is it realistic to think that I'm observing the die heating up because of the work involved in handling several hundred USI requests? And if so, does anyone have suggestions about how to get more of a long-term stable temperature reading? I've not used this sensor before, I don't really know what to expect. Should I be averaging over some sample interval rather than just returning the latest reading?

The code basically sits in idle state most of the time, with a 4 MHz clock, except that I currently have it constantly doing ADC conversions while it does so. (The temperature sensor, and some external voltages.) There's a timer ticking; it pets the watchdog and flashes a LED. Basic power management tricks have been applied (nothing aggressive). Eventually it will take samples less often ... say, only after petting the watchdog.

Or else ... when the host talks to this slave via I2C, my current test rig gives it bursts of maybe 50, or 50 + 200, requests that both keep I2C active and involve a bit of work. ("In the field" such burst will be rare.) The I2C clock is closer to 400 KHz than 100 KHz. So I could imagine those bursts of work heat the die up enough that the temperature sensor is misleading.

Comments?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

The 3-4 K temperature increase due to internal heating sounds realistic. Because of the this self heating and the low overoll accuracy, it is probably not neccessary to read the temperature more than just once.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I would suggest, avoid different CPU states with different power consumption.

E.g. instead idle, enter an endless loop.

Peter

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Your AVR is going to use no more power calculating or sitting in an idle loop. If you use the power_down or sleep functions then the power consumption will reduce.

The chip will use more current if it is driving the output ports. A high toggle rate driving a capacitive load will also increase current.

So in my personal opinion any self heating of the die is mostly due to resistive losses in the i/o ports rather than any cpu processing.

You may find it an interesting experiment to observe the temperature rise with nothing connected to the ports. I would guess that it is negligible. You could also intentionally abuse your Tiny by driving the maximum total current allowed in the data sheet. Observe the recorded die temperature. Compare with the temperature ratings for the chip.

David.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

@Kleinstein: Reading temperature only once is no good; that (sub)task is to provide a reading of current ambient temperature, and potentially issue alarms if that goes too high. But thanks for the confirmation that my theory seems plausible.

@danni, @david.prentice: Hmm, not sure. Power consumption is always an issue. I could believe that in this case some extra heat *is* from driving the SDA (and less often, SCL) lines ... but CPU use would seem to be an issue too. One difference between active and idle states is that the CPU isn't supposed to be clocked in idle! That's lots of transistors (not) switching. The only resistive load being driven is a lowpower LED, but its duty cycle is constant so that couldn't explain a change in temperature.

I think what I'll end up doing is probably cutting the sample rate, say down to once a second, and then averaging the last N samples.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I hope I am not being pedantic. You should never drive the i2c lines. You are either an input or you are sinking the line. If you should try driving the line high then any other device that is sinking the line will have a conflict.

I would suggest that a regular i2c interrogation is not much activity. If your Tiny does nothing more than report the temperature when asked. I presume you are using the normal start interrupt followed by USI interrupt for your Tiny slave.

Your Tiny could obviously be fast asleep until it gets its i2c-start IRQ. I still doubt that sleep / active mode will make a significant temperature difference. If you are driving an LED then you cannot be fast asleep, and I agree that this will be a consistent load. Even a low powered LED will consume a significant current and contribute to dissipation in your die.

David.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

@david.prentice: You're being a trifle pedantic; by "drive" I meant no more than "let the USI controller have its say about signal levels". Yes, it's a standard USI driver, though it's much more correct than the appnote from Atmel suggests.

The only reason I suggest that the I2C activity might be a bit much is that it's got a fair amount of protocol to run in this test setup. As I said, possibly several hundred requests. So the theory is that the *CPU* activity may be affecting the part of the die near the temperature sensor. I'd expect the path driving that (debug) LED shouldn't need to go through those parts of the die ... those currents should stay near the periphery, not the center, of the die.

Some more information about the problem makes me think the problem might be exaggerated by some issues on the I2C master side. The particular numeric encoding used involves some conversion from the integral sensor value reported over I2C into floating point, which is then displayed. It happens that the floating point code is what I'd call young and untrustworthy... there's no hardware FPU, and that whole toolchain is young. I added a simpler alternative representation, and that reports less variability.

So while it's clear that the raw temperature sensor reading is indeed varying by several units, I now think I see a couple more factors at play.

    First, the floating point behavior looks odd; the true difference is wrongly magnified.
    Second, if I consider that "temporally adjacent" raw temperature sensor readings will differ by a few LSBs .... I think I'm also observing plain old fuzziness in those LSBs, of the type that can be caused on AVR8 by digital activity during the sampling.
The hundreds of I2C operations are certainly happening while a sample is being taken, unless the chip was previously idle.

I think that I may well be observing the die warming because of those activity bursts, but that another issue is that in this system I can't really expect the lowest two ADC bits are stable. And with these on-chip temperature sensors that means the readings are going to be highly variable; there are only maybe 7.5 bits of usable range, after all.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Are you building one or many?

And, therefore, are you CALIBRATING one, or many?

The ATTiny data sheet, (Section 16.12, not listed in the pdf index...), notes that the Tiny's Temp Sensor must be calibrated. It is not factory calibrated / laser trimmed. Also, for a single point calibration the accuracy is only about +/- 10 'C. :!:

Also, each chip is different, and must be individually calibrated.

Obviously it gives a Temp reading, but if you need better accuracy, or desire a calibrationless system, there are better alternatives.

JC

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

1. Sorry about the "pedantic" bit. I was worried about bus conflicts causing over-current. Are your i2c pullups 4k7 or do you use very low values ?

2. I am still very sceptical about cpu processing activity causing die warming.

3. I have no doubt that resistive losses due to currents in i/o pins will definitely cause die warming.

4. I do not have this chip, so I cannot experiment myself. However a simple test would be:
a). busy cpu, no external connections or internal pullups.
b). busy cpu, only USI reporting on temperature.
c). busy cpu, very busy USI on i2c bus.
d). trivial cpu, RJMP here. i.e no arithmetic

I would assume that you would not get any significant temperature rise. However you have probably got several other loads on your i/o pins ... these could make a difference.

You are always going to get "noise" on your least significant bits. The normal approach is to use a running average. The slow down of response is ging to be trivial compared to the heat transfer time.

David.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

DocJC wrote:
Are you building one or many? And, therefore, are you CALIBRATING one, or many?
It's set up to use a per-chip offset retrieved from EEPROM, and the chip in the devel system is of course calibrated ... against a tmp75, which is an lm75 clone with 12-bit precision (and none of these observed stability problems).

DocJC wrote:
The ATTiny data sheet, (Section 16.12, not listed in the pdf index...), notes that the Tiny's Temp Sensor must be calibrated.
It's calibrated. The docs also say the sensitivity is about one LSB per degree C, while I'm observing two or more LSBs variability. This means that offsetting can't explain the variability.

DocJC wrote:
Obviously it gives a Temp reading, but if you need better accuracy, or desire a calibrationless system, there are better alternatives.
True, but the board design is done. That's something to remember for future designs. My real concern here is to know the limits of what can be done with just this ATtiny (and various resistors).