Rumba board no communication since failed firmware update via repetier server

Hi, I probably made a big mistake:
usinf repetier firmware V1.0.3 on a rumba board and repetier server on a raspberry Pi.
For BLTouch I did some firmwar changes and transferred from laptop via USB cable. Everything worked fine.

No I found in repetier server the possibility to perform firmware updates.
Compiled in arduino environment and exported. Two files were created , one without and one with bootloader.
By mistake i chose the one with bootloader.
The detail windows shows many "stk500v2_ReceiveMessage(): timeout".
since then I am not able to communicate with the rumba board.
I tried many hours to find a solution with
- putting the board in DFU mode
- Atmel Flip driver in win10 - faile due to missing certification
- Flip driver in a virtual Win XP - failed for incompatible driver
- Flip driver in a virtual Win7 - could be installed
  Now I have an Atmel USB device with ATmega16u2 in device manager - I was hopeful.
  But flip could not open USB device.

I was printing face shield for MakervsVirus, but this is now stopped.

So I would be happy about any advice how to bring my rumba board back to live.
programmer - buy new rumba - buy another board?

And despite this: happy eastern and stay healthy!


  • The AVR chip normally has fuses set to prevent overwriting the bootloader. So I wonder if you really managed to overwrite the bootloader or just having problems to rewrite firmware. I also got the timeout warning sometimes with healthy bootloader. So I would power of the rumba and repower it and upload new firmware.

    If we assume you managed to destroy bootloader somehow, I know it can be written with a ISP or other arduino used as ISP ( - is that what you try to do? Then make sure to use the right ISP connector on rumba board. There are 2 - one for serial usb driver and one for the firmware. You need the one next to motor driver like shown here: with that you can repair any bootloader.
  • Thanks for your quick answer!
    I tried many times to power off/on and install firmware from arduino environment. At Rumba Board, just the Tx LED is flashing one per 10 seconds, also LCD Display shows nothing. Therefore I think, the bootloader is damaged, firmware doesn't start.

    In arduino doku I mostly find to use windows and flip software, but I was not successful like described above.
    So the only chance I see ist either an arduino as ISP

    As far as I understand ( now I have to burn
    - ATmega16u2 Firmware using the JTAG connector and an extra programmer
    - ATmega2560 bootloader using the ISP connector
    - and then hopefully being able to transfer the repetier firmware to the board using USB

    On the other hand thinking of all the time diging for informations.. I'm close to buy a new board.

  • First you can burn both with ISP connector. And the ATmega16u2 chip has no bootloader so you can not have deleted it with the upload. So if you never used the ISP port for your tests it should still be in tact. If you see the com port in windows it is in tact. So all you need is flash the mega2560. You can also buy a cheap for this like this one: less then 13 euro and much cheaper then a rumba board. And you are prepared if anything goes wrong in future.
  • Thank you for being active also on easter sunday!
    I'll follow your recommendations and will report afterwards.

    Regarding the firmware update feature of repetier server something went wrong.
    Since I want to understand what has happened:
    What I did:
    compiled V1.0.3 with some modifications and exported it.
    Two files were generated, one without, one with bootloader.
    The server is running on a raspberry pi 3B+
    Then, in the servers Website I called firmware update and selected to hex file with bootloader.

    In the dialog there were some messages (which I dont remember), then many many stk500 timeout messages, every 10 econds.

    What could have gone wrong in my opinion?
    The arduino environment does not know about the connected rumba board. It only knows arduino mega 2560.
    Therefore the created bootloader may not compatible to the rumba board.
    If everything is back working, I#ll try firmware update using the non-bootloader file. This should be less dangerous.

    Wish you'll find more easter eggs today than easter bugs!
    And thanks very much for your productive help.
  • I can not really say what happened. What the uploader does is calling calling avrdude with same parameter arduino ide calls for the non bootloader upload. It might be that the files contain target address (bootloader is at end of memory I think while Program goes to start). But if you write to bootloader memory that would change the software running at same address which will crash maybe the bootloader. Not 100% sure since I did not write it. But then you have a problem like you described. But also the fuses were then set wrong I guess since bootloader should be protected to prevent overwriting. With an ISP it is possible to change these fuses. That is how you upload the bootloader - also ISP does not need bootloader to upload.
  • Now my printer is back, a damaged bootloader of atmega2560 was the problem.

    Thanks for your help, Repetier!

    But all I tried without success and the way it worked for me might be interesting for others:

    What I didn't get to work:
    1) following
        entering the DFU mode seemed to work, Tx/Rx flashed shortly.
        Didn't find any way to install the Atmel flip driver atmel_usb_dfu.inf in Win10 because of missing certificate
    2) setup a WinXP system in virtual box
        driver was not accepted (other reason, not because of certificate)
    3) setup a Win7 system in virtual box
        driver was accepted (devie manager showed Atmel USB Devices / ATMega16U2
        as other reason, not because of certificate)
        Flip acceptet to select USB for communication. Clicking on open: could not open device
    4) Hardware programmer Erfos AVR-ISP in Arduino IDE
        6 pin cable was not included, made one
        USB device was recognized in Win10
        Arduino IDE: Selected AVR-ISP,
        Main Errors stk500_getsync() attempt 1 of 10: not in sync: resp=0x03
            avrdude: stk500_recv(): programmer is not responding
    5) Hardware programmer Arduino as ISP
        Arduino IDE
        Cabeling like several manuals
        Selected Arduino as ISP as Programmer
            Main error message: avrdude.exe: Device signature = 0x000000 (retrying)
    6) Hardware programmer Diamax AVR USB Stick
        like above
    7) installed Atmel studio
        all selection boxs in device programming were emtpty.
        didn't want to read through manuals

    What worked finally for me (I'm a greenhorn in bootloaders, so there could be just small steps to make other options work - or not work):
        hardware programmer "DIAMEX USB ISP-Programmer Stick für AVR"
        searched for another programming software, found bitburner
            Settings: no changes
            Tab AVRDude
                - AVR Device: ATMEGA2560 (m2560)
                - Programmer: Atmel AVR ISP V2 (avrispV2)
                - COM7  (found in device manager)
                - AVRDude Arguments: <empty>
            Tab AVR Memories
                - Flash: <Bootloader-hex-File from reprap link (see above)
                - EEPROM: grayed out
                - Memory Programmer: Flash only
                - Button write --> it wrote and said success!!
            AVR Fuses
                - Set fuse bytes like shown in Reprap Link
                - Low Fuse, Value 0xFF  
                - High Fuse, Value 0x10
                - Extended Fuse, Value 0xFD
                - Write
        Power Off/On Board
        Then I was able to write Repetier Firmware usind the arduino IDE.

    One more information:
    The Bootloader hex file from reprap-Link is not identical to the bootloader,
    which is ceated by arduino IDE when ATmega 2560 is set, and you export the compiled binary file.
    The reprap linked bootloader is part of the arduino V1.8.3, named Mega2560-prod-firmware-2011-06-29.hex,
    but this file seems to be not used (not found in boards.txt).

    Hope this helps somebody else!

Sign In or Register to comment.