5. The Production of Electronic Boards¶

Goal(s):

Group assignment:
Characterize the design rules for your PCB production process
Individual assignment:
Make an in-circuit programmer by milling the PCB, program it, then optionally try other PCB processes

Introduction¶

This weeks Assignment is to learn about PCB fabrication and mill the Fab ISP board in a CNC Machine. I am familiar with electronic components bbut not with Printed Circuit Boards and this was a new exercise for me. While I have used the CNC before for milling and routing of wood, milling copper clad PCB’s was new and was a huge learning curve for me as I did not know anything about programing and microchips

In-circuit Programmer / In-System Programmer / FAB ISP¶

FabISP is an in-system programmer for AVR microcontrollers, designed for production within a Fab Lab. There are different versions of ISP’s available in the archive. Because I am using a Windows system, I had to select Brians Version of Fab ISP called “FabTinyISP” for making this week.

The main idea of the In-System Programmer is about learning how to write codes to Microchips yourself and this was before the advent of Arduino and Arduino IDE when programming of microchips needed real technical interest. The idea behind this exercise is how to use a Microchip to write codes to other microchips and hence called a Programmer (not a Programmee).

For this purpose, an ATTiny Microchip is used as the chip for programming and can be seen as the brain of an electronic appliance.

I had to browse through many tutorials and understand about the main chips used for this and they are listed below. The main irritation with this project was that we had to use SMD Packages.

For this exercise, the main microchips that were available in the market were only ATTiny45 and ATTiny85 mainly in non-SMD packages. After much searching, I was able to find ATTiny85 (SMD) easily but not ATTiny45 so I had to go through the differences between 45 and 85 when finally programming the chip.

Update: The ATtinyX5s are only different in the amount of memory; in all other respects they are identical.

FabTinyISP¶

It is a ATtiny45 based board having high-performance, low-power Atmel 8-bit AVR RISC-based microcontroller combines 4KB ISP flash memory, 256-Byte EEPROM, 256B SRAM, 6 general purpose I/O lines, 32 general purpose working registers, one 8-bit timer/counter with compare modes, one 8-bit high speed timer/counter, USI, internal and external Interrupts, 4-channel 10-bit A/D converter, programmable watchdog timer with internal oscillator, three software selectable power saving modes, and debug WIRE for on-chip debugging. The device achieves a throughput of 20 MIPS at 20 MHz and operates between 2.7 - 5.5 volts.

The main reason to choose this board is that it doesn’t have any clock circuits and additional LED’s are there to indicate the status of the board while programming, whereas the other chips do not have these features.

Schematic¶

A schematic, or schematic diagram, is a representation of the elements of a system using abstract, graphic symbols rather than realistic pictures. A schematic diagram is often used to describe the design of equipment. Here is the schematic of the Fab Tiny Star ISP Board.

Position Diagram¶

The position diagram shows the componenet placement in the printed circuit board. Different components will be identified by labels such as for resistors R1,R2 and for capacitors C1,C2 etc. Some components will have polarities, for that the polarity marking will be there (e.g: Diodes, IC’s, MOSFET’s etc). Using the Board diagram we can place the components for soldering. Here is the ISP Position Diagram.

Milling Traces and cut layout¶

Download the PNG files for the traces and the board outline:

Traces (1000 dpi)

Outline Cutout (1000 dpi)

I have downloaded these layouts from Brian’s FabTinyISP documentation page. Before starting the milling of the board, let’s start with characterising the design rules for the PCB production process.

PCB Production Process¶

From my time reading all the various archives and from Neil’s lectures, I was able to deduce that there were multiple methods of PCB production that were being followed in different labs.

Using a Mini Mill (important)
Using laser + chemical etching (optional)

MIlling the boards¶

Using our Mini Mill which was neither a Modela nor a MonoFab, it was a MultiCNC model designed for 2.5D milling, routing, pen plotting, thermocol cutting and electonic circuit milling.

IN order to characterise the design rules for the PCB milling, we first had to run the test file to ensure that the machine was capable of milling boards for SMD components.

After running the test file we were able to see the quality of the milling as seen in this picture.

Then we proceeded to run the ISP file for milling

The resolution on the Milling machine was not fine enough for SMD Circuit milling and but did yield 2 boards after much trying.

Also, we had to be very particular about levelling the bed correctly to ensure good quality milling

We were able to get only 2 functional boards for each square foot of PCB clad board milled.

Wasted board

laser + Chemical etching¶

As this was the first time making PCB’s and I did not want to waste the entire board on milling, I searched for some tutorials and I found this page

I used the following image as a template to make the PCB’s first.

This image was opened in Corel Draw and the negative was laser engraved on to a Copper clad plate with a sticker attached leaving the postive side of the circuit present on the board

The engraved board was removed and cleaned with Iso-Propyl alcohol to remove glue traces.

The board was then placed in an etching solution of 1:1 Hydrochloric acid and Hydrogen peroxide and agitated continuously for 3 - 7 minutes until all the copper was removed.

The final board was then cleaned with Acetone to remove all the glue and the stickers from the board

The other machining processes for the PCB Board were also tried, but they did not yield satisfactory results and hence the chemical process was used.

Making the Programmer Board¶

After using the same PCB Workflow for the FabISP Tiny Star, the final board is shown here

Stuffing and Soldering¶

The FabISP Tiny Star needs the following parts:

1x ATtiny45 or ATtiny85 (This was the one available)
2x 1kΩ resistors
2x 499Ω resistors
2x 49Ω resistors
2x 3.3v zener diodes
1x red LED
1x green LED
1x 100nF capacitor
1x 2x3 pin header

It is important to note the orientation of the parts,

The zener diodes are marked, both in the drawing and on the packages, with a line on the cathode side.

The LED cathodes on the PCB drawing are marked with dots and thicker lines. The one in our lab has a green line visible on the cathode side of the epoxy lens. The ATtiny85 marks pin 1 with a dot laser-etched into the corner of the package. Pin 1 is marked in the drawing with a dot as well. This should be pointing to bottom left when the USB is on the left side. And its better to start soldering with the ATtiny85 as it will be more accessible when other parts not around. Once the parts are all soldered in then need to use solder to create a bridge on the jumper near the ISP header (J1). This temporarily connects VCC to the Vprog pin on the ISP header so that the header can be used to program the board.

Once the soldering is done, we need to inspect it against the schematic and PCB layout image, and also check if the parts are all placed correctly and connection are soldered properly.

Programming the board¶

First we need to setup the environment for programming the boards.

Being a Native Windows user, the documentation was very clear on Brian’s page for the programming of the TinyISP, unfortunately, it was quite challenging as the chips used were ATTiny45 and the chips that were avaialble to us in the lab was mainly ATTiny85 which presented difficulties which did not have mush in the trouble shooting section.

After following all the steps in the tutorial for the installation of the Zadig drivers, we got the following errors when we ran the AVRdude toolchain for the programmer.

avrdude.exe: Error: Could not find USBtiny device (0x1781/0xc9f)

This was a major error and prevented us from the programming for a very long time holding up the progress of the Electronics assignments during the cycle.

After trouble shooting this error, and trying to find the cause for the ATTiny to not get detected, I was able to find the earlier documentation of the Fab Tiny Star from this link which clearly detailed the differences and shortcoming of the ATTiny45 vs. the ATTiny85.

If you put an **ATtiny85** on it instead, then you should be able to flash it with the Micronucleus bootloader (the 45 just doesn't have enough memory for that to be realy useful, but it can be done) and it will be almost completely compatible with the LittleWire and somewhat compatible with the the DigiSpark.

Due to this error and corresponding lack of documentation for ATTiny85, this was a major issue and had to be dealt with soon.

To get around this problem, we had no other option but to use Linux system for the programming as per the local evaluators guidance and after we dual booted the system to run Ubuntu, the process became really simple and the programming was completed.

I used the very same process that was docuemnted in GitBook to use Arduino as ISP for the very first programmer to be used in our FabLab and generate the Makefile to be used in the Linux system.

After generating the Makefile correctly, we were able to load it into the Linux system for the next steps which went smoothly.

Linux Programming¶

In Linux,

We used AVRDUDE, which is a utility to download/upload/manipulate the ROM and EEPROM contents of AVR microcontrollers using the in-system programming technique (ISP). For setting up the following command is entered on the terminal on Ubuntu.

sudo apt install avrdude gcc-avr avr-libc make

This installs the dependencies and other AVR programs.

Then we need to download the firmware source code and extract and cd that path on a terminal window. Then we need to Run make. This will build the hex file that will get programmed onto the ATtiny85. When the command completes, we should have a file called fts_firmware.hex.

Then we need to connect another programmer, I have used Arduino As ISP, to load the program to my FabISP (which will be covered later).

Then we need to enter “make flash” on the terminal. This will erase the target chip, and program its flash memory with the contents of the .hex file we built before. We should see several progress bars while avrdude erases, programs, and verifies the chip.

But I got the following message.

WARNING: Unable to detect MCU

avrdude.exe: set SCK frequency to 1000 Hz
avrdude.exe: warning: cannot set sck period. please check for usbasp firmware update.
avrdude.exe: error: program enable: target doesn't answer. 1 
avrdude.exe: initialization failed, rc=-1
             Double check connections and try again, or use -F to override
             this check.


avrdude.exe done.  Thank you.

After going through the problem in detail, I found the following text at the top of the Makefile within the firmware downloaded

Arduino Programmer is AVRISP

Right code for Arduino as ISP

I then checked the Gitbook for troubleshooting the problem and was able to resolve it after checkng all Makefile codes and solder joints and using the right codes for the Arduino as ISP

tranemt@tranemt-ThinkPad-X1-Carbon:~/Desktop/fts_firmware_bdm_v1$ make flash
avr-gcc -mmcu=attiny45 -Wall -DF_CPU=16500000UL -I. -funsigned-char -funsigned-bitfields -fpack-struct -fshort-enums -Os -Iusbdrv -c main.c -o main.o
main.c:109:13: warning: always_inline function might not be inlinable [-Wattributes]
 static void delay ( void )
             ^
avr-gcc -mmcu=attiny45 -Wall -DF_CPU=16500000UL -I. -funsigned-char -funsigned-bitfields -fpack-struct -fshort-enums -Os -Iusbdrv -c usbdrv/usbdrv.c -o usbdrv/usbdrv.o
avr-gcc -mmcu=attiny45 -Wall -DF_CPU=16500000UL -I. -funsigned-char -funsigned-bitfields -fpack-struct -fshort-enums -Os -Iusbdrv -c usbdrv/oddebug.c -o usbdrv/oddebug.o
avr-gcc -x assembler-with-cpp -mmcu=attiny45 -Wall -DF_CPU=16500000UL -I. -funsigned-char -funsigned-bitfields -fpack-struct -fshort-enums -Os -Iusbdrv -c usbdrv/usbdrvasm.S -o usbdrv/usbdrvasm.o
avr-gcc -mmcu=attiny45 -o fts_firmware.elf main.o usbdrv/usbdrv.o usbdrv/oddebug.o usbdrv/usbdrvasm.o
avr-size -C --mcu=attiny45 fts_firmware.elf
AVR Memory Usage
----------------
Device: attiny45

Program:    2470 bytes (60.3% Full)
(.text + .data + .bootloader)

Data:         75 bytes (29.3% Full)
(.data + .bss + .noinit)


avr-objcopy -j .text -j .data -O ihex fts_firmware.elf fts_firmware.hex
avrdude -p attiny45 -c avrisp -P /dev/ttyACM0 -b 19200 -e \
    -U flash:w:fts_firmware.hex

avrdude: AVR device initialized and ready to accept instructions

Reading | ################################################## | 100% 0.02s

avrdude: Device signature = 0x1e9206 (probably t45)
avrdude: erasing chip
avrdude: reading input file "fts_firmware.hex"
avrdude: input file fts_firmware.hex auto detected as Intel Hex
avrdude: writing flash (2470 bytes):

Writing | ################################################## | 100% 3.52s

avrdude: 2470 bytes of flash written
avrdude: verifying flash memory against fts_firmware.hex:
avrdude: load data flash data from input file fts_firmware.hex:
avrdude: input file fts_firmware.hex auto detected as Intel Hex
avrdude: input file fts_firmware.hex contains 2470 bytes
avrdude: reading on-chip flash data:

Reading | ################################################## | 100% 1.76s

avrdude: verifying ...
avrdude: 2470 bytes of flash verified

avrdude: safemode: Fuses OK (E:FF, H:DF, L:62)

avrdude done.  Thank you.

After flashing we need to set the configuration fuses, which is done by entering “make fuses” on the terminal. This will set up all of the fuses except the one that disables the reset pin. Next we need to check the USB connectivity. This is done by typing lsusb in the terminal, which will list USB devices. And if we should see a “Multiple Vendors USBtiny” device, it worked correctly.

tranemt@tranemt-ThinkPad-X1-Carbon:~/Desktop/fts_firmware_bdm_v1$ make fuses
avrdude -p attiny45 -c avrisp  -P /dev/ttyACM0 -b 19200 \
    -U lfuse:w:0xE1:m -U hfuse:w:0xDD:m \
    -U efuse:w:0xFF:m

avrdude: AVR device initialized and ready to accept instructions

Reading | ################################################## | 100% 0.02s

avrdude: Device signature = 0x1e9206 (probably t45)
avrdude: reading input file "0xE1"
avrdude: writing lfuse (1 bytes):

Writing | ################################################## | 100% 0.02s

avrdude: 1 bytes of lfuse written
avrdude: verifying lfuse memory against 0xE1:
avrdude: load data lfuse data from input file 0xE1:
avrdude: input file 0xE1 contains 1 bytes
avrdude: reading on-chip lfuse data:

Reading | ################################################## | 100% 0.01s

avrdude: verifying ...
avrdude: 1 bytes of lfuse verified
avrdude: reading input file "0xDD"
avrdude: writing hfuse (1 bytes):

Writing | ################################################## | 100% 0.02s

avrdude: 1 bytes of hfuse written
avrdude: verifying hfuse memory against 0xDD:
avrdude: load data hfuse data from input file 0xDD:
avrdude: input file 0xDD contains 1 bytes
avrdude: reading on-chip hfuse data:

Reading | ################################################## | 100% 0.01s

avrdude: verifying ...
avrdude: 1 bytes of hfuse verified
avrdude: reading input file "0xFF"
avrdude: writing efuse (1 bytes):

Writing | ################################################## | 100% 0.01s

avrdude: 1 bytes of efuse written
avrdude: verifying efuse memory against 0xFF:
avrdude: load data efuse data from input file 0xFF:
avrdude: input file 0xFF contains 1 bytes
avrdude: reading on-chip efuse data:

Reading | ################################################## | 100% 0.01s

avrdude: verifying ...
avrdude: 1 bytes of efuse verified

avrdude: safemode: Fuses OK (E:FF, H:DD, L:E1)

avrdude done.  Thank you.

Now there are two final steps left to turn your board into a programmer that can program other boards. First, we need to change the bit that will turn the ATtiny85’s reset pin into a GPIO pin. Once again, this will disable our ability to reprogram this ATtiny85 in the future, which is why we wanted to make sure everything was working before doing this. Connect the ISP programmer to the board one more time, and run “make rstdisbl”.

tranemt@tranemt-ThinkPad-X1-Carbon:~/Desktop/fts_firmware_bdm_v1$ make rstdisbl
avrdude -p attiny45 -c avrisp  -P /dev/ttyACM0 -b 19200 \
    -U lfuse:w:0xE1:m -U hfuse:w:0x5D:m \
    -U efuse:w:0xFF:m

avrdude: AVR device initialized and ready to accept instructions

Reading | ################################################## | 100% 0.02s

avrdude: Device signature = 0x1e9206 (probably t45)
avrdude: reading input file "0xE1"
avrdude: writing lfuse (1 bytes):

Writing | ################################################## | 100% 0.01s

avrdude: 1 bytes of lfuse written
avrdude: verifying lfuse memory against 0xE1:
avrdude: load data lfuse data from input file 0xE1:
avrdude: input file 0xE1 contains 1 bytes
avrdude: reading on-chip lfuse data:

Reading | ################################################## | 100% 0.01s

avrdude: verifying ...
avrdude: 1 bytes of lfuse verified
avrdude: reading input file "0x5D"
avrdude: writing hfuse (1 bytes):

Writing | ################################################## | 100% 0.02s

avrdude: 1 bytes of hfuse written
avrdude: verifying hfuse memory against 0x5D:
avrdude: load data hfuse data from input file 0x5D:
avrdude: input file 0x5D contains 1 bytes
avrdude: reading on-chip hfuse data:

Reading | ################################################## | 100% 0.01s

avrdude: verifying ...
avrdude: 1 bytes of hfuse verified
avrdude: reading input file "0xFF"
avrdude: writing efuse (1 bytes):

Writing | ################################################## | 100% 0.01s

avrdude: 1 bytes of efuse written
avrdude: verifying efuse memory against 0xFF:
avrdude: load data efuse data from input file 0xFF:
avrdude: input file 0xFF contains 1 bytes
avrdude: reading on-chip efuse data:

Reading | ################################################## | 100% 0.01s

avrdude: verifying ...
avrdude: 1 bytes of efuse verified

avrdude: safemode: Fuses OK (E:FF, H:5D, L:E1)

avrdude done.  Thank you.

This does the same thing as the make fuses command, but this time it’s going to include that reset disable bit as well. We should see some progress bars, and with that, avrdude will never be able to talk to this chip again through the ISP header.

We know it was programmed because we can see it appear as a USB device when we enter the “lsusb” command in the terminal

tranemt@tranemt-ThinkPad-X1-Carbon:~/Desktop/fts_firmware_bdm_v1$ lsusb
Bus 002 Device 002: ID 8087:0024 Intel Corp. Integrated Rate Matching Hub
Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 001 Device 005: ID 5986:0266 Acer, Inc 
Bus 001 Device 004: ID 0a5c:21e6 Broadcom Corp. BCM20702 Bluetooth 4.0 [ThinkPad]
Bus 001 Device 003: ID 147e:2020 Upek TouchChip Fingerprint Coprocessor (WBF advanced mode)
Bus 001 Device 006: ID 0b05:17ac ASUSTek Computer, Inc. 
Bus 001 Device 002: ID 8087:0024 Intel Corp. Integrated Rate Matching Hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 004 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 003 Device 008: ID 0eef:790a D-WAV Scientific Co., Ltd 
Bus 003 Device 012: ID 1781:0c9f Multiple Vendors USBtiny
Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

My modified MakeFile is available here