Learning-by-doing: PCB design

As a mini project to learn about hardware design/electronics I thought it would be fun to build some new insides for something. I found a collection of three 'untested' Nokia 6500 slide phones on ebay for a few quid which looked perfect. I intentionally did not do much planning, because it's boring, and there's more to learn by making mistakes if you're willing to accept some failure. Having said that, my basic plan was to make something simple with a microcontroller and common parts, and get it working to learn the process and make some newbie mistakes; then afterwards, make something a bit more complicated (higher density board, BGA, etc) and maybe even useful.

I've only recently discovered that nobody etches their own PCBs at home anymore, because there are overseas companies like Elecrow that can offer this service with professional quality results for a very low price by combining lots of different customers' boards on one panel. They offer a very cheap special offer for 10 identical small PCBs with 6/6 space/trace and 12mil vias. The premium service goes down to 3/3 and 8 but is based on individual quotations.

Common sense says this should have been a 4 layer board, but:4 layer boards are much more expensive than 2 layer. This also had to be 0.8mm to match the original and fit in the phone (even 1.0mm would be too thick, I checked), which added $18 to the price. When you're already paying that much you might as well get it with an ENIG finish as well because it looks nicer... and adds another $18 :/ Also the freeware version of Eagle only supports 2 layers. So for a future version, OK maybe... but for this first prototype that might not have even fit in the case or something, I stuck with 2 layers (scroll down to see the results!). I also didn't push their limits and most of it is 8/8. Some places might be 7 when it was necessary, I can't remember!

I best start off by saying I have no idea what I'm doing - I'm making it up as I go along to see what happens! I found a few mistakes before the boards even arrived (oops!) so a 'revision B' is already in the works. Some of my options were limited, and heavily affected the layout. I did not try and calculate the USB differential pair impedance as it breaks just about every other layout rule out of necessity, but it's only FS anyway so should be OK. Here's what other restrictions I can remember:

• 10x5cm limit, 2 layer PCB (Actually was about 8.5x4.5 and had to be the exact same shape as the original)
• Component heights <= 2mm
• Some places with no components (battery area, and FPC area for the slide)
• Positions of:
• 50-pin LCD connector
• 20-pin Keypad connector
• USB connector
• AV connector
• DC connector**
• Camera connector*
• Battery 
• Volume & camera switches

 * I ignored the camera for now - I don't have a datasheet but I know it's using one of the "top secret" MIPI serial standards and at a guess the MCU won't be fast enough to bit-bang this in any usable manner. Here's a photo I took of what I think is a logo & part code of some description from the image sensor die. I couldn't find anything else that stood out. It's a ~3MP sensor. Maybe I should hook up the I2C bus and see if it responds without any of the other connections...


** I have no use for the DC connector, so needed something to fill the 2.8mm hole. Apparently it's impossible to get a 2.8mm RGB LED, so instead I found these light pipes that work really well. Here's a torch shining through it backwards (not pushed in all the way because it would never come back out). The resulting problem was (assuming my maths worked out) the LED had to be 0.9mm in height from the PCB. PLCC RGB LEDs are nearly double that at 1.6mm. My solution was reverse-mounting the LED in a cut-out so I also had the 0.8mm board thickness to work with (i.e. 0.9+0.8-1.6 = 0.1mm wiggle room). Elecrow charge extra for castellations (it would have doubled the price!) so I made the hole a tiny bit too small and widened it myself.
 
The connectors were quite easy to identify. The 50-pin is a Molex 51338-0574, the keypad is a JST 20R-JANK-GSAN-TF. The usb and battery any cheap ebay version will do. If anyone knows what the 4 little V shaped springy contact things at the edges are called please let me know because I couldn't find anything even similar!

I remembered to take some screenshots along the way:

At this point I decided it was looking a bit unroutable so ripped it up and started again with the MCU at 45 degrees and moved down a bit:

Woo-hoo, finished! Ignore the "Rev. B" - I only remembered to take a screenshot after I sent the gerbers off and started fixing some of the mistakes (so there are a couple of minor changes):

Finished layout (no ground pour for clarity)

Finished layout (with ground pour)

So in 4 days Elecrow had made the boards and shipped them. They took only 8 days to arrive (China post):

They look great, I don't care even if they don't work :)

I didn't spot any flaws in the manufacturing (they're e-tested anyway) and I'm really happy with the results and service for the price. Where the low cost does show slightly is in the alignment of the silkscreen and soldermask. They're both out by about 4 or 5mil (the broken circle around TP18 was my fault - I forgot to change it and it didn't meet their minimum thickness) :

So how did I do with matching the original shape? Spot on actually, I was surprised!

And the first couple of idiot mistakes:

I didn't bother to check the datasheet/measurements for the JST header I picked for the debug interface. It overlapped the battery by a tiny amount so I had to shave a bit off:

I didn't notice this metal thing which bumps into the capacitor at the top of the board. It was that small of a change that it fit by soldering the cap not-quite-centered on the pads:

Aside from those, I didn't have any diodes that fit the footprint properly, but that wasn't really a mistake in the design I just didn't have the patience to buy some and wait.

EDIT: And I've just noticed I messed up the pad names for the volume switches so they're always pressed. D'oh!

Here's the finished rev. A board after soldering:

It passed a smoke test, and was detected OK:

...and it actually seems to work!

Now I need to develop the software/firmware and see if anything else is broken, then get to work on rev. B!

CK 3756 kynar wire stripper - buy one!

I wish I'd bought one of these sooner! Expensive, but it just works:

Mini 3G 150M A5-V11 Router (internals/UART)

This is a generic/unbranded router from dealextreme (product 217078)

There's very little information in the product description, but for my 7 quid I ended up with a board known as "A5-V11", which has a RT5350, 4M SPI flash, 32M RAM. It is supported by openwrt (here) but the current bleeding edge with the defaults set is too big. It fits if you drop the IPv6 related packages.

It's already well documented so there isn't any need for much more here. Worth noting is that a standard SOIC clip (i.e. Pomona-style) won't quite make contact due to the position of the big capacitor in the middle. The micro USB port is only used for power... so for future experiments I wired the UART to it following the same pinout as Mediatek stuff. A resistor is required on RX or it won't boot (value not critical, also works fine with 330 ohm).

Maybe needs a couple of blobs of hot glue

The jffs2 thing is a known bug

HP Printer JTAG

Harvesting parts from a HP Officejet 6310 the other day I saw this:

Of course I couldn't leave something like that without at least attempting to find out what they were for! Luckily I hadn't yet destroyed any important bits so it went back together...

And typically, they didn't seem to do anything at all. Maybe because it had no cartridges? Well I certainly wasn't going to buy any, so I thought I'd take a ROM image and if I got bored enough some day I could have a poke around it. But then - I found a connector header covered over with soldermask. As a 2x19 with central ground pins I took a lucky guess at "Mictor 38" layout and got a JTAG connection.

---------------------------------------------------
VTarget = 2.691V
Info: TotalIRLen = 4, IRPrint = 0x01
Info: CP15.0.0: 0x41059461: ARM, Architecure 5TE
Info: CP15.0.1: 0x0F0D20D2: ICache: 4kB (4*32*32), DCache: 4kB (4*32*32)
Info: Cache type: Separate, Write-back, Format B
Found 1 JTAG device, Total IRLen = 4:
 #0 Id: 0x1594602B, IRLen: 04, IRPrint: 0x1, ARM946E-S Core
Found ARM with core Id 0x1594602B (ARM9)
  ETM V1.3: 4 pairs addr.comp, 2 data comp, 8 MM decs, 2 counters, sequencer
Target interface speed: 100 kHz
---------------------------------------------------

...and that's where my knowledge of JTAG debugging ends at the moment. The CPU is some kind of custom HP "top secret" NXP part that doesn't exist, which makes things a bit trickier. This probably isn't the best way to learn about JTAG either. Nevertheless, I'll just keep prodding it until something pops!


<-- "Door open"?! that's the least of your problems haha

8-layer PCB Scanning - Practice Run (T100s)

If you don't own an MRI (I did check ebay and dealextreme just in case!) then this is a fairly easy, effective, but very slow way of recreating PCB artwork from a multilayer board.

I imagine a Dremel would rip through this in seconds... but that's probably going to cause problems when you only want to remove a few microns at a time. Instead I went for a combo of 120grit alox and 400grit carbide paper. I also nearly got screwed over by HP and their bullshit claims of 1200dpi! Take a look; on the left is a corner scanned on a HP at "1200dpi". On the right, the same corner scanned on a £50 Canon I got from PC World, also set to 1200dpi:

The phone was broken by the way, it just buzzed from somewhere on the back of the board... although I did get a complete eMMC dump by jamming it in a vice with a bit of an IDE connector putting pressure on whatever was broken. It took a few goes as when it warmed up it must have moved just enough to switch off. I also forgot that without a battery you only ever get 13.5 minutes in bootrom mode before it switches off (MT6592). Finally with a PSU pretending to be a battery, I got it imaged in about 17-18 hours.

The concept is straightforward:

While you have remaining layers,
1. Scan a layer
2. Remove half* a layer


*Micro vias are impossible to see if you only scan the copper layers. Take a scan part-way through the epoxy as well. They are pretty small at around 100μm in diameter:

Before:
(yes, I was too lazy to rotate one of these)

During:
(Lesson I learnt is I should have put scrap PCBs around the sides to prevent this from happening)

2 more layers! On the left, remaining 2 copper layers. On the right, sheet of standard 80gsm printer paper. Photo through a 30X lens.

And after:

Chinese magic phone dust is probably highly toxic and definitely stains your hands green, brown or grey. It also ended up in my ears somehow!

Then with a set of scanned layers, use your favourite image editing software to isolate the copper coloured bits. Combine all of those, align them all, job done:

Further improvements that I'd do if this wasn't just a practice would be to neaten up the few areas the colour processing got wrong, and square off the tracks / non-round pads.

I'm still trying to find a program to visualise the layers in 3D. If it was a vector image then it would be straightforward but I couldn't find the equivalent for raster. There isn't even a good file type to save it in... Adobe psd seems to be the most popular :/
If I find something appropriate then I'll upload the whole thing, but at the moment it's 1.2GB and not very friendly.

Focaltech touchscreen oops / Leagoo customer service

I've been playing around with the Leagoo Lead 3 for some time now. Initially I chose this due to price and the fact that it was not just another "counterfeit samsung" like many others. Apart from it having a fairly low spec (but still great for £50!) I really like this in terms of build quality, official ROM update availablility, and as I've just found out, Leagoo customer service is great too!

Nice packaging

It's an unbrickable device - even a full eMMC wipe can be recovered from as the SoC has an internal bootrom that will emulate a low speed uart over usb, which you can then flash the preloader back and go from there.

There is however one more "secret" flash storage area that unfortunately can be erased. It turns out that Focaltech CTPMs have an 8051-based controller with... firmware stored in its own flash memory. A couple of days ago I (somehow) managed to wipe the contents of one, rendering the touchscreen completely useless. The device that you need the part number from is this:

I tried a bunch of random firmwares with (obviously) no luck. They're each tailored to a specific screen. In a last ditch attempt before microwaving the brick* I contacted Leagoo customer services to see if they would send me the firmware. A few emails later... I got it :)

Working touchscreen again

The strange device-to-host i2c comms of this thing still confuse me, but it should be possible to write a kernel module to dump a backup of the firmware which could come in handy when dealing with phones from companies with useless (or nonexistent) customer service *cough* Cubot, Axgio, Landvo *cough*



*and of course a closer look at the mainboard - if anyone has a broken Lead 3 they want to send me for that purpose then I will do!

Reconstructing MTK LCM drivers

This is another one of my "why didn't I think of that sooner" ideas that could have saved me a few days. Basically Chinese touchscreen datasheets do not exist, or not that I can find for free anyway. Out of all of the phones on my desk I only got 1 "close" match for the controller datasheet and it wasn't any use for writing a driver as the screen initialisation info is in the LCD datasheet (I couldn't even find the company that apparently made this screen. I think it probably begins with J!).

From the LK or kernel console, the LCD timings are easy enough to pick out. If you're lucky enough not to have bought an "agold" special then you also should have the name of the LCM controller. Some phones have multiple supported in each firmware (important).

That's great - apart from you don't have the initialisation commands. Again if you're incredibly lucky (or paid extra and got a Wiko/Lenovo/Acer/etc) then you might be able to find the exact driver on github. If not, then either you could randomly keep trying similar sounding drivers (...bad idea!) or just pull the struct from a working firmware's lk.bin. Most (but not all) of the drivers are boilerplate and using the same struct to store the data - there shouldn't be much to change between devices.

Example:

qHD 4.5" screen, driver IC either RM68191 or OTM9605

Looking at lk.bin, in the chunk of data at the end: the RM68191 data was first (sequences start with "0x55 0xAA 0x52 0x08 0x03" as seen in similar drivers), then the OTM9605 data that I wanted for this phone. It's in the same layout that you would expect knowing the struct: cmd (yellow), count (green), para_list (red)

22 columns made things line up nicely

I dd'ed just the initialisation data out and formatted it ready to copy/paste using this (note: minimal error checking etc - common sense may be required!)

Then put it all together and try it out to see if you missed anything...

This sort of thing happens if you miss a bracket!

Typo fixed and then it worked fine. Figured it was pointless to add a photo of a working phone though!