This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

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

Part Number: TPS659037

Dear All,

I do have several questions regarding TPS659037 PMIC:

1. Is there any information about converting on-die temperature (channel 0xC) to Celsjus degree?

I'm able to start single conversion:

i2c dev 0;i2c mw 0x59 0xCD 0x9C 1;i2c md 0x59 0xCD 3
00cd: 8c de 0c ...

but those values are meaningless..... since there is no map for termistor voltage (up to 1.25 V) to degrees Celsjus

I can observe the value drop when I cool down the device with external fan, so I assume that it works.

2. I'm implementing fix for "Known issues" for GPADC [1] (point 3 in [1]).

2.1 Is there any way to read from TPS659037 if we boot up from cold or warm reset?

2.2 How can I trigger (with already build device) the behaviour to test if the SW works? 

(for now I've just implemented pseudo-code to be run at system boot up).

2.3 Can I test solution for "Known Issues" - dummy conversion - with e.g. on-die temperature reading?

Documents:

[1] SLIA087 – May 2015 - Guide to Using the GPADC in TPS65903x and TPS6591x Devices

[2] SLIU015 – October 2015 - TPS659037 Register Map

[3] SLIS165C – DECEMBER 2014 – REVISED NOVEMBER 2015 - Documentation

Best regards,

Łukasz

  • 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

    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.
    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.

    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.

    Regards,
    Karl

  • 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