openinput-fw
Support for SteelSeries Sensei Ten
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?
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
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.
What about the SROM data? Can the generic one be used before a special one is extracted? How would it be extracted?
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.
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 :stuck_out_tongue:.
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?
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 :wink:
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.
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
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?
I think we want to do that in the future, but for now it is simpler to do it this way.
@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.
No, I dont.
If i recall, I flashed a custom firmware that was loaded with the stock bootloader, that then dumped the contents of the mcu and the external eeprom through swo
Here you can find most of what we figured fromt he 310, the bootloader dump is not there, i have to see if i find it and upload it too. https://github.com/perigoso/rival310-re
@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 0008 and 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
Sorry Im not following, you're saying the sensor is not being read properly?
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.
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 https://github.com/openinput-fw/sensor-blobs/pull/2 )
are you uploading the right fw blob? the truemove3 blob should not be compatible
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
Yes, it's the correct blob. I also added CRC checks (not in the trace) and it give the correct result.
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.
ah, yeah pixart is terrible with info on their sensors, I dont think theres any more detailed DS around
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.
I still could not get it to work. Except when not uploading the SROM; then it works nicely.
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
This is what I tried. I'll try to produce another SPI dump tomorrow and look again.
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