flash_st17h66.py: Improve documentation for flashing procedure in README (photos of common boards and pinouts)

[JayFoxRox]

The README is lacking information on how to wire up the board / chip before running the flasher.

Currently, there's a bunch of useful information that I had to search for myself:

• https://github.com/vadimkozhin/st17h66-OHS-tag/tree/main/flash_tool
• Lenze ST17H66 custom firmware #5
• Using a Minew iBeacon slot as proof of concept (confused on formatting) seemoo-lab/openhaystack#105 (comment)

My tags are still on their way from China (fingers crossed they are actually st17h66), so I can't try it yet.
However, skimming over those long issues makes it somewhat hard to get the most up-to-date flashing method.

I'm still not sure how to wire up my UART (or which UART adapter is even powerful enough to do it, as an ESP32 was mentioned as a UART bridge).
Also, is battery power (CR2032, for example) enough while flashing?

[biemster]

Currently, there's a bunch of useful information that I had to search for myself:

great! that's exactly the point of this repo actually. there are too many UART adapters out there to keep a list, but you're right we could update the readme to indicate that lack of power should be one of the first things to investigate if it does not work.
Battery power should be fine, as is some external 3v3 source if the adapter is too weak. (although many adapters are actually able enough)
If you want to curate a list of common boards and pinouts, PRs are welcome!

[JayFoxRox]

I'm trying to flash my 2 trackers this weekend, but I believe I already broke one of them.

- Is the reset state persistent? (= once reached, will the chip to refuse to boot normally, even before an erase?)

One of my trackers doesn't power up normally anymore (long holding the button doesn't do anything, when normally it would flash the LED and start beeping)

I basically got stuck in this loop but kept printing some garbage:

FindMy/Lenze_ST17H66/flash_st17h66.py

Lines 73 to 80 in 113ebf4

	import serial
	uart = serial.Serial('/dev/ttyUSB0', 9600, timeout=0.01, inter_byte_timeout=0.01)
	res = uart.read(10)
	while not res.endswith(b'cmd>>:'):
	uart.write(b'UXTDWU')
	time.sleep(0.05)
	res = uart.read(10)
	if res: print(res)

So it did see some stuff on the serial bus before, just not "cmd>>:".
I decided to aboard the flashing attempt but when I rerun the script it still gets stuck in that loop.

As I mentioned, it doesn't work with just the battery power anymore either - it shows no signs of life.
The only remaining sign of life is that the beeper ticks while that loop is going.

[biemster]

I'm trying to flash my 2 trackers this weekend, but I believe I already broke one of them.

• Is the reset state persistent? (= once reached, will the chip to refuse to boot normally, even before an erase?)

They are quite resilient chips, only physically breaking them by overvolting or similar would really kill your chip. The bootloader is not touched during flashing and should always be available.
On the other hand the flashing process is anything but resilient. You'll need to fiddle around a bit with how to apply power and be sure your programmer supplies enough (a couple 100 mA if I remember correctly).
Also many people including me started off with the rx and tx crossed, so you should definitely try with those swapped as well.
The best way to flash these chips is by connecting all wires except Vcc, start the flasher (the buzzer should start ticking), and apply power over and over again until the buzzer does a squeak and you see the CMD>> in the terminal.
While doing this, it is possible that the TX line of your programmer actually powers the chip and leaves it in a non-booting state, so after a tryout cycle of about 5 power on's, dis/reconnect both tx and rx as well.

It's a tricky process, but when you finally see that CMD>> showing up it's very satisfying :)

[JayFoxRox]

Thanks for your patience. I hope I'll be able to contribute back if I get it working eventually.
I've tried a bunch of things but no luck yet.

The chip labels are "ST17H66B".
My board looks exactly like https://github.com/vadimkozhin/st17h66-OHS-tag/blob/main/flash_tool/img/board.jpg
The PCB label on backside says: "CH-LZ17H26-FD01 v1.8" (second row "20210716")

I'm trying it like this:

• Connect a clamp to the bottom battery holder GND
• Connect a clamp to the bottom battery holder BAT+
• Connect a clamp to the left side of R4 (as seen here: https://github.com/vadimkozhin/st17h66-OHS-tag/blob/main/flash_tool/img/board.jpg)
• I'm holding a pin to the pad which is labelled as VPP (marked RX on https://github.com/vadimkozhin/st17h66-OHS-tag/blob/main/flash_tool/img/board.jpg)

Let's assume the other side of all clamps / pin aren't initially connected to anything.

As serial adapter / power source I'm using an nodemcu V3 which has a "1117C" (second line: "22 C232").
I connected the nodemcu GND to the EN pin (to disable the ESP8266, meaning the RX/TX are pass-through and 3V is otherwise unused).
I'm using an M1 Macbook laptop as the machine connected to the nodemcu via USB.
Connecting nodemcu RX to nodemcu TX will loopback "UXTDWU", so the serial appears to work.

First I connect nodemcu GND to the respective GND clamp .
I then connect the nodemcu TX / RX pins to the clamp (R4) / pin (VPP).

I then run python3 ./flash_st17h66.py <my-advertisement-key-base64-here> on my laptop (although I did add an unconditional print for res and modified it to use my serial port).
As soon as I run the script, the beeper starts making a ticking sound.

I now connect the VCC clamp to the nodemcu 3V pin; the beeper becomes louder.
Nothing useful shows up in the script output - it keeps printing b''.

Occassionally I try to disconnect/connect BAT+ to reset the chip - I'm not sure if this is enough, because I still hear the beeper ticking (it seems to get power through nodemcu TX).
Because of that, I often disconnect all 4 pins at one to reset the whole setup.

When reconnecting just 3V, sometimes I get garbage output like:

b''
b'\xff\xff\x00\x00\x00\x00\x06\x00'
b''
b''
b''
b''
b'\x00\x00\x00&\x10\x1d\x08\x01\x00\x00'
b'\x00\x00\xc8\xc1\x04\x0f\x00h\xfc\xf8'
b'\x00\x00\x00\x00\xf8'
b''
b''

After a couple of failed attempts I switch RX/TX and repeat this. It did not help.

I also repeated these steps while holding the button or pressing the button (especially while reconnecting).
Sometimes, this caused the board to do the long-beep of normal operation.

In at least one attempt, the button became unresponsive (no longer a beep / no LED blink; yet, no "cmd>>:" either).
Repowering the device made the LED / beeper work again while holding the button.

They are quite resilient chips, only physically breaking them by overvolting or similar would really kill your chip. The bootloader is not touched during flashing and should always be available.

One of my two boards seems broken and I'm still not sure why.

It worked fine first (as in: normal operation prior to reflashing attempts).
However, with the setup mentioned above, the ST17H66 got very hot at least once. It continued to work for a while, but then seems to have died later? There's no visual damage.
Now the board no longer reacts to the button / normal operation doesn't work (using power from CR2032 battery), even if disconnected from all clamps / pins.
It was only ever powered from the 3V/GND of the nodemcu and used RX/TX, so overvolting is unlikely.

I did never reach "cmd>>:" on either of these boards, so it wasn't flashed.

I've looked around it and sounds like #23 (comment) (which turned out to be clone chip and trouble was caused by reversed RX/TX)

Unfortunately I don't have another flasher or good 3.3V source right now.
I'll probably wire some CR2032 as a power supply and then leave nodemcu 3V disconnected (GND = CR2032 GND = nodemcu GND; BAT+ = CR2032;RX = nodemcu TX; TX = nodemcu RX) .
However, I don't think power supply is the issue here? At least the nodemcu never restarted / reset.

Ideally someone would provide a video recording of how to flash this, so one can easily repeat the shown steps.

---

So my specific questions are:

• Do I have to press/hold the button? If so, when and for how long?
• Are there any sound recordings of what the beeper sounds like if RX/TX are connected correctly? (both, the ticking sound, and sound once successful "cmd>>:" occurs)
• Is it possible that the broken board saw the UXTDWU and prevents normal operation now, even after a reset? (= does connecting to the board flash it?)

Also tagging @vadimkozhin

[biemster]

First to answer your questions:

1. No you don't need to press/hold the button
2. I'm not aware of anyone making a recording of the flashing process unfortunately, but the ticking sound is good
3. It's quite likely that the board that doesn't seem to work now actually went into flash mode and received part of the firmware, but got interrupted at some point

My main concern is your unconventional setup, I'm guessing your chip actually boots up through the power of the tx/rx lines and does not get into flash mode. You could actually use just your ESP32 to flash the chip, I did that in the beginning. For that you could have a look here: #5 (comment) (check out that whole issue, there is some more info there)

[olivluca]

FWIW, I could flash my board using an ESP32 as an uart adapter, see here https://medium.com/@shelladdicted/how-to-use-an-esp32-devkit-as-an-uart-adapter-e698594e0378

[JayFoxRox]

I could flash my board using an ESP32 as an uart adapter

Yes, that's pretty much my setup. I'm using a nodemcu board as serial adapter, but keep EN on GND, so the ESP is actually turned off (meaning 3V/GND is from the nodemcu voltage regulator and RX/TX are from the USB <> Serial adapter at 3V level).

You could actually use just your ESP32 to flash the chip, I did that in the beginning.

I figured it was easier to run the python script on my PC and only use the nodemcu 3V and serial port.
Especially after your reports that the ESP32 (mine is an ESP8266) itself might not be powerful enough to supply the board.

However, I'm skeptical now whether the nodemcu 3V is stable enough and if the serial port voltage is stable enough.
I'm also wondering if macOS handles the serial port properly or if it might introduce issues (I assume most people are on linux or Windows?).
For example, I noticed that I received 'UXTDWU' from the other side, so there might be some interference or a short (how?) between TX/RX. I also noticed that the nodemcu serial would repeatedly receive '\x00\x00\x00...' despite the tracker board being powered off and only tracker TX and GND being disconnected - this makes no sense.

---

I have gotten it into RESET mode at least twice now, but still no luck flashing:

• In the first attempt the script ran through all commands in less than a second and as response it got garbage each time (as if the adapter wasn't in 115200 baud). It obviously didn't work.
• In the second attempt it blocked after sending er512 (so I killed power after ~30 seconds).

I'll give up for today.

When I find time for this again, I'll probably add a logic analyzer into the mix or go to my hackspace (if time permits) to use some other serial adapter / 3V supply.

[JayFoxRox]

I got some help from a friend at our local hackerspace.

We were able to flash both tags!

Some observations:

• The PCB with broken beeper has a broken R4 which causes the beeper to remain silent, it's connection on the pads still seems fine.
• Even the other PCB which had gotten hot in the past and didn't operate normally, did succesfully go into the bootloader.
• The cheap chinese serial adapter I used this time behaves very differently from the nodemcu as serial adapter (nodemcu blocks on reads, whereas the other flasher kept seeing b''`).
• We checked behaviour on RX/TX pin when connecting the ST17H66 using an oscilloscope to gather some info on the timing. I'll probably repeat that and document our findings when the next batch of boards arrive.
• We eventually did it in a 2 part process. Said friend wrote some ESP8266 code which waits for RX to go high, if it goes high, it waits a bit and sends a single UXTDWU. If we saw the cmd prompt, we then disconnected the ESP8266 and connected the serial port to my macbook running the original Python script (with the first loop commented out). This setup worked very reliably (first or second connection attempt each time); I'll try to improve the serial script to reproduce this using the break condition (I had experimented with this before, but it didn't work, but we can check the timing more easily now).
• With 4 hands this is very easily doable without soldering (or even without a pogopin jig)
• I checked if the tags can be found in "nRF Connect" (Android): Yes!

After that I had some trouble registering an apple id (on https://appleid.apple.com/).
Apple rejects most phone numbers from "receive SMS"-webtools. I then got IP blocked probably.
However, I did find out that https://music.apple.com/account/create (which I found by following some URLs I found in the iTunes Windows binary) has very lax checks and it can even be automated (as its a simple HTTP GET with clean interface). It even accepts trashmail accounts.
So if trusted-device is enough as second-factor, we can potentially programmatically create the apple id.
I assume some of this is already known, but it was new to me and should be documented on this repo (or docs should be linked).

However, I'm still unable to use my airtags because pyprovision does not work on macOS, yet (Dadoum/pyprovision#3).
I'm still trying to get pyprovision running right now (although I might port provision to Python instead).

So far I've modified the Python scripts a bit so they are more reusable (API by default, CLI tools optional).
I'm also adding docs about dependency installation and change the repository structure a bit (prefer source-code, move some stuff to CI).
Not sure when I'll find time to PR this, I have too many projects right now.
I might even go back to add https://github.com/hatomist/openhaystack-python as dependency again.

(I'll also try to get back to #35 probably sometime next year)

[biemster]

Great! well done. Just as a first response, don't try the main branch on macOS, but use the catalina (python2) or monterey (python3) branches. You don't need pyprovision or any other anisette providers if you are on macOS, those two branches patch into the native frameworks to grab the data. They also can read the MME store for the search-party-token, you don't need any additional queries to obtain them when you're already on macOS.

[biemster]

About a PR, I don't accept any unless they are bugfixes. I regard this project as finalized, but everyone is free (and encouraged!) to reuse the code in their own projects. Just a mention would be nice though.

Flashing those chips is very finicky, as I can say from experience and many other's, like yours as well. It does however pay up to get a couple different usb uarts, as my CP2102 is working very reliably. But a well equipped hackerspace is very useful too!

A trusted device is enough for second factor, but I guess you would connect your main apple id to it? And not a burner account made on Apple Music? (great find btw, I'm going to try that as well)

On provision, that will be very complex to port to python. Dadoum seems to be a bit of a genius, he wrote some android lib emulation code in D that can hook directly in those libraries that are built for a different libc even. This will prove very difficult to replicate using python ctypes, although the pypush creator managed this using the unicorn emulation layer.

To conclude, awesome that you managed to flash your tags! And if you plan to run this on macOS, by far the easiest would be to run either the catalina or monterey branch (and maybe fix that for your version of macOS if needed), since they can pull the anisette data and search-party-token straight from your running system.

[JayFoxRox]

About a PR, I don't accept any unless they are bugfixes. I regard this project as finalized, but everyone is free (and encouraged!) to reuse the code in their own projects. Just a mention would be nice though

Fair enough; I'll probably make my own repository then.

Flashing those chips is very finicky, as I can say from experience and many other's, like yours as well. It does however pay up to get a couple different usb uarts, as my CP2102 is working very reliably. But a well equipped hackerspace is very useful too!

It'd rather avoid ordering more PCBs I rarely use. Hackerspace was good, but ideally we'll use the available tools there to debug issues with the other adapters so people can keep using whatever they have at hand (with minor software tweaks or some passive component).

A trusted device is enough for second factor, but I guess you would connect your main apple id to it? And not a burner account made on Apple Music? (great find btw, I'm going to try that as well)

I don't really have a main apple id. I use my personal phone number for work (where I'm more or less restricted to a macbook). I plan to use a burner from that Apple Music login (if that works.. which I'll have to check).
It will force you to assign a phone number when logging in to the appleid.apple.com website, but that might not be necessary - until then, e-mail seems to be the second factor. Once you linked a phone number, it will always require that for verification.

On provision, that will be very complex to port to python. Dadoum seems to be a bit of a genius, he wrote some android lib emulation code in D that can hook directly in those libraries that are built for a different libc even. This will prove very difficult to replicate using python ctypes, although the pypush creator managed this using the unicorn emulation layer.

Just FYI: I've previously worked on various video game emulators (mainly MIPS, ARM and x86); I also have plenty of experience of porting / decompiling games to other platforms using unicorn-engine for unfinished portions.
So the stuff in https://github.com/Dadoum/Provision/blob/main/lib/provision/androidlibrary.d looks trivial to me, but I'm somewhat concerned with the stuff in https://github.com/Dadoum/Provision/blob/main/lib/provision/adi.d (which is mostly boilerplate, but if it doesn't work, it's harder to debug).

To conclude, awesome that you managed to flash your tags! And if you plan to run this on macOS, by far the easiest would be to run either the catalina or monterey branch (and maybe fix that for your version of macOS if needed), since they can pull the anisette data and search-party-token straight from your running system.

My setup will probably also run on some Linux setup in the future (likely my raspberry pi); I'm just doing the development and testing on macOS.
I'd also rather have all of this stand-alone and portable (part of why I initially got into the emulation scene: I prefer to be able to play on whatever system I want; pyd / dlang is currently a problem in that regard).
I also prefer avoiding Apple products and I don't want to link my apple id from work for personal shenanigans.

As soon as more info becomes available about other searching networks (like the Samsung or Google ones) I'll also consider switching.

[biemster]

Just FYI: I've previously worked on various video game emulators (mainly MIPS, ARM and x86); I also have plenty of experience of porting / decompiling games to other platforms using unicorn-engine for unfinished portions. So the stuff in https://github.com/Dadoum/Provision/blob/main/lib/provision/androidlibrary.d looks trivial to me, but I'm somewhat concerned with the stuff in https://github.com/Dadoum/Provision/blob/main/lib/provision/adi.d (which is mostly boilerplate, but if it doesn't work, it's harder to debug).

Keep me in the loop, I'm looking forward to that very much!

As soon as more info becomes available about other searching networks (like the Samsung or Google ones) I'll also consider switching.

Yeah me too, not many idevices in my neck of the woods. Although I'm planning on a single firmware to rule them all.

[supaeasy]

If it helps I wrote a very detailed Step-by-Step for a certain Tracker but it is 100% adoptable for other models nrf51:
https://github.com/acalatrava/openhaystack-firmware/blob/main/apps/openhaystack-alternative/iBeacon%20StepByStep.md