Hello, I'm new to this forum so my apologies if I'm posting this in the wrong place. I've made a custom arduino pro mini for my research project, and have been trying to upload code to it. In a previous design, I found that it sometimes worked and sometimes got stuck on uploading. I realized that I had forgotten to include a 10k resistor between RESET and VDD, which I assumed was causing the issue. I've made the change and am now finding that it gets stuck on uploading every time.
I'm using a sparkfun 3.3V FTDI header to upload the code and have verified all of my connections. I'm using the ATMEGA328P at 3.3V and with a 8MHz oscillator. I've also verified that my code isn't the issue by running it on a commercial arduino. My connections for uploading are as follows: FTDI GND -> custom GND, FTDI CTS -> custom GND, FTDI 3.3 -> custom VDD, FTDI DTR -> custom RESET (through 0.1uF cap), FTDI RX -> custom TX, FTDI TX -> custom RX. I'm fairly confident in all of my connections because I've made no changes (with the exception of adding the resistor between VDD and RESET) since my previous design, which worked at least some of the time.
I checked the DTR pin of the FTDI header with a multimeter, and it is VDD at idle and drops to GND during upload, and stays at GND until upload fails (after about a minute). I'll share an example of the error message I get, although the actual resp value seems to change depending on my upload attempt.
avrdude: stk500_recv(): programmer is not responding
avrdude: stk500_getsync() attempt 1 of 10: not in sync: resp=0x63
avrdude: stk500_recv(): programmer is not responding
avrdude: stk500_getsync() attempt 2 of 10: not in sync: resp=0x63
avrdude: stk500_recv(): programmer is not responding
avrdude: stk500_getsync() attempt 3 of 10: not in sync: resp=0x63
avrdude: stk500_recv(): programmer is not responding
avrdude: stk500_getsync() attempt 4 of 10: not in sync: resp=0x63
avrdude: stk500_recv(): programmer is not responding
avrdude: stk500_getsync() attempt 5 of 10: not in sync: resp=0x63
avrdude: stk500_recv(): programmer is not responding
avrdude: stk500_getsync() attempt 6 of 10: not in sync: resp=0x63
avrdude: stk500_recv(): programmer is not responding
avrdude: stk500_getsync() attempt 7 of 10: not in sync: resp=0x63
avrdude: stk500_recv(): programmer is not responding
avrdude: stk500_getsync() attempt 8 of 10: not in sync: resp=0x63
avrdude: stk500_recv(): programmer is not responding
avrdude: stk500_getsync() attempt 9 of 10: not in sync: resp=0x63
avrdude: stk500_recv(): programmer is not responding
avrdude: stk500_getsync() attempt 10 of 10: not in sync: resp=0x63
avrdude done. Thank you.
Failed uploading: uploading error: exit status 1
Please let me know if there is any more information which I can share that would be helpful! Thank you.
Almost all of the required information is missing, so have a look at the "How to get the best out of this forum" post for advice. It is linked at the head of every forum topic.
The minimum would be a complete schematic of your design plus a photo of the setup, what you have done to test it, and why you think it should work.
As far as my setup, here is a photo which should have everything you need. I also explained the connections in words above. Please note that the 0.1uF capacitor between RESET and DTR was removed for testing purposes and isn't in the photo above, but was used during my attempts to upload that I describe here.
So far, I've done a lot to test it. This is only the newest iteration of the design. In the past, it was very inconsistent whether the upload would work or not, which I attributed to missing the 10k resistor between VDD and RESET. However, once I added this resistor it seemed to always get stuck on uploading instead of just intermittently. I've tried using a multimeter to check the voltages of the DTR and RESET pins, I've also tried to manually tap RESET to GND during the upload process, which didn't work.
I think that this SHOULD work because it has in the past, and I think that my design has all of the necessary components from the commercial arduino pro mini. With that being said, I'm obviously missing something, but am not sure what it is.
I'm using the arduino IDE and using a commercial arduino pro mini as ISP to burn the bootloader. I've been using a different circuit version to burn the bootloader onto the chip before soldering it to my current design, and haven't had any issues in burning the bootloader.
I did not use a schematic capture system, I made that design myself by hand in Rhino. I'm sorry that what I shared was useless. Do you need the pin numbers corresponding to the ATMEGA328P connections? It seems to me that what I shared has the other relevant information although I could be missing something.
I'm not entirely certain what you mean by which bootloader I burnt, but I can tell you what I did. I selected the board 'arduino pro or pro mini' and the processor 'ATMEGA328P (3.3V, 8MHz)'. Based on a quick search that means I think it was the Optiboot bootloader. Hope that answers your question.
Schematics are the universal way to understand an electronic circuit. Translating any form of physical layout involves people in either trying to translate it in their head or the very time consuming reverse engineering approach. This is too much to ask for a forum member to do.
It is very much like posting code as a screen image and expecting some one to type that in to try your code. It is simply not going to happen on a forum of any sorts.
Did you have an Arduino like a UNO R3 acting as a programmer? If so you need to put into it the the code to do act as a programmer. Then you need to disable the auto reset on the board by either a switch on the input port or a large capacitor on the reset line. Only then can you burn into your processor a bootloader, from the IDE menu options.
Yes that is what I wanted to know.
The only thing I can see that could be a problem, is that the crystal is not oscillating.
Have you used the same crystal in other designs that worked?
How did you select the capacitor values for the crystal?
Hard to tell from the picture, have you looked closely through a magnifier to make sure no pins are shorted on the processor, particularly on the side nearest the strain gauge?
I haven't checked every pin, but I did desolder and resolder the ATMEGA328P since I was worried it might be a contact/short issue. I can double check when I'm back at work tomorrow.
I have used the same crystal in my other designs (which worked intermittently). I picked the capacitor values based on what the crystal I purchased had listed. The 8MHz crystal I used said that it required 18pF capacitors, which are what I used.
Regarding programming the board, I used a commercial arduino pro mini to act as a programmer. In all of my designs so far I've had no issues with burning the bootloader and the fact that my uploading worked (intermittently) in previous designs makes me think that the bootloader isn't the issue, but I could definitely be wrong. As far as the schematic, I can share the schematic which I based my design on.
You're absolutely correct, my mistake. I'm taking another look into this now, but it does look like I should be using higher capacitance values (22pF?). I appreicate the help, this seems like it could be the cause of my issue. I'll make those changes early this week and can let you know if that fixes things. Thank you!
The crystal circuit should be close to the 328P with short traces.
If there is no ground plane underneath, then the stray capacitance may be very small, so you may need larger capacitors.
Hello, I tried replacing the capacitors connected to the crystal oscillator and I'm seeing the exact same upload behavior as before. I ended up using 27pF capacitors. I also removed and resoldered my main chip, which did not help either. Any guidance of what to try next? I'm happy to provide any more information that is needed.
