Notifications
Sign Up Sign In
Q&A

Tools required to burn code in a quad flat microcontroller

+2
−0

I always have a doubt that how do firmware engineers dump code into a quad flat microcontroller? For a starter kit there is already connection like USB or some SPI ,I2C headers to burn the code,also starter kits are very costly. I know that for Dual inline Package there are some cheap programmers in the market.Then what about quad flat micros used in industrial application?How do you all proceed?My question is based on a hobbyist or a small firmware engineer point of view.

Why should this post be closed?

1 comment

Regarding programming interfaces, each MCU family tends to have their own standard for connectors and signals. The most common ones nowadays for ARM, PowerPC and similar mainstream 32 bitters is JTAG and the spin-off called SWD. JTAG typically uses a plain 2,54mm/0.1in header, 2x10 or 2x7. SWD typically uses a 1,27mm 2x5. Lundin 19 days ago

1 answer

+4
−0

The days of socketed microcontrollers are long gone. In most cases, the socket would cost more than the micro.

Nowadays, microcontrollers, whether in quad flat pack packages or not, are surface mount soldered onto boards along with all the other parts. There are then two ways to get the program into the micro:

  1. Get the micro pre-programmed with your code.
  2. Provide connections to the programming lines and program the micro yourself during the production test and/or calibration process.

Pre-programmed

If you have a high volume product that is basically "done" where you don't expect firmware changes, then #1 can make sense. Microcontroller companies and their distributors can pre-program parts for you in volume.

At high volumes, the additional cost is usually small. The main downside is that it can be costly to change the firmware. Not only is there significant lead time, but you may end up scrapping 1000s of parts with the old firmware.

Because of the inflexibility of this approach, it is usually only done for very high-volume low-cost products which you don't expect to change. Toys, for example, can fall into this category.

Self-programmed

In most cases, you bring out the micro's programming lines to someplace on the board you can access during production test. I usually use a 5-pin Molex KK series connector for this. These are cheap and take up little room. Connecting a programmer and programming the micro are then part of the production test procedure.

For a bit higher volumes, there will probably be a custom-designed semi-automated tester anyway. In such cases, all you need to do is add some pads on the bottom of the board for pogo pins to connect to. The incremental cost to the tester is minimal, and the incremental cost to each board is very small. The largest per-unit cost in this case is probably the extra production time for programming the micro.

For hobbyist, just add the ICSP (In-Circuit Serial Programming) connector and be done with it. You'll need that for developing and debugging the firmware anyway. This is what I do most of the time for real commercial products too, when the volume is too small to justify a pogo-pin tester.

Here is a snippet of a schematic for a commercial product I'm working on right now:

Image alt text

P38 is the programming header. I generally use the same connector and pinout across products. This way I can plug the same programmer with the same interface cable into any board to program the micro. The most common connector I use for this purpose is a Molex 22-23-2051. These are cheap, widely available, and take relatively little space.

I do this so often the I have a special parts defined just for this purpose in Eagle. You can use them too. Install my Eagle Tools release from http://www.embedinc.com/pic/dload.htm and look around in the "connector" library for devices with "ICSP" in their name. As you can see above, this Eagle part includes the names of the lines each pin is supposed to be connected to. This makes it really easy to end up with the same pinout every time.

Note the resistors in series and capacitors to ground on the programming lines (PGC and PGD). These are low pass filters that slow down the edges a little when the signals are driven by the micro. Unfortunately, the standard Microchip cable puts PGC and PGD next to each other. Without the filters, there can be crosstalk, causing the communication to get out of sync and programming to fail. No, this is real. See my In-Circuit Serial Programming discussion for more information.

For this reason, my USBProg2 PIC programmer has a 6-pin connector for the programming lines. Only 5 pins are needed, but I added an additional ground pin between the programming clock and data lines to minimize crosstalk in ribbon cables. I still use the smaller 5-pin connector on boards. The two ground wires of the 6-wire ribbon cable are tied together right at the board and of the cable. I have made programming cables over 2 meters long that worked without any problems.

1 comment

There's also an option 3), which is to hack together your own bootloader over SPI, UART, CAN etc. Many modern MCUs come with some manner of hardware support for writing bootloaders, meaning that you can do it even if the chip wasn't previously flashed. Though these are only for specialized needs, usually relatively slow and can't be used for in-circuit debugging. Lundin 19 days ago

Sign up to answer this question »