iButton ds1990a emulation doesn't work

[jagotu]

Describe the bug.

I've been having issues with emulating my iButton to the door lock, so I took a logic analyzer to it and got some recordings.

It seems to me (and I'm an amateur at this) like the window between resets left by the reader is just 230 microseconds and the flipper doesn't react fast enough.

This is what the emulation attempt looks like:

Between resets, there's just 230 microseconds:

I also MITM'd the actual key and it reacts with the presence signal in 35 microseconds:

I also attach saleae recordings of the failed emulation attempt and what a succesful communication looks like. The MITM communaction is cut-off before the UID transmission but the beginning of the transaction is clearly visible.

1wire_saleae.zip

I have pretty much unlimited access to the button, the readers and the logic analyzer, so I can provide more captures if necessary.

Reproduction

1. Emulate a ds1990a iButton
2. Attach Flipper to the reader, making sure there is good connectivity.
3. No reaction whatsoever from the reader.

Target

No response

Logs

No response

Anything else?

No response

[alecmatthews]

I've also noticed this with my iButton key. The flipper can capture the key just fine, but can not emulate it back to the reader correctly. I believe it's a similar issue with timing, but I don't have the correct equipment to measure it.

[skotopes]

@nminaylov can you take a look in next sprint?

[jagotu]

@nminaylov Any updates? Did you manage to reproduce? Is more information required from me?

[Steampunkery]

Hello, I am having the same issue with the same type of iButton key. I can successfully read the key and save it, but emulation does not work.

[skotopes]

@Steampunkery we just finished refactoring of ibutton application and underlying libraries. Can you test again?

[Steampunkery]

Hi, I installed the new firmware, but it still doesn't work. The key reader doesn't recognize it as a key or blink red or anything, just no response. I even tried it with breakout jumpers just to be sure.

On Mon, Mar 13, 2023, 10:22 あく @.***> wrote:

@Steampunkery https://github.com/Steampunkery we just finished refactoring of ibutton application and underlying libraries. Can you test again?

— Reply to this email directly, view it on GitHub https://github.com/flipperdevices/flipperzero-firmware/issues/1847#issuecomment-1466236519, or unsubscribe https://github.com/notifications/unsubscribe-auth/AC3IOU3C4PJ3DJ75RMAHRQLW34UQZANCNFSM6AAAAAAQ76OVEQ . You are receiving this because you were mentioned.Message ID: @.***>

[skotopes]

i think we need data from log analyzer to figure out what happens on the bus

[Steampunkery]

I think I have access to a logic analyzer. I'll see if I can get a dump from it next week.

[theoilie]

Hi, confirming I see the same issue with the latest stock firmware update - DS1990 can read and write just fine, but emulation doesn't seem to elicit any response from the reader.

[skotopes]

@theoilie We need oscillograms and/or record from logic analyzer to understand better what happens on the bus.

[jeffdlin1618]

I have the same issue but on the DS1971 Emulation, but with this reader.

the flipper zero stays on the iButton Emulating screen, which makes me believe that there is something within the reader that is blocking the emulation.

@theoilie @skotopes, is there anything I can provide to help?

[skotopes]

data from log analyzer, reader name

[jeffdlin1618]

I don't have access to a GPIO module for the log analyzer, but the ibutton reader is DS1402D-DR8+-ND

[skotopes]

@doomwastaken FYI

[doomwastaken]

Found the reader, should be able to try this within the week

[theoilie]

I don't have any oscillogram data to provide, but the reader was a Schlage deadbolt lock with anti-emulation which makes sense for why an emulator doesn't work on it. The workaround is to write to a programmable DS1990A key (ie RW1990), and then that works just fine on the Schlage reader.

[doomwastaken]

We are waiting arrival of one of the 1-wire readers mentioned here, I will try and search for Schlage 1-wire lock, however they are mostly US based, will update once I get more details

[jeffdlin1618]

Any update since receiving the reader?

[doomwastaken]

Checked with logistics, should be available for testing on monday

[davidwernhart]

Are there any updates on this issue yet?

[doomwastaken]

Currently unable to verify, until NFC refactor is merged. We've purchased DS1402D-DR8+-ND, just need to set it up. I will have time available this week, if I will try and confirm the issue locally. You can ping me for it too

[klim3000]

I have found an interesting feature - the reader does not respond to Dallas key emulation, but it does respond (gives an error signal) when Metacom or Cifral emulation is used.

[jeffdlin1618]

I have found an interesting feature - the reader does not respond to Dallas key emulation, but it does respond (gives an error signal) when Metacom or Cifral emulation is used.

Hmm any ideas on how we can get Dallas to work?

[jeffdlin1618]

Seems like there was a hardware solution here: https://forum.flipper.net/t/problem-emulating-ibuttons/4463/19

[davidwernhart]

Seems like there was a hardware solution here: https://forum.flipper.net/t/problem-emulating-ibuttons/4463/19

This is really interesting! Seems like it would actually be an easy fix in software. Let's hope this gets sorted out soon!

[skotopes]

@DrZlo13 reminder

[cr0eax]

I tried to investigate the issue of DS1990 not working.

As far as understood, flipper does not see 1->0->1 (RESET) on the line, meaning that interrupt handler registered in one_wire_slave.c newer gets called: furi_hal_gpio_add_int_callback(bus->gpio_pin, onewire_slave_exti_callback, bus); furi_hal_gpio_init(bus->gpio_pin, GpioModeInterruptRiseFall, GpioPullNo, GpioSpeedLow); Changing GpioSpeedLow to other values did not helped. Impulse might be too short, so flipper just does not see it. [I think this is confirmed by logic analyzer logs in the first post]

[as someone mentioned that using Metakom emulation gives BEEP-deny from terminal] I also looked at Metakom emulation and it is implemented in completely different way (using timers). So I rewrote the interrupt callback using timer implementation.

static void ibutton_fixed_interrupt(void* context) {
    OneWireSlave* bus = context;

    bool current_state = furi_hal_gpio_read(bus->gpio_pin);
    if (current_state == 1) {
        // read 1
        if (bus->pulse_start != 0) {
            // high -> [low -> high]
            const uint32_t pulse_length = (DWT->CYCCNT - bus->pulse_start) / furi_hal_cortex_instructions_per_microsecond();

            LOG("pulse_length %i\n", pulse_length);

            LOG("cond %i <= %i <= %i | %i\n", 
                onewire_slave_timings_overdrive.trstl_min, pulse_length, 
                onewire_slave_timings_normal.trstl_max,
                (pulse_length >= onewire_slave_timings_overdrive.trstl_min) && (pulse_length <= onewire_slave_timings_normal.trstl_max));

            if((pulse_length >= onewire_slave_timings_overdrive.trstl_min) && (pulse_length <= onewire_slave_timings_normal.trstl_max)) {
                /* Start in reset state in order to send a presence pulse immediately */
                bus->error = OneWireSlaveErrorResetInProgress;
                /* Determine reset type (chooses speed mode if supported by the emulated device) */
                bus->is_short_reset = pulse_length <= onewire_slave_timings_overdrive.trstl_max;
                /* Initial reset allows going directly into overdrive mode */
                bus->is_first_reset = true;

                const bool result = onewire_slave_bus_start(bus);

                if(result && bus->result_callback != NULL) {
                    bus->result_callback(bus->result_callback_context);
                }
            }
            bus->pulse_start = 0;
        } else {
            // nothing on the line       
        }
    } else {
        // read 0
        if (bus->pulse_start == 0) {
            // start of RESET impulse [high -> low]
            bus->pulse_start = DWT->CYCCNT;
        } else {
            // low signal continue
        }
    }

    furi_hal_ibutton_emulate_set_next(10 * furi_hal_cortex_instructions_per_microsecond());
}
void onewire_slave_start(OneWireSlave* bus) {
    furi_hal_ibutton_pin_configure();
    furi_hal_ibutton_emulate_start(0, ibutton_fixed_interrupt, bus);
}
void onewire_slave_stop(OneWireSlave* bus) {
    UNUSED(bus);
    furi_hal_ibutton_emulate_stop();
    furi_hal_ibutton_pin_reset();
}

It also did not worked. Maybe my furi_hal_ibutton_emulate_set_next is wrong? I tried to make timer fire as fast as possible.

Last thing that was metioned [in external thread, link in one of the upper posts] is that by using external button and shorting 1W to GRD we can get emulation working. And this is also confirm theory that flipper need a much longer RESET impulse comparing to the impulse door generates.

I hope this info will help someone more skilled in flipper firmware programming to resolve this issue.

[skotopes]

@gsurkov FYI

[davidwernhart]

@doomwastaken Have you been able to replicate this by now?

Thank you for your time!

[armdn]

After 0.99.1 update same issue appears. DS1990 emulation stopped to work. In details, it has 1 impulse, then it stopped to emulate.

[gsurkov]

@armdn this problem is unrelated and should be fixed in #3519.