Spontaneous numlock

[dsimic]

I saw that but for some reason I think it doesn't affect the chip's count of writes unless it gets through.  Like the retry is for if the USB communications fail.   There's one of those loops on read too.  And they allow 20 tries for opening in boot mode above that.  

Who knows does a failed write actually affect the write count on the keyboard controller?  It shoud be better to stay on the safe side, if possible; also, we'll see what the author of the forked firmware updater will say on that.

Looks like there are 3 write processes:

flash_tp_upate  in step 1 (ansi and iso are the same)
flash_tp in step 2 (both the same again)
flash_kb_ansi or flash_kb_iso at the end of step 2

This is exactly what I've already described at least a couple of times.   See my description of the "helper" firmware.

What if there's some mixup of versions?  Like you flash an iso with ansi or vice-versa.  It would probably be worse than it is now.

Probably nothing good would happen.   The most weird thing is that the ISO variant is supposed to keep working after the "helper" firmware is flashed to the keyboard controller, while the ANSI variant stops working at that point.  I wonder why?

So the keyboards about to leave the factory work perfectly?  Wonder what they have loaded.  It wouldn't be that hard to disable the write part and just read back to write to a file I think.  Leave all the overhead intact and just comment out the actual writes.  All 3 of them.  That shouldn't trip the limit.  Since the write-limited chip mentions the limit in its datasheet I think that's probably where the limit is.

I've already explored the way for reading the current keyboard firmware into a file, but I'm not sure if reading the current firmware is possible without writing something first, or if everything is going to "explode" that way, rendering the keyboard unusable.  I'll make the required changes to the source code of the updater, but would you be willing to test that out?