Error: The script writes the wrong area of ​​Flash on ST17H66B!

[pvvx]

The script writes the wrong area of ​​Flash on ST17H66B!

Flash_st17h66.py log:

b'cmd>>:'
RESET MODE activated. Changing baudrate to 115200
Erase + Write
sent b'er512'
Response is: b'#OK>>:'
sent b'rdrev+'
Response is: b'0x01124485 6222M005 #OK>>:'
sent b'wrreg4000c890 ab000001 '
Response is: b'#OK>>:'
sent b'wrreg4000c838 ff010005 '
Response is: b'#OK>>:'
sent b'spifs 0 1 3 0 '
Response is: b'#OK>>:'
sent b'sfmod 2 2 '
Response is: b'#OK>>:'
sent b'cpnum ffffffff '
Response is: b'#OK>>:'
sent b'cpbin c0 002000 130 11002000'
Response is: b'by hex mode:'
sent c0 (len=304)
Response is: b'checksum is: 0x00010945'
sent checksum
Response is: b'#OK>>:'
sent b'cpbin c1 005000 3f50 11005000'
Response is: b'by hex mode:'
sent c1 (len=16208)
Response is: b'checksum is: 0x0015270a'
sent checksum
Response is: b'#OK>>:'
sent b'cpbin c2 020000 7088 11020000'
Response is: b'by hex mode:'
sent c2 (len=28808)
Response is: b'checksum is: 0x002a5483'
sent checksum
Response is: b'#OK>>:'

All ok.

But the recorded FW FindMy does not work!
After resetting the chip power supply, the previous FW starts, since FindMy recorded itself in the second half of the Flash!

And there are many such ST17H66B.
I'm not the only one getting this error.

[biemster]

wut! how does it work for me? I'll look into this, thanks!

[pvvx]

It's just a different revision of the chip.
With this chip revision your and my scripts do not work correctly.

If you give the "reset" command without turning off the power after your script version, the chip will restart and will work. But if you turn off the power - then, when you turn on the power again, the old firmware will work.

If you again give commands to initialize and enable SPIF (XIP) in ROM and "reset", then Findmy will work again.

cmds.append(b'spifs 0 1 3 0 ')
cmds.append(b'sfmod 2 2 ')
cmds.append(b'cpnum ffffffff ')

This is either a ROM bug or a special chinese quirk. :)

Flash in the chip according to JEDEC ID command is 256 KB. But FW your script writes to the second Flash of 256 KB.
The total volume of Flash chip is 512 KB.
Enabling SPIF in ROM swaps 256KB Flash blocks into a common 512KB address space.
Such a сhinese joke :)

Without full documentation or disassembly of the ROM of this revision, this cannot be cured.

Info:

=========================================================
PHY62x2/ST17H66B/TG7100B Utility version 26.02.25
---------------------------------------------------------
Connecting...
PHY62x2/TG7100B: Release RST_N if RTS is not connected...
ST17H66B: Turn on the power...
Chip Reset Ok. Response: b'cmd>>:'
Revision: b'01124485 6222M005'
FlashID: 1124485, size: 256 kbytes
Flash JEDEC ID: 854412
PHY6222 - connected Ok
Flash Status: 0x0000
Flash Serial Number: 4150343033373211
Flash OTP[0:3]: ffffffff
Flash data at 0x01102000: ffffffffffffffffffffffffffffffff
Flash data at 0x01102100: ffffffffffffffffffffffffffffffff

(Empty Flash - I erased everything in it for testing.)

[biemster]

I gleaned those commands from the LeKit software, did you have a look how the latest version of this package is handling this chip revision?

[pvvx]

I don't know what "LeKit" is.
There is a basic version of PhyPlusKit.
All the same, they do not have a complete decoupling from the bootloader partition protection. And without this, you cannot make a copy - you cannot restore the original firmware, etc.

---

There have been many chips with different company names and markings for a long time, but all with crystals from PHY62xxx. That's where everything grows from. This is a "people's" Chinese company - it distributes the chip design to everyone...

[biemster]

I don't know what "LeKit" is. There is a basic version of PhyPlusKit.

Yeah ofc 😄 that's what I meant.

So it's not a matter of flashing to the right flash area? I noticed LePhyKit generates some header for the provided binary with the right addresses to jump to, there is no playing with that?

[pvvx]

Useless program:

The result is similar.
something was programmed into the wrong of the two Flash memories and it doesn't work :)

The power supply current shows the startup into empty Flash :)

[pvvx]

It should be like this

(write BOOT_KEY2_v21.hex)

But it works until the power is turned off :)

[biemster]

This is either a ROM bug or a special chinese quirk. :)

Quite a quirk indeed :D I'd love to get one of those chips to try out, do we have a (semi) reliable source? If we have write access to the right flash area from our own code we might be able to cook up some minimal ota kind of contraption?

[pvvx]

Such chips are installed in https://pvvx.github.io/SP621E/

I'm too lazy to make a flash loader in RAM for PHY... There is nothing complicated there. All ROMs of PHY chips have a command to write to memory... (Write control interception directly to the interrupt vector table)
Using write and read commands at any address, I read different ID, OTP and UID Flash through the SPI controller registers :)
But all commands in ROM are disabled when "FCT mode" is set (writing to a specific address of the Flash key to protect against copying). After that, only one command works - erase the entire Flash. Such devices have already been encountered... It is possible to write a new FW only by erasing all.

			print ("Use the 'Erase All Flash' (ea) command to exit FCT mode!")

[biemster]

i just received my first sp621e yesterday, i immediately ordered one after your discovery. I'll have a look if it has one of these quirky chips.

Do i understand correctly that after an "erase all" it still boots the original fw after a power cycle?

[pvvx]

Do i understand correctly that after an "erase all" it still boots the original fw after a power cycle?

If you use ROM commands, then yes. (The new firmware is also saved, but it is in a different Flash. To launch the new firmware, you need to give the commands "spiffs..." and "reboot".)
If you give the command to erase all flash everything through the SPI controller registers, then it will erase everything :)
A running FW can easily write anything to the first Flash. It is protected only for commands in ROM (software - only the boot table area is protected). The second Flash has no protection.

On all other versions it was possible to write to the Flash duplication area. Then it was limited - fixed. Now it is necessary to write to the RAM cell an increased Flash size and again it is possible to write to protected Flash areas by adding the Flash size to the address. But in this miracle version this was also blocked or I have not yet figured out how to bypass it...
And these chips have a new joke - two Flash crystals jumping to addresses :)

---

In general, everything is more complicated with ROM commands. The boot partition table is erased only by the erase all command. Re-writing the FW without this will not work. They've made it too complicated - there is no point in this.

PS: Google translates the technical description very poorly. It takes a long time to find words and sentences to keep the meaning. I described it as best I could, through triple translation and editing in Google Translate. :)

[pvvx]

The reason is described here
pvvx/THB2#94 (comment)

=========================================================
PHY62x2/ST17H66B/TG7100B Utility version 26.02.25
---------------------------------------------------------
Connecting...
PHY62x2/TG7100B: Release RST_N if RTS is not connected...
ST17H66B: Turn on the power...
Chip Reset Ok. Response: b'cmd>>:'
Revision: b'01124485 6222M005'
FlashID: 124485, size: 256 kbytes
Security Boot: 1
# Flash JEDEC ID: 854412
PHY6222 - connected Ok
Flash Status: 0x0000
Flash Serial Number: 4150343033373211
Flash OTP: ffffffffffffffffff...
Flash 0x11002000: 0600000078344e6b3818ff1fffffffff
Flash 0x11002100: 00000100540b00000000011165a1df0d
Efuse Lock Status: 0x0000000e
Efuse 0: 0000000000000000
Efuse 1: 9f6dcc0bfd530804
Efuse 2: 0000000000000000
Efuse 3: 56634424a0a2d385
Security Boot: 1

I haven't figured out how to erase eFuse yet. It's impossible with standard PHY utilities or ROM routines.
PhyPlusKit eFuse writing routines and ROM functions do not work. They do not write eFuse at all.
The code in the ROM is identical to the PHY6222 chips.
The Patch code for the eFuse recording procedure found on the Internet also does not work.

https://github.com/pvvx/PHY62x2/blob/master/Doc/PHY62XX_3.x.x_ANS/PHY622X_Security_Boot_User_Guide_v1.0.pdf

[biemster]

PS: Google translates the technical description very poorly. It takes a long time to find words and sentences to keep the meaning. I described it as best I could, through triple translation and editing in Google Translate. :)

Thanks a lot for all this investigating and updating me on it. I finally got time to cut open my sp621e and noticed it got an unbranded chip with just a lot number, but I highly suspect it's a 17h66. If it is I will order a whole lot more because I really like the ability to run it from anything between 3v and 24v, on a tiny package if i cut off the unneeded LED half, for just $1.

So I will definitely continue investigating, what I did not fully understand from the google translations, do these chips check the validity of the fw in the first section, or will it boot whatever is written there even when it was put there by a RAM flash loader using direct SPI? So can I overwrite the first flash with just a jump to the second, and the chip will happily accept that?

[pvvx]

1. After a power reset, the chip reads the eFuse and requires loading only encrypted firmware.
2. The programmer program writes zeros to the eFuse registers. After this, your firmware can be launched. More specifically, when starting in programming mode, the eFuse settings are reset. This allows you to run your simple FW.

The documentation states that eFuse registers can only be written to once.
I was unable to re-write to the eFuse or change the status of any of the 4 eFuse registers.

Documentation for the previous series (PHY6202 PHY6212). Approximately coincides with what needs to be done in PhyPlusKit to write encrypted FW to PHY6222 (17H66B) chips.
https://github.com/pvvx/PHY62x2/blob/master/Doc/prbmd02-security-boot-user-guide.pdf