Support for apparent clone chips: E2XT23xx

[agittins]

Great work you've been doing to get these devices going! I've read a lot of the threads across your various repos, so I think I've got a rough idea of the state of things, but I'm still green :-)

I bought a handful of the beacons just like the ones that pvvx received. Mine don't have a st17h66-stamped chip though, I think it's a clone - my chips are stamped with:

         8
  E2XT2320
  SHEMnxxx

(where n is a letter (seen A and J so far) and xxx three digits) I'm using Linux.

I was able to flash using the python script(s) in the FindMy and RF repos. The hex file from the FindMy repo works, and I see FindMy adverts from mac D1:22:33:44:55:66.

When I flash the hex files from this _RF repo I don't see any advertisements coming through, but the onboard LED does flash every 500ms so I'm confident the code is running. I tried the (keil?) built one in the bin folder (by setting [0] for ARM in the flasher script), and the GCC one in ./build/, as well as building my own using gcc. They all flash the LED but I can't see adv packets in nrfconnect.

Am I on a "known-working" setup? I know you've been having to use the windows tools to start with so wasn't sure if building and flashing on linux with gcc was at an "it works" stage or still at "it builds!" stage :-) I wondering if the issue might be with setting the MAC address, but there's probably plenty of places something could have gone wrong!

Ultimately I want to probably have a couple of them as openhaystack tags for tracking assets, but most of them I want to use as buttons in home assistant - I was planning to modify your _RF repo to send BTHome packets - hopefully I can get it to use the encrypted form eventually. They seem like ideal buttons to just throw all over the house, and with multiple esphome-based bluetooth proxies I'm thinking it could be a pretty solid solution.

[biemster]

Interesting! My latest batch of tags to arrive also were no st17h66, but

E2XT2319
SHEM4400

which greatly disappointed me, awesome news that they seem to be just clones! (didn't try to flash them yet)

This _RF repo has the most recent work, and fully works on GCC, so you are on a known-working setup. The plan is to replace the firmware from the _FindMy repo with the _RF repo (then I can abolish the Keil requirement), so it is disappointing that this does not work anymore with the clones. The difference between the _FindMy and _RF repos is the latter does not use the SDK and Bluetooth stack, but the RF frontend directly (@natschil even got Zigbee working like that!). I guess the direct RF method is missing some init for the clones, I'll look into that when I find some time.

Your use case is exactly like mine! This tracking was just a bonus, but I also intend to mainly use them as buttons in my home. I wanted to go the Zigbee or bare 802.15.4 route, but maybe BTHome is actually easier. I'm very curious on your progress on this!

[agittins]

Great to know that the repo is is working order and the issue is likely local to my devices. I'm not sure how much help I can offer working it out, my C is very rudimentary and best suited to taking things that already work and breaking them in new ways, rather than the other way around! 🤣

Yes I was amazed that natchil had got some zigbee stuff going, that's very cool. I think I'm keen to go the bthome route myself. I find zigbee not very transparent for troubleshooting, and I don't like how there's a single point of failure with the co-ordinator. I like that using ble with bthome we can fairly easily have encrypted signalling that can have redundancy from multiple proxy receivers. I think the Zigbee path will be a lot trickier too since there'll need to be some two-way work I assume for pairing etc. It's a promising prospect though!

I did manage to mangle some nrf51822 sample code into a bthome beacon, but these buttons are half the price of an nrf51 board and in a case with battery, so much preferred for throwing all over the house in my case. Also interested in possibly tacking in a few more tac-switches as well using the spare IOs. But for a few bucks each I guess one might as well just add another entire button :-)

I'll have a poke around and see what I can discover, but not sure how much time I'll be able to put in - but any pointers you might have on top of what you've already mentioned would be welcome, and otherwise I hope you might find some luck with your latest batch in case the solution is common to them (sounds pretty likely at this stage).

[danhuanggt]

Edit: Resolved below

Hi @agittins, @biemster brought to my attention that I've been attempting to flash my "ST17H66" when in fact it is one of these "clone" chips.

I am using the flash_st17h66 python script from the FindMy repo, but have been unsuccessful. Any tips or pointers on how to flash these clones?

I too am pretty green to all of this as well, but I've been absorbing across all repos as well!

These are closeup pictures of the "clones":

[danhuanggt]

Update: I was able to flash them! Just had my TXDs and RXDs reversed!

[agittins]

Yes, they look identical to mine. Great that you were able to flash them!

I was able to get the pre-built airtag clone firmware flashed and working, but I have not been able to get anything else to work on them - the other pre-built binaries from @biemster don't seem to function, nor do any that I've been able to build using the gcc toolchain.

When I get some time I plan to try out the windows build environment (a bit painful since I don't run any windows machines) to see if I can work out what's going on. I have a feeling that the issue is the flashing script, it does a lot of wrangling of the binary image and decision-making on what addresses to flash with what, but I have no idea what the details are. @biemster if you have any additional info/comments you could put in the flashing script that might help me get my bearings it would be greatly appreciated! Much of the issue is probably my inexperience with embedded development - I understand a bit of the underlying architecture (I cut my teeth hand-writing machine code on the Z80 many years ago without an assembler) but my knowledge from asm to C is embarrassingly slim :-)

I have a feeling the images I am building with gcc are probably "good" but the flasher script probably needs to treat them differently for them to work once they land on the device (it flashes, but doesn't appear to run).

[biemster]

Awesome, well done @danhuanggt! @agittins The issue is most likely in the SDK calls during initialisation, or possibly the ISR vector. I've done some hacky stuff there to get it working in GCC, which might not cut it for those clones if they run some newer version of the internal HAL. A good place to start experimenting is https://github.com/biemster/st17h66_blinky. (that's where I will start soon) I doubt the issue is with the flashing script, as the output is a byte exact copy of the output from the LeKit software (which runs fine using wine btw, no need to setup a windows build environment!) EDIT: Keil also runs great using wine, but I fully agree with your wish to stay away from windows.