I’m working with some sort of proprietary MCU to MCU serial protocol form 2008. On the master side it’s a boiler and the slate side is a small display and keypad that shows the boiler temp which is what I’m trying to capture for my home automation system. the key pad can change parameters of the boiler so the protocol can send data both ways. There is only clock, data, and ground between the 2 MCUs. I’ve researched every serial protocol I could find and none fit the description (It is absolutely not i2c or SPI).

The protocol when the master is sending data seems simple enough…..every 100ms 6 bytes are transmitted separated by 200us between bytes. I think I’ve figured out which of the 6 bytes is the data I’m looking for and I can ignore the rest. But the thing that’s driving Me crazy is some data bits appear to come early and out of sync with the clock.

Ive spent hours looking at this and it seems that 3us before the clock goes high the data line goes high or low. Normally when the clock is low the data line is floating (high impedence) from the tranmistting (master) MCU and gets pulled down on the PCB board of the receiving MCU (slave) And shows low. But at 3us prior to clock going high the master MCU pulls the data line low or high For some reason. If the data bit is low then I get a pulse ahead of the clock pulse. If the data bit is high in this scenario the width of my data pulse is 3us wider. If the master pulls data low before a clock pulse it looks normal because the data line is normally Pulled low anyway by the slave.

kinda hard to explain but simply put - what would be the purpose of a data line going high or low during Transmission of bits within a byte frame when the clock is low? With ic2 and SPI i believe usign the data line when clock is low signals start and stop. But in my case this seems to happen before every bit transmitted. Also I can’t determine any kind of pattern When the data line goes low or high ahead of the clock. Sometimes it goes high on the 3 bit of the 4th byte and other times it’s the 1st bit of the 3rd byte, etc.

am I chasing a phantom problem Or can anyone explain why a designer would use the state of the data line ahead of a clock pulse for 2 wire serial protocol? Here is an example of when data line goes high ahead of a zero data bit…

 

Welcome to AAC.

Could that be a parity bit, some sort of ECC or FEC to ensure the integrity of the bitstream? Given that it doesn’t seem to be once per byte, it would have to be calculated against the whole message, or some more-than-8–bit portion.

It might help to record several transmissions and the positions of the errant clocks to see if there is a larger pattern.

 

I’ve looked at many 6 byte messages and don’t seem to see any kind of pattern.

At first I thought it was just a high pulse but i looked at the signal with the cable disconnected and therefore the slave MCU isnt pulling the data line down with a 10k resistor to ground. From the Scope it seems the master MCU sends a low 3us ahead of the clock most of the time. At first I though this was just the master MCU making the data go low before it sends a bit but that seems to be happening 1us before the clock pulse. So if my analysis is correct the master sends a high or a low ahead of each bit for some reason and each bit starts with a 1us low before sending the bit.

 

With I2C, SDA goes from HIGH to LOW before SCL goes HIGH to LOW.
Maybe your signals are I2C inverted?

 

Yea i've considered that too but why would it be prior to each bit? I believe IC2 when SDA goes high to low ahead of a clock it means a start of a full message (or frame?). In my case it seems like its before each bit. Here is an example where the data line is floating - high impedance at master and no connection to slave. The data line is still ramping back up to 5V high impedance state from the last low so its not yet fully at 5V. Here you see 3us before the clock the master sends a low. Then 1 us before the clock it goes high to set the data bit. In this case that data bit is 1 obviously.

Perhaps this is just the master MCU setting the pin to 0 before it sets it to 1 so it creates a square wave. But looking at the signal 100 different ways it seems the master MCU is usually at high impedance state until 3us before a clock pulse, then 1 us before the clock pulse it sets the line high or low, and at the end of the clock pulse (roughly 2us) it goes back to high impedance. Second picture is when the data line is floating close to 5V and i believe at 3us it goes high before 1us it goes low to send a 0 bit. Third picture is just a zoomed out view of the signal when just the master MCU is connected and the transmission cable is disconnected (floating).

Yellow (Ch1) is clock / Blue (Ch2) is data - in these 2 pictures - the third picture ch1 yellow is clock







Here is the data signal - sorry its yellow which is opposite of what i have above...

 

If the data goes LOW-to-HIGH before every bit then the data is self-clocking.
Why would you need a CLOCK signal?

 

The DATA signal appears as if it is missing a pull-up resistor. Try putting a 10kΩ pull-up resistor.

 

Synchronous data is always transmitted that way. You have to ensure the data line is stable before the clock transition. Think what would happen if they change at the same time. The cluck edge might latch the data before it was set up.

 

Indeed it is a mystery!

Based on what i am seeing however its seems it usually the line gets pulled low ahead of the clock signal. Only every once in while does the line go high ahead of the clock signal. I can't find a pattern in it which is why i'm wondering what would be the purpose of this which might help me decode the full protocol. Sorry its hard to see but here are 3 samples of the data being sent in 3 different 6 byte messages. I excluded byte 1 and 6 in this picture but you get the point. Where i've highlighted in yellow is where the data line goes high ahead of the clock. Sometimes this is ahead of a 1 and sometimes a 0.

This hardware setup is from around 2008 and the MCU data sheets show very basic serial processing supported. UART and 8-bit synchronous serial - no I2C, SPI, CAM, etc. So i imagine the designer at the time had to create their own 2 line serial protocol...

 

The DATA signal appears as if it is missing a pull-up resistor. Try putting a 10kΩ pull-up resistor.

That is just in the images in my subsequent posts to show that the data line is in high impedance state EXCEPT 3us before the clock pulse and during the clock pulse itself. It helps to show that the master MCU is deliberately setting the data line to HIGH or LOW ahead of the clock signal. In my original post I have the signal with the transmission line connected to the PCB that has a 10k pull down resistor....

 

Synchronous data is always transmitted that way. You have to ensure the data line is stable before the clock transition. Think what would happen if they change at the same time. The cluck edge might latch the data before it was set up.

Yes agreed and i would expect the master to set the data line ahead of the clock signal regardless of what the data bit is. I actually figured it would set it to low regardless since its going from a pulled down level (low) and then would set it to HIGH or keep it LOW depending on the data bit. However it seems that it sometimes sets it to HIGH ahead of the clock. That is what is throwing me off. Why would it be setting it to low most of the time and every once in a while setting it to high ahead of the clock? See my post above where i have 3 messages and highlight the bits that are preceded by a HIGH.

 

What circuits are driving the two signals?
From the oscilloscope screen in post #1, data and clock signals are 2μs wide with rise and fall times of 0.4μs. That seems long to me.

 

I see nothing wrong with the traces. The state of the data line when the clock is low is generally considered undefined. That means it can be high, low or not driven without changing the meaning of the message. Perhaps the software was unnecessarily setting it high before being set low in those cases, and it stayed that way since there was no reason to fix it.

I don’t think there is a missing pullup or pulldown, since it actively drives the line when it is actually needed.

 

Why are the rise and fall times 400ns? There must be a lot of capacitance load on the line.
Is the oscilloscope band-limited?

 

Why are the rise and fall times 400ns? There must be a lot of capacitance load on the line.
Is the oscilloscope band-limited?

Here is the circuit of the receiving side (slave) which is pretty basic. I'm working to identify the exact circuit on the transmitting side (master) but that is a much more complex PCB and i'd prefer not to disconnect that board from the boiler. From what I can tell on the master side its another 8-bit microcontroller. Both MCUs are Fujitsu that are discontinued and seem to be pretty basic MCU functionality (i'm no expert). On the slave circuit the serial out pin is controlling the pull up or down state of the data line. For most of the data transmission, and in between, this pulls the data line to ground. However during byte 1 and 6 it does go high after some bits in a pattern that happens consistently on each message. That is another mystery that I've been ignoring and haven't included in this so as not to add more confusion.

The transmission line is a 1 meter IDC ribbon cable with 10 wires but only 5 of them are used - data, clock, ground, 12V (to power slave), and a reset signal. I bought a scope for this project so i'm sorta new to scopes so this could all be measurement errors on my part. I have a Rigol DHO804 which is 12bit, 70 MHz, 1.26 GSa/s with memory depth 25 Mpts and Waveform Capture Rate of 1,000,000 wfms/s. I am using their default probe and i have it set at 10x. I'm using IC test "hooks" (https://www.amazon.com/gp/product/B083PRVPCR/ref=ppx_yo_dt_b_search_asin_title?ie=UTF8&psc=1) connected to the slave MCU pins to read.

 

I see nothing wrong with the traces. The state of the data line when the clock is low is generally considered undefined. That means it can be high, low or not driven without changing the meaning of the message. Perhaps the software was unnecessarily setting it high before being set low in those cases, and it stayed that way since there was no reason to fix it.

I don’t think there is a missing pullup or pulldown, since it actively drives the line when it is actually needed.

So basically this is an artifact from the design or build and should just be ignored. I'm still trying to decode the protocol so I can ignore these and see if i can make sense of it. Does seem a bit random that there are bits where it intentionally goes high ahead of a high or low bit. But i also am suspicious i'm chasing a phantom issue here....

 

What is the model number of the Rigol oscilloscope?
Check to see if there is a noise filter setting or a bandwidth limit setting.
Let us see the data and clock signals with the oscilloscope set to 100μs/DIV.

 

So basically this is an artifact from the design or build and should just be ignored. I'm still trying to decode the protocol so I can ignore these and see if i can make sense of it. Does seem a bit random that there are bits where it intentionally goes high ahead of a high or low bit. But i also am suspicious i'm chasing a phantom issue here....

I am not saying that absolutely, the off clock data might be meaningful, but I would proceed in decoding it as if it was not meaningful.

 

Here is the circuit of the receiving side (slave) which is pretty basic. I'm working to identify the exact circuit on the transmitting side (master) but that is a much more complex PCB and i'd prefer not to disconnect that board from the boiler. From what I can tell on the master side its another 8-bit microcontroller. Both MCUs are Fujitsu that are discontinued and seem to be pretty basic MCU functionality (i'm no expert). On the slave circuit the serial out pin is controlling the pull up or down state of the data line. For most of the data transmission, and in between, this pulls the data line to ground. However during byte 1 and 6 it does go high after some bits in a pattern that happens consistently on each message. That is another mystery that I've been ignoring and haven't included in this so as not to add more confusion.

The transmission line is a 1 meter IDC ribbon cable with 10 wires but only 5 of them are used - data, clock, ground, 12V (to power slave), and a reset signal. I bought a scope for this project so i'm sorta new to scopes so this could all be measurement errors on my part. I have a Rigol DHO804 which is 12bit, 70 MHz, 1.26 GSa/s with memory depth 25 Mpts and Waveform Capture Rate of 1,000,000 wfms/s. I am using their default probe and i have it set at 10x. I'm using IC test "hooks" (https://www.amazon.com/gp/product/B083PRVPCR/ref=ppx_yo_dt_b_search_asin_title?ie=UTF8&psc=1) connected to the slave MCU pins to read.

View attachment 319128

Looks much like a traditional SPI three to four wire resistor hack on the slave side.
Usually on the master side you will see something like this for SPI four wire to three.

 

Looks much like a traditional SPI three to four wire resistor hack on the slave side.
Usually on the master side you will see something like this for SPI four wire to three.
View attachment 319136

I've been looking closely at SPI but haven't seen a 2 wire SPI reference anywhere. In my case its only a master and a single slave so the chip select really isn't needed. So i'm left with a clock and a single data line between the master and slave. I know my implementation sends data both ways. What does the SPI protocol look like for sending data both ways on a single data line?