MSO4x 1-Wire Decoder Framing

Hello Tek support,
I'm attempting to diagnose a 1-Wire bus, and I'm finding that the MSO4x's 1-Wire decoder is flagging framing errors or end-of-packet events if there is any delay (greater than ~100 µs) between one byte and the next. A bit's time slot has no maximum time, as long as it is at least 85 µs (or 16 µs with overdrive), so there is no requirement that bytes within a packet sent via 1-Wire be sent immediately after each other, as the decoder seems to be mandating.

This is especially problematic for 1-Wire operations that require a delay between sending the command and reading the result; the decoder is never able to return the result part because it times out during the delay and idles until it sees the next reset.

Is there a way to suppress "framing errors" so the decoder will continue decoding across delays within a packet?
I'm using an MSO46 running firmware Version 2.4.4.1152.

Hi Donald,

Would you be able to share a session or waveform file of this in action so I can replicate it and get it passed on to our engineering team to fix it?

Hi Afonso,

I have a waveform file I can share, though it exceeds the upload size for this forum even when compressed (approx 70 MB). Do you have an alternative means for me to provide the file? I recaptured the waveform at a reduced sample rate and saved it as a session file, see my post below as I don't think I can add an attachment to this post anymore.

In the waveform, you will see a reset at the start, then a long string of operations and waits that ultimately results in a successful read from an EEPROM page (32 bytes containing all zeroes). Because none of the operations require a reset in between them, the decoder only detects the reset and presence pulse, identifies one framing error, and then decodes nothing after the framing error.

In the waveform capture, I am using an Analog Devices (formerly Maxim) eval kit and software to perform the EEPROM read for a product that has been released ~7 years now; while eval kits may certainly have non-optimal behavior, I would expect Maxim knows how to communicate using their own protocol and any bugs with this software should be minimal or represent corner cases at this stage in the product lifecycle.

It looks like I cannot add an attachment to my prior post, so here is the session file with the waveform re-captured at a lower sample rate. It shows the same behavior as described above.

Here is the annotated output from the EV Kit software, showing what Maxim believes it is sending and receiving during the transaction. Note the "<STD> RP" at the start, that is the only Reset-Presence cycle performed in the entire transaction (at STanDard speed):


//Read Memory, Page 4
*************************************************************************************
//1-Wire
// Reset- OD Match ROM 
<STD> RP
 69 4C 6E 27 96 00 00 00 53 
//1-Wire Packet
69 04 FF FF  AA 
//Wait for computation
<Delay 50ms> 

[AA] [0] [0] [0] [0] [0] [0] [0] [0] [0] [0] [0] [0] [0] [0] [0] [0] [0] [0] [0] [0] [0] [0] [0] [0] [0] [0] [0] [0] [0] [0] [0] [0] [C7] [C7] 
//Command Result
<SUCCESS>
//Page Data: 
// 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
// 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 

Hi Donald,

That's great, thank you for getting me that file!

I'm no 1-Wire expert so I'm going to submit a report on this and I'll let you know how we plan to address it once I have more information.

Hi Tek support,
Wanted to follow up and see if this is something Tek plans to address, or if there are any workarounds/settings I can tinker with to get it working?

I can, though it will take me a couple weeks; our scope is about to be sent out for calibration. I can run the test when it returns.
Notably, 1Wire is not mentioned in the release notes between the version I ran, 2.4.4.1152, and the latest, 2.6.38.

Hi Donald,

That's correct, and I am not expecting the update to fix your issue, I just want to make sure you're running the latest version just in case it has been changed (most of the changes aren't in the release notes).

Hi Afonso,

The scope came back somewhat early, I've updated its firmware, and I see no change in behavior using FW 2.6.38 (release date 2023-11-02).

Just as in the file attached before, if there is a delay between bytes sent after the reset pulse, it is declared a framing error and decoding halts until the next reset pulse. As noted before, that is not an invalid 1-Wire transaction; things like an EEPROM read require a pause between bytes, but do not require a reset pulse in-between commands.

Hi Donald,

Sorry about the delay in answering you, I've been discussing this matter with my colleagues and it has been significantly delayed by the lack of a single standard for 1-Wire.

From my reading of the DS199x datasheet, I believe you are correct that the recovery time between bits (tREC) can be arbitrarily long without causing a framing error.

I'm working with our internal resources to get this changed in a future software update.

Understood on the delay, and agreed that the lack of a single standard is unfortunate.