TPS659037: Question regarding die temperature conversion and "known issues" solutions

Karl Wallinger said:

Hello Lukasz,

1. For ADC temp reading, you can use the below equation:
Voltage = 2.64mV*TEMP + 0.753V

This means the full equation from ADC code to temperature is:

( ( ADC_Read_Data / 2^12) * 1.25 ) – 0.753V
TEMP = --------------------------------------------------------
2.64mV

Temperature conversion:
-----------------------
>>> ((0xca0 / 4096.0) * 1.25 - 0.753) / 0.00264
88.38186553030303
>>> ((0xcc8 / 4096.0) * 1.25 - 0.753) / 0.00264
93.00574100378788

So the values seems correct.

2.1. There is no explicit way to read if there was a cold or warm reset. But you could flip an unused bit to check if it was reset or not. For example, at power-up set POWER_CTRL.ENABLE1_MASK = 0. If there is a warm reset, it will remain at 0. If there is a cold reset, it will get reset to 1.

When I use "reset" command from u-boot and "reboot" from Linux - I do have this bit set to 1, so with "normal" operation it is not possible on my HW to force "warm" reset.

Another option is to just do the dummy read after every reset, whether it's cold or warm. It will mean you have some extra reads, but it shouldn't have any other effects.

This seems the best option - I will perform a dummy read after each reboot.

2.2 The false read is random, based on the device's internal state when the warm reset happens. There is no way to force it to happen. But it should happen about 50% of the time, so I expect if you issue 10 warm resets, you will see the false read at least a couple times.

2.3 Yes, if the GPADC gets in this state, then any GPADC read will return all 0s. Then all future GPADC reads will be correct until the next warm reset. So it does not matter which channel you read.

Ok, So I will read the on-die temperature for this purpose

Thanks for explanation :-)

Best regards,

Łukasz

Hi Karl,

If I may - I'm trying to reproduce the second "workaround for known issues" on TPS65903x - namely the autoconversion stuck scenario:

Enable Automatic conversion
=====================================
GPADC_AUTO_SELECT - channel 0 - conv1
i2c dev 0;i2c mw 0x59 0xC8 0x00

GPADC_THRES_CONV1_LSB
i2c mw 0x59 0xD2 0xFF
GPADC_THRES_CONV1_MSB
i2c mw 0x59 0xD3 0x00

GPADC_AUTO_CTRL (interval 1/32s + enable AUTO_CONV1_EN) - 0x20:
i2c mw 0x59 0xC3 0x20

ONE LINE [1]:
i2c dev 0;i2c mw 0x59 0xC8 0x00;i2c mw 0x59 0xD2 0xFF;i2c mw 0x59 0xD3 0x00;i2c mw 0x59 0xC3 0x20

READ results/status [2]:
GPADC_AUTO_CONV1_LSB + GPADC_AUTO_CONV1_MSB and test GPADC_STUCK.STUCK
i2c dev 0;i2c md 0x59 0xC7 1; i2c md 0x59 0xCB 2

DISABLE auto conversion [3]:
i2c md 0x59 0xC3 1; i2c mw 0x59 0xC3 0x00; i2c md 0x59 0xC3 1

In u-boot I issue [1].
then I reset the board with "reset" command (no power cycle), and in boot code check for "stuck" bit at GPADC_STUCK Register (Address = 2C7h) to be set.

"Unfortunately" it always works :-).

Even explicitly disabling auto conversion (with [3]) and executing [2] do not show "stuck" state.

Best regards,
Łukasz

Hi Lukasz,

Regarding the "locked GPADC" issue, this only happens when there is a reset or disable during the actual conversion. The conversion itself only takes ~100us, and the fastest auto conversion time is 1/32s = ~32ms. So the probability of any reset occurring during the conversion is about 100us/32ms = 0.3%, which means this does not happen often.

My procedure to replicate this is to start the automatic conversion, wait for 30ms, then issue a reset. If I loop that 300 times, I am able to consistently see the GPADC become locked. I think the 30ms wait time could be any number, you just need some variation so that one of the resets overlaps with the conversion over many loops.

Regards,
Karl

Hi Karl,

I took a bit different approach:

cnt = 10000;
	while (--cnt) {
		tps65903x_errata_start_auto();
                udelay(10);
		tps65903x_errata_stop_auto();
		ret = tps65903x_errata_locked_GPADC();
		if (ret)
			error("tps65903x errata - locked GPADC failed!");

	}

And the start/stop code itself:

int tps65903x_errata_start_auto(void)
{
	palmas_i2c_write_u8(TPS65903X_CHIP_P2, 0xC8, 0x00);
	palmas_i2c_write_u8(TPS65903X_CHIP_P2, 0xD2, 0xFF);
	palmas_i2c_write_u8(TPS65903X_CHIP_P2, 0xD3, 0x00);
	palmas_i2c_write_u8(TPS65903X_CHIP_P2, 0xC3, 0x20);

	return 0;
}

int tps65903x_errata_stop_auto(void)
{
	palmas_i2c_write_u8(TPS65903X_CHIP_P2, 0xC3, 0x00);

	return 0;
}

However, no luck until now......

p.s. With the dummy read, it happens that from time to time after reboot I'm able to observe SW conversion result as 0x0000. Afterwards I'm able to read proper on-die temperature from PMIC.

Best regards,
Łukasz

Hi Karl,

I've modified this code to start automatic conversion, wait for 30 ms and then reboot.
(It is exactly the same as you proposed :-) ).

Now, after some time I'm able to see GPADC_STUCK.STUCK bi t set.
After performing the "fix procedure", the SW triggered temperature conversion works properly.

To sum up:
-----------------

With above guidelines I can reproduce both GPADC "known issues" and test proposed solution code.

Thanks for support,

Łukasz

Glad to hear it's working now! Let me know if you have any other questions.

Regards,
Karl