• State Resolved
  • Locked Locked
  • Replies 7 replies
  • Answers 4 answers
  • Subscribers 31 subscribers
  • Views 1463 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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.

tmp104 not responding

John Dowd81
Prodigy 40 points
Other Parts Discussed in Thread: TMP104

I'm using the tmp104 device on an evaluation kit that is our manufacture. It is connected to the USART of a STM32L4 processor (ARM Cortex-m4) configured for autobaud @ 57600,8,N,1 and I have a console application on the ARM with which I can read/write to the USART interface.

The voltage levels have been checked and can be seen in the following image. That image was taken with a scope that is tapping into the Host's RX side of the chain. There is only 1 tmp104 in this chain. The data being written to the chain is "0x55 0x90". These 2 bytes of data are being written after the application wrote "0x55 0x8c" to the chain.

 

I've extended the capture buffer on the scope out to make sure there is no further activity from the tmp104 on the line. What I don't see is the address value from the device. I'm a bit unclear if I should see the value coming back to the host as "0x55 0x91" or a 3rd value so that the read back would be "0x55 0x90 0x01" but none the less, I see nothing. So, When I write either the calibration string or the Address Initialize string to the device, I only get back what I wrote, never the device "count". 

The electrical levels, timing and data values are quite clear in the scope trace.

I'm hoping someone can help me try and figure out what is being done wrong or do we have a dead sensor.

Cheers!!

  • 0
    TI__Mastermind 41785 points
    The sensor is supposed to echo what it receives and append any read back afterwards. If you are seeing the echo, then the device is not dead. I'll need some more time to look into your other questions.

    Ren
  • 0
    TI__Mastermind 41785 points
    For Address Init, you should write 0x55 0x8C 0x90. The first device in the chain should echo the same command with an incremented address to the next device in the chain. This would look like 0x55 0x8C 0x91 returned to the master since you don't have additional devices.

    Ren
  • 0 in reply to Ren Schackmann
    Prodigy 40 points

    Ren,

    Thanks for looking into this.

    I have tried to send the string 0x55 0x8c 0x90 and checked on the reply. What I get is:

    0x55 0x8c

    No address/count byte. I will keep digging into my s/w to make sure that the 3rd byte is sent and that I'm not ignoring the reply. Have you seen this data truncation before for this device?

    Cheers!!

  • 0 in reply to John Dowd81
    TI__Mastermind 41785 points

    Here's an oscilloscope picture of Address Init performed at 57600. The yellow line is Master Tx/Slave1 Rx. The blue line is Slave1 Tx/Slave2 Rx. The purple line is Slave 2 Tx, and so on.

    If you are certain you are sending 0x55 0x8C 0x90, I would double check your connections.

    Ren

  • 0 in reply to Ren Schackmann
    Prodigy 40 points
    I've managed to capture the correct response on our oscilloscope now so I know that I have a s/w issue. What is confusing is that the same s/w works for many other different UART connections. I have it configured as a auto-baud connection with 1 Stop bit, 1 Start Bit and the nominal baud rate of 57,600, not Parity no h/w flow control.

    I receive the first two bytes 0x55 0x8c but the 3rd byte is never seen. When I examine the USART I can see that I am getting an Overrun Error which implies that the processor is unable to get to servicing this USART in time. The processor is a STM32L4 ARM Cortex-m4 running at 76MHz. I have changed the USART's interrupt priority so that it is the highest and I'm still getting the same problem.

    Is there some "secret sauce" to be used with this particular processor and it's USART?
    Can I have your Oscilloscope? (just put it in a box and ship it!!)

    Cheers!!
  • 0 in reply to John Dowd81
    TI__Mastermind 41785 points
    Are you sending the third byte? I know you said before that you were. In more detail:
    The yellow line is what was transmitted by my UART. The first device in the chain is allowing the first two bytes to pass through. At the end of the 2nd byte, it knows that it is going to perform address init, so it stops letting the master's transmission pass through. When the the third byte finishes, the first device is able to store this byte as its address, and then start a separate communication to inform the second device of its address. this is the 0x91 on the blue line.

    In the mean time, the second device has been doing the same thing as the first device. It also allowed the master's first two bytes to pass through it until it recognized the Address init command in byte 2. Even though there is a delay in receiving the third byte, the second device is not bothered. It goes on configuring itself, and informing the third device of its address (0x92 as seen on the purple line.)

    This is asynchronous UART communication. Each byte is one 8 bit packet with a start and stop. This is the most basic of UART-style communication, and requires no special features or settings. Since it is asynchronous, the transmit and receive are typically implemented as separate buffers. Your micro should be configured to push every packet it receives into a receive buffer regardless of when it was received. You will have to poll (or configure an interrupt) the receive buffer until all of the expected packets arrive. Your micro may not expect such long delays between receiving packets, and activate a time out. Finally, I don't have experience with this micro, and I've no idea what your 'auto-baud' setting does. It may be expecting certain patterns to come from the slave device in order to detect its baud rate. Our device would not support this functionality.

    My oscilloscope cost over $10k but is discontinued now. It is a Tek DPO4034 with DPO4EMBD and DPO4COMP software modules for protocol decoding. I'm quite fond of the software modules myself. You can get a DPO2k or DPO3k with the same interface and software modules for less than $5k, but the screen is physically smaller. Such a bargain, I know.

    Ren
  • 0 in reply to Ren Schackmann
    Prodigy 40 points
    Thanks again Ren. I'm going to have to dig around in the s/w some more it would seem.

    Cheers!!