Atmel ICE, JTAG and the ATmega32U4

Having spent a lot of time working with AVR microcontrollers I decided a number of years ago to invest in a dedicated In Circuit Emulator (ICE). At the time Atmel had just released their new Atmel ICE device. This seemed to fit the bill perfectly. atmel-ice_angle1024Not only did it support  traditional JTAG debugging but also debugWIRE. Atmels own propriety debug protocol aimed at low resource devices such as the ATMega88/168/328 family. I purchased the Atmel ICE basic kit. The kit consists of the Atmel ICE and a 10 pin ribbon cable to 10 to pin JTAG (0.05″ pitch) and 6 pin (0.1″ pitch) SPI connector. The full kit available at a much greater cost shipped with a number of different cables and adaptors. As debugWIRE uses the RESET line for debugging I deemed the 6 pin SPI cable would be all I needed. Or so I thought.

Moving on a few years I find myself now working with the ATmega32U4 again (I needed USB functionality) and to my surprise this device does not support debugWIRE only JTAG. What!!! How can this be?

I was wondering if Atmel sold those additional debug cables separately? Turns out they do but they are almost £50. After shelling out just shy of £100 in the first place I wasn’t prepared to spend another £50 on cables.
adaptor
So I set about building my own adaptor. The main problem I faced was the Atmel have used 0.05″ (1.27mm) pitch connectors rather than the more readily available standard 0.1″ (2.54mm) pitch connectors. What I needed was some form of breakout board or even something to convert from the 0.05″ pitch connector to something more manageable. After trawling the net it turns out Adafruit have a Cortex SWD adaptor which in essence is a 0.05″ pitch to 0.1″ breakout board. The pin mapping is one to one so assuming you ignore the silk screen it should be easy to interface to the ATmega32U4. The best thing about this solution is the price, I managed to get two of these boards from a local supplier for just £3.

The development board I am currently using is an OLIMEXINO-32U4 an Arduino Leonardo type design from Olimex. The table below shows the Cortex SWD to AVR JTAG pin mapping. Also shown is the JTAG connections of the 32U4 (or Arduino Leonardo if you prefer) development board.

# SWD Pin JTAG Pin Olimex 32u4 Pin
1 Vin TCK A3 (PF4)
2 SWIO GND GND
3 GND TDO A1 (PF6)
4 CLK VCC VCC
5 GND TMS A2 (PF5)
6 SWO RESET RESET
7 KEY N/C N/C
8 N/C N/C N/C
9 GND TDI A0 (PF7)
10 /RST GND GND

Below you can see a picture of my setup. I am not sure if they are needed but I did add 10K pull ups to all of the control lines TCK, TDO, TMS and TDI.

board1

One thing that had not dawned on me was the fact JTAG is not enabled by default. The pins designated to the JTAG interface PF4-PF7 are used as analog inputs. So in order for JTAG to work you need to ensure the JTAGEN fuse is programmed. This can be done through the ISP interface in the normal manner. Once I had that programmed I could successfully download and debug my code on target. Result.
Advertisements

Raspberry Pi Internet Radio

I am a big fan of internet radio stations but it can be a bit restricting listening to my favourite stations on my laptop or phone. So over the last couple of weeks I have been building my own internet radio. A lot of people have converted old routers into radios but the best example I found was Bob Rathbones amazing Raspberry PI Radio. I had an old Raspberry Pi 2 lying around not doing much so I decided why not give it a try. Bob provides on his website an extremely comprehensive guide that takes you through the process of building an internet radio which if you’re interested you can download here.

At the heart of this radio is Music Player Daemon (MPD) running on Raspian Jessie. MPD is a flexible, powerful, server-side application for playing music. Through plugins and libraries it can play a variety of sound files while being controlled by its network protocol. Bobs manual provides a detailed overview of construction and software. It contains instructions for building the radio using either the HDD44780 LCD directly wired to the Raspberry PI GPIO pins or alternatively using an either an Adafruit RGB-backlit LCD plate or the PiFace Control and Display (CAD) . An I2C backpack is also now supported. It can be constructed using either push buttons or rotary encoders. An optional infra-red remote control can also be used. Along with the construction guidelines Bob also provides software to drive the LCD, read the switch states and interface with the MPD server.

When I started I had a pretty good idea of what I wanted to achieve with this radio. I wanted a 4×20 HDD44780 based LCD display, push buttons for control (rather than rotary encoders) and a pair of 4″ coaxial speakers. I wanted it to sound as good as possible so decided early on to use a Digital to Analogue Converter (DAC) rather than relying on the line level audio output on the Pi. A network connection would be via WiFi rather than a LAN connection. It would also have the ability to play music from an external USB device. Possible even the ability to control it with an old infra-red remote control.

The enclosure was constructed from 9mm MDF sheet. The dimensions of which were based around the two coaxial 4″ speakers and the LCD display. I didn’t want anything too big but I also didn’t want it so cramped inside that everything wasn’t going to fit.

enclosure2.Using Front Panel Designer I drew up a template to aid with the drilling of the holes for the speakers, the switches and the panel cut out for the display. The whole thing was then glued and joined with furniture blocks before being painted.

While in my local Maplin store I managed to bag a pair of 4″ Vible Slick Coaxial speakers from their clearance section for a good price. They fitted the bill perfectly. The speakers are driven via a 2x30W audio power amplifier kit from Velleman. The amplifier has an RMS output of 15W into 4 ohms and is protected against overheating and short circuits. The LCD display is driven directly by the GPIO lines of the Raspberry Pi. As are the switch inputs. inside3aIn order to minimise the wiring somewhat I built a little interface board between the display, the switches and the header on the Raspberry Pi. I added a small potentiometer to the interface board to allow the overall volume to be configured.

Power for the Raspberry Pi is provided by the official mains power supply while the amplifier is powered via a 12V 50VA toroidal transformer. As I have already mentioned I wanted the radio to sound the best it possibly could so I opted to use the HifiBerry DAC+, a little expensive costing nearly as much as the Pi itself but it was definitely worth it. I am no audiophile but when driven hard those 4″ speakers sound great. With the addition of a panel mount USB socket music can also be played from a USB device.

Total spend is probably approaching well over £100, even already having the Raspberry Pi, but I am really pleased with the result. I have now have a fully up-gradable internet radio with around 600 stations configured that I can control remotely and sounds and looks amazing.

LG 32LC56 Power Supply Repair

I recently inherited a completely dead LG 32″ LCD TV from my parents. Apparently this TV set was working fine one day and completely dead the next. So I thought I would have a look and see if I could get it back up and running. Upon receiving the set the first thing I did was try and power it up. Nothing completely dead. No standby light nothing. Checked the fuse in the plug (obviously) and that was fine. Time to dig a bit deeper.

With the current symptoms the obvious suspect is going to be the power supply. The internet is strewn with examples of power supplies going bad in these TVs and people on eBay are even selling repair kits for anyone wanting to repair them.

After carefully removing the back panel I had managed to expose the power supply board. I must say a bit of a beast by all accounts. But if you think about the job it has this is to be expected. Fortunately most of the connectors were labelled with the expected output voltages. Probing around on these pins showed no voltage on any of them. Checking the mains into the board gave a reading of around 230V AC. Checking the voltage after the 5A fuse on mains input read nothing. Turns out this fuse had blown. Question is why?

On closer inspection smoke damage can be seen on the large heat sink holding the power transistor, bridge rectifier and rectifier diode on the input stage. My first thoughts were one of these may have been damaged but on closer inspection it turns out the smoke was caused by a 220 pF 2Kv ceramic disc capacitor just in front of the heat sink (shown in the image above directly between the transformer and the heat sink) exploding. Which explains why the fuse may have blown. Probing around the remainder of the input stage the other components appeared to be fine as far as I could tell. Turning my attention to the electrolytic capacitors (shown above) on the output stage I could immediately see a number of these were starting to show the tell tale signs of failure with at least three of them having significant bulging. So I decided I would replace all of them just as a matter of course along with the ceramic disc capacitor that had blown.

Once all of the new components had arrived and been fitted along with a new fuse I powered up the board on the bench and now had a 5V standby voltage present. After fitting the board back into the TV and a quick press the power button on the side and the TV sprung back into action. Result. So a nice easy fix this one. Total spend was about £3 whereas a refurbished power supply board runs to around £30. And for a TV only worth probably that in the first place it hardly seems worth it.

Build a Performance Quadcopter for under £150 – Part 2

I would like to start off by saying thank you to HobbyKing for their extremely prompt service. I now have in my possession a cardboard box full of quadcopter parts. I wasn’t going to waste any time getting started.

The first task was to assemble the frame. The frame consists of two glass fibre plates, an upper and lower plate, as well as four coloured plastic arms, two red and two white. How you configure of these arms is entirely up to you. I decided I would have the two white arms pointing forwards while the red arms pointed backwards. Attaching the arms is simply a case of screwing them to each plate with the screws provided. I found it easier to attached the arms to the lower plate first before adding the upper plate. If your following along with your own build be careful not to over tighten these screws and I would suggest investing in a decent set of hex drivers before starting.

With the frame assembled I then moved on to attaching the motors. This was simply a case of lining the up the holes on the motor with the holes at the end of each arm and using the screws provided with the frame to secure them in place.

Keeping this post short because I have run out of time for now. Next up I will be preparing the speed controllers and flashing them with Simon K’s modified firmware. So stay tuned.

Build a Performance Quadcopter for under £150 – Part 1

With summer fast approaching I decided it was high time I started a new project. I have been toying with the idea of building a quadcopter for a while now. The internet is littered with websites and videos detailing other people’s builds so I decided to give it a go. What will follow hopefully is a number of successive posts detailing my build process. Which should provide enough instruction for other people to build their own.

From the outset I had a fairly rough idea of what I wanted to achieve but for a little more inspiration I started reading a other peoples builds. One if the best builds I found was from a chap named Daniel J. Gonzalez. He based his quadcopter around a 330 mm frame which seemed like a good compromise to me. Click on the picture below to jump directly to the build on his blog.

Daniel J. Gonzalez My First Quadrotor

Daniel J. Gonzalez’s My First Quadrotor.

Like Daniel I opted to use the Hobby King F330 glass fibre frame. For the flight controller I decided on the Hobby King KK2.1.5 based purely on the customer reviews. Apparently the KK is easy to set-up and flies exceptionally well. It may well do with a competent pilot but time will tell how it copes with me in control. The speed controls I chose were the Hobby King blue series controllers. These are a fairly standard controllers however they can be flashed with Simon K’s high performance firmware optimized for quadcopter use. More on this later. The motors were Turnigy 1100kV outrunners which I am hoping should produce more than enough thrust to get the quadcopter off the ground and maybe even enough to carry a GoPro in the future.

The complete shopping list is shown below:-

Part Quantity Cost ($)
Glass Fiber Mini Quadcopter Frame 330mm 1 11.75
D2822/17 Brushless Outrunner 1100kv 4 20.00
Hobbyking KK2.1.5 Multi-rotor LCD Flight Control Board 1 19.99
HobbyKing 20A BlueSeries Brushless Speed Controller 4 39.40
GWS Style Slowfly Propeller 8×4.5 Black (CW) (4pcs) 1 2.63
GWS Style Slowfly Propeller 8×4.5 Black (CW) (4pcs) 1 2.62
Turnigy High Quality 14AWG Silicone Wire 1m (Red) 1 1.56
Turnigy High Quality 14AWG Silicone Wire 1m (Black) 1 1.56
Turnigy High Quality 18AWG Silicone Wire 1m (Red) 1 0.60
Turnigy High Quality 18AWG Silicone Wire 1m (Black) 1 0.80
10CM Servo Lead (JR) 32AWG Ultra Light 1 2.46
PolyMax 3.5mm Gold Connectors 10 PAIRS 2 4.20
Turnigy 4mm Heat Shrink Tube 1M (Red) 1 0.85
Turnigy 4mm Heat Shrink Tube 1M (Black) 1 0.73
Turnigy 5mm Heat Shrink Tube 1M (Red) 1 0.77
Turnigy 5mm Heat Shrink Tube 1M (Black) 1 0.68
Nylon XT60 Connectors Male/Female 1 3.92

Total spend = $114.52 + $8.09 (shipping) = $122.61 which was approximately £89.42 GBP at the time of purchase. All that was required to complete the build would then be a suitable 3S LiPo battery pack and radio system. I hadn’t decided on which radio system to use so opted to leave that until the initial build was complete.

Parts on order so the next post I shall start the build process.

GPS Data Logging

Over the last few weeks I have been playing with a couple of U-Blox NEO-6 Global Positioning System (GPS) receivers I purchased from eBay. What I love about these receivers is they are extremely easy to use. Once powered is applied the receiver starts outputting positional information. The two receivers I have both use a UART interface. However I believe the chip set does support other interfaces including SPI and USB.

Support for these receivers from U-Blox is second to none. As well as a comprehensive manual U-Blox also provide free evaluation software known as U-Center which allows you to evaluate and test these modules in real time. The receivers may also be configured using U-Center.

By the time I received the receivers I already had a couple of projects I wanted to use them for. First off I wanted to build a standalone GPS display device similar to the Quanum GPS Logger V2. The main use for these appears to be for carrying out speed runs of radio controlled cars and planes. Although not massively expensive I figured it would be much more fun to build something similar rather than going out and buying one.

Secondly I wanted a dedicated GPS logging device. As I keen cyclist I am regularly out and about on my mountain bike and often find myself off the beaten track in the middle of nowhere. What would be nice would be the ability to record these routes and import them into Google Earth when I return home. Of course I can track these routes on my phone using Strava or My Tracks but I wanted something a bit more robust. Something I wasn’t overly worried about getting damaged.

Reinventing the Wheel

As I have already mentioned the NEO-6 receivers output positional information via a serial interface. They support two protocols a propriety binary protocol and the National Marine Electronics Association (NMEA) standard. The NMEA standard uses a simple ASCII protocol to send sentences to listening devices. The typical baud rate for this protocol being 4800 baud however my receivers came preconfigured to use 9600 baud. The default update rate for these receivers is every second which is more than adequate for logging purposes.

When it comes to importing this information fortunately Google Earth is now able to import NEMA logs directly without the need for conversion. In the past NEMA logs would have to have been converted to Keyhole Markup Language (KML) format in order to use them with Google Earth. Thankfully this is no longer the case.

So with the receiver continually outputting NMEA messages all that was required was the ability to capture these messages and save them to external media. Now there is no point reinventing the wheel and I figured there must be a whole host of data loggers out there cable of logging serial data. Sparkfuns OpenLog seemed like the ideal solution. OpenLog is an open source Arduino based data logger. Running on an ATMega328 micro controller OpenLog stores received data to an external microSD card. Cards up to 64GB are supposedly supported.

Rather than buying an OpenLog module I built one using a Arduino Nano and a microSD card breakout board. Worked out a lot cheaper in the end. The serial output from the GPS receiver was then fed directly into the Arduino Nano UART RX pin. I did make one minor change to the original OpenLog sketch. By default OpenLog creates new files with the “.TXT” extension. I changed this to “.LOG” which is file type Google Earth is looking for when importing logs. The device is powered via the USB connector, I have it attached to a portable USB power bank at the moment.

logger

I have done a couple of test runs with it and it works great I have logged a couple of bikes rides as well as a 300 miles round trip in the car. All of which imported into Google Earth perfectly. All that remains is to get it into a suitable enclosure.

 

Driving OLED Displays

In a recent project I used a small 128×64 pixel OLED display module. These modules are great because the provide a clear and vivid display while requiring no back lighting. The display I used had a Systech SSD1306 controller fitted. The internet is rife with examples of code for driving these displays so I had it up and running with fairly minimal effort.

Having decided to use these displays on another project I am currently working on I found them on the R/C model site HobbyKing. Turns out the MultiWii flight controller (Arduino based flight controller originally using gyroscopes and accelerometers from the Wii controllers) uses an add-on OLED display module which no surprise features a 128×64 OLED display driven but the SSD1306 controller. As I was already ordering from Hobby King I decided to bundle one in with my order.

When the display arrived I assumed since both modules used the same display drivers the code I had already written would work out of the box. Wrong! Come on things are never that simple. Time to start investigating. First thing was to look at the two displays see how they compare. One thing that strikes you straight away is the lack of components on the new display (yellow PCB) compared with the old display (blue PCB).

Working_labelledWorking display module.
Not_Working_labelled

Not working display module.

Next step was to start reading the data sheet to see how this controller is configured. The pin out for the connections to the display can be seen below. I have also labelled them on the pictures above.

Pin Connection Description
1 N/C No connection. (GND)
2 C2P Charge pump capacitor.
3 C2N Charge pump capacitor.
4 C1P Charge pump capacitor.
5 C1N Charge pump capacitor.
6 VBAT DC/DC converter supply.
7 N/C No connection.
8 VSS Logic ground.
9 VDD Logic power supply.
10 BS0 Protocol select.
11 BS1 Protocol select.
12 BS2 Protocol select.
13 CS Chip select.
14 RESET Driver reset.
15 D/C Data/Command select. In I2C mode, this pin acts as SA0 for slave address selection.
16 R/W Read/Write.
17 E/RD Enable Read/Write.
18 D0 Input/output. When I2Cmode is selected, D0 is theserial clock input SCL.
19 D1 Input/output. When I2Cmode is selected, D2 & D1 should be tired together andserve as SDAout & SDAin.
20 D2 Input/output.
21 D3 Input/output.
22 D4 Input/output.
23 D5 Input/output.
24 D6 Input/output.
25 D7 Input/output.
26 IREF Brightness current reference.
27 VCOMH COM signal high voltage. A capacitor should be connected between this pin and VSS.
28 VCC OEL panel power supply. A stabilization capacitor should be connected between this pin and VSS when the converter is used.
29 VLSS Analog ground.
30 N/C No connection. (GND)

The controller has an internal charge pump regulator circuit for generating the 7.5V required by the display. Two external capacitors are required. These are connected between C1P/C1N and C2P/C2N and can be seen on both displays.

Both VCC and VCOMH have decoupling capacitors down to GND as outlined in the data sheet. The brightness current is set by the resistor between IREF and GND. The working display using 910K while the non working display opting to use 560K. The 3.3V regulator provides the required logic voltage.

Interestingly it turns out the controller supports communication over I2C, SPI (3 and 4 wire) and parallel. The protocol selection pins BS0-BS2 allow different protocols to be selected. Both displays have BS0 and BS2 are tied to GND while BS2 is tied to the positive supply which as expected sets the mode to I2C.

When configured for I2C mode D0 acts as the serial clock input. The data sheet stipulates that D1 and D2 should then be connected together to act as the serial data line. On closer inspection of both displays it becomes apparent this is the case the working display (blue PCB) but not with the non working display (yellow). Another thing the working display appears to have pull up resistors connected to SCL and SDA. Something you would expect with I2C comms. The non working display has no pull ups fitted.

Having said that the non working display appears to have three unpopulated foot prints on the PCB allowing for pull resistors to be fitted and for D1 and D2 to be connected together. So the first I did was to add and a zero ohm link between D1 and D2 joining them together. I didn’t bother with any pull up resistors. After fitting the display back into my development board and powering up to my surprise it worked!!

I can only assume when configured for I2C operation D1 acts as the serial input to the controller while D2 acts as the output. Joining the two must allow the acknowledge bit set by the controller to be read by the driver. The driver could have been modified to remove the need for the acknowledgement but this would have meant changing the code to be device specific which I didn’t want to do.

One nice feature on the old display is the ability to change the slave address. In I2C operation the Data/Command pin can be configured to set the lowest bit of the slave address SA0. Allowing the slave address to be either 0x78 or 0x7A. Meaning more than one display could fitted on the same bus.

Another slight gripe is the lack of power on reset circuitry on the new display. The working display has a simple reset circuit comprising R1, C1 and D9. The RC network ensures the reset pulse is present while the supply voltage rises keeping the controller in reset while the supply stabilises. D9 allows C1 to quickly discharge on power down in order to generate a reset pulse on power up in the case of short power downs or spikes. Having the reset pin tied directly to the supply, in the case of the new display, means the reset pin will rise of the same rate as the supply which is not ideal. The track could be cut and a reset circuit added but since it worked I wasn’t going to start modifying it.