Data recovery from a broken android tablet (aka Everything with a CPU has a serial port!)

Some weeks ago I destroyed my tablet, let’s say “by mistake”. I actually destroyed the display first, and then the connector from the motherboard (the one and only board in the tablet) and the LCD.

The tablet itself was nothing special (~100€) so I’m almost glad I can now  look for a better one, would I need it (…I really did not…).

Namely it’s a TrekStor SurfTab (ST10216-2).

So, no problem at all… except… WTF! The files inside it! …well, files that are not SO important (in that case I would have saved them somewhere else of course) but still, manuals and application notes that would be boring to recollect.

But, as Plato used to say: Everything that has a CPU on which some flavour of linux is running, MUST have a console serial port!

So I started looking for some probe-contacts (probably used with some sort of pogo-pins during the early life of my tablet) and discovered where the console serial port is (pretty easily, they are near the CPU); so I share some pictures:

serialtablet

And:

serialtablet2

It turns out it’s a LOW VOLTAGE (i.e.: 3.3V, DO NOT attach it to a standard RS232 port) serial port running at 115200bps.

After attaching it to a 3.3V USB-Serial adapter and powering (I detached the battery and powered it through the battery contacts with a bench PSU), that’s what my terminal showed:

screenshot

And after issuing the su command, I’m root inside my tablet.

Nice 🙂

Now I can finish destroying the rest of the tablet.

PS.: OK, on my device I found that the cp command is not available, but I discovered that busybox is, so the command to use is busybox cp <src> <dest> (…it even accepts wildcards!, found it here); in particular I used the sdcard to tranfer all valuable data.

A KiCad script to programmatically create simple labels

KiCad is a great tool and one of its features I like more is scripting. Here I want to share a very simple script that helps in generating labels using KiCad, pcbnew in particular.

The idea is very simple:

  1. A “reference” label is created on the first copper layer, with known placeholders inside text labels;
  2. The python script is modified by inserting the correct placeholders and the text strings we want on the labels;
  3. The python script is executed, which replicates the labels on the other copper layers;
  4. The generated layers are printed and after some cutter work, the labels are ready.

The kicad-ized python script and the example pcbnew project can be downloaded from here (it would not deserve a git repo, but wordpress does not allow uploading zip files…). I used this script to generate some labels to organize the resistors obtaining this:

kicad_labels

Of course, to generate different labels both the python script and the pcbnew file must be modified, but it’s very trivial.

Happy printing,
Cheers 🙂

Daisy-chained 74HC595s controlled by SPI on STM32F4 – part 1 : working principle

[part 1 part 2]

In this post I will describe a simple project. The idea is to use a bunch of daisy-chained serial-in/parallel-out shift registers (namely the 74HC595) to expand my STM32F4Discovery board.

First questions: the discovery board has a plenty of GPIOs, so why not using them directly? In other words: why using external circuitry to obtain something that can in principle be obtained simply using the GPIO configured as outputs?

Some reasons:

  • With only 3 wires on the controller side we can control multiple outputs; this simplifies circuit routing;
  • the number of outputs can be increased simply by increasing the daisy-chain length (at the cost of slower update speed);
  • using the SPI in DMA mode, the CPU is free to perform other tasks while the external outputs are updated; this can become a substantial performance improvement if the number of lines we want to control is greater than 16 (the size of the GPIOs per register);
  • the ‘595 can produce 5V signals.

Of course this approach has also some cons:

  • More devices are needed, one ‘595 per 8 lines, this has a cost and requires space on the PCB (but more signals do, too);
  • more devices have to be powered;
  • the update speed of the output lines is limited by the speed of the SPI channel and the ‘595 propagation time; and the more the output lines we want to control, the slower the maximum update speed.

The reference circuit that I’m considering contains four 74hc595 registers, allowing to control 32 output lines:

stm32_74hc595_schematics

Of course, for practical applications the output of the ‘595s can be routed to a suitable connector instead of the LEDs.

If 3-state outputs are needed, the G input of the ‘595s can be controlled by (separately per chip or all together with a single line); in our case the ‘595s outputs are always active.

The 74HC595 contains two main items: one 8-bit shift register and an 8-lines latch. Simplifying, the working principle of the ‘595 is simple (pin names reported on datasheet from various manufacturers may vary, so I’ll refer to the names reported in the previous figure):

  • At the rising edge of the clock input SRCLK, data present at SER input is loaded into the shift register;
  • when a rising edge is detected at the RCLK, the data contained in the shift register are presented at the outputs QA..QH;
  • ‘595s can be daisy-chained thanks to the shift register output, at /QH;
  • a shift register clear input SRCLR is available, as well as an output enable input G.

The timing diagram of the 74HC595 is reported in the following figure, in which a single pulse is propagated in the shift register and presented at the output pins:

74hc595_timing

So, the basic (and far from being novel) idea is to write four bytes to one of the SPIs of the STM32F407 microcontroller of the discovery board to update the 32 output pins in a single operation using the DMA.

In the next post, the code for the STM32F4 microcontroller will be described.