JuiceBox

The Juicebox was a cheap media player for children that came out around 2007ish, made on behalf of Mattel by a company called Emsoft. It was a bit of a commercial flop apparently. The lack of success in the pre-teen gadget market was likely due to the videos for the device being sold separately on completely proprietary (and quite flimsy) little cartridges containing low resolution, low frame rate video and audio with a limited range of content based around kids TV shows of the day. That and for the same price at release you could go and get a Gameboy Advance and play some games instead.

So it wasn't long before the poorly selling stocks of the Juicebox were being heavily discounted in toy retailers across the land. Which was when the more technically minded among us realised we could buy an ARM7TDMI board with a colour LCD screen from Argos (Or Ebay in my case) for about £5. And the JTAG pads on the PCB inside were readily accessible...

The Embedded Linux Wiki has a lot of useful detail about the device which I relied on heavily in the following activities.

When my Juicebox unit arrived, I turned it on and watched the video included in the on board ROM. Then had a look at the built in self test by holding down the rewind and play buttons whilst powering on.

The Juicebox running its cartridge test.

It was then taken apart, JTAG and serial port lines were soldered in, and hooked up to a JTAG Wiggler.

The Juicebox ready for loading and debugging some code over JTAG. The breadboard has an MAX232 level shifter on it, and also serves to connect a 5V supply to a suitable DC plug.

Using OpenOCD, some test code could be loaded thus:

Run OpenOCD as root:

# openocd -f ~/openocd/doc/configs/arm7_wig.cfg

If you're intending to run code from RAM on the target, enable software breakpoints (consumes one the hardware breakpoint resources so they are disabled by default):

$ telnet localhost 4444
> arm7_9 sw_bkpts enable

On the other hand if you want to force use of hardware breakpoints, say if you're planning on stepping through the assembly in the boot ROM:

> arm7_9 force_hw_bkpts enable

Now in another console, fire up a GDB session and, assuming you've built your binary with debugging symbols, step through some source code:

$ arm-elf-gdb myprogram.elf
(gdb) target remote localhost:3333
(gdb) load
(gdb) b my_function_name
(gdb) c

Alternatively, a binary can be loaded and run using JTAGER:

# jtager
JTAGER:> halt
JTAGER:> idcode
JTAGER:> memset --base=0x0C001000 --infile=myprogram.bin
JTAGER:> restart 0x0C001000

(Change the load address used, based on your linker script)

As well as video cartridges each containing low res video, an MMC cartridge is available. This is nothing but a PCB with an MMC/SD card socket on it, and cartridge pin 20 pulled down, indicating to the on board firmware (Which was uCLinux based) that an MMC card is attached and it should attempt to read and play MP3s from it. On a video ROM cartridge pin 20 is pulled high. The ever talented prpplague on the elinux wiki provided details of a hack for the MMC cartridge in which an xD card (Serving as a NAND flash) is connected to the cartridge connector pings on the MMC cart PCB, and pin 20 is pulled high to make it appear as a ROM cartridge instead. I couldn't find a Juicebox MMC cartridge to buy to try this, so decided to just build one from scratch, with extra space to solder an xD card onto it:

The MMC+xD Juicebox card made from scratch.

The Eagle CAD files for that are here. The Juicebox slot and mini SD socket libraries came from files available on this page. In hindsight I would have tried to source an xD socket as that would have made attaching the xD card quite a lot simpler (And less messy). Note: It seems when I built the SD+xD board I neglected to add such fanciful items as resistors to the pull up lines etc. In fact I can't remember too clearly if it worked at all now, as it was about six years ago as I write this. Perhaps I'll try it out again at some point and update here.

Talk at the ELBC

Around the time I was doing playing with the Juicebox, just after finishing my degree, I was at a conference presenting with one of my lecturers Craig Duffy. I was telling him about my efforts with this cheapo ARM7 system and he suggested doing a little talk about it at the first ever UWE Embedded Linux Boot Camp. Aimed at around A-Level age/pre-university attendants, the ELBC is all about getting a bit of experience with Linux on whatever Embedded devices can be gotten hold of. So the Juicebox seemed like a good fit.

I turned up and gave twenty minutes of advice on how to get started "Hacking Embedded Linux Devices on the Cheap". Here are the slides:

The talking was followed by a demonstration of stepping through some C code running on the device with OpenOCD and GDB.

And after that... well the reality of the situation is that theres not much to be done with the Juicebox. The microcontroller in the system, a Samsung S3C44B0, has plenty of general purpose peripherals for a low end gadget (LCD controller/PWM/GPIO etc), but nothing to handle Video playback, such as codecs or fancy media accelerators. And a 66MHz ARM7 can only do so much on its own. The ROMs on the Juiceware cartridges were likely filled with uncompressed raw interleaved video and audio data, just pumped through to the screen and speaker. Use of the on-chip peripherals is limited by what pins are brought out to usable locations on the PCB.

Due to these limitations, my activities on the Juicebox dropped off soon after the ELBC talk, while I was writing some code to program files from the SD card into the NAND on my home made UMDCart. However, as an educational tool for learning about ARM, a different brand of micros, and a look inside how a low end consumer electronics device might be put together, it served its purpose. Experimenting with an ARM board still has value in 2013, but the ARM7 has been somewhat superseded by the Cortex-Mx line now.