1-wire protocol with UART and TMP1827 - Page 1
Forum section: electronics / general

author: TinkeringSteve
author_rank: Frequent Contributor
timestamp: September 10, 2025, 06:17:55 pm
content: I'm trying to get my STM32 with a USART to communicate with a TMP1827 used as temperature sensor.Like in the datasheet about using UART, I have a TX (open-drain & external pull-up) and RX pin together, going to the chip, which is the only one on the "bus".With the datasheet byte patterns to send the reset pulse and read the presence pulse, it did not work (writing 00 and getting 00 back -> no change).I found this article:https://deepbluembedded.com/stm32-1-wire-one-wire-protocol-ds18b20-code-example/While the article has a questionable setup for the reset phase (no RX on TX and really reading at the same time as transmitting, thus reading a changed value),it uses different byte values to send, and those do work: The device seems to respond: I send F0 and get C0.For the reset phase, the baud rate was configured to 9600, as described in the article, to get the timing, and later back to 115200, all confirmed on the oscilloscope - as are the general time intervals of the edges for different frames of this protocol, vs. the datasheet (except the byte values).But so far I was unable to read temperature values. Whether I use the byte values, now for 1s and 0s, from the datasheet or the ones from the article.I have been doing this:1. write reset / read presence pulse, as described2. write CC # skip addr3. write 44 # convert temperature4. wait tdelay + tconv5. write reset / read presence6. write CC # skip addr7. write BE # cmd "read scratchpad-1"8. read low byte9. read high byteWhere "read" actually, for every bit, sends a FF first, then reads a byte, as per datasheet.What I am seeing on the oscilloscope is that all is expected (with RS232 decoding on) until I am to read the low +hi bytes. Instead of totally 16 bits, I am only getting 2 bits on 1-wire level i.e. 2 bytes on UART level, and then the line stays HIGH and doesn't do anything anymore.The TMP1827 is "parasitic powered" i.e. through the 1k pull-up resistor (between 800R and 2k2 says the datasheet).The datasheet also mentions a recovery time, which seems to be covered already by the stopbit (logical 0, HIGH with low-active logic), as I see it, but I even tried to add a delay after it to give it more time - to no avail.Why might the device start to send and then "give up" after 2 bits?P.S: the scope screenshot only shows the last part of the whole above sequence, as zooming out further would make the RS232 decoded hex vanish. I can post the first part later.

author: voltsandjolts
author_rank: Unknown
timestamp: September 10, 2025, 06:25:42 pm
content: Try using a logic analyser with 1-wire decoding, it might show where you are going wrong.One of those cheapo analysers and sigrok pulseview would do.

author: d-el
author_rank: Regular Contributor
timestamp: September 10, 2025, 07:46:33 pm
content: May be help you:https://github.com/d-el/uwb1wire

author: ahsrabrifat
author_rank: Regular Contributor
timestamp: September 11, 2025, 12:15:18 pm
content: TMP1827 in parasitic-power mode needs a strong/high-side drive during conversions/read bursts. If the bus is only “weakly” pulled up (or the MCU’s TX start bit repeatedly drags the line low), the device’s internal charge can collapse mid-read — you will see a couple of bits, then the line goes idle/high.https://www.ti.com/lit/ds/symlink/tmp1827.pdfScope the VDD (parasite node) at the sensor while doing a convert/read cycle. If VDD droops when conversion starts or during reads, it’s a power collapse. If VDD remains stable, suspect the MCU driving the bus. If your one is a customized board, you have to check if there is a manufacturer error.https://www.theengineeringprojects.com/2024/07/common-issues-faced-in-pcb-designing.html

author: TinkeringSteve
author_rank: Frequent Contributor
timestamp: September 25, 2025, 07:32:55 pm
content: "Scope the VDD" - does not work. From the datasheet for VDD: "In bus powered mode, must be connected to ground".The idea with the logic analyzer, yeah it was on my list, too, remembering I once bought one of those Saleae clones and played with Sigrok.The recorded stuff from sending 2 high level frames (1. prepare data conversion, 2. reading scratchpad) gives me the first one with the initial reset condition detected as "ERROR" by the protocol analyzer, the 2nd frame looks ok except that there are only 2 bits reply from the device.Since the reset stuff looks exactly the same in the 1. frame vs. 2nd, I guess that's a bug in the protocol analyzer... which does not get a bit of a high signal at first (which is the only difference visible to me between frame 1 and 2), which is a necessity by the capturing trigger working on the down slope, so the recording starts with a low signal, not a high one going down, even though that's what happened (by necessity, or the falling edge trigger would not have triggered when I had the MCU start the transmission)

author: cv007
author_rank: Frequent Contributor
timestamp: September 26, 2025, 08:23:14 am
content: QuoteThe uart is in control of the bus. If the uart was supposed to put out 16 bytes to read 16 bits, and you only see 2 bytes from the uart, then the uart is the one that is 'giving up', not the 1wire device. If using code from link you provided, simply do a DS18B20_ReadByte and you should see 8 uart bytes (don't really care what the 1wire device is doing, and could also be disconnected). Either that is what you get, or not. If not, then call DS18B20_ReadBit 8 times and see what you get.edit- or you simply used your read bit function when you should have used the read byte function.

author: mikerj
author_rank: Super Contributor
timestamp: September 28, 2025, 04:25:20 pm
content: Are you holding the data line high for a minimum of 2ms (Tinit) before starting any comms?