ATMega16U2 Arduino Mega - Page 1
Forum section: electronics / general

author: Mario87
author_rank: Frequent Contributor
timestamp: November 07, 2019, 12:32:57 am
content: Hi all, I am working on a project based around the Arduino Mega2560. I have just finished designing and assembling the first custom PCB.The PCB uses an ATMega16U2 and ATMega2560 just like the proper Arduino Mega does. All supported components (clock crystals, capacitors, etc) are the same values used on the Arduino Mega.However, I am having an absolute nightmare trying to configure the ATMega16U2! When I connect the USB cable I get nothing at all in device manager, as if it's dead.However I have managed to use my Arduino UNO as an ISP to load the bootloader onto the ATMega2560, and it appears to work fine. The "L" LED binks, and when you hold the reset button it stops blinking until released.I just cannot for the life of me get the USB functionality with the ATMega16U2! I am able to communicate via ICSP and AVRDude. AVRDude sees the IC fine, communicates fine and can adjust fuses, etc over ICSP with no issues, but I am obviously doing something wrong.The commands I am sending are as follows.....First send:avrdude -c arduino -P COM1 -b 19200 -p m16u2 -t -e, this should remove any lock bitsNext send:avrdude -c arduino -P COM1 -b 19200 -p m16u2 -F -U efuse:w:0xF4:m -U hfuse:w0xD9:m -U lfuse:w:0xEF:m -U lock:w:0xCF:m, this should set the fuses, values taken from this thread here...https://forum.arduino.cc/index.php?topic=146049.15Finally send:avrdude.exe -c arduino -P COM1 -b 19200 -p m16u2 -F -U flash:w:Arduino-usbserial-atmega16u2-Mega2560-Rev3:i, this will program the firmware with the one which comes with Arduino IDE.All steps work fine, no errors at all, but when I connect the USB cable I get nothing at all, PC just does not recognise it.Any ideas?

author: JustMeHere
author_rank: Frequent Contributor
timestamp: November 07, 2019, 01:50:18 am
content: Schematic pls.The USB needs the CPU frequency to be set to a very tight window. Make sure your running the chip at a frequency that can be easily multiplied up to the needed USB frequency.Sorry it's been a few years, but I had a similar problem. I think I had to have an 8Mhz external clock. The onboard oscillator could not do the job.

author: andersm
author_rank: Super Contributor
timestamp: November 07, 2019, 05:28:47 am
content: Have you tried the "Arduino-COMBINED-dfu-usbserial-atmega16u2-Mega2560-Rev3.hex" firmware? The corresponding Uno file worked for our custom Uno-based board.

author: magic
author_rank: Super Contributor
timestamp: November 07, 2019, 07:49:37 am
content: Review your board for possible mistakes with regard to:https://www.eevblog.com/forum/microcontrollers/at90usb162-porgramming-without-programmer/msg2768448/#msg2768448Does the Arduino bootloader require the HWB pin to be in some particular state? It probably needs to be either low or high.Did the factory-programmed DFU bootloader work? Does it work if you flash it with avrdude? This bootloader activates if HWB is held low during reset.

author: Mario87
author_rank: Frequent Contributor
timestamp: November 07, 2019, 10:31:16 am
content: Quote from: JustMeHere on November 07, 2019, 01:50:18 amSchematic of how the ATMEGA16U2 is connected shown below....I am using a 16MHz crystal, more specifically, this one....https://lcsc.com/product-detail/DIP-Crystal-Resonators_Yangxing-Tech-X49SD16MSD2SC_C16212.htmlQuote from: andersm on November 07, 2019, 05:28:47 amYes, I have tried the combined FW and it makes no difference.Quote from: magic on November 07, 2019, 07:49:37 amThanks, I have had a look at that link where he says the following...."The minimum circuit for 5V/16MHz operation needs a 16 MHz crystal and its two caps (10 pF, I believe), one 1µF cap from UCAP to ground, 0.1µF and 1µF bypass capacitors (from VBUS, UVCC, AVCC, VCC, all connected together, to ground), and two 22Ω resistors (one between USB D+ and microcontroller D+, and the other between USB D- and microcontroller D-)."I have the 16MHz crystal, but I am using two 22pF caps, not 10pF, I have a 1uF cap from UCAP to GND and I am using 0.1uF caps on VCC, AVCC and USBVCC, but I do not have 1uF bypass caps on these lines also.However, looking at the Arduino MEGA schematic, my layout directly matches their one and it clearly works fine for their usage, so should work for mine also, link to Arduino schematic...https://www.arduino.cc/en/uploads/Main/arduino-mega2560_R3-schematic.pdfI honeslty do not know if the the factory DFU bootloader worked, I never attempted to get it into DFU mode while in factory settings. All I can say is the PC has never, ever recognised the microcontroller.If you can provide a link to the factory bootloader I can give it a try, not sure where to find it.As for the Arduino bootloader, the default setting for the HWB pin (PD7), or as they call it "RESET-EN" appears to be open circuit (low) as they have a solder jumper on the board which is left open.Any further suggestions greatly appreciated!!

author: magic
author_rank: Super Contributor
timestamp: November 07, 2019, 11:02:13 am
content: 22pF shouldn't be a problem. In fact, pretty much any value, including zero, shouldn't be a problem. It only affects frequency and even if clock frequency is completely wrong and even if you swapp D+ with D- the chip should still appear on USB bus, although enumeration would fail.I mean, try it: connect a 1.5k resistor between D+ or D- and 3.3V, you should see a message about "unrecognized device" or something. If you aren't getting even that far, something else is wrong.HWB/PD7 is pulled down by R13 so the chip executes the bootloader upon startup. This should workBy the way, you are supposed to put 22Ω resistors in series with D+ and D-. But it worked without those resistors for me. Maybe try a different cable?Is there any activity from the chip? What's the voltage on UCAP pin? On D+ and D-?

author: Mario87
author_rank: Frequent Contributor
timestamp: November 07, 2019, 11:07:58 am
content: UPDATE:I got it to work!! Turns out the IC was not properly solderedI removed it, cleaned up the pads, resoldered and applied some gentle pressure as it cooled down...boom it appears!However I now have a new issue...When I try to upload a basic "blink" sketch from Arduino IDE I can see the RX light on the board flash periodically, but no Tx, so the board is not responding, then I get the following errors..."An error occurred while uploading the sketchavrdude: stk500v2_ReceiveMessage(): timeoutavrdude: stk500v2_ReceiveMessage(): timeoutavrdude: stk500v2_ReceiveMessage(): timeoutavrdude: stk500v2_ReceiveMessage(): timeoutavrdude: stk500v2_ReceiveMessage(): timeoutavrdude: stk500v2_ReceiveMessage(): timeoutavrdude: stk500v2_getsync(): timeout communicating with programmer"So I am making progress, albeit slowly. If anyone has experienced this new issue any further advice would be greatly appreciated!

author: Psi
author_rank: Super Contributor
timestamp: November 07, 2019, 11:19:36 am
content: Not sure if it's still relevant, now that you can talk to the chip, but the two things i can see are- You seem to be enabling Boot Loader Protection Mode 3 through the lock fuse bits.Messing with the lock bits can have some weird side effects.Best to leave the lock fuse byte alone until the end, once everything is working.Writing 0xFF to the lock fuse byte will keep all locking features disabled (instead of 0xCF)- You are running the low power crystal oscillator in the ATMega.I think that will probably be fine. But the chip does have a full swing crystal oscillator you could try. (CKSEL3:0 bits)

author: Mario87
author_rank: Frequent Contributor
timestamp: November 07, 2019, 12:32:49 pm
content: Quote from: Psi on November 07, 2019, 11:19:36 amOk, I erased the IC which apparently sets the lock bit back to 0xFF as you can't seem to write that yourself. I also added the full swing crystal oscillator option which changed the LFUSE from EF to E7, now I cannot communicate with the IC at all, either via USB or via the ICSP headers???avrdude sees the device signature as 0x000000 (basically not found), any ideas??

author: Mario87
author_rank: Frequent Contributor
timestamp: November 07, 2019, 01:32:46 pm
content: OK.....I got back to where I was!Someone on AVR Freaks had made a sketch for arduino that creates an 8MHz signal on pin 3. I removed the crystal, held the 8MHz clock on XT1 pin and it worked, was able to see the IC and set the fuses back to EFuse: F4, HFuse: D9 & Lfuse: EF, I can see the board in Windows again, but I still cannot upload, so back to where I was 2 hours ago....For my own reference in future, these were the AVR Freaks threads...https://www.avrfreaks.net/forum/does-device-signature-0x000000-mean-atmega-bad&https://www.avrfreaks.net/comment/885850#comment-885850So if anyone has any ideas about not being able to program the 2560?

author: magic
author_rank: Super Contributor
timestamp: November 07, 2019, 04:46:37 pm
content: Maybe some UART pin somewhere is still unsolderedCheck for continuity, make sure you have the right bootloader on the ATmega2560, make sure your programmer uses the right baud rate (it probably should, no idea, never used Arduino stuff).

author: oPossum
author_rank: Super Contributor
timestamp: November 07, 2019, 04:57:08 pm
content: Quote from: Mario87 on November 07, 2019, 11:07:58 amDoes the 'L' LED blink? If it doesn't check the reset circuit. The 16U2 has to reset the 2560 to start the bootloader.

author: Mario87
author_rank: Frequent Contributor
timestamp: November 07, 2019, 05:39:21 pm
content: Quote from: magic on November 07, 2019, 04:46:37 pmThis is embarrasing.... the Tx pin was not soldered on correctly, so while the IC was receiving data it could not communicate back out. Going over the pins with the iron has sorted it, made sure to go over all other pins as well.This was my first project using solder paste & stencils, so a bit of a learning curve. Might look into investing into a microscope as I had a short on that same IC yesterday that could not be seen, was only evident when I removed the IC and the short disappeared....Thanks again everyone! Greatly appreciated. Just ashame the faults were all my own doing

author: Mario87
author_rank: Frequent Contributor
timestamp: November 07, 2019, 06:09:54 pm
content: Ok, so not totally out of the woods it seems!While I can upload the example "Blink" sketch which just blinks the "L" LED on the board, when I go to upload any more substantial piece of code, it times out and fails every time. I also noticed it only allows you to upload once then you need to power cycle to upload again. Could this be a fuse setting issue on the ATMEGA16U2?Current fuses are set as follows.... LFuse: 0xFF, Hfuse: 0xD9, Efuse: 0xF4 & Lock: 0x0F

author: Psi
author_rank: Super Contributor
timestamp: November 08, 2019, 11:28:25 am
content: 0xFF is correct for L=FUSEThat sets the longest startup delay for a crystal 8mhz or higherYou might want to change E-FUSE though.Your current 0xF4 sets the brown out detector voltage to 3.0VFor 16mhz operation you need VCC to be more than 4.5VSo best to set brown out to its highest setting of 4.3V which is E-FUSE = 0xF0Other things to check.- Make sure you have a short clean ground path for the xtal to the GND pin right next to the two XTAL pins.- Make sure you have the C12 100nf cap between the VCC and GND pins as close as possible to the pins.- If you power supply is a bit noisy you might want to also add a 10uF cap between VCC and GND

author: Mario87
author_rank: Frequent Contributor
timestamp: November 08, 2019, 03:37:01 pm
content: Thanks for the info, but I figured it out, just needed to ensure the jumper for the reset enable was connected so that avrdude was able to send the reset command and start the bootloader prior to programming.Without it, it was only possible to program shortly after powering on and while the bootloader was running. Once in full application mode (for lack of a better term) it's not possible to program the IC, so either a power cycle is needed or an ability for avrdude to perform a reset and get into the bootloader for programming.

author: Mario87
author_rank: Frequent Contributor
timestamp: November 11, 2019, 05:27:46 pm
content: Hello again!!Back with another ATMEGA16U2 issue....basically the IC appears to not be working again for no obvious reason. I uploaded some code from Arduino IDE, and while checking stuff on serial monitor and attempting to make changes to the code the Arduino IDE locked up and wouldn't respond. I pulled the USB cable (only partly for some reason) as that sometimes unfreezes the IDE environment (not this time).Anyway, after I sorted the IDE crash I re-opened the software and reconnected the board....nothing! No "Windows detected hardware" sound! I have checked and I can still communicate and program the ATMEGA16U2 via the ICSP headers, everything works except for USB. I even uploaded some code that transmits data to the ATMEGA16U2 constantly, when this occurs the ATMEGA16U2 should light up the Tx LED which is connected to it, but nothing happened.I have tested the code on an Arduino UNO and can see that when the 16U2 receives comms on pin 8, then the LED connected to pin 11 should light up.My gut feeling is something internal to the ATMEGA16U2 has failed, but what is the concensus on here? Anything else I should try before replacing it (need to order one)?

author: Psi
author_rank: Super Contributor
timestamp: November 12, 2019, 09:52:41 am
content: You may be having intermittent programming issues that come and go and thinking that you have fixed the problem by doing Y because it started working. But in fact it just started working randomly because the problem is more intermittent. This has tricked me many times.*Can you post a pic of your xtal/caps pcb section, this area is somewhat more critical when running at 16mhz. 8mhz is pretty hard to screw up but 16mhz can cause problems.*You could also look at changing you 22pf crystal caps to 18pf, perhaps 22 is too high for your crystal.*You could also try removing that 1meg resistor across the xtal, i've never needed that for AVRs and i dont know what other effects it might have.*Try checking the fuse bits are still what they should be.Sometimes if you have programming fails on AVRs the fuse bits can get corrupt during the fail.That could change clock settings and prevent USB.I'm not sure if the AVR chip itself is to blame for corrupted fuse bits or avrdude.exe. But i would put my money on avrdude.avrdude checks fuse bits before programming and after programming to confirm they have not been corrupted. But if the programming connection itself gets corrupted or has comm/signal errors i think avrdude can get confused and try to 'fix' a non-existent fuse bits issue. If there are comm/signal issues the last thing you want avrdude to be doing is messing with fuse bits!I've programming 1000's of AVRs over the years and one thing i have noticed is that if you have intermittent programming issues where programming fails then you are risking getting the AVR into a weird state every time it happens.It's a good idea to stop and fix programming problems instead of trying to proceed with development ignoring the occasional programming issue, this has come back to bite me a few times.I suspect it's something like corrupting undocumented fuse bits used for factory settings, or something like that. I once had a ATmega start running at a clock speed twice what should be possible given the specs in the datasheet. Really weird.That said, ive never used a AVR with USB, so im not sure how relevant that is for them.

author: Mario87
author_rank: Frequent Contributor
timestamp: November 12, 2019, 11:37:21 am
content: Hi, I don't have the board nearby, but I have the PCB design on my laptop. Here are pics of the upper and lower portions of the board respectively....Image of schematic for completeness / to help identify component placement...I can try removing the 1M resistor tonight, but I do not have 18pF caps to use, would need to buy some.The fuse bits never, ever change when I program the IC over the ICSP port, they are always what they should be.This is not an intermittent programming issue in my opinion. The board worked fine for a couple of days and it was only when I pulled the USB and left it half connected in the port that this happened. Prior to that I had power cycled and connected/disconnected the board numerous times without issue. It just stopped suddenly, not during a programming session.The IC and PC would have been in communication as I unplugged it which may have had an effect.From the datasheet it says that when USB Enable is set the device will be detected by the PC (assuming correct bootloader obviously). However when the device is in a reset state USB Enable will not come on.I also CANNOT get the device into DFU mode. To get into DFU mode I should be able to just short the reset & GND connections for a moment, at which time the "L" LED should blink and then go into DFU mode, however when I short the reset & GND the "L" LED does NOT blink and nothing happens.To me it looks like the IC is stuck in a permanent state of reset as per the top of page 190 in the datasheet....http://ww1.microchip.com/downloads/en/DeviceDoc/doc7799.pdfI also do not believe this to be an issue with the physical circuit, as it is a carbon copy of that used for the Arduino UNO and Arduino MEGA, both of which have sold millions with a few ATMEGA16U2 issues, not not every single one (as you would expect from a hardware issue).I have also checked the PCB and all surrounding components. The clock is indeed 16MHz (probed the output, not ideal, but gave a close enough indication), all 5v rails are present, resistors are all the values they should be, I get 5v in on the USB line, I can see on the oscilloscope that the receive line on the PCB gets some sort of data coming in from the USB connection as it is plugged in, but after a second or so it stops, most likely due to no response from the IC.Hope that additional info helps with any other suggestions anyone has?

author: Psi
author_rank: Super Contributor
timestamp: November 12, 2019, 01:53:52 pm
content: It does sound like the chip maybe damaged or locked in a weird state.But that crystal layout is pretty bad. The caps should be within a few mm of the crystal rather than on the opposite side of the chip.Also the pin3 ground pin should have a clear path to the two xtal caps. They provided it next to the two xtal pins for that reason.I'm not saying it wont work like it is, but it's definitely not helping to keep your crystal stable.And a stable crystal is important for USB.(Made single image to make it easier to see)

author: Mario87
author_rank: Frequent Contributor
timestamp: November 12, 2019, 02:32:14 pm
content: Yes, I had someone comment on that already. Admittedly, this was a mistake, I placed them there in a bit of a rush (stupid), ordered the PCB's and realised after the fact it will be fixed with the next revision.However, the board did work fine for 2 days, and when I had a clock issue previously I could not communicate with the IC at all, even over ICSP. However the ICSP works fine at the moment. So while this may not be ideal, it does not explain why it suddenly stopped working.Do you think I may have damaged the IC due to a short or transient when the USB cable was left half plugged in?

author: Psi
author_rank: Super Contributor
timestamp: November 12, 2019, 02:42:59 pm
content: Have you checked the soldering on the USB connector?If it was marginal then plugging/unplugging may have cracked it.

author: Mario87
author_rank: Frequent Contributor
timestamp: November 12, 2019, 03:07:42 pm
content: Quote from: Psi on November 12, 2019, 02:42:59 pmAdmittedly not checked that, but it's a full sized USB-B connector with through hole connections, so I am doubting that is the case, but it is a possibility. Will check it when I get back within the next hour or so.If (for arguments sake) that does not sort it, is there anything else left to try? I was going to upload the stock DFU firmware / bootloader as well from the Microchip website, but after that and the soldering of the USB connector I'm not sure what else to try??

author: Mario87
author_rank: Frequent Contributor
timestamp: November 12, 2019, 04:40:33 pm
content: Ok, I have re-soldered the USB connector and tried the original DFU bootloader from the Microchip website to no avail!

author: Psi
author_rank: Super Contributor
timestamp: November 13, 2019, 06:22:27 am
content: Try a full chip erase. I think it's -e on command lineAlso, while you're doing the erase, check and post what the current fuse bits are.I know you said they have not changed but i just want to be sure. These sort of issues always end up being something silly.Also, another thing to try is a usb hub instead of direct into the PC USB port.I know it sounds weird but i have found PC USB ports to be more critical of usb clock freq than cheap china USB hubs are.So i have multiple times found a USB device to work on a china USB hub but not directly into PC. If this is the case for you it points to a clock issue.

author: Mario87
author_rank: Frequent Contributor
timestamp: November 18, 2019, 07:51:59 am
content: Thanks for the suggestions, I had already tried full chip erase previously to no avail. Fuse bits were as I mentioned previously.... LFuse: 0xFF, Hfuse: 0xD9, Efuse: 0xF4 & Lock: 0x0FI did try various ports to no avail..in the end I decided to swap out the IC. That resulted in good and bad outcomes.Bad outcome: Required pad lifted on the board, so I decided to swap the components over to a fresh board.Good outcome: USB worked instantly with the new IC on the new board, I am convinced it was an IC fault, but as the board was swapped I cannot rule out a PCB issue from previous reworking of the old one.Bad outcome: Since swapping components over to a new board I have 3 issues, 2 of which I believe to be related. I'll briefly post them on here, but think they should get their own thread as they are related to the ATMEGA2560.Basically, the UART Rx on pin 17 of the Arduino Mega (PH0 ( RXD2) on the ATMEGA2560) isn't responding. I have a module connected to it and when I send "AT", I should get a response "OK", but I get nothing. I have viewed it on the scope and can see the "OK" response is being returned and goes into the 2560, but then it disappears....if I solder wired from the module to an Arduino UNO it works fine though!Another issue I have is with SPI communications. When trying to read from a MicroSD card it recognises there is a card in the slot, but it says it can't find a partition. Also, if I try to upload a new bootloader to the MEGA2560 it can read the device signature, but can't upload the firmware.Again, I tried to solder wires from the MicroSD to an UNO, but exact same result. Then I noticed if I have the power enabled for the MicroSD (I installed power switches on all sub-circuits for testing) I found that I cannot even read back the device signature of the MEGA2560.Out came the scope again and I have only investigated while trying to upload the bootloader, but if the MicroSD power is OFF, then the SPI comms goes high to 5v for a short period and as soon as the SCK clock kicks in the SPI comms drops down to 0-2v rather than 0-5v comms. Even more interesting is when I power on the MicroSD the comms NEVER go above the 0-2v range.So that initial 5v burst I am seeing on the scope must be the IC sending out it's device signature, and then for some reason the clock kicking in drops it right down to 0-2v which obviously the UNO (used as ISP programmer) or MicroSD do not recognise as ever going high, so fail due to "no response" when the reality is it's just a "very quiet response".So anyway, that needs more investigation, but I am 50/50 whether to look into it further and spend more time on what is just an initial revision or to just spend the money on new parts (not alot) and build a fresh board from scratch, as these issues only came into play after swapping parts over from a damaged board to a new board, so something has gone awry in that process.I have screenshots of the SPI comms from the scope, but like I said, think this needs its own thread and I don't have them to hand.

author: maginnovision
author_rank: Super Contributor
timestamp: November 18, 2019, 08:09:45 pm
content: Can you post a decent picture of the actual board? Seems like the first one was bad soldering and you probably ruined it trying to fix it. It's good to rule out the original error. Could you also post exactly the same version full board layout?