Support for SteelSeries Sensei Ten

[t-8ch]

How hard would you estimate it to be adding support for SteelSeries Sensei Ten mouses?

MCU: STM32F103T6U6A ( https://www.techpowerup.com/review/steelseries-sensei-ten/4.html )
Sensor: TrueMove Pro (based off the PixArt PMW3389.)

Also: Is the assumption that the innards of the Sensei 310 are identical to the ones of the Rival 310 reasonable?

[perigoso]

support should be pretty straightfoward, just need to figure out what is connected to what, the pcbs are different, but it might be similar enough that no changes are required

[t-8ch]

Good to hear, then I'll probably try to do so.

[FFY00]

Yeah, you just need to create a new config for the stm32f1-generic target (see https://github.com/openinput-fw/openinput/blob/main/src/targets/stm32f1-generic/config/rival310.h for an example), and add a symlink to stm32f103t6.ld for your config in https://github.com/openinput-fw/openinput/tree/main/config/linker/stm32f1-generic.

[t-8ch]

What about the SROM data?
Can the generic one be used before a special one is extracted?
How would it be extracted?

[t-8ch]

Also is the bootloader that is responsible for flashing a new firmware protected against overwrite?
Or is there something to care about to prevent a hardbrick.

[FFY00]

The firmware blob for the sensor should go to https://github.com/openinput-fw/sensor-blobs, and we'll generate a header that can be used in the code.

We don't have a bootloader yet, just the firmware. You can either flash it directly, or keep the stock bootloader. If you want to keep the stock bootloader, you will have to change linker script to put the ROM in 0x08002000 IIRC. We have reverse engineered the Steelseries update protocol used in the Rival 310 and friends, which I am pretty sure is the same use in the Sensei Ten. You should be able to use tools in https://github.com/openinput-fw/openinput/tree/main/tools to generate the CRC and flash the firmware.
Though, we'd recommend to flash directly, if you have that option. But maybe it's better if you dump the original memory first so that you can go back. You can do this by flashing a custom firmware that just reads out the memory, that's what @perigoso did, I don't know if he still has the source around.

We want to write a custom bootloader and then a dummy firmware that can be flashed with the original bootloader and will replace it with ours, but that is still a TODO 😛.

[t-8ch]

How would I extract the firmware blob for the sensor?

How would "flashing directly" work?

Dumping the original memory would be great. Should it be possible to attach a debug probe and read the ROM via that?

Does the bootloader implement the update protocol? If so how would the firmware be updated after a firmware without a bootloder is flashed?

[FFY00]

How would I extract the firmware blob for the sensor?

Your device as an external eeprom, right? It should be stored there.

How would "flashing directly" work?

Plugging a debug probe, like a st-link, and flash the firmware that way.

Dumping the original memory would be great. Should it be possible to attach a debug probe and read the ROM via that?

Possibly, though I think they probably enabled readout protection. If that is the case, you will have a to use the method I described -- flashing a custom firmware via the original bootloader to dump the contents.

Does the bootloader implement the update protocol? If so how would the firmware be updated after a firmware without a bootloder is flashed?

Yes, it does. If you flash it directly (remove the bootloader), you will only be able to update with the debug probe, and not USB. For now at least 😉

[t-8ch]

Your device as an external eeprom, right? It should be stored there.

Will check as soon as I have it.

Possibly, though I think they probably enabled readout protection. If that is the case, you will have a to use the method I described -- flashing a custom firmware via the original bootloader to dump the contents.

Ok.

Yes, it does. If you flash it directly (remove the bootloader), you will only be able to update with the debug probe, and not USB. For now at least.

Then I'll keep the original bootloader for now probably.

[perigoso]

I dont recall what i did exactly to extract the original fw, i was just hacking around.

I had mixed results when keeping the original bootloader, i dont konw what they do there, but the firmware a lot of time just didnt work, while working fine when flashed directly.

I you do end up flashing with a debug probe you can restore the original state with the probe as well, provided you have the original fw

[t-8ch]

Is there a reason for baking the sensor firmware into the normal firmware instead of also taking it from the eeprom like the stock firmware?

[FFY00]

I think we want to do that in the future, but for now it is simpler to do it this way.

[t-8ch]

@FFY00 Ok

@perigoso Do you still have the code the code to dump the flash?
I used https://github.com/doegox/stm32f1-firmware-extractor but the result is not complete, so most probably not runnable.