Go Down

Topic: 2560 upload problems... (Read 1 time) previous topic - next topic


I had good experience for two days programming "Hello World" expansion in Atmel Studio using TinyUSB PRG. Also programmed sketches via USB.

Third day,, nothing. All connectivity gone, except that Windows Hardware reports the presence of USB device as the Arduino 2560.

I have three programmers: USBtiny, ATMEL ISP MKII, and Mikro Flash PRG.

Late in second day I think I tried reading and writing the MEGA16U2 firmware. Have tried several times since to replace the 16U2 firmware. Have 2560 bootloader and blinking LED. AVR DUDE reports ERROR 1  and gives "C8" as unexpected status.

Have now read ONLINE posts and made a change to the BOARDS definitions file "wiring" in protocol. Will go and try it.

TinyUSB was working perfectly, had a very positive expereince in Atmel Studio.

This is frustrating, seems to need more support. Part of my problem is being off-grid, disconnected from the community.


Reinstalled the driver, actually by updating it.

After losing serial USB communication with my 2560 r3 Arduino it is fixed.

System Hardware reported the device as working properly. Still there was no USB communication. This after uploading both the bootloader and firmware files via the AVRISP MKII programmer in Atmel Studio.

Earlier, I read information explaining one of the firmware files as explicit for MAC or Linux OS. Thus, I gained confidence in selection of the serial version for my R3 board with MEGA16U2 USB interface device. The appropriate STK500_V2_MEGA2560 boot loader file is a bit more obviated. I loaded it into the 2560 via ISP. Result was blinking LED as before.

I tried to upload a simple sketch, no success.

I thought about this, recalling how in Atmel Studio terminal window the connection appeared looped, echoing back all transmissions. I decided again the problem must be on the PC side.

I opened the XP control panel and the SYSTEM application selecting Hardware Device Manager. At the top was the USB 2560 Arduino. I opened it and selected to update the driver.

When the update application opened it asked whether I should let it install automatically. I selected NO, and located the INF file in the DRIVERS folder of the 1.52 Arduino installation. The update application took awhile to peruse the file and finally decided to make a Windows SYSTEM RESTORE point before updating the DLL into the system32 folder. It completed the process.

I reopened the minimized Arduino sketch window and compiled the file. It uploaded without an error for the first time in two weeks. No problem. Voila! Fixed.

Steps: A. Upload correct 16U2 firmware file (serial for Windows) B. Upload STK500_V2_2560 boot loader.  3. Update the Windows driver using Control Panel/Device Manager to select the Arduino USB device which is reported by Windows as working, but isn't.

Big symptom was the looped terminal. Windows was apparently echoing all transmission. It appeared the 16U2 was doing it, however no blinking TX-RX LEDS. The board identified itself to Windows properly... which seemed very strange but convinced me nothing was damaged.

I am learning that almost everything needed for is there in the installation ZIP and folders. However, I am having trouble getting the 16U2 firmware to compile...


Slowly, I may be coming around to realization that the pseudo-C language presented in Arduino is compromising effort to invigorate AVR development by way of a friendlier language than C which seems to have too many inherent features that cause people to drop it.

I learned some assembly, then Pascal, then some Perl, HTML, Javascript, then quite a bit of Visual Basic. By that time, I was burned out and have resisted learning C ever since. With my existing background, I relate everything to the new language looking to isolate examples that work.

Am encouraged at having ability to reinstate factory code and have it all work.

Am looking for the needed LUFA files in the firmware C-build, interested in a bit-banged USB as in Atmel AN309 2313 example. Could figure out how to send/receive bytes in ASM... give me an AVR in a package I can socket or actually solder for building my own small-scale producible device.

Go Up