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:




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:


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:


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 2 : code

[part 1 part 2]

In this post the code I will present the code related to the simple project described in my previous post.

Basically this piece of code send some data through one of the SPI using DMA. This approach has two nice properties: the CPU does not have to wait until the transfer has finished; moreover, if the data at the 595s’ outputs need to be maintained for a certain period of time (e.g.: in order to communicate with some old slower logic) one can use the circular mode of the DMA to manage the timing, again without afflicting CPU performance.

So, first we want to configure the STM32 peripherals for our purpose. For this purpose, using the nice STM32CubeMX from STMicroelectronics is seems perfect.

The STM32CubeMX project can be downloaded from here, but mainly we:

  • configure clocking (the external crystal is 8 MHz, this involves the RCC configuration)
  • configure some GPIOs (the 4 LEDs and one line to control the RCLK input of the 595s)
  • configure the SPI
  • configure the DMA to use the SPI
  • configure the SWD (Serial Wire Debugging)
  • configure the USART (for debug)

The complete code, that can be downloaded from here, mainly performs the following tasks:

  • Perform some initialization (mainly generated by the STM32CubeMX utility)
  • Enter the main cycle in which:
    • Prepare the data to be sent to the 595s
    • Move the RCLK pin on PC3 (the setSTCP function)
    • Start the DMA transfer
    • Collaterally some LEDs on the discovery board are toggled and the time required by the DMA to perform the transfer is measured and sent through the serial port.

Of course, take a deep look at the code to understand what it exactly does before executing it on your device.


Happy coding 🙂



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:


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:


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.

Using SCons with GNU toolchain for ARM on Windows – part 3 : the SCons script

[part 1 part 2 part 3]

So we have prepared the code that we want to compile using SCons.

1. Command prompt

Since SCons will be invoked from the command line, it’s nice to have a batch file that will open the prompt with the necessary settings; so let’s create the following file in the project folder and call it shell.bat:

REM Add Python and tool-chain locations to system path
set PYTHON_PATH=C:\Python27


start cmd.exe

Of course the specified paths must be substituted with correct ones. Now, if we double-click on the shell.bat file, a new command prompt will be opened.

2. The SCons script

Let’s then create a file in the project folder and call it SConstruct with the following contents:

# gnu arm toolchain must be already in system path

import os
env = Environment(ENV = os.environ)

env['AR'] = 'arm-none-eabi-ar'
env['AS'] = 'arm-none-eabi-as'
env['CC'] = 'arm-none-eabi-gcc'
env['CXX'] = 'arm-none-eabi-g++'
env['LINK'] = 'arm-none-eabi-g++'                # predefined is 'arm-none-eabi-gcc'
env['RANLIB'] = 'arm-none-eabi-ranlib'
env['OBJCOPY'] = 'arm-none-eabi-objcopy'
env['PROGSUFFIX'] = '.elf'

# include locations
env['CPPPATH'] = [

# compiler flags
env.Append(CCFLAGS = [

# linker flags
env.Append(LINKFLAGS = [
    '-TTrueSTUDIO/Discovery001 Configuration/STM32F407VG_FLASH.ld',

# defines
env.Append(CPPDEFINES = [

# build everything
prg = env.Program(
    target = 'main',
    source = [

# binary file builder
def arm_generator(source, target, env, for_signature):
    return '$OBJCOPY -O binary %s %s'%(source[0], target[0])
env.Append(BUILDERS = {
    'Objcopy': Builder(


This is our SCons configuration file. SCons experts will deservedly turn their nose up, because it’s super-simplified. SCons can do a lot more and better, but this script works and proves how it can be used to cross-compile for our target.

What the script does is very simple:

  • In the first section it set the parameters that inform SCons about the toolchain we are using.
  • Then the include libraries are added, together with compiler and linker flags.
  • Finally all the sources are compiled and the final program is built. Afterwards the produced .elf file is converted in the binary form suitable for uploading to flash.

3. Building and uploading the project

In order to build the project, open a new command prompt by double cliccking on the previously created shell.bat file and type scons.

If everything works, at the end you should read something like “scons: done building targets.” and a couple of files should now be present in the project folder: main.elf and main.bin.

The second one can be uploaded to the MCU flash using the command:

openocd -f board/stm32f4discovery.cfg -c "init; reset halt; flash write_image erase main.bin 0x08000000; reset run; shutdown"

After some seconds, the board should start blinking, and if you connect to the USART2 port some chars are received.

Happy coding!

Using SCons with GNU toolchain for ARM on Windows – part 2 : the code

[part 1 part 2 part 3]

After downloading and installing all the necessary tools (see my previous post), I will create a project for the discovery board using STM32CubeMX tool.
The application will just send some bytes through the serial port USART2 and light the LEDs on the discovery board.

 1. The STM32CubeMX project

So, let’s start creating the STM32CubeMX project. The STM32F4Discovery board I’m using is equipped with a STM32F407VGT6 MCU; so that’s the platform I’m going to choose in the new project wizard.

The various configuration steps are described in the attached figures, and I’m not going to detail every step since they are relatively straightforward.

a) Peripheral selection

Peripheral Configuration

b) GPIO configuration

Pin Configuration

c) clock configuration

Clock Configuration

d) Peripheral configuration: USART2
USART Configuration
e) Peripheral configuration: GPIOs
GPIO Configuration
f) Project settings: project
Project Settings - code generation
g) Project settings: code generator

Project Settings2. Code generation

Now the code can be generated by clicking on the Project > Generate Code menu. If requested, allow STM32CubeMX to download the necessary device libraries.

The generated project looks like this:


3. Code editing

The generated code (see Src/main.c) does nothing but configuring the MCU hardware, so we need to edit the code to send data through serial port and light up the leds.

Let’s modify the main.c file between the /* USER CODE BEGIN 3 */ and /* USER CODE END 3 */ as follows:

  /* Infinite loop */
  uint8_t c = 'A';
  uint16_t cnt = 0;
  while (1)
	  HAL_UART_Transmit(&amp;amp;huart2, &amp;amp;c, 1, 10);
	  if(c == ('Z'+1)) c = 'A';
	  switch(cnt) {
	  case 0:
		  // green led on
	  case 100:
		  // green led off
	  case 200:
		  // orange led on
	  case 300:
		  // orange led off
	  case 400:
		  // red led on
	  case 500:
		  // red led off
	  case 600:
		  // blue led on
	  case 700:
		  // blue led off
	  cnt = (cnt+1)%799;
  /* USER CODE END 3 */

This code just sends chars to the serial port and lights on and off the leds on the discovery board. In order to see the sent chars (from ‘A’ to ‘Z’) we will need a TTL to RS232 level converter or a LVTTL USB serial port interface. Let me stress that because of different voltage evels you cannot connect the discovery board directly to an RS232 interface.

What we still need is is the startup file. A working startup file can be downloaded from Coocox public repository. I admit, I didn’t check this file, but it works. So, download the file a put it into a new folder named sys in the Src folder of the project, and rename the file startup_stm32f4xx_fromCoocox.c (to remember from where we got it).

In the next post the SCons script will be created and used to build the application.

Using SCons with GNU toolchain for ARM on Windows – part 1 : necessary tools

[part 1 part 2 part 3]

SCons is a software construction tool, a sort of alternative to the ubiquitous GNU make. What makes SCons very interesting in my opinion is that its configuration files are actually python scripts.
In this very brief – and probably imprecise – post I just want to jot down a way to use SCons with the GNU toolchain for ARM, under Windows 7.
What I’m going to do is produce the project infrastructure with the nice STM32CubeMX application from STMicroelectronics and compile it with SCons.
So, let’s start from the beginning.

1. Install GNU toolchain for ARM

Download and install GNU toolchain for ARM. Download it from; in my case I downloaded and installed “gcc-arm-none-eabi-4_9-2014q4-20141203-win32.exe“.
During installation, it’s better NOT to add the toolchain path to the environment, as this will be managed in a suitable batch file in order to keep the system environment clean.

2. Install OpenOCD

Download and install OpenOCD from; in my case I downloaded and installed “openocd-“. Here, “installing” means extracting the content of the downloaded archive somewhere.

3. Install the cable drivers

Now I guess it’s a matter of which h/w is used. In my case I’m using an STM32F4Discovery board, which embeds an ST-LINK/V2 cable, and I’m working under Windows 7 64 bit, so I downloaded the STSW-LINK003 drivers from STMicroelectronics website.
After installation, the STM32F4Discovery board is recognized as a “STMicroelectronics STLink dongle” peripheral, under the “Universal Serial Bus devices” category in the device manager.

4. Install the Python language

I’m working under Windows 7, which does not include “native” support for python, so it must be installed. SCons requires version ❤ of python, so let’s download and install python 2.7.x from the official website.

5. Install SCons

Now we can download and install SCons. Download the archive from SCons website; in my case I downloaded the source version 2.3.4 and followed the instructions on the SCons manual (python install).

In the next posts the project will be generated and a SCons script will be produced.