Bootloading ATMega328p-AU SPI issue

Thread Starter

Sam Matthews

Joined Jan 16, 2016
178
Hello guys and girls, hoping someone can shine some light on my following issue.

I have created my PCB, the brains/microcontroller being a Atmel ATMega328p-au, and among everything else on the board i have included a SPI header to burn the bootloader through, well what i planned to do anyway. I've got everything soldered up (what i think is correctly anyway), i've tested all the SPI pins for continuity and they all match their supposed pins on the Mega, according to the datasheet on Atmel's site. I'm using a command prompt to test the connection to the board using avrdude.exe. I've got the drivers installed for my USBasp programmer, that is working fine, however i'm getting the following error when i execute "avrdude -p m328p -c usbasp -B 50":

Code:
avrdude: error: program enable: target doesn't answer. 1
avrdude: initialization failed, rc=-1
         Double check connections and try again, or use -F to override
         this check.
I have attached the Eagle files for my PCB and Schematic.

Looking forward to troubleshoot with you guys.
Thanks in advance,
Sam.
 

Attachments

nerdegutta

Joined Dec 15, 2009
2,684
Hi, and welcome to AAC.

Instead of posting a zip file, it is better to use Eagles inbuilt export function. Both on the schematic,and the board. Furthermore, upload a picture of your soldered PCB. Then we can start talking.

:)
 

Thread Starter

Sam Matthews

Joined Jan 16, 2016
178
I'm sorry about linking a zip file, i will get that sorted right now for you. How would you like these files to be exported, as images or?
 

Thread Starter

Sam Matthews

Joined Jan 16, 2016
178
Here you go, I could only export it as a .png, if you have any issues with this please let me know and I'll crack open Photoshop to make jpgs for you. On the board image you can see a hairwire from the center battery pad, i have sorted that out with a external wire acting as a jumper to the vcc pad on the 'nRF24L01' header section in the bottom left. That then feeds to the mega. I have also included GND planes on top and bottom layer.
brd.png sch.png IMG_7098.JPG IMG_7099.JPG
 

Thread Starter

Sam Matthews

Joined Jan 16, 2016
178
You really feel that the caps are too far away? We're talking probably 13-15mm away from the uC. I'm pretty sure i don't have any solder bridges. I'm almost certainly confident i have no bridges on the controller itself and the only other place i would have bridged is under those 2 47uF caps. Other than that, i'de be happy to say i'm certain there are no bridges.
 

Thread Starter

Sam Matthews

Joined Jan 16, 2016
178
Those are mighty close compared to mine. Maybe you have a point with that comparison then :(

Those caps are there as i was advised to have some randomly placed 0.1uF's to act as smoothing caps in places along the circuit. They actually advised me to just have the footprints there, in case i needed some smoothing caps later on, but i just populated them to save me doing it at a later stage. Are they pointless in your eyes?
 

Thread Starter

Sam Matthews

Joined Jan 16, 2016
178
I breadboarded this circuit/setup using a arduino nano, then i jumped from that into this and i thought that the form factor of the mega i needed to use was surface mount (different pinouts to the DIP one) so i assumed it would be time wasting by breadboarding with a DIP when i couldn't use that in practice. The code that i propose to install works a treat, just this hardware issue. I think i may have to get a DIP and breadboard it even with the pinout differences.

I ordered enough components for a few boards, do you think i should try another without those caps to try and eliminate the chance of solder bridges that i can't see (If i have made some by accident)?
 

nerdegutta

Joined Dec 15, 2009
2,684
If you inspect your nano, I'll bet you'll see caps close to the uC. Guess it also has a crystal...

If it works with the nano, a first version prototype might be using the nano on a PCB with female pin headers, so it fits nicely. :)
 

Thread Starter

Sam Matthews

Joined Jan 16, 2016
178
Then 2 other versions before i get to the final version to work as i have now? Even what i have now its very tight on space where it is to be installed. So, every change you make you would implement a new version/revision of the board?
 

nerdegutta

Joined Dec 15, 2009
2,684
If it's already tight on space, then you just have to redesign your schematic and PCB. Go over all connections from the Nano to the breadboard and to the other peripheral components. Unless you are a wizard with the soldering iron and cut some traces to squeeze the caps closer to the uC, you'll need to do it all over.

Inspect the Nano, ans see where the res, caps and x-tal are connected. You'll have to duplicate that in you schematic. You don't need the FTDI and the micro USB, I think. All the circuitry on the Nano is there for a reason.

I'm sorry.

But on the bright side: Draw your new schematic, and design your PCB, and upload it here before sending it to a board house. Then the members here can check it out.

Perhaps other members have any other suggestions or comments? (For your sake, let's hope I'm wrong, and that some guy glides in from the right and say do this, that and the other and you'll have a working PCB).

Anyone?
 

Thread Starter

Sam Matthews

Joined Jan 16, 2016
178
Its all part of the learning curve that I'm here to experience. I do not get hurt or let it get me down when i make mistakes that cost money and a lot of time. That is part of becoming a skilled person in the areas that you focus on. I will get comparing a nano to my circuit now and see where about the caps are. I will then make changes as and where needed and upload here. I'll have a little look over it now and report back with some feelings on where i went wrong to see if you agree or disagree as I'm still very very new to this.

In the mean time if anyone else has any suggestions to my current PCB then please, do not hesitate to inform me of your thoughts.
 

Thread Starter

Sam Matthews

Joined Jan 16, 2016
178
Good morning, I've been working away this morning at revising my schematic, time to move onto the board itself now. As i'm designing and mapping out the board, could you just give this a quick look over for my board please, do you feel its in working order?

I have the 3 caps as decoupling caps across the VCC and GND inputs, should bridge VCC and GND on every VCC pin for the uC or every VCC line that goes into the uC from the battery? Or could I run the VCC line from the battery (through a smoothing cap, 47uF) into one of the VCC pins on the uC, bridge to GND with a 0.1uF cap, and then run from that pin to the other VCC's without any other caps?

While designing my board, I will attempt to have all the caps and the pullup resistor as close as i can to the uC rather than being close to the header.

If I'm not explaining myself clearly enough for you to understand please, don't hesitate, to tell me.
Thank you for your continued help,
Sam.

schRev2.png
 
Last edited:

nerdegutta

Joined Dec 15, 2009
2,684
Good morning!

Should c9 be rotated 180 degrees, with the + leg to VCC?
A 0.1uF ceramic cap on the FTDIs GND and VCC is missing.
Doesn't the uC need a crystal on PB6 and PB7, uC pins 7 & 8?

What are the power requirements for the NRF-24? Does it work well on a 3v coin cell battery?
What will the current consumption to the circuit while operating? I suspect the 3v battery is not enough.

I might be wrong. :)

I think you should be able to edit you post. Have you tried to log in directly to this site?
 

Thread Starter

Sam Matthews

Joined Jan 16, 2016
178
Firstly, soon as you posted that reply I'm able to remove my previous post, so that is all cleared up now.

C9 - You're correct indeed, that was like that on Rev1 too, I think. I will investigate that further once I applied the change to Rev2.
FTDI Cap - Right okay, of course, that will be leading back to the uC itself, is this the reason we need a cap there to protect the uC from the VCC from the FTDI Adapter when updating software? Presumably that would be required to be close to the uC in this case too then, right?
Crystal - I'm choosing to run this off the internal oscillator that the Mega328p has on board, to reduce power consumption. It is not needed to be fast, just the internal will do, according to investigation/research done into the use of this board.

Power requirements for the nRF - Absolutely no higher than 3.3v.
Current consumption - I'm hoping to get it down to around 0.142 mA. Planning on having the board go into a sleep mode when its not being used. I'm hoping that in the future, I can get it linked to the mains, however that is nowhere near yet, i will not be attempting any of that until I actually know what I'm doing.

What are your thoughts about my caps on the VCC line, do i need all 3 on the 3 VCC inputs for the uC, or would you advise using one and then from that pin of the uC, route to the other VCC pins on the chip, therefor removing the need for the 2 caps (and more importantly, lowering the board footprint).
 

nerdegutta

Joined Dec 15, 2009
2,684
FTDI cap as close to the pin header as possible.
Running on internal osc saves both current and space, but it has to be considered. Good call. :)
For the nRF... How much current does it use when transmitting?
I'd place one cap on each powerpin, ref my picture.
 

Thread Starter

Sam Matthews

Joined Jan 16, 2016
178
Oh, the cap has to go close to the header, not the uC o_O - Is there anything referencing why or could you explain in your own words, that is not what I would have assumed. I want to learn more about why that is. I was going to use the first working board to test if the internal oscillator was quick enough, if not I would then revise another version including a crystal.

For the nRF data, here is the datasheet. Please refer to page 14 for the power consumption.

I will put a cap on each VCC pin then, thank you for advising that, better to be safe than sorry :)
 
Top