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.

TMP125: one-shot mode?

Other Parts Discussed in Thread: TMP125, CC2540

Hello,

I've some trouble understanding the one-shot mode of TMP125. Sorry if my question is stupid but first time doing this...

So as I understand it from the manual:

1) To enter shutdown mode:

nCS = 0
MOSI = 1
2x SpiRead()
nCS = 1

2) To exit shut down mode - set MOSI = 0 and perform 16bit read

3) One-shot:

The manual says the following:

The one-shot command can be used to force a single conversion. When the command is issued, the part will perform a single conversion and then go into  hutdown mode. After the conversion is complete, the conversion result should be read with the power-down bit high (see Figure 3) if you do not want to start a  new conversion.

So... I don't understand the above... After MOSI is HIGH on the third SCK rising edge (and it's in shutdown) I've to force it LOW on the next SCK rising edge or what?

I want to do the following:

tmp125 is in shutdown -> sleep 5s -> one-shot read -> sleep 5s -> one-shot read

Example will be appreciated! 

Thanks :)

  • Hi Tod,

    I need to review this, and get back to you.

    Aaron

  • Any progress? This was posted 2 weeks ago.
  • Hi Bo,

    The sequence should look like this:
    nCS = 0
    Transmit = 0x3000 (to indicate both shutdown and oneshot)
    nCS = 1
    wait >60ms
    nCS = 0
    Transmit = 0x2000 (to maintain shutdown but not initiate another oneshot)
    nCS = 1
    retrieve the 16 bits from the last transaction and convert them to temperature
    wait 5s (or 5s-60ms if you prefer)
    repeat

    TMP125 has a 60ms conversion time. This means that once you initiate a one-shot, the result will not be ready to be read until 60ms has passed. This is the reason for the two transactions in my example. This is also the reason why I did not bother to retrieve the response from the first transaction. This would contain old temperature data that we're not interested in.

    Your microcontroller should have an SPI master built in that transmits when you give it data. At the same time that it is transmitting, it should be receiving data from SO in a buffer. You'll need to retrieve the contents of this buffer after the transaction. Note that this device requires 16 bit transactions. Your microcontroller might view this as two 8 bit transactions. You may have to specify an array 0x30 and 0x00 in order to transmit 16 bits. In this case, nCS should be held low throughout these "two 8 bit transactions."

    Ren
  • Thanks a lot for the detailed answer, Ren
    Just one (stupid) question: I should send MSB first, right? If I'm doing two 8bit transactions I should send first 0x30 (resp 0x20) and then 0x00.
  • Yes, MSB first as shown in datasheet illustrations.

    It's possible that the endianness of your microcontroller would require you to swap the array elements, but I'm not aware of a microcontroller with this issue. en.wikipedia.org/.../Endianness

    Ren
  • Hi Ren,

    I tried what you suggested but after the first read the temperature data is not updated.

    Here is a code snippet:

    #define SCK             P1_3
    #define MISO            P1_4
    #define MOSI            P1_5
    #define CS              P1_2
    
    #define CS_DISABLED     1
    #define CS_ENABLED      0
    
    void spiReadByte(uint8 *read, uint8 write);
    
    void tmp125_initAndShutdown(void)
    {
        uint8 pVal = 0;
    
        // *** Setup USART 0 SPI at alternate location 2 ***
    
        // USART 0 at alternate location 2
        PERCFG |= 0x01;
        // Peripheral function on SCK, MISO and MOSI (P1_3-5)
        P1SEL |= 0x38;
        // Configure CS (P1_2)
        P1DIR |= 0x04;
    
        CS  = CS_DISABLED;
    
        // *** Setup the SPI interface ***
        // SPI master mode
        U0CSR = 0x00;
        // Negative clock polarity, Phase: data out on CPOL -> CPOL-inv
        //                                 data in on CPOL-inv -> CPOL
        // MSB first
        U0GCR = 0x20;
        // SCK frequency = 480.5kHz (max 500kHz)
        U0GCR |= 0x0D;
        U0BAUD = 0xEC;
    
        // *** one-shot + shutdown ***
        CS  = CS_ENABLED;
        spiReadByte(&pVal, 0x30);
        spiReadByte(&pVal, 0x00);
        CS  = CS_DISABLED;
    }
    
    void tmp125_oneShotRead(uint16 *temperature)
    {
        uint8 pVal = 0;
    
        CS = CS_ENABLED;
        spiReadByte(&pVal, 0x20);
        *temperature = pVal;
        spiReadByte(&pVal, 0x00);
        *temperature = (*temperature << 8) | pVal;
        // temperature value is in D14-D5 
        *temperature >>= 5;
        CS = CS_DISABLED;
    }
    
    void spiReadByte(uint8 *read, uint8 write)
    {
            U0CSR &= ~0x02;             // Clear TX_BYTE
            U0DBUF = write;
            while (!(U0CSR & 0x02));    // Wait for TX_BYTE to be set
            *read = U0DBUF;
    }

    I'm using CC2540.

    Do you see anything wrong?

    Looking (again) at the datasheet maybe it should be:

    1) 0x2000 -> to enter shutdown mode

    2) 0x3000 -> trigger one-shot

    BR,

    Boris

  • I don't see the 60ms and 5s waits that we discussed in your code. If you do not wait 60ms after sending the one-shot command, you will not see a change in the temperature value.

    Ren
  • Yes, they're in another source - I'm waiting 3sec.

  • Can you verify that the only issue you are seeing is that the temperature does not change?
    Does the temperature that you receive make sense?
    Can you heat/cool the device and verify an appropriate change to the result? You may need to power cycle your system to see any changes to the temperature result since you are trying (perhaps unsuccessfully) to put the device in shutdown.
    Can you verify the data in the waveforms does not change? Can you verify the waveforms match your result?
    Can you verify the >60ms delay in the waveform?

    Ren
  • What I can verify is that if I send 0x2000 initially and then 0x3000 every 3sec I can get relevant temperature results and through the sensor flows ~0uA current (measured at the GND wire). And I see peaks in the sensor current every 3sec.

    If I do 0x3000->0x2000->0x2000->0x2000... the temperature value is read correctly only on startup (tested by heating the sensor & board restart).
  • transmitting 0x2000 puts the part in power down mode so it never does another conversion so you should just get the same temperature reading over and over as described in figure 3 of the datasheet. What you need to do

    is transmit 0x3000

    then wait 120ms

    then read the conversion result with 0x2000 the part will now be placed in power down

    when you are ready to start another conversion you need to transmit 0x3000 then wait etc...

    If you want the part to just continuously convert just transmit 0x0000.  

    Take care,