An Open-Source Cortex-M0 Halogen Reflow Oven Controller With TFT LCD - Andys

An open-source Cortex-M0 halogen reflow oven controller with TFT LCD | Andys Workshop
HARDWARE » STM32 STM32PLUS ARDUINO DOWNLOADS

HELP » FORUM
Search
Home » hardware » An open-source Cortex-M0 halogen reflow oven controller with TFT LCD
HARDWARE
STM32 AN OPEN-SOURCE CORTEX-
STM32PLUS M0 HALOGEN REFLOW OVEN
CONTROLLER WITH TFT LCD
POSTED ON MAY 11, 2014 IN HARDWARE, STM32,
STM32PLUS
TAGS
Introduction
It’s been so long since I had the idea for this project that I can’t remember why
REFLOW STM32PLUS
I had the idea in the first place. At least I blame it on the passage of time
although this engineer is getting on a bit now so it could easily be memory rot
TFT
on my part. So here we are then, a reflow oven controller. Let’s quickly recap
what a reflow oven is for those that are new around here.
The two main processes used in industry to build printed circuit boards are
RELATED wave soldering and reflow using a very large industrial oven that you probably
POSTS can’t afford and if you could afford to buy it you probably couldn’t afford to
house or run it.
A custom enclosure for
the Android bluetooth
reflow controller
Nanocounter is an
accurate frequency
http://andybrown.me.uk/2014/05/11/awreflow/[7/15/2016 1:44:38 PM]

counter using an
FPGA, STM32 and a
bluetooth android app
USB HID device
development on the
STM32 F042 Reflow on the large scale is achieved by applying solder paste to the printed
A development board circuit board using a laser-cut stencil with cutouts placed precisely where the
pads are located. The solder paste itself is a mixture of flux and tiny balls of
for the STM32F042
solder. A pick-and-place machine lifts the components from their packaging,
TSSOP package
e.g. a tape and reel dispenser and places them on to the board with their pads
resting in the little gobs of solder paste.
The board then gets placed into the oven where a carefully controlled
SHARE THIS
temperature profile is applied over the course of about 5 minutes. During this
time the solder paste melts and the components ‘sit down’ into place before the
solder sets as the board cools.
We can apply this basic technique to the hobbyist world with a simple plan of
action. The pick-and-place machine will be replaced by my right arm and a
pair of tweezers. A cost of zero so far, great stuff. Stencils and solder paste are
PROJECT both available to the hobbyist but the cost of the stencils are relatively high if
you’re going to be making only a few boards and the solder paste needs
DIFFICULTY
refrigerated storage and only has a short shelf life. I’ll replace this part with a
simple tinning of my boards using a soldering iron. It’ll take longer but should
work just as well.
Finally we have the oven itself. Small ovens in various forms are available on
ebay, amazon and they might even sell them in real shops made out of real
bricks and staffed by real people. The fun part of the question is how do we
make our oven follow a pre-programmed temperature profile instead of just
powering up to a target temperature and staying there until the dinger goes
All components are ding and your chicken is roasted.
commonly available.
Of course we’re going to use a microcontroller to do it and that’s what the
There are 6 integrated bulk of this article is about. Please read on.
circuits.
The integrated circuits Prior art
all have exposed pins.
I’m not the first to build an MCU-based reflow oven controller and I’m
The Cortex M0 has a probably not going to be the last. A quick google around throws up the
0.5mm pin pitch. following results, and these are just the guys that have put virtual pen to paper
There is a 34 pin and taken the time to publish their work.

connector with a
0.4mm pitch on the Here’s an Arduino shield-based controller that looks professionally
produced and generally well thought out.
bottom of the board.
Dan Strother’s effort is a simple affair but his firmware is very good. While
The smallest discrete you’re there take a look at his Spartan-6 BGA test board. I can’t believe he
component (the ESD did it with Eagle, there’s only so much pain a man can take.
diode) is 0402. Sparkfun did one once and then pulled it. Goodness knows why.
There’s even an instructable that you can follow.
A significant amount of
peripheral hardware There’s more. There’s a lot more, so why another one? The commercially
needs to be built. available controllers didn’t look particularly inspiring to me so a self-build was
going to be the way to go. I could either follow someone else’s schematic or
come up with my own. Well I felt up to the challenge of doing it myself and
bringing my own bit of flair to the presentation as well as making it highly
RECENT POSTS cost-effective.
An acrylic case for
Nanocounter
Component selection
A review of the
Maximator Altera A significant number of components need to come together harmoniously for
FPGA development this project to work. In this section I’ll go over the main component parts and
board how I selected them.
A custom enclosure for

the Android bluetooth The Solid State Relay
reflow controller A solid state relay (SSR) is designed to allow you to switch mains voltages on
Nanocounter is an and off using low voltage DC control, i.e. a microcontroller. They do this by
accurate frequency using an optocoupler to internally isolate the two sides from each other. When
counter using an you trigger the photodiode the mains current is allowed to flow. However, it’s
not quite as simple as that. The relay will only change the state of the AC
FPGA, STM32 and a
output at the two points in the AC sine wave where it crosses zero so that the
bluetooth android app
input and output waveforms are maintained, the zero-crossing. That imposes
USB HID device limits on the frequency we can use to switch it on and off, something which I
development on the will tackle in the firmware design.
STM32 F042
The best quality SSRs are made in the USA and you do get what you pay for.
There are cheap Chinese Fotek SSRs on ebay for a fraction of the cost of the
USA-made SSRs. I knew I was going to need a heatsink so I got one on ebay
that came with one of the Fotek’s attached. They were so cheap that I thought
I’d get one just to see what they were like.

I tested the Fotek using a light load — literally — it was a desk lamp and it did
what it was supposed to do, no problems there. Reports on the internet from
users of the Fotek range from ‘it caught fire’ to ‘I’ve been using it for years
with no problem’. I suspect that some users don’t realise that you must cool an
SSR. It probably doesn’t help that the Fotek only comes with a little
aluminium plate on the base that does not shout out its role as a heatsink.
I unscrewed the base to take a look at the innards but could only get it out a
few millimetres without damaging the internal wiring. From what I could see
there is a PCB housed towards the top of the unit and then a set of bare wires
come down to the aluminium base plate where an unidentifiable component is
soldered directly to it. This must be the heat generating component.
The overall cheapness of the Fotek did not fill me with confidence so I loitered
some more on ebay and managed to pick up a brand new USA-made device
for about £8.

The difference in quality is immediately obvious. This device is completely

solid and resin-filled. It feels like a proper industrial component and a stamp
on the side declares that it’s ‘200% tested’. My only reservation is that the AC
and DC terminals are only air-gapped. The Fotek, for all its faults, physically
separates the two sides so arcing or shorting from the AC to the DC would be
practically impossible.

Just look at that base plate. If you were ever in any doubt that this is a device
designed to be attached to a heatsink then you won’t be after you see that. I
unscrewed the Fotek from its heatsink, applied some thermal transfer gunk that
I had left over from a computer HSF kit and screwed in the Opto-22 device.
I’m now confident that there won’t be any smoke coming from my mains
control unit.
The temperature sensor

After doing some research it turns out that the most popular IC for handling
the amplification and analog to digital conversion of the thermcouple readout is
the MAX6675 and its successor, the MAX31855 from Maxim. The two
devices have the same footprint and pinout but are not software compatible and
may not all work with the same thermocouples.
The MAX6675 can read a range of 0 to 1023°C with 0.25°C resolution. The
MAX31855 extends the capabilities by being able to read below zero but it
adds the limitation that the thermocouple must not be grounded. The
MAX6675 can be grounded and in fact it must be grounded if you want to
take advantage of its ability to sense an open (disconnected) state. I decided to
design the board to be able to handle either type of sensor IC using a jumper to
ground it and I’ll be using the MAX6675 on my own build.

A defective MAX6675
The MAX6675 (and its successor, the MAX31855) are rather expensive little
chips but I noticed that they were available on ebay for just a few pounds so I
bought one. Mistake. I wasted about half a day trying to figure out why the
readings I was getting from it were scaled up by a factor of 8. It just didn’t
make any sense.
I couldn’t just say, yeah whatever and write my software to scale down by 8
because the maximum reading would be 128°C which is way too low for a
reflow oven. This issue had to be resolved.
Eventually I decided to try removing it from the board and replacing it with
one that I got from a different seller on ebay that had slightly different
numbering printed on the case, perhaps indicating a different batch. It worked
perfectly. Lesson learned, it’s just not safe to buy ICs on ebay because you
don’t know where they’re sourced from. Next time I’ll swallow the cost and
stick to the usual major name suppliers that I usually use.
Anyway, in case it helps anyone else here’s a picture of the bad IC. If you’ve
got one with the same ‘+120′ numbering and it’s misbehaving then drop-kick it
into the waste bin and replace it with one from a reputable supplier.
Now that the sensor is selected I’m going to need a compatible

thermocouple…
The thermocouple
Thermocouples have different designations depending on the temperature range
that they are designed to handle. If you’re interested, Wikipedia has a complete
list of all the types. The MAX6675 sensor requires a ‘K’ type thermocouple
which has a range of -200°C to +1350°C, far more than we will ever need. ‘K’
type thermocouples are available on ebay for just a few pounds and the user
feedback for them is very good so I bought-one-now and waited forever for it
to arrive from China.

This is a grounded thermocouple. That is, there is electrical continuity between

the blue wire spade terminal and the cable braid and the outer metal end of of
the sensor itself. This will work with the MAX6675 but I’m not at all sure that
you’ll be able to use it if you choose the MAX31855.
The controller
All of the components listed above need to be linked together with an MCU-
based controller board. The basic requirements of the controller board are as
follows:
Accept user control input.

Provide user feedback via a display.
Interface with the MAX6675 temperature controller.
Implement a PID algorithm to control the state of the SSR.
I decided to integrate a Cortex M0 MCU with the 640×360 TFT LCD from the
Sony U5 Vivaz mobile phone. If you haven’t already done so then you can
read all about my prior efforts in reverse engineering that display in this
article. The graphical user interface will be supported by an 8Mbit SPI flash
device from Spansion.

The 3.2″ Sony Vivaz LCD
When I started this design there were a couple of aspects where I was operating
on a hunch that things would work out. Firstly, the STM32F051C8T7 MCU
comes with 64Kb flash. I wasn’t sure whether that was going to be enough to
hold the debug builds of the firmware that I would need to do in-circuit
debugging with my ST-Link/V2 debugger.
Secondly, I wasn’t certain that the SPI flash interface was going to be fast
enough to create a responsive user interface. I really dislike sluggish user
interfaces, only instant responses are acceptable to me. The killer feature here
is the DMA channels linked to the SPI interface in the STM32F0. If I run the
SPI interface at 24MHz (the fastest available) then I should be able to get a 1.5
megapixel/sec sustained transfer rate using DMA because each pixel is 16-bits
wide. That should be enough for a responsive UI but I will only know for sure
after it’s too late to go back.
Controller schematic

Click on the thumbnail to see the full schematic PDF. I’ll go through the each
section of the schematic in detail but first lets take a look at the bill of
materials.
Designator Description Footprint Quantity Value
BOOT0, Push-to-make
PCB button 2
RESET button
C2 Capacitor 0603 1 56pF 50V
C3 Capacitor 0603 1 56pF
C4, C8 Capacitor 0603 2 2.2µF
C5, C15,
Capacitor 0603 3 1µF
C17
C6, C7,
C11, C12, Capacitor 0603 5 100nF
C13
Electrolytic
C9 Radial 2x6x6 1 10µF
capacitor
Tantalum
C10 1206 1 22µF
capacitor
C14 Capacitor 0603 1 10nF
C16 Capacitor 0603 1 10nF
C18 Capacitor 0805 1 1µF 50V
Electrolytic
C19 Radial 2x6x6 1 100µF

capacitor
Electrolytic
C20 Radial 2x6x6 1 4.7µF
capacitor
C21, C22 Capacitor 0603 2 100nF
D1, D2, ESD OnSemi

SOD-923 3
D4 Suppressors ESD9B5.0ST5G
Schottky
D3 SOD123 1 B0530W
Rectifier
Header, 10-Pin,
DEBUG 2.54mm pitch 1
Dual row
FB1, FB2 Inductor 0603 2 BLM18PG221SN1D
L1 Inductor CDRH5D28 1 22µH
Panasonic
LCD AXE534124 1 (only digikey US)
connector
Left, PCB terminal

2 pin 3
Right, OK block
MCU Header, 3-Pin 2.54mm pitch 1
ON:
SENSE, Header, 2-Pin 2.54mm pitch 2
USART
PCB terminal
POWER 2 pin 1
block
PWR SEL Header, 2-Pin 2.54mm pitch 1
TSM3442
Q1 SOT26A-6AN 1
MOSFET
Generic
Q1.1 SOT23-3N 1
MOSFET
R1, R2,
R3, R7,
Resistor 0805 8 10kΩ
R8, R9,
R10, R11
R4, R5, R6 Resistor 0805 3 1kΩ
R12 Resistor 0805 1 100Ω
R13 Resistor 0805 1 5.1Ω

SPI Header, 5-Pin 2.54mm pitch 1
PCB terminal
SSR 2 pin 1
block
2.8V LDO
U1 SOT353-5N 1 ZXCL280H5TA
regulator
U2 3.3V regulator SOT223-4N 1 AMS1117
8Mbit serial
U3 SOIC8N_N 1 S25FL208K
flash
ARM Cortex
U4 LQFP48_N 1 STM32F051C8T7
M0
Thermocoupleto SOIC127P600-
U5 1 MAX6675
A/D Converter 8AN
Backlight boost
U6 SOT26A-6AN 1 AP5724
converter
The LCD interface
This is a direct copy of the connector schematic from my Vivaz reverse

engineering article. It’s a proven design so the decision to drop it into this
schematic is an easy one to make. The Vivaz backlight is a string of six white
LEDs in series. We have to provide the power for that string but the R61523
controller in the Vivaz LCD has a programmable PWM output that we can use
to provide a programmable brightness by connecting that PWM output to the
enable pin of the voltage boost converter.

TFTs always need two voltage inputs, one for the digital interface and one for
the analog display driver. If you’re lucky they’re both the same and fit the
same range as your MCU. We’re not so lucky with the R61523. The digital
interface will take 3.3V but the analog voltage requires 2.8V. That’s no
problem, we just drop in this small and cheap regulator.
That string of 6 white LEDs in series needs 19 point something volts to light
up. The best way to do that is with a constant current backlight generator such
as this AP5724 from Diodes Inc. The feedback resistor R13 sets the desired
current to 20mA and the EN pin allows us to vary that down to provide a
dimmer function.
The power regulator
3.3V power is provided by an AMS1117 3.3V regulator. The maximum current

output, 1A, is way above what we will need but the main reason for selecting
this regulator is its high input range of up to 15V. I’ve bought some

illuminated panel buttons for the physical case that require a 12V input to light
up so I’ll be able to use a single 12V input to power the controller board and
illuminate the panel buttons.
The ESD diode is optional and can be omitted if you trust your 12V input
power supply. The AMS1117 will operate quite happily with just the 22µF
output capacitor but I took a belt-and-braces approach and added a 10µF
electrolytic capacitor to the input side as well. In this design the power supply
needs to be smooth because of the sensitivity of the MAX6675 to noise so the
output capacitor should be chosen carefully. I chose a tantalum device because
they perform just as well as a ceramic in this role and are more cost-effective
in the 22µF size.
The PWR SEL jumper allows me to isolate the AMS1117 from the controller
board. Why would I want to do that? When I need to program the SPI flash
with the graphics for the UI I will connect up an STM32 development board
and use it to program the flash. When I do this I will need to power my board
from the same supply as the STM32 development board. The 3-pin MCU
header allows me to do this but I must also isolate the AMS1117 because
voltage regulators don’t like to receive a reverse current on their output pin.
The 3-pin header also has an MCU_RES pin that is connected to the RESET
pin of the Cortex M0. When I’m programming the flash using an external
MCU I will connect this pin to ground so that the Cortex M0 is held in a reset
state and does not try to initialise and interfere with the programming session.
The MAX6675
This module handles the MAX6675 interface. The power, ground and SPI
connections are all so-so, nothing special there. However the the T+ and T-
inputs to the device are handled with some care. I’ve made provision for
filtering the inputs using a 10nF capacitor and ferrite beads as well as

protecting the device with ESD protection diodes. All of these features are
optional and may be omitted from the final design but it doesn’t hurt to get the
footprints for the filtering components on to the board just in case we need
them.
The SENSE jumper block allows the T- terminal to be grounded when the
jumper is connected. When the MAX6675 is grounded it is able to sense if the
thermocouple becomes disconnected. I use this feature in the firmware to
provide an emergency abort if the thermocouple link is broken during the
reflow process.
If you plan to use the successor to the MAX6675, the MAX31855 then this
jumper must be left in the OFF position because that device does not like
being grounded. Although I do have a couple of 31855’s in the workshop I
have elected to use the simpler 6675 in my implementation because the 31855
comes with some limitations on the type of thermocouple that you can use.
The SPI flash
The Spansion flash device is connected up using a standard SPI interface. This
device supports ordinary 1-bit SPI output and also a fast dual-output mode that
uses both MOSI and MISO to output 2 bits per clock. If we were using an
FPGA then we could use this feature to double the output data rate. However
the MCU SPI peripheral doesn’t understand this proprietary feature so we will
be using 1-bit mode at 24 megabits/sec.
The debugger

This 20-pin header is designed to interface directly with the JTAG cable that
comes with the ST-Link/V2 debugger. The ST-Link/V2 will be used to upload
programs as well as mediate between an OpenOCD server and the Cortex M0
MCU using ST’s SWD protocol so that I’ll be able to do full IDE debugging
using Eclipse.
BOOT0 and RESET buttons
Having a reset button is a convenience just in case I need to force an MCU

reset. The pin is pulled up since reset is active low and a small capacitor
provides some protection against transient dropouts causing a spurious reset.
I decided to include a button that would allow me to control BOOT0 just in

case I wasn’t able to get SWD debugging to work. If BOOT0 is high when the
MCU is reset then it will boot from the internal bootloader which can then
download a flash image from the USART pins. I hoped I wouldn’t need this
but it does give me another way to flash the device if SWD didn’t work (it did
work…)
The input buttons
This design will feature three buttons for navigating the user interface. There’ll
be a left, right and an OK button. I considered, and rejected the idea of a touch
screen because when I operate this device my hands will be dirty and a touch
screen would quickly become fouled up. The three buttons will be ‘active high’
so they are pulled down and get connected to 3.3V when the user presses the
button.

The MCU
Here’s the heart of the system, the STM32F051C8T7 MCU in an LQFP-48

package. These MCUs are extremely competitively priced. For £2.60 + tax at
Farnell you get a 48MHz 32-bit ARM MCU with 64Kb flash, 8Kb SRAM,
loads of on-board peripherals and a DMA controller. You don’t even need an
external oscillator as long as you can accept up to 1% deviation from the stated
clock speed. They’re even available for less than a pound at Future Electronics
and if it wasn’t for their punishing international delivery charges that’s where
I’d get them from.
We’ll use all of port B for the LCD 16-bit data bus. That means with the help
of an optimised assembly language stm32plus driver I’ll be able to push pixels
to this device at 12MHz because the Cortex M requires 2 clocks to write to a
GPIO pin and we need to do that twice per pixel write-cycle. 12MHz, or 83ns
is very close to the maximum supported by the R61523 LCD driver which is
very handy for us.
PA0..2 are mapped to the LCD control signals. PA5..7 correspond to the SPI1
MCU peripheral pins and PA3 and PA4 are the chip select signals for the SPI
flash and the MAX6675, respectively. We will share the SPI1 bus between the
flash and the 6675 and use the chip-select signals to choose which one we are
talking to at any one time.
PA9 and 10 are mapped to the MCU USART1 peripheral TX and RX. I
mentioned earlier on that I would use the USART to flash the MCU via its

bootloader if I had problems with the SWD debugger. In the end I did not have
any SWD problems so I decided to use the USART as a way of exporting
reflow session data as a CSV file to a connected computer.
PC14, PF0 and PF1 handle the button inputs and PA11 is the output control
pin for the SSR.
The VDD and VSS (ground) connections as well as the decoupling capacitors
all follow ST’s recommendations.
The SSR output
The relay output is a simple on-off switch which I’m implementing as a logic
level N-channel MOSFET. A high level pulse on the gate will cause 3.3V to
flow through the SSR’s control pins and back to ground. We already know that
the SSR has a 1kΩ resistor between its control pins so we don’t need to add
any more resistance of our own.
I happen to have quite a few TSM3442 MOSFETs in stock so that’s the one
I’m using. However, it does come in a rather obscure SOT23-6 footprint when
nearly all the competitors come in a SOT23-3 format. To make it easier for
others to implement this design I’m including footprints for both devices on the
PCB and you just need to use the footprint that fits the device you can obtain.
The PCB design

With the schematic compiled and ready it’s time to start laying down the PCB
footprints and traces. The LCD panel measure 80x45mm and I want the PCB
to double as a mounting base for the LCD so I’m going to work on a
100x100mm PCB board size. Here it is.

PCB design thumbnail, click for PDF
On one side there is the LCD and its connector. The physical layout of the
LCD panel is such that when the LCD is facing upwards the connector is
facing downwards which makes it easy to mount on to the board. This is the
side of the board that is designed to be pressed up against a window cut out
from the box in which the board will be mounted. The other side of the board
contains all the components and connectors. This will face down into the box
and therefore be accessible for debugging purposes.
The highest frequency signals are going to be between the MCU and the flash
and the MCU and the LCD therefore these signals are kept as short as possible.
The MAX6675 needs to be kept safe from noise so it’s placed away from the
digital components and its power line takes as direct a route from the regulator
as possible and there is an unbroken ground plane beneath it.
I generated gerber files from the design and uploaded them to Elecrow for
printing. Other, similar services from ITead and Seeed Studio are available but
I’ve had good service from Elecrow and their prices are the best (at the
moment) so I continue to use and recommend them.
After the usual multi-week wait for the slow postal service to deliver the
boards they arrived safely and every one’s a winner as far as I can see. Click
on an image for a larger version.

Most of my vias are large and untented because you never know when you’re
going to need an impromptu probe test point on your board but there are some
tented vias around the LCD connector where there would be a danger of the
FPC tail coming into contact with the circuit board.
These tented vias are necessarily small otherwise the solder mask will just fall
into the hole instead of tenting over the top. Unfortunately the reality of these
cheap prototype services is that total tenting is very hit and miss, usually the
mask does cover the annular ring but then collapses into the hole.
Note that these boards do not feature the Q1/Q1.1 dual-footprint option for the
SSR MOSFET switch that I talked about earlier. I added that to the design
after these had been printed.
Now it’s time to build it. The build was straightforward in that there’s nothing
on there that I haven’t soldered before but there are rather a lot of components
and there is the additional complexity of components that require reflow on
both sides of the board.
The way I dealt with that problem is to reflow the board in stages using my
hotplate. The LCD connector on the reverse side went on first as it’s probably

the most troublesome with its 0.4mm pin pitch. After that was down I divided
the top of the board into sections containing ICs that could be reflowed one
section at a time by holding the board partially on the hotplate so the part with
the LCD connector fitted to the back hung off the edge.
After the ICs were reflowed into place I then went back to my hot air gun for
the SMD passive components and a normal iron for the remaining through hole
parts. As you can see from the image above it all worked out rather well. Let’s
have a look at the board modules.
The AMS1117 is closely accompanied by its supporting electrolytic and

tantalum capacitors. The PWR_SEL jumper in the foreground is normally on,
allowing power to come from the external 12V wall adaptor. When
programming the flash device from an external MCU this jumper should be
OFF to prevent the AMS1117 from seeing a reverse current on its output pin.
The 3.3V/GND/RESET header is then used to apply power from the board
that’s being used as the programmer and the RESET pin is tied to GND to
prevent the Cortex M0 from ever coming alive while programming is taking
place. You can’t achieve this by isolating the power pins because the voltages
that the MCU sees on its IO pins will cause it to unexpectedly power up —
you have to hold it in the reset state.

The AP5724 backlight boost converter circuit and its associated inductor and
schottky diode. The output capacitor C18 is going to be seeing around 19V so
it needs to be rated accordingly. I used a 50V rated 0805 part.
The STM32F051C8T7 MCU and the 4.7µF electrolytic capacitor

recommended by ST. This MCU does not require an external oscillator, the
clocks are generated from an internal 8MHz oscillator trimmed by ST to
around 1% accuracy. Soldering the LQFP-48 part was remarkably easy. To
most people the legs on these ICs look the same but having soldered so many
different ICs I can tell you for sure that some are made of metal that attracts
solder much more readily than others. This IC is one of them. Just add flux,
touch the legs and the solder runs up those legs like its magnetically attracted.
I’ve seen the same with Xilinx FPGAs and it’s a real relief when a device
behaves like that.
The 20-pin header originally specified for JTAG. For every signal there is a
neighbouring ground line. Very good for minimising crosstalk on a parallel
cable but very profligate on pin usage. We are going to be using ST’s Serial
Wire Debugging (SWD) protocol which only requires a small number of pins
that you can see labelled on the board here. The pinout is designed to match
the 20-pin cable that comes with the ST-Link/V2 debugger and the little bump
in the silkscreen aligns with the bump on the cable connector.
The Spansion flash device is placed close to the MCU, keeping signal lines
short and helping with signal integrity. It’s placed at a 45° angle because that’s
just the way it worked out so that the traces were the shortest they could be.
The MAX6675 footpring is accompanied by a jumper that determines whether

the T- pin should be grounded or not. For the MAX6675 this needs to be ON
so that the open circuit state can be detected. For the MAX31855 this must be
OFF. In my design I left space for ferrite beads and ESD diodes but in the end
I did not need them as I get a nice clean reading without them so the ferrites
are replaced by 0R resistor bridges and the ESD diode footprints are left blank.
The SPI breakout header allows me to access the two SPI devices for testing
and, for the flash device, programming with an external MCU. When
programming the flash I hardwire nCS_OVEN to 3.3V so that it can’t interfere
with the programming process.
The navigation buttons break out to terminal blocks at the edge of the PCB
suitable for wiring directly to a momentary push-to-make button. A pull-down
resistor causes the unpressed state to be GND and a small-ish series resistor
helps to smooth out unwanted noise from the button contacts.
The output terminals for the SSR control pins break out to a standard screw
terminal block. The actual (small) load is switched with a logic level
MOSFET. You can see the TSM3442 in the photograph with its unusual

SOT23-6 pinout. This photograph was taken before I added the choice of
footprints between this one and the more standard SOT23-3.
The two switches allow me to manually reset the MCU and also to control
BOOT0. The ability to reset is useful during debugging but not essential and
can be omitted. Controlling BOOT0 was part of my belt-and-braces approach
to being able to flash the board. I wasn’t 100% certain that my SWD interface
was going to work so I needed a way to cause the MCU to use its internal
bootloader to source the flash image from the USART pins as a failsafe. In the
end though the SWD interface worked perfectly so this BOOT0 switch is
redundant and can be omitted.
In the above paragraph I explained why I might have needed access to the
USART pins for programming purposes but since that scenario did not come
to pass I was left with a couple of potentially useful pins looking for a purpose.
What I did in the end was program the firmware to have an option to output
the (T,degrees) points from a reflow curve to the USART so that they can be
viewed on a computer charting program.
The firmware
Time to write the firmware and for me that’s definitely the fun part. I decided
to use my own stm32plus C++ library to take the strain out of interacting with
the hardware and to allow me to just get on with producing a good interface.
I decided that the interface would feature a main setup ‘control’ screen where
you can change the reflow parameters followed by an ‘action’ screen that
would actually perform the reflow according to the parameters I’d defined.

Time to fire up Photoshop and create a mockup UI that would serve as a

template for my control screen.
Click for full 640×360 size
This full size 640×360 mockup allowed me to extract and save the individual
graphics, including all the numeric characters saved as graphics against their
correctly coloured backgrounds. These graphics will be converted to a raw
format by the stm32plus bm2rgbi utility and then uploaded to the Spansion
flash device on the controller.
The tiled format, with apologies to Microsoft, gives a nice and clear UI that I
will be able to navigate around using the three buttons on the controller. The
SnPb and SnAgCu tiles allow me to select between lead and lead-free profiles.
The mockup shows both tiles checked because I’ll need to save out both those
check-boxes to flash due to the different coloured backgrounds (the graphics
are anti-aliased by photoshop against the background colours and I need to
preserve that).
The purple reflow buttons takes us to the ‘action’ screen. The grey ‘flame’
button shows a constantly updating readout of the current oven temperature
which is useful during the cool down phase.
The blue buttons allow me to adjust the co-efficients of the PID algorithm.
The defaults will be 1/1/1 and after simulating the algorithm on my PC I know
that I only need to be able to move up and down in integer steps to increase or
decrease the effect of each component of the algorithm.
The selected parameters are saved to a page in the flash memory and are
automatically restored on power-up.
You have to be careful when selecting a font due to commercial licensing

issues that cover most of those very nice looking ones that come with
Windows so the font that I used throughout is Titillium Web from the Google
open source web fonts project.
Fast SPI graphics

There’s three words you don’t often see used together. Surely a 1-bit interface
is never going to be fast enough for interactive graphics? Well, it is. By
running the SPI interface at the fastest 24MHz rate offered by the MCU and
utilising DMA to transfer big blocks at once we achieve bursts of 1.5
megapixels/sec. This is more than fast enough to update just the changing parts
of the display in real-time.
My implementation is realised by a FlashGraphics class that initialises the

SPI interface on construction and de-initialises it on destruction. This allows

me to freely write graphics or read a temperature from the oven even within
the same function without having to care much about who owns the SPI bus.
The bus is owned by whichever controller class happens to be in scope at that
time.
Here’s the main drawBitmap method from the FlashGraphics class.
/*
* Read the bitmap from SPI and write it out to the display
* We'll use the Read Data (03H) command because our max
frequency of 24MHz
* is lower than the device's max of 44MHz so we don't have to
use the Fast Read
* command that would incur a speed penalty due to the dummy
writes.
*
* The strategy here is to use DMA to read in the bitmap from the
flash device into
* a buffer in chunks. When half the buffer is full we transfer
it to the display
* while DMA is filling the remainder. When DMA has filled the
remainder we transfer
* it to the display. This allows us to get a good utilisation
out of the SPI bus.
*
* Note that in master mode the SPI clock will not tick unless we
transmit something.
* Without a ticking clock the flash slave device will not latch
out the data. Therefore
* we use DMA to "transmit" fake zero bytes just to get the clock
to tick so that there
* will be data for us to receive. This is one of the oddities of
ST's SPI implementation
* that you just have to learn.
*/
void FlashGraphics::drawBitmap(const Rectangle& rc,uint32_t

offset,uint32_t length) {
uint8_t zero,bytes[4];
Panel::LcdPanel& gl(_panel.getGraphicsLibrary());
Panel::LcdAccessMode& accessMode(_panel.getAccessMode());
// set up the drawing rectangle and get ready for receiving

data
gl.moveTo(rc);
gl.beginWriting();
// first 32-bits are the read command and the offset
bytes[0]='\x3';
bytes[1]=(offset >> 16) & 0xff;
bytes[2]=(offset >> 8) & 0xff;
bytes[3]=offset & 0xff;
// select our device
SpiNssManager nss(*_spi);
// write out as four 8-bit transfers
_spi->send(bytes,4);
// get a temporary buffer and set the dummy byte to zero
uint8_t buffer[READ_BUFFER_SIZE];
zero=0;
while(length>=READ_BUFFER_SIZE) {
// start a read and wait for half complete
_rxdma.beginRead(buffer,READ_BUFFER_SIZE);
_txdma.beginWrite(&zero,READ_BUFFER_SIZE);

while(!_rxdma.isHalfComplete());
// transfer the first half to the display while the other

half is finishing off
accessMode.rawTransfer(buffer,READ_BUFFER_SIZE/4);
// wait for the full complete
while(!_rxdma.isComplete());
// transfer the second half
accessMode.rawTransfer(&buffer[READ_BUFFER_SIZE/2],READ_BUFFER_SIZE
);
length-=READ_BUFFER_SIZE/2;
}
if(length>0) {
// receive and transfer the remainder synchronously
_spi->receive(buffer,length);
accessMode.rawTransfer(buffer,length/2);
}
}
To prove the theory I set up my logic analyser to capture the DMA transfer.
You can see the results in the screenshot below.
Click for larger
The serial clock is ticking at a continuous 24MHz while the data is being
latched out of the device on the MISO line. This is all as expected and
validates this part of the design nicely. I’ve documented the process for
flashing the graphics to the IC in the readme page that accompanies my github
repo.
The reflow page

When the desired reflow profile and parameters have been chosen the purple
‘reflow’ icon takes us to the page where all the action is. This is a separate and

distinct area of the firmware. All memory used by the control page is freed and
the reflow page is constructed to take its place.
Click for full 640×360 size
Again I mocked up how the page might look in Photoshop before starting the
coding. All the necessary graphics were saved off and added to the UX
resources that would be written to the SPI flash memory.
When the user lands on this page the oven is off and we’re ready to go. At this
time the user can activate the ‘go’ icon which is selected by default or the
‘exit’ icon can be activated to return to the control page.
Assuming the user hits go then the action starts. The PID algorithm will be
repeatedly run to select a low-frequency PWM signal for the halogen lamp as
the algorithm attempts to track the reflow profile. The actual temperature will
be displayed in orange just below the desired temperature. A red-line will plot
across the chart to show how the oven is performing.
The PID algorithm

The Proportional, Integer, Derivative (PID) control algorithm is documented at
length on the internet so I won’t go over how it works again here. The actual
algorithm itself is very simple indeed. The core of my PID implementation is
shown below and can also be seen here and here on Github.
/*
* Update the algorithm with the current error and get a
percentage value back
* that can be used as a PWM duty cycle (0..100). This method
should be called at
* a fixed time interval.
*/
uint8_t Pid::update(variable_t desiredTemperature,variable_t

currentTemperature) {
variable_t error,pwm,derivative;
// current error term is the difference between desired and

current temperature

error=desiredTemperature-currentTemperature;
// update the integral (historical error)
_integral+=error;
// the derivative term
derivative=error-_lastError;
// calculate the control variable
pwm=(_kp*error)+(_ki*_integral)+(_kd*derivative);
pwm=Max(Min(100.0,pwm),0.0);
// save the last error
_lastError=error;
// return the control variable
return static_cast<uint8_t>(pwm);
}
The datatype used by the algorithm can be either fixed or floating point (a
variable_t typedef in my code above) and that means we have a choice to
make. The lazy man’s default choice is the IEEE double type that’s built
into the C++ language. It’s a shame that the built-in type manages to be the
worst performing choice without hardware assistance and, being a binary
fraction suffers from accuracy issues that serve to trip up the unwary.
So now that I’ve slated it I decided to be that lazy man and see whether it
would do for me or whether I would need to optimise. Sure enough as soon as
the double type and the necessary calculations were added the firmware size
jumped up by 8 Kbytes in debug mode. A fixed-point implementation could
surely knock that down to less than 1 Kbyte but wasn’t necessary because I
was nowhere near the 64Kb flash size limit and it would have been a case of
premature optimisation.
Logo screen
With so much of the MCU and external flash resources still available I decided
to design a logo screen to show for a few seconds when the device powers up.
Out came Photoshop again and after an hour or so of faffing around here’s
what I came up with.

Click for larger
The logo graphic is DMA’d from flash to the LCD whilst the backlight is
switched off and then I fade up the backlight, hold for a few seconds then fade
back out, construct the ‘Control’ screen and fade back in again. The end result
is a smooth transition between states.
Final code size

With everything enabled and using inefficient double-precision numbers for the
PID algorithm, here’s the resulting code sizes.
Mode Optimisation Text data bss
debug none 44268 2128 1144
fast -O3 41568 2128 1144
small -Os 25592 2128 1144
The debug size is the most important because if that one breaks through the
MCU limit then I won’t be able to attach to the running instance and debug it
with Eclipse and gdb. The small size is particularly impressive, just 25Kb is
needed for an optimised version of the firmware.
PWM and the SSR

A zero-crossing SSR such as the Opto-22 device that I’m using cannot be
operated with a high-frequency PWM signal in the same way that you can dim
an LED. The only way to do it reliably is with an external zero-crossing
feedback circuit and a pulse-density algorithm. Essentially it would work like
this:
1. Each second, run the PID algorithm and get a percentage density for the next
second. Distribute 1’s and 0’s evenly across 1 second according to that
percentage density that you have. For example a 100% density will result in

100 1’s for people in a 50Hz mains country. A 50% density would result in
100 alternate 1’s and 0’s. A 25% density would result in 0-0-0-1 repeated
until you’ve got 100 digits. Reset your interrupt’s index position to zero.
2. Hook up the zero-crossing detection line to an external interrupt (EXTI on
the STM32). It should fire at twice your mains frequency.
3. When the interrupt fires pick the 1 or 0 from the array you created at the
interrupt index position. If you get a 1, switch on the SSR, a zero will switch
it off. Increment the interrupt index position and reset it to zero if you hit the
end of the array.
I don’t have a zero-crossing feedback signal in my design but that wasn’t

going to stop me trying the above algorithm anyway with a fixed 100Hz
interrupt. It didn’t work reliably at all. It seems you really do need to be in
sync with the actual zero crossing.
No matter, although it would have been nice to dim the halogen lamp it’s not
really necessary. The heat-up/cool-down speed is so slow that you can easily
just use a PWM signal with a low frequency (I chose 2Hz). The length of the
on-off periods in a 2Hz signal is high enough to span a lot of zero crossings so
it doesn’t matter if you miss one at the start or the end.
The hardware build

The controller’s built, the firmware’s written. Now it’s time to put it all
together and test it in the real world.
The oven

Click for larger
This is the halogen oven that I bought. It cost about £25 on ebay for a 12 litre
model rated at 1300W. When it arrived it was bigger than I thought it would
be. 7 litre models exist but I chose the larger 12 litre model because they come
with the more powerful 1300W bulb that I thought I might need to get the
temperature up as high as I need it to go.
Halogen versus toaster oven. Why choose halogen? Lots reasons put together
really. Toaster ovens aren’t as common in the UK as they are in the USA,
halogen ovens are very common and low cost. Halogen ovens heat up faster
than toaster ovens and that’s important for the ramp-up stage of the reflow
profile. Halogen ovens have amazing visibility. Not only is the whole thing
glass but there’s that extremely bright halogen lamp as well. Let’s take a look
at the modifications that I’ve made to the oven to make it reflow-friendly.
Mounting the thermocouple probe

The thermocouple probe needs to be mounted inside the oven and it comes
with a screw connector near the probe end that can be used to secure it to the
inside of a frame. The problem is that the halogen oven is entirely glass and
that means I’m going to have to grind a hole in the side of it.
Grinding a hole through glass is remarkably easy. You just need a rotary tool
and a diamond-coated engraving and drilling bit. I bought this set on ebay.
It comes with all manner of bits for engraving and grinding. This is the one to
use for grinding a hole through glass.
The procedure for boring the hole is that you need to use your rotary tool on
its lowest speed and you must keep the grinding area wet. I marked a point on
the edge of the bowl just slightly above the higher of the two internal metal
stands and then I put a large drop of water on that spot and set about grinding
through. The water forms a white paste with the ground glass which helps to

grind further down as well as protecting your bit from damage. I worked
slowly and was soon through the bowl without any hassle. I then had to spend
a few more minutes working the hole larger by rotating the bit around and
grinding outwards until the hole was large enough to take the thermocouple.
There it is, no cracks or splinters. It really is easy to grind through glass if you
take it slowly.
And there it is with the thermocouple screwed in and ready so that only the
probe is exposed to the heat and not the cable that runs back to the control
unit. The probe is positioned just above the stand so that it will sense the

temperature within millimetres of the board surface.
The controller housing

I decided to mount the controller inside an ordinary black project box. A rough
hole was cut in the front panel where the LCD would show through. The rough
edges were then masked with a black square of thin plastic film with an
accurate cutout for the LCD visible area. Then I placed a 10x10cm square of
clear acrylic over the top and the four screws go all the way through the panel
and the PCB mounting holes.
Click for larger
Further holes were drilled for the buttons, the 2.5mm SSR cable, the 2.1mm
power cable, the power button on the back and the thermocouple cable.
Insulation tape is wrapped around the back of the thermocouple cable to
prevent the metal braid from shorting anything in the box.

Here it is switched on. The front panel buttons are illuminated and the control
page is being displayed. It’s notoriously difficult to photograph an LCD
display and this photograph does little to convey just how bright and colourful
it is in reality. The controller box feels very light in the hand, maybe I should
glue a brick inside to give it that ‘quality’ feel
The AC control unit

You’re an engineer, you don’t need to be warned
about the potentially lethal dangers of working with
your household mains supply do you? Stay safe, learn
why and how.
In my design I have elected to separate the SSR and its mains interface away
from the sensitive low voltage MCU controller and particularly the MAX6675
thermocouple AD converter. That means that I need to find a second chassis

that is safe to house mains current. I chose to use an old computer PSU from a
long forgotten AT-format computer that was languishing on a shelf in my
garage.
A computer power supply case is ideal for this task because it’s designed to
handle mains voltage, has an earth post on the chassis, and it has an in-built
fan for cooling. Furthermore, these old AT supplies come with a passthrough
connector that was intended for your monitor. In my design this outlet will be
used for the oven routed internally via the SSR. I discarded the 80mm 12V DC
fan that came with the PSU and replaced it with a 240VAC 80mm fan that I
found on amazon.

I noted that the power connectors are rated for 10A but the oven comes with a
13A fuse in its wall plug. It would be a bad idea for the connectors to melt
before the fuse blows so I decided to fit a 10A fuse into the wall-plug.
I wasn’t immediately certain how many amps a 1300W oven would draw until
I searched around on the internet and found that the camping fraternity were
successfully using these ovens at sites that have 10A limits along with all their
other kit without tripping the circuit breakers. Halogen lamps are filament
lamps and so they should be almost purely resistive with a power factor close
to 1.0. That means that the current draw at 1300W ought to be around 5 or 6
amps.
Here’s the PSU chassis after I modded it to hold the mains parts of my project.
The SSR is screwed to the heatsink which is screwed to the bottom of the
chassis. The yellow wires are the control signals that connect back to the
control box with a 2.5mm ‘headphone jack’ cable connected into one of the
existing holes in the PSU chassis that originally held one of the power cables.
The perspective of the photograph makes that 2.5mm socket look a lot closer
to the mains SSR terminals than it actually is but still I would prefer to have a
physical barrier over those mains terminals and indeed Opto22 do sell a cover
separately. I may do something about this issue later but at least for now I
know that the chassis is earthed all the way back to my house supply which is
itself protected by a very sensitive RCD board.
Testing
For my first test run the oven was unmodified except for the hole where the
temperature probe is fitted. The firmware performed as expected, which was a

relief, and the P-I-D co-efficients were set to 1-1-1.
It should be evident from the photograph of the display at the end of the run
that we have some problems that need to be solved.
1. The ramp up time is too slow meaning that the oven cannot keep up with the
profile. There could be a few reasons for this.
a. The surface of the glass, particularly the top, gets very hot. This heat loss
can be addressed with the addition of some insulation material.
b. There’s a metal guard below the lamp that must be there to shield the lamp
from fat spatter when the oven’s being used to cook food. The guard is
drilled but nonetheless it serves to reflect back a significant portion of the
lamp’s output.
2. The PID algorithm doesn’t react fast enough to the cooling down phase at
the end. I can address this by simply stopping the process at the end, or
perhaps tuning the P-I-D coefficients. P (the present) needs to be more
significant than I (the past) to make it react faster to change.
So there I was watching the above test run and in the background my wife was
peering in with that ‘now what’s he up to?’ look on her face. The test finished
and I was muttering to myself about heat loss and how I was going to have to
go off to B&Q to see if I could find some oven insulation. “Why don’t you
line it with tin foil?” came a voice from over my shoulder. You know what,
that might just work was what I thought.
So I lined the bottom and sides of the bowl with foil, shiny side inwards,
leaving the top uncovered so I could get a good bird’s eye view of the board
being cooked and then I re-ran the test when everything had cooled back down
to room temperature. Did it work? Hell yes! At 100% power the ramp up rate
is much faster than that required by the reflow curve and it easily reaches the
peak temperature.

After playing with the PID variables I settled on 30/1/1. These values result in
a very close tracking of the target curve.
As you can see cooling is still an issue and with no way to automatically vent
heat – all I can do is cut the power – the best way to achieve the cool down
phase is to simply lift the lid of the oven. That’s what I did in the above test
run. I also modified the firmware to make it not advance time until the 25°
profile starting temperature is reached.
Fan modding
There’s a metal AC fan in the lid of the oven that operates at a constant high
speed while the oven is operational. It’s designed to circulate the hot air to
help cook food quickly and evenly. I want to keep the fan so that heat is
distributed evenly but the problem is that it’s so strong that it blows small
components clean off the PCB. I need to modify it.
I first thought about slowing it down using an inline capacitor but on closer

inspection I noticed that the fan is actually two fans on the same spindle. Up
above the inner fan there’s another set of blades inside the housing that I can
just see through the vents in the plastic. It’s obviously there to cool the
electronics from all that heat below and that’s a valuable feature that I want to
keep. I decided to modify the lower fan blades to reduce their impact on the
PCB in the oven.
Here’s the unmodified fan. I decided that the easiest thing to try would be to
bend the blades from their default steep angle to a much shallower angle. That
should result in less air being moved and the air that is moved ought to create
a circular vortex around the outside of the bowl.

As you can see the modifications are not too drastic and leave me room to
flatten the blades further if necessary but in my first test an 0603 capacitor
placed on a dry PCB didn’t move at all during the entire test run so I don’t
think I’ll need to compress the blades any more.
Watch the video

I put together a video of the oven executing the SnPb reflow profile. You can
see it by clicking on the player below. Alternatively, click here to view it on
the youtube website.
Open source halogen oven PID reflow controller
The video shows the oven during one of its test runs. There’s a small test PCB

inside the oven with some 0603, 0402 and 0201 components placed at strategic
locations to check that the fan doesn’t blow them away. The embedded close-
up of the controller shows how well the oven tracks the reflow profile. The
ideal track is in green, the actual track is in red. The panel at the top right
shows the actual temperature, ideal temperature and the 2Hz PWM duty cycle
being applied to the oven’s mains supply by the SSR.
Source code and Gerbers

The source code’s available from Github. Recent changes have added support
for the MAX31855 and made it the default supported probe. If you want to use
the MAX6675 then you’ll need to make two small changes before you compile
it.
Firstly, edit Max31855TemperatureReader.h and delete or comment out the

typedef Max31855TemperatureReader DefaultTemperatureReader line at the
bottom of the file.
Now edit Max6675TemperatureReader.h and uncomment the typedef at the

bottom.
The Gerber files are available from my download page. These will be accepted
as a 10x10cm board order by any of the usual suspects such as Seeed, ITead or
Elecrow.
Final words
This has been a fun project, the outcome of which has provided me with a real
enabling tool that will make all my future builds much controlled and
repeatable than they ever have been before. I mean, I was getting pretty good
with a hotplate but there was no way the plate heating ever followed a standard
profile and the danger of burning the bottom of the board that is in contact
with the plate was always just a few seconds away.
If you’re considering building your own reflow oven and have any questions or
comments on what I’ve presented here then please feel free to leave a comment
or send me a message using my website contact form.
Disqus seems to be taking longer than usual. Reload?

FEED AND SOCIAL SUBSCRIBE BY

EMAIL
Enter your email address to receive
Follow @andyworkshop
notifications of new posts by email.
YouTube 1K
Subscribe
Copyright © Andy Brown 2012-2015. All rights reserved | Terms and conditions | Contact

An Open-Source Cortex-M0 Halogen Reflow Oven Controller With TFT LCD - Andys

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

An Open-Source Cortex-M0 Halogen Reflow Oven Controller With TFT LCD - Andys

Uploaded by

Copyright:

Available Formats

An open-source Cortex-M0 halogen reflow oven controller with TFT LCD | Andys Workshop

HARDWARE » STM32 STM32PLUS ARDUINO DOWNLOADS

http://andybrown.me.uk/2014/05/11/awreflow/[7/15/2016 1:44:38 PM]

http://andybrown.me.uk/2014/05/11/awreflow/[7/15/2016 1:44:38 PM]

A custom enclosure for

http://andybrown.me.uk/2014/05/11/awreflow/[7/15/2016 1:44:38 PM]

http://andybrown.me.uk/2014/05/11/awreflow/[7/15/2016 1:44:38 PM]

The difference in quality is immediately obvious. This device is completely

http://andybrown.me.uk/2014/05/11/awreflow/[7/15/2016 1:44:38 PM]

The temperature sensor

http://andybrown.me.uk/2014/05/11/awreflow/[7/15/2016 1:44:38 PM]

Now that the sensor is selected I’m going to need a compatible

http://andybrown.me.uk/2014/05/11/awreflow/[7/15/2016 1:44:38 PM]

This is a grounded thermocouple. That is, there is electrical continuity between

Accept user control input.

http://andybrown.me.uk/2014/05/11/awreflow/[7/15/2016 1:44:38 PM]

The 3.2″ Sony Vivaz LCD

http://andybrown.me.uk/2014/05/11/awreflow/[7/15/2016 1:44:38 PM]

Designator Description Footprint Quantity Value

C2 Capacitor 0603 1 56pF 50V

C3 Capacitor 0603 1 56pF

C4, C8 Capacitor 0603 2 2.2µF

C14 Capacitor 0603 1 10nF

C16 Capacitor 0603 1 10nF

C18 Capacitor 0805 1 1µF 50V

http://andybrown.me.uk/2014/05/11/awreflow/[7/15/2016 1:44:38 PM]

C21, C22 Capacitor 0603 2 100nF

D1, D2, ESD OnSemi

FB1, FB2 Inductor 0603 2 BLM18PG221SN1D

L1 Inductor CDRH5D28 1 22µH

Left, PCB terminal

MCU Header, 3-Pin 2.54mm pitch 1

PWR SEL Header, 2-Pin 2.54mm pitch 1

R4, R5, R6 Resistor 0805 3 1kΩ

R12 Resistor 0805 1 100Ω

R13 Resistor 0805 1 5.1Ω

http://andybrown.me.uk/2014/05/11/awreflow/[7/15/2016 1:44:38 PM]

SPI Header, 5-Pin 2.54mm pitch 1

U2 3.3V regulator SOT223-4N 1 AMS1117

The LCD interface

This is a direct copy of the connector schematic from my Vivaz reverse

http://andybrown.me.uk/2014/05/11/awreflow/[7/15/2016 1:44:38 PM]

The power regulator

3.3V power is provided by an AMS1117 3.3V regulator. The maximum current

http://andybrown.me.uk/2014/05/11/awreflow/[7/15/2016 1:44:38 PM]

http://andybrown.me.uk/2014/05/11/awreflow/[7/15/2016 1:44:38 PM]

The SPI flash

http://andybrown.me.uk/2014/05/11/awreflow/[7/15/2016 1:44:38 PM]

BOOT0 and RESET buttons

Having a reset button is a convenience just in case I need to force an MCU

I decided to include a button that would allow me to control BOOT0 just in

The input buttons

http://andybrown.me.uk/2014/05/11/awreflow/[7/15/2016 1:44:38 PM]

Here’s the heart of the system, the STM32F051C8T7 MCU in an LQFP-48

http://andybrown.me.uk/2014/05/11/awreflow/[7/15/2016 1:44:38 PM]

The SSR output

The PCB design

http://andybrown.me.uk/2014/05/11/awreflow/[7/15/2016 1:44:38 PM]

PCB design thumbnail, click for PDF

http://andybrown.me.uk/2014/05/11/awreflow/[7/15/2016 1:44:38 PM]

http://andybrown.me.uk/2014/05/11/awreflow/[7/15/2016 1:44:38 PM]

The AMS1117 is closely accompanied by its supporting electrolytic and

http://andybrown.me.uk/2014/05/11/awreflow/[7/15/2016 1:44:38 PM]