RUMBA Unable to upload Marlin firmware or get RUMBA into DFU mode

Hello,

I seem to be having a problem I feel like should be a pretty basic fix, but I am having a ton of trouble with it nonetheless. I am trying to upload my latest version of Marlin to my printer with some basic function changes, but I can't get the RUMBA to respond. The board is currently hooked up to my printer.

The errors I'm receiving are as follows:

avrdude: stk500v2_ReceiveMessage(): timeout
avrdude: stk500v2_ReceiveMessage(): timeout
avrdude: stk500v2_ReceiveMessage(): timeout
avrdude: stk500v2_ReceiveMessage(): timeout
avrdude: stk500v2_ReceiveMessage(): timeout
avrdude: stk500v2_ReceiveMessage(): timeout
avrdude: stk500v2_getsync(): timeout communicating with programmer

I realized I should just be able to whip the RUMBA into DFU mode by putting a jumper on the reset pins as explained on the RUMBA RepRap wiki page. Unfortunately my RUMBA doesn't appear to be moving into DFU mode, as the TX and RX LEDs are inactive after removing the jumper from the pins. Strangely, LED1 is strobe flashing, and I don't know what to do. If I try to upload the firmware I still get the timeout errors and the jumper doesn't send the board into DFU mode.

What can I do to solve this issue?

Thanks,
Sam

Um.... some confusion here.

the ATMega16u4 has a DFU bootloader the ATmega 2560 has a STK500v2/Arduino2560 Bootloader (or should have)

don't short reset out when trying to upload to ATmega 2560, as it stops the usb/serial converter (ATMega16u4) from running.

I am equally confused about my issue!

Thanks for the reply! If shorting the reset out will prevent the USB/Serial converter from running, how can I get my firmware on the RUMBA?

Even when I don't put the jumper on the reset pins, the board won't respond to uploads. All it does is strobe flash LED1.

Thanks!
Sam

Edited 1 time(s). Last edit at 06/11/2018 09:56AM by skc5741.

What is meant to happen is the usb/serial interface is told to set DTR low then high, this resets the ATmega 2560
On reset the ATmega 2560 runs its bootloader, this uses the usb/serial to get new data, if it doesn't receive anything it then runs the installed firmware. (2-3 seconds later)

The only other easy possibility is you may need to move the "usb power/stand alone" jumper onto usb power, this is where the atmega gets is power.

If this doesnt work most likely your suppliers didn't install the bootloader on the atmega 2560, so you have no way to replace the firmware over serial.


You can install one.. if you have a avrisp or a arduino board use as a avrisp.

Its not simple if your havent done it before... but if you can follow instructions we can give it a try,

I've switched the power supply to USB power, and unfortunately that did not solve the issue. What's strange is that I was definitely able to upload firmware in the past without issues, so I'm not sure exactly what changed.

I haven't installed boot loaders before but I believe I can do a proficient job of following instructions, thanks so much! I am running on MacOS, so that may change the upload process. I have Windows machines available if it would be easier to upload firmware from there.

I do have an Arduino board and am willing to use that.

Thanks so much for your help!
Sam

Edited 1 time(s). Last edit at 06/13/2018 10:46AM by skc5741.

So I attempted to follow a tutorial online here, using my Arduino Uno as an ISP for the RUMBA. This is how I connected the Arduino Uno to the RUMBA:


As the tutorial advised, I set the programmer to "Arduino as ISP" and then proceeded to "Burn Bootloader". I only had the Arduino connected to the computer, but the Arduino appeared to be supplying power to the RUMBA as well, as there were some lights flashing. Once I burned the boot loader, I assumed it had worked, as the Arduino software reported "Done burning boot loader", but I noticed during the process of uploading there were a series of errors that the Arduino software reported:

avrdude: stk500_getsync() attempt 1 of 10: not in sync: resp=0x18
avrdude: stk500_getsync() attempt 2 of 10: not in sync: resp=0x98
avrdude: stk500_getsync() attempt 3 of 10: not in sync: resp=0xe6
avrdude: stk500_getsync() attempt 4 of 10: not in sync: resp=0x98
avrdude: stk500_getsync() attempt 5 of 10: not in sync: resp=0xe6
avrdude: stk500_getsync() attempt 6 of 10: not in sync: resp=0x98
avrdude: stk500_getsync() attempt 7 of 10: not in sync: resp=0x1e
avrdude: stk500_getsync() attempt 8 of 10: not in sync: resp=0x98
avrdude: stk500_getsync() attempt 9 of 10: not in sync: resp=0x80
avrdude: stk500_getsync() attempt 10 of 10: not in sync: resp=0x18

I tried to upload firmware normally first, but received the same error I had to begin with. Next I tried to upload using the Arduino as ISP, and still had no luck. What can I do?

Thanks!
Sam

For my RUMBA I managed to solve the issue as follows.

Arduino: 1.8.5 (Windows 7), Board: "Arduino/Genuino Mega or Mega 2560, ATmega2560 (Mega 2560)"

avrdude: stk500v2_ReceiveMessage(): timeout
avrdude: stk500v2_getsync(): timeout communicating with programmer



I know this is an old thread but in my search for a solution for the same problem, I eventually found a solution that no one else seemed to mention so thought I have to post it somewhere in a hope it will help others.

After 2 days of being unsuccessful with the Arduino Software and even with 'XLoader' trying all the recommended steps of reloading software, resetting the Rumba board etc, I had to start thinking outside of the box.

I was positive that I had the correct Board selected and the correct port. I had also loaded the correct USB RUMBA software.

After giving up with the Arduino program, consistently getting the 'Time out" message I then tried with the free program "XLoader" but even here the RUMBA board would sit with the RX flashing every 10 seconds or so and after a very long wait I found that the program had hung up. After rebooting the computer and the board, it got me thinking for other solutions that had not been posted yet.

The answer that worked for me was the following. (Sorry this is a Windows 7 solution but I am sure it will help with other OS's as well.)


Windows - Go to 'Start Menu'
Go to 'Device Manager'
Select the port that is your Arduino/Rumba board (in my case it was Com 8)
Right click on the port and select "Properties"
select the 'Port Settings' tab
change 'Flow Control' from none to "Hardware"


After making the change and reloading XLoader, suddenly all the TX and RX lights on the RUMBA board lit up like November 5th. Oh Joy.

I then went back to the Arduino Program and tested this and it worked as well.

So it seems that the port is trying to do basic flow control hand shaking and this is why the Arduino software eventually times out giving the errors as posted by other contributors to this forum.

The clue that helped me reach this conclusion is that with the 'XLoader' program running, I noted that the RX led on the RUMBA would flash every 10 seconds or so which made me suspect that the board was waiting for something. I can vaguely remember things about 'Clear To Send' and 'Request To Send' from back when using old dial up modems to connect to the world.

I really hope this helps someone else. If it does, please post back here to let others know that it worked.

I had all of these issues.

Interestingly, I was able to solve it by disconnecting the LCD. I think it may be due to power requirements from some of the larger LCDs being too much, and there being an undervolt.

The hint for me was that the screen was coming out with low contrast, and I was reading 3.8V on it (rather than the expected 5 its supplied).

To clarify, I was unable to upload sketches, when I could before. I thought it must be the ATMega16U2 USB decoder at the core like all the posts suggest. I struggeled to get it into dfu mode, and failed and failed. All the above things failed.

I did not try to get into DFU mode, but, simply disconnecting the LCD resolved the power problem and it seems to have uploaded correctly.

I was also considering if initializing EEPROM overwrites something critical, and if this recurs Ill revisit it, but as of now, its working.


I know this is old, but hopefully others will find themselves here.