I have copied the Arduino Mega 2560 R3 reference design into my own project. I had PCBs made from this. I loaded the bootloader from an Arduino Mega2560 R3 into my bootloader. When I plug in USb to my PCB, it is not recognized at all by my PC.
Attached is a schematic of my PCB in Eagle Cad.
The USBVCC signal does not connect to +5V on my PCB. I supplied that separately so the whole PCB had power during testing.
I would appreciate any help on this.
Thank you,
Tim.
Control PCB.zip (151 KB)
Did you program the firmware into the 16u2?
In copying the hex file from an existing 16u2 on an arduinio mega 2560 R3, wouldn't I have accomplished that?
I am a complete newbie at this so, please feel free to tell me if I am incorrect.
I have a mySmart USB light programmer which I can used to do the transfer of the hex file. The software I used to do this was BASCOM in its manual programming mode.
After further testing, I found that the image did not copy properly from the arduino Mega 16u2 to my 16u2 on my PCB. Back to the drawing board. Trying to figure out how to install the firmware into an arduino mega to see that I have the process right using my programmer. Then I will install it into my PCB.
My only significant experience with the Atmel microcontrollers has been with BASCOM and ICSP programming. Using a bootloader is new to me. I have done so on the arduino mega 2560 but never had to install a bootloader before.
I can't find an optiboot .hex file for the Arduino Mega 2560 R3. Can someone point me in the right direction? I don't know how to make one using the make file.
Thank you!
In copying the hex file from an existing 16u2 on an arduinio mega 2560 R3, wouldn't I have accomplished that?
Yes, but you only mentioned copying the bootloader. Both the 16u2 AND the 2560 need to have code installed on them ("firmware" and "bootloader", respectively), via different ISP connectors.
I can't find an optiboot .hex file for the Arduino Mega 2560 R3.
Official MEGA boards do not use Optiboot. They use "stk500v2" from, say: .../hardware/arduino/avr/bootloaders/stk500v2/stk500boot_v2_mega2560.hex
The is Optiboot for 2560 - you can find many pre-built .hex files as part of MegaCore, such as (MEGA compatible) MegaCore/avr/bootloaders/optiboot_flash/bootloaders/atmega2560/16000000L/optiboot_flash_atmega2560_UART0_115200_16000000L_B7_BIGBOOT.hex at master · MCUdude/MegaCore · GitHub
Hi westfw. I sent you a PM.
Thank you your last response. The sentence "Both the 16u2 AND the 2560 need to have code installed on them ("firmware" and "bootloader", respectively), via different ISP connectors." gave me the missing clue.
I use the mySmartUSB light programmer. BASCOM supports this programmer directly. It has a really cool feature. You can turn on 5V or 3V to supply the target PCB. I use BASCOM (BASCOM-AVR - MCS Electronics) for all my normal work. In the Manual Program part of BASCOM, there is a menu: Board -> MyAVR -> Voltage. Set 5V or 3V here.
Then Board -> MyAVR -> Board Power -> Turn On or Turn Off.
I added the mySmartUSB light programmer to the programmers.txt file for the Arduino IDE by adding these 3 lines to: C:\Program Files (x86)\Arduino\hardware\arduino\avr\programmers.txt
mysmartusb.name=mySmartUSB light
mysmartusb.protocol=stk500v2
mysmartusb.communication=serial
I then connected the programmer to the ICSP header for the ATMEGA2560 and selected Burn Bootloader. That took care of the bootloader part.
I then downloaded the firmware for the 16u2 from here: ArduinoCore-avr/Arduino-COMBINED-dfu-usbserial-atmega16u2-Mega2560-Rev3.hex at master · arduino/ArduinoCore-avr · GitHub
I used the Manual Program part of BASCOM to read the hex file and program it to the 16U2 using the ISCP header for it.
Now, it is recognized by the PC!
Well, I spoke too soon. It makes the sound like it should when I plug in an arduino to the computer, but it does not show up as a serial port like the other arduinos do. Back to the drawing board.
Checked and corrected lock bit. Still no joy.
Copied hex file from Arduino Mega 2560 R3 16u2 chip again. Programmed that hex file to my 16u2 and it worked correctly. Thanks for everyeone's help.
I'm glad you got it working. Did you figure out what had gone wrong with your initial attempts, or did it just happen to work when you tried again? Fuses, perhaps?
In theory, the 16u2 has a bootloader as well as firmware, and I'm not sure where that bootloader lives, or the best way to get both of them into the 16u2, so your strategy of copying from the working MEGA chips was probably a good idea.
I learned some interesting stuff in doing this process. I had to program the microcontrollers before they would accept a hex dump and work as they are supposed to. I use BASCOM.
So, I made a program to blink an LED on the 16u2 and the 2560. In those programs, I added a line to set the Fuse and Lock Bits for each microcontroller. After programming that code and watching the LEDs blink on each chip, I was able to move forward.
I never could get the 16u2 to work with the Arduino-COMBINED-dfu-usbserial-atmega16u2-Mega2560-Rev3.hex file. So, I copied the hex from a working 16u2 on an Arduino Mega 2560 R3 and saved it to a file. I then put that into the 16u2 on my PCB using BASCOM's Manual Program screen.
I then used the Burn Bootloader function of the Arduino IDE to get the 2560 to behave.
I did all the chip programming using my smartUSB light programmer.
My earlier problem was that I did not know that the bootloader had to go in the 2560. I was trying to put it into the 16u2. Thank you again to westfw for setting me straight on that. With that clue, I began searching the internet for how to do both parts correctly. With my new untested PCBs, there was always doubt as to whether the problem was with my hardware or the software implementation until it all worked.
Good job! You did pretty much all of the things I would have suggested, if I would have written it up faster (including the whole "program the 16u2 with a blinky to make sure the process works and the clock fuses look right.")
It's not too surprising that BASCOM doesn't like the "combined" .hex file; it would have non-contiguous segments of code, which is pretty unusual.