This is how to resurrect a ‘bricked’ MK809IV Android TV Stick by removing the lid, and with the help of a schematic, you can put the device into factory programming mode by shorting a pair of microscopic pins. It is then possible to reprogram System-on-Chip’s integrated, hidden NAND (flash memory) using factory software.
The Devices
MK809IV and MK808/MK808B devices are inexpensive (as low as £22) portable Android/Linux computers for your TV. They are complete computers, nearly as small as a memory stick.
Despite the cost, they’re actually quite capable for general use on a TV. They often come with 2GB of RAM, 8 or 16GB of storage, WiFi and Bluetooth, and a Mali GPU easily capable of playing back 720p TV or 1080p with a lower frame rate. That’s enough to watch videos, use basic apps, or play simple or retro games like on any other Android device.
Many of these TV sticks look identical. However, there are many variants, and the board and chip design can vary. Most of them run anything from Android 4.4 to Android 6. This is a common case design:
MK809IV common outer case
Identifying the Board
The device is simply held together with plastic clips. The tools required to complete the job are:
- A thin plastic spudger to separate the two halves of the device.
- A very small, jeweller’s flat-head screwdriver to short two specific pins.
- USB extension with two male ends, one for power only.
- A USB power supply capable of delivering at least 2 amps.
For nearly all boards in embedded devices, the model and revision is printed on the PCB. In this case, the board’s model number is H122, Version 1.4:
MK809IV board H122 V1.4
Often you can put devices like this into a special programming mode by shorting the NAND chip’s Clock pin to Ground. This has to be done properly timed, and without guesswork as to which pins to use. You then remove the short, and the NAND chip can be reprogrammed without desoldering it.
Delayed Data Corruption
Several of these models appear to exhibit issues with data corruption over time. Apps can crash on startup, and, eventually, the device becomes stuck in a boot loop. If you try to restore default settings by using the tiny reset button whilst applying power, then there is a permanent situation where you get no output on the HDMI port at all. Luckily, it appears as though the fault isn’t with the chipset, and these devices can be recovered.
The boot loop with this device involved:
- The blue light starting dimmed for a couple of seconds, then becoming slightly brighter.
- An ‘Android TV’ logo for about 3-4 seconds.
- An ‘MBOX’ logo for about 20 seconds.
- The screen going blank and starting again from the ‘Android TV’ logo.
No NAND Chip
Most MK809IVs seem to have a NAND/eMMC chip of some kind soldered onto the board. This device has no such chip — just bare solder joints. Since the device must have erasable flash memory somewhere, it had to be inside the CPU package, like a System-on-Chip (SoC) architecture, where various devices are integrated onto one chip. This is a bit like ‘Famiclones’, where an entire NES/Famicon gaming console is embedded on a single chip.
Resetting and Data Corruption
Pressing the reset button on the dongle, with a blunt paperclip, whilst applying power can appear to do the right thing initially. However, with this device, it tried to erase the /data partition, which took a little while. Then, after the automatic reboot, instead of rebuilding the partition, the device simply showed a black screen. The blue ‘Power’ light was somewhat dimmed in comparison to normal, which appeared to indicate that the device didn’t boot at all.
When starting up from power on, the Bootloader is the first place the SoC looks for machine code instructions on how to do the initial stages of boot, such as starting the chipset initialisation for the operating system. This partition resides at address 0×0 in the NAND chip, and should never be altered, even if the operating system is replaced or upgraded, because it usually acts as the final point of recovery. This partition had clearly been corrupted, and the device was ‘hard-bricked’.
The first thing to try was getting the blue LED to go to the bright state again. However, the device was no longer sending or responding to data on the USB bus. It looked like the Bootloader partition of the NAND chip had been erased, replaced, or corrupted. This should never happen, since the Bootloader should never be written to – even if the operating system is erased.
These devices are unlikely to be programmed before soldering, so the only solution looked to be using factory software to reprogram the device. There is a way to get them into a factory-programming mode, by shorting the Clock pin to Ground on the NAND chip whilst applying power.
Isolating System-on-Chip NAND
Luckily, it is possible to get hold of schematics online, which show the specific pins (usually the ‘Clock’ and ‘Ground’ pins) to short on the NAND chip. This results in the SoC’s NAND being put into the ‘MASKROM’ (factory reprogramming) mode. The usual way of upgrading the firmware is ‘LOADER’ mode, but that requires booted firmware and interrupting the startup sequence. In this case, you have to short pins 29 and 30 (‘I/O0′ and ‘I/O1′) together during startup, which I’d imagine has the same effect as shorting ‘Clock’ to ‘Ground’, since it would prevent any communication on the data bus.
The schematic is a required prerequisite to a repair like this. It is definitely not a good idea to randomly try shorting pins on any Printed Circuit Board. This is where this specific board required a temporary short:
MK809IV (H122 V1.4, no NAND or eMMC chip) solder pads
Reprogramming
Software required:
- Rockchip Batch Tool (any recent version).
- AndroidTool (any recent version).
‘Rockchip Batch Tool’ is used to rewrite the Android 6 firmware for this class of devices, whereas ‘AndroidTool’ can replace individual partitions. This is sometimes needed to fix incorrect signatures — meaning you can then write and boot an operating system partition from another image.
When in ‘MASKROM’ mode, the CPU provides very basic functionality on the USB bus — just enough to get the NAND programmed.
Oddities with PSUs and Cables
This particular USB stick only wanted to be flashed with specific cables – others produced programming errors. Upon analysis with a USB voltmeter and ammeter, it appeared that the fault was not with the power supply, which could deliver a solid 2 amps without dropping below 5 volts.
Since the device was plugged up to a computer for reprogramming, only 0.5 amps would be delivered. This meant a special ‘split’ USB cable had to be used to boost the current, with the power also connected to a 2 amp power supply and the other side connected to the PC’s USB power. Even attaching a good quality (or so I thought) USB extension caused the programming to fail. It is helpful to have a USB power meter like this:
USB voltage and current meter
This power meter’s data pins are routed from the male end to both the female ends, which has the potential to cause corruption. This means you should only plug into one of its two ports at a time. It also does not support above 9 volts, so it should not be used with chargers which can deliver above that voltage.
What Went Wrong?
When fixed, in normal operation, this device looked like it was working properly, but over time it would become ‘bricked’ again. The cheap, included, USB power cable seemed to be the cause of poor NAND writes during wear levelling. Since System/Bootloader data is rarely written, these areas are a prime target for the controller to consider reallocating, to help with NAND wear. This can cause a block of rarely written system data to be moved to another location and never be re-written. Thus, the device can’t find the Bootloader, and nothing happens when you apply power.
The Solution
After reprogramming the device for a second time and simply replacing the USB cable with a higher quality one that does not produce voltage sags, the device was fine from that point onwards.