328p burning board

Using Arduino Project Guidance
#1

I made a bunch of custom projects based on Atmega328p TQFP MCUs. Always use Nick Gammon's bootloader method from here (Gammon Forum : Electronics : Microprocessors : How to make an Arduino-compatible minimal board). On my boards I always ad ICSP header and use Arduino Nano for programming. Never a single issue.

It is time to move on from ICSP header, to not include it at all on my design. For that purpose, I need to burn the bootloader different way. Idea is to have a board with Atmega328p on it which will burn the bootloader. Besides that MCU, there should be sockets for both DIP and TQFP MCUs. Board is here, but not works as expected.

Here is the schematics.

1171×828 61.9 KB

Here you can see the main MCU U3, which works as expected, I think. I can upload a sketch on it through the P1 header. There is a LED on pin 13 which can blink, etc. I don't think there is a problem with that part. U4 header is an ICSP header which I used to burn the bootloader on this Atmega328p.

U5 is a 4 DIP switch to disconnect SPI lines from the programming MCUs and SPIs from two sockets. When off, I can upload a sketch safely on this MCU.

The second part of a PCB is two sockets with shared components. I made it this way because I never intend to put two MCUs at the same time.

It looks ok on my PCB, but, not good enough.

When I upload the Atmega_board_detector on U3 with DIP OFF, it is ok. When I disconnect it and put DIP ON, to make U3 communicate with U1 or U2 serial shows that it can not enter programming mode. Which say or there is no MCU, or wiring is bad.

Funny thing is when I use the same Nano and connect its SPI by wires with SPI on DIP socket directly, I can program TQFP MCU on the second socket. With DIP switches off.

Here is the actual picture of the board.

4608×2240 324 KB

I am sorry for the text wall. If need more info, please let me know.

#2

Have you tried with reduced spi clock? e.g. avrdude -B 10 .... ?

#3

To even detect MCU on one of the sockets? Nope.
I just use the sketch as it is. I can upload it here if you want to check it out.

I can always use Nano, with wires connected with the DIP socket to program TQFP socket 328p. But it is not what I want to make. :slight_smile:
To make this 328p do its job, that is the goal.

#4

Try a Pololu USB ISP programmer.

You can easily slow it right down.

Works when other programmers do not.

Down side is that the programmer costs as much as £10.

#5

Any idea about what is wrong with my schematics? Or how to troubleshoot some bad soldering? How to check why U3 Atmega can not comunicate with two in sockets?

#6

who_took_my_nick:
It is time to move on from ICSP header, to not include it at all on my design.

Why? :roll_eyes:

#7

Where do you have the RESET lines for the programming sockets wired to? From the schematic, it looks like they connect to the RESET on U3 through the DIP switch.

Its a bit late now, but wouldn't it have been a bit easier to just put a nano board onto your programming board, instead of mounting the surface mount U3 and having to use an external USB to serial adapter?

#8

who_took_my_nick:
It is time to move on from ICSP header, to not include it at all on my design.

I also ask WHY?
ICSP is InCircuitSerialProgrammer, why don't you want to simply program your controller incircuit?
All the hardwork is done...
What does your project actually do, what is the application?
Did you protoboard it before going to PCB?
Tom... :slight_smile:

#9

who_took_my_nick:
It is time to move on from ICSP header, to not include it at all on my design. For that purpose, I need to burn the bootloader different way.

Agreed, this doesn't make sense.

Moving on would to me mean dropping the FTDI headers instead. Then you don't need to burn the bootloader (well, it's what you have to do to set the fuses of a chip even if there's no actual bootloader uploaded). ICSP works well and is simple (I use the USBASP programmer to make it super simple), and the bootloader doesn't do anything good on an embedded project anyway.

If you want Serial debugging, just add a 3-pin header. Tx, Rx, Gnd. In fact you may not even need to break out the Rx line if it's for debugging only. Just two pins for that.

I wonder how you even think to get the bootloader on the chip (required for FTDI) without having ICSP available!

#10

Landing pads are how you add a programming port to a PCB when you don't want a header. Pogo pins in a programming jig connect to the pads.

#11

I design the header in as 2x3 2.54mm THT part, then just don't populate it, giving me a group of 6 holes. Makes holding those pogo pins in place a lot easier (I don't have a jig for that, just press it on by hand).

This doesn't even have to take much space, as it may fit under another part.

#12

@All
I want to exclude the ICSP header from a project by making it more compact. If I need a board that will measure temperature and prints it on the OLED screen, why should I need an ICSP header? If I have burned bootloader, ICSP is only taking the space. It will be programmed once, maybe a few times more, but that's it. That is why I have a programming header. Put an MCU on the burner board, burn the bootloader, solder it on PCB, and upload the sketch. To me, it is much easier to do it this way. I am not sure why should I include the ICSP? Maybe I am wrong...

@David_2018
Yes, RESET lines from the sockets goes through DIP switches to a U3 MCU. If needs, I can upload Gerber files.
Why I didn't use Nano? Well, I like to use barebone MCUs as much as I can. But if I use it on this kind of board, you think I wouldn't have this problem? The MCU is trying to communicate to another MCU, this way or another. It CAN communicate but between two sockets, as I mentioned in my first post.

@TomGeorge
Yes, I will use this board to burn the bootloader. Only.

@wvmarle
Sorry, I didn't quite understand your question. On this board, I have ICSP for U3 MCU. For sockets, I don't need it. I will use U3 to burn bootloader to MCUs on it. On PCBs where I will use MCUs with burned bootloader from here I don't need ICSP because the bootloader is burned already. USBASP is a nice tip. Thank you.

Now, aside from the point do I need ICSP on my PCBs or not, and shouldn't I had to use another approach, I would like to hear from you why I can not burn the bootloader from U3 to other sockets. Is there any problem with the schematics? Maybe some shared lines are in conflict? Maybe those LEDs are making the problem on SCK lines? Maybe DIP switches are causing the problem?

What should I check? Should I unsolder LEDs? Should I take a beer?

I appreciate all the help from you, and any suggestion is welcomed. But, now, I just want to make this one work. :slight_smile:

Thanks.

#13

From the schematic, it looks like you have the RESET pin of U3 (the atmega328 being used as the programmer) connected to the RESET pin on the programming sockets (going through the DIP switch). During programming, the RESET of the target processor is driven from an I/O output of the programmer, I do not see this connection.

#14

who_took_my_nick:
I am not sure why should I include the ICSP?

You dont need to include ICSP as such, its always there.

There are push on ICSP adapters with spring pins that you hold in place over the TQFP 32 package on the PCB so its easy peasy to reprogram the bootloader.

#15

If you want to make your PCB small, why are you still using those bulky DIP packages and sockets? The same chip in TQFP package + ICSP header takes way less space than just the DIP package.

I didn't know about those push-on adapters, that's mostly interesting for production runs I think. Where it's really program once and done. For your case it may also work; and you can again drop the FTDI header, that's anyway redundant if you have ICSP broken out.

#16

david_2018:
From the schematic, it looks like you have the RESET pin of U3 (the atmega328 being used as the programmer) connected to the RESET pin on the programming sockets (going through the DIP switch). During programming, the RESET of the target processor is driven from an I/O output of the programmer, I do not see this connection.

Sorry, I am not sure I follow you well enough.
To burn the bootloader I need 5V, GND for power and SCK, MISO, MOSI and Reset for SPI connection. Right?
When I connect my UART adapter to the P1 programming header, I get 5V and GND to two sockets. I checked it and it is ok. With DIP switches ON (U5 Slide Switch), I pass MOSI, MISO, SCK and Reset to the sockets. There is a net port "reset" on U3 and the same on the DIP switch. From there goes net port "resetOut" to sockets.

Maybe I miss something.

And guys, I do appreciate the help. Any kind of help. But, the board is as it is. DIP socket is just an addition to the board. The main usage form this board is to burn the bootloader to TQFP. Can you just forget the DIP socket?

Is there any way to check which of SPI lines isn't ok? I checked it with a multimeter and it looks ok.

#17

who_took_my_nick:
Maybe I miss something.

I still don't get why you're so dead set on burning a bootloader in the first place.

Is there any way to check which of SPI lines isn't ok? I checked it with a multimeter and it looks ok.

Measure more carefully. Don't put any significant pressure on the chip pin when measuring the connection, as just that may make the connection in a poor solder joint, making you believe the connection is sound when it isn't.

Look at those connections very carefully under a magnifying glass, make sure all solder joints are proper, and at the slightest doubt get out your soldering iron or hot air gun and redo the joint. Soldering iron with small tip works wonders for those 0.8mm pitch TQFP parts.

#18

Thank you. I will try it.

I assume you think schematics is ok.

#19

Nothing obviously wrong but I didn't go through it in detail. I do assume you double checked the correct pins on the MCU and so before building the PCB. As long as you go those right, it should just work.

The times I've had problems with ISP programming it always turned out to be a soldering issue. Not enough solder under the pin so it wasn't connected; sometimes also had too much solder under a cap (0805 size) causing a short - so had to undo a dozen or so decoupling caps to find the offending one... and solder them back on. Solder bridges between pins of the TQFP packages are anohter common problem. Tedious to solve, but since I started using stencils more often than not getting it right the first time. Hand assembly - SMD where I can, THT where I must - usually limited to connectors where you need the physical strength.

Just built 10 PCBs tonight, with an ATtiny84a MCU, ISP header for programming - not populated, just using pogopins. 10 out of 10 working beautifully. Burn bootloader to set the fuses (by default 1 MHz internal oscillator - change to 8 MHz), upload sketch, done.

#20

who_took_my_nick:
Sorry, I am not sure I follow you well enough.
To burn the bootloader I need 5V, GND for power and SCK, MISO, MOSI and Reset for SPI connection. Right?

RESET, to the target processor, needs to be controled by the Arduino doing the programming.

The Arduino as ISP program normally uses pin 10 on the programmer Arduino connected to RESET on the target.

Do your schematic show this ?