Menu

#83 Firmware Update failed for Ryos MK Pro

v1.0_(example)
open
nobody
None
1
2017-11-06
2017-07-15
No

I was just trying to update Firmware to V1.26 on my Roccat Ryos MK Pro Keyboard.

Before the update, we had

$ lsusb | grep RO
Bus 002 Device 005: ID 1e7d:3232 ROCCAT
Bus 002 Device 003: ID 1e7d:2ee1 ROCCAT

The firmware file Ryos_MK_Pro_v126.bin was downloaded from the SF files area and choosen for update. After hitting Update, the application sayd "Update completed, please unplug ..."

After plugging back in, the keyboard is dead, all lights off.

Linux now recognizes only one of the two USB devices:

$ lsusb | grep RO
Bus 002 Device 003: ID 1e7d:2ee1 ROCCAT

Any attempt to recover the situation failed so far.

  • What went wrong ?
  • Is there any chance to repair the keyboard ?
  • The firmware update functionality should be disabled, if it is'nt working

Discussion

  • GPFault

    GPFault - 2017-11-05

    I have exactly the same problem:
    After updating fw version 1.25 to 1.26 on Ryso Mk Pro with roccat tool 5.6.0 on kernel 4.13
    and replugging the keyboard it only recognizes as an usb hub with three ports.

    The VendorId:ProductID of the hub is quite different (04b4:6572 Cypress Semiconductor Corp.) but googling shows that it is normal -
    some working keyboards has such identification of the hub (it can read IDs from eeprom).

    According to lsusb -v from root:

    Hub's port 1 is in a state "power"and doesn't has any activity
    Hub's port 2 corresponds to exterenal usb port and works fine (USB flash plugged into exteranl port works).
    Hub's port 3 is in a state "power connect"

    According to wireshark while linux kernel sends GET_DESCRIPTOR to the device on port 3 -
    it anwsers with simple 64 byte packet that doesn't contain descriptor data at all. So no os can recognize it.
    Dmesg shows device descriptor read/64 error -32
    Windows shows Unknown USB Device (Device Descriptor Request Failed).

    Last year I had an succesfull experience flashing RocatKone+ with roccat tools, and no problem occures.
    So it looks like that the flashing problem is Ryso Mk Pro-specific.

    So I really suggest disabling flashing for the Ryso Mk Pro - there is another thread with several bad flashes for this keyboard - see
    https://sourceforge.net/p/roccat/discussion/989581/thread/1b68f654/ and https://sourceforge.net/p/roccat/discussion/989581/thread/27d84dfc/

    And no any threads about another devices bricked.

    Nevertheless, thaks for the roccat-tools! The configuring UI is very useful.

    About flashing - is it known that roccat has something "press specific key during power on to mke usb switch to some flash recovery mode?"
    I haven't disassebmle the keyboard yet (maybe I'll try make a return, assuming that at roccat they would be able to flash it normally),
    but I've read about JTAG flashing on the links above.

    The source code roccat_firmware.c of flasing process splits binary into several STEPS... Does it correpond to different storages on the device or it has exactly one firmware storage?

     
    • Stefan Achatz

      Stefan Achatz - 2017-11-06

      Version 5.6.0 of roccat-tools is outdated. 5.7.0 has important changes in firmware update code.
      The problem is that I can't reproduce this bricking problem. The Ryos MK Pro is one of the primary testing devices for my update code with lots of updates done, some failed but it never bricked beyond repair.
      No recovery mode is known for the Ryos MK Pro. Newer devices seem to have Bootloader that support a failback mass storage device, but I don't know how to enter this mode on purpose.
      The firmware binary is stored by the bootloader in a continuous area in the MCUs flash, right behind the bootloader itself.

       
  • Fredy Paquet

    Fredy Paquet - 2017-11-06

    All attempts to re-flash the keyboard from windows also failed.

     

Anonymous
Anonymous

Add attachments
Cancel





MongoDB Logo MongoDB