iButton: Flipper gets stuck on “Writing ID” with old RW1990.1 keys that can be successfully written with Arduino

Describe the bug.

Flipper Zero is unable to write DS1990 IDs to several RW1990.1 writable iButton clones.

When using:

iButton → Saved → [DS1990 key] → Write ID

the Flipper detects the key but remains indefinitely on:

Writing ID

No success or error message is displayed.

The same RW1990.1 keys can be successfully programmed using an Arduino Uno over 1-Wire.

Firmware

Tested initially on:

Unleashed unlshd-080e (2025-01-23)

I then updated to the current Unleashed firmware and reproduced exactly the same behavior.

Hardware

• Flipper Zero
• RW1990 writable iButton clones purchased around 2016
• Five unused RW1990 keys from the same batch
• One previously programmed RW1990 key from the same batch

Target DS1990 ROM:

01 7B 0A 8E E8 00 00 CE

Reproduction

1. Read and save a valid DS1990 key: 01 7B 0A 8E E8 00 00 CE
2. Open the saved key.
3. Select Write ID.
4. Touch an unused RW1990.1 key to the iButton contacts.
5. Flipper remains indefinitely on Writing ID.

Additional testing

A previously programmed RW1990 from the same batch can still be successfully rewritten by the Flipper.

However, all five unused keys failed to write with Flipper.

Some unused keys initially contained invalid DS1990 ROM CRC values. Example:

01 7B EA 5C 01 00 00 0B

Stored CRC: 0B Expected/calculated CRC: 5B

Another unused key had a valid ROM and CRC:

01 C2 F0 5C 01 00 00 0B

CRC: OK

Flipper also remained indefinitely on Writing ID with this key.

Therefore the problem is not caused by the invalid CRC.

Dallas Tester

The working RW1990 reports approximately:

FAM 01 CRC ok tPDL 142 us tPDH 40 us

A non-writing key with valid CRC reports:

FAM 01 CRC ok tPDL 135 us tPDH 38 us

So both behave similarly on the 1-Wire bus.

RW1990 type verification

I connected the keys to an Arduino Uno using the OneWire library and a 4.7 kΩ pull-up.

RW1990.1 detection was performed using the 0xD1 write-flag command and 0xB5 readback.

Both the previously working key and the keys that Flipper cannot write return:

B5 response: 0xFE

and are detected as:

RW1990.1

Arduino writing test

All five RW1990.1 keys that Flipper could not program were successfully programmed using an Arduino Uno.

For RW1990.1 the working sequence was:

• reset
• send 0xD1
• write bit 0 to enable writing
• reset
• send 0xD5
• write all 64 ROM bits, with the data bits inverted
• send 0xD1
• write bit 1 to disable writing
• read ROM and verify

After programming, all five keys read:

01 7B 0A 8E E8 00 00 CE

CRC verification:

stored=CE calculated=CE CRC OK

All five passed full ROM verification.

Important observation

During initial Arduino testing, writing the target bytes without inversion produced:

Target:

01 7B 0A 8E E8 00 00 CE

Read back:

FE 84 F5 71 17 FF FF 31

This is the exact bitwise inversion of the target ROM.

After changing the Arduino writer to invert each byte before sending the bits, programming succeeded:

VERIFY ROM: 01 7B 0A 8E E8 00 00 CE VERIFY CRC: stored=CE calculated=CE [OK] VERIFY OK

Conclusion

The RW1990.1 devices are functional and writable.

The issue appears specific to the Flipper iButton RW1990.1 writing implementation or its handling of this older RW1990.1 variant.

The fact that:

• the devices are correctly readable,
• RW1990.1 detection succeeds,
• a previously programmed key from the same batch can still be written by Flipper,
• and all five problematic keys can be successfully programmed and verified using Arduino,

suggests that this is not a hardware failure of the iButtons.

I can provide the Arduino detection/writer sketch and additional tests if useful.

Found in version

unlshd-092

Dev version

No response

Logs

Anything else?

No response