Repository navigation
Support for SteelSeries Sensei Ten #64
Description
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?
Activity
perigoso commentedon Jun 20, 2021
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 commentedon Jun 20, 2021
Good to hear, then I'll probably try to do so.
[-]Support for SteelSeries Sensai Ten[/-][+]Support for SteelSeries Sensei Ten[/+]FFY00 commentedon Jun 20, 2021
Yeah, you just need to create a new config for the
stm32f1-generictarget (see https://github.com/openinput-fw/openinput/blob/main/src/targets/stm32f1-generic/config/rival310.h for an example), and add a symlink tostm32f103t6.ldfor your config in https://github.com/openinput-fw/openinput/tree/main/config/linker/stm32f1-generic.t-8ch commentedon Jun 20, 2021
What about the SROM data?
Can the generic one be used before a special one is extracted?
How would it be extracted?
t-8ch commentedon Jun 20, 2021
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 commentedon Jun 20, 2021
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
0x08002000IIRC. 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 commentedon Jun 20, 2021
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 commentedon Jun 20, 2021
Your device as an external eeprom, right? It should be stored there.
Plugging a debug probe, like a st-link, and flash the firmware that way.
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.
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 commentedon Jun 20, 2021
Will check as soon as I have it.
Ok.
Then I'll keep the original bootloader for now probably.
perigoso commentedon Jun 21, 2021
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 commentedon Jun 22, 2021
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 commentedon Jun 22, 2021
I think we want to do that in the future, but for now it is simpler to do it this way.
t-8ch commentedon Jun 22, 2021
@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.
3 remaining items
t-8ch commentedon Jun 23, 2021
@perigoso Thanks.
I flashed openinput which works mostly but the motion burst data received from the sensor is not parsed correctly.
Then I tried to go back to the vanilla firmware which didn't work because the bootloader was also gone and I don't have an intact version of it.
I managed to make it work by manually creating a stub bootloader consisting of
0028 0020 1970 0008and a lot of zeros, setting the stack and PC to the firmware values.The mouse is fairly unhappy, both LEDs are blinking red, all hidraw devices are gone, but it's still capable of properly running the basic mouse functions.
Now I just have to figure how the data is to be interpreted.
The attached file for example are motion burst reports (register 0x50) while the mouse is being moved at 4000DPI and then lifted.
burst_reports.txt
perigoso commentedon Jun 24, 2021
Sorry Im not following, you're saying the sensor is not being read properly?
t-8ch commentedon Jun 24, 2021
Yes. The motion burst always reports 0 for the delta values.
Looking at the "Motion" byte in the motion burst report shows that the sensor is in "Rest mode 1", although Rest mode should be disable via the Config2 (0x10) register.
t-8ch commentedon Jun 24, 2021
If you want I can provide SPI traces for both cases.
Edit: Attached are sigrok SPI traces that can be viewed in PulseView.
(Optionally with openinput-fw/sensor-blobs#2 )
spi_traces.zip
perigoso commentedon Jun 24, 2021
are you uploading the right fw blob? the truemove3 blob should not be compatible
perigoso commentedon Jun 24, 2021
I have not yet tested with the pmw3389, so the driver might be doing something wrong, datasheets are obtainable
I'll look at the captures in a bit
t-8ch commentedon Jun 24, 2021
Yes, it's the correct blob. I also added CRC checks (not in the trace) and it give the correct result.
t-8ch commentedon Jun 24, 2021
Can you point me to the datasheet? The only one I found did only specify the numbers of the registers, not how they are to be used.
perigoso commentedon Jun 24, 2021
ah, yeah pixart is terrible with info on their sensors, I dont think theres any more detailed DS around
perigoso commentedon Jun 24, 2021
Well, from everything I'm looking at, this should just work, the behavior should be the same as in the 3360
Only just now looked at your captures, stock seems to be doing a couple different things, I'll be looking deeper.
t-8ch commentedon Jul 1, 2021
I still could not get it to work.
Except when not uploading the SROM; then it works nicely.
perigoso commentedon Jul 1, 2021
what have you tried? we can try to modify the driver until the startup matches the stock exactly, from there we can figure out what we're missing
t-8ch commentedon Jul 1, 2021
This is what I tried. I'll try to produce another SPI dump tomorrow and look again.
perigoso commentedon Jul 1, 2021
right, sorry I'm not paying much attention to this
I'd like to try something myself but sadly I don't have anything with a pmw3389, or the sensor itself
FFY00 commentedon Jul 1, 2021
Ugh, I must have that sensor somewhere, because I did order one, but I just can't find it.