Well if you’ve read in our First and Second Articles on the cheap little 1.5″ digital photo frames, we’ve started some hacking attempts. So far, we’ve lucked upon the Vendor’s official SDK, which consists of the source code for the whole damn device! plus some miscellaneous tools that will help in development.
Long story short, their firm built fine for us with some makefile cleanup – those issues may, of course, be due to our own incompetence. But if it doesn’t build for you first time, you might as well read about our trials and tribulations in hopes of getting you up to speed a little quicker. Please note that none of the generic LCD libs included in the vendor SDK is working “off-the-shelf” with the COBY DP-151. We hope to have that corrected ASAP. But for now you have your choice of: Properly rendered photos but malformed menus, or reversed LCD with a few pixels offset. Suck!
So while we toil with disassembly of the factory fresh firmware dump (which matches the vendor asm files quite nicely for the most part), we can download our combined knowledge to you in order to plant a few seeds of development in other places. Hopefully, they’ll sprout and you’ll take over once we’ve exhausted our skillz on this device.
Fig 1 – Doh! DP-151 Running Newly Compiled Vendor Firm (with Wrong LCD Lib)
Hehe – Yup the color is good but the LCD setup is obviously fux0r’d. Offset, portrait mode instead of landscape, and oh yeah – it’s freakin reversed! Very sad, we wanted to try to play the vendor-supplied pacman game with only two buttons!! Well, actually we did play it – as you may expect it sucks with only up/down movement. But at least with only freedom in the Y-direction, we didn’t get motion sickness due the reversed LCD!
But on the bright side, this proves that it’s at least POSSIBLE to home-compile the vendor firmware. And additionally… That the firmware is properly flashed to, and recognized by, the COBY device. So let’s talk about the flasher for a moment.
AX206 Firmware Flash Tool
In the /Tools directory, there is a program called ProgSPI.exe. However, it needs the ini files from the main directory, and refers to the SPI_LIB.BIN in the /Firmware subdirectory. The easiest thing to do is to to run i from the root dir with a
or just copy it from /Tools to one directory up, the root of the SDK’s world. It runs fine from there.
The software was put in /Tools because the very clever and very useless UEStudio can spawn an external process with a different home directory than where it resides. Woop de doo. After installing UEStudio and working with it for a day, we dumped it. It’s not necessary and is basically UltraEdit with an extra menu. We are rabid UE users here, but crap is crap. Forget UEStudio, you don’t need it for this build.
Fig 2 – AX206 Firmware Flash Tool In Action
As we mentioned in the second article on this device, this flash tool is used by the hardware bootloader and can erase and reprogram the entire flash memory of the device. It uses a bin file format that is pretty much blindly written to the SPI flash on the device. The bin file contains the fimware, the CDROM ISO image that is presented to the user upon standard USB plug, as well as any sample pictures that are preloaded on the device. The SDK’s makefile builds this bin up from the assembled firmware plus any desired “Resources” such as the CDROM ISO and the generic pics.
Also in that second article we mentioned that there was no checksum in the device but that was incorrect. What happened is that when we dumped the firmware the proper checksum was already in the flash and so it was read out into the dpf_dump.bin file. If you’re going in to the bin files to hex edit stuff, you’re going to need to rechecksum the bin file using CRC.exe out of the /Tools folder. It updates the crc’s at locations $09-0A and $0E-$0F in the bin file, and it expects a file with 00 00′s in those locations. It will work on a file with arbitrary bytes in those locations, but trying to re-crc a file into itself doesn’t work – so be careful.
AX206 Software SDK
This is only an overview of how the SDK is structured and how to get up and running. But in order to explain their crazy structure and making scheme, you have to first consider the codebanking scheme. We’ll give an overview of that, first, and then jump into the SDK and making stuff. Once you’ve got your mind wrapped around the codebanking, you’ll want to go read all the gory details in the AX206 Development Handbook as mentioned in the first article.
All in all, this is a very clever use of a severly RAM limited system. In essence, all the functions such as pic decoder, menu,clock, games, are written as little separate chunks of code. When the micro wants to switch from one function to another (or when it needs to make a function call residing in a different chunk) it reads the new chunk into RAM and then passes execution to it. So the thing is just switching back and forth between different firmware chunks as you switch between functions, etc. How interesting!
We’re amazed that it appears to run so quickly, as it seems that it must be constantly fetching chunks out of the relatively slow serial EEPROM. We would have expected a strongly annoying delay, but perhaps since it’s so slow anyway you just don’t notice. This is a clever technique to keep in your back pocket, folks – if you happen to be designing a system that needs to do many different things (but not all at once), consider seriously if you can just load one function at a time. You could eliminate the large and costly flash block from your CPU, and transfer it to a relatively cheap external SPI flash.
We are using the vendor-recommended Keil C51 compiler, as we have it on hand and we didn’t want to have to translate to some other tool. YMMV, and you could possibly get away with using a free tool if you’re willing to put in the time hacking it up. Please let us know if you get the SDK built using free tools, and we will certainly do the same. In actuality, you don’t need the compiler, just assembler and linker so it seems there’s a very good chance… Well, it’s speculation for another day.
All righty – back to the source code.
By now, you should have unpacked the SDK files (with directory structure!) and taken a peek around. Most directories are source code for various function chunks (they call ‘em sectors, so we should probably do the same) but there are a few notable directores that are a little different.
Firmware – Holds the SPI_LIB.BIN that is used by the vendor flash tool, as well as a header file pointing out the various functions stored in it. Definitely looks like it will come in handy one day.
LCD – Holds many sub-directories for various LCD screens. You choose your screen in config.ini in the root dir, don’t muck about here. But if you want to add your own LCD screen support, you WILL want to generate a new subdir inside LCD. Then, just add your subdir name up in the LCD section of config.ini, and you can make the standard firmware with your own LCD lib.
Tools – Contains DOS tools for working with image files, as well as the SPI programmer and a cygwin make. Although most of this crap resides here, it expects to be called from a different directory. So instead of cd’ing into Tools and firing make, you would actually do a “.toolsmake all” from the root directory of the SDK.
And friends, please don’t use UEStudio or the stupid batch files. Here’s all you need to know.
.Toolsmake all – To compile, link, and glob all the files together into a nice bin file for upload to the device.
.Toolsmake clean – To clear out all the crap from the last build in order to start fresh. You’ll need it if you change something, as make will skip over any directories that have their final built OBJ’s and HEX’s already residing in them. You are free to just delete the files from the directories you’re working in, but when laziness finally takes over, make clean make all.
At this point we must inject some warnings and notes – you may have seen them posted as a comment in the first article, but here they are in entirely.
One important note on the subject of make! If you have other cygwin tools (WINAVR, Xilinx, gcc) residing on your system and you simply type “make”, windows is going to go use one of the other cygwin makes running in a csh or something. This ends up puking and dying with stupid error messages about anything with a semicolon, such as S( or D(.. And there’s plenty! You will know you have a problem if you see errors like
/usr/bin/sh: -c: line 1: syntax error near unexpected token ‘S(‘
Annoying! The fix is to stub out the path, so all the precious SDK’s and other cygwin crap you have on your system is essentially invisible to the DOS session you are residing in. To clear out your path, just do a
set path=c:windowssystem32 or even
Now try it again – boom, you linked, right? Well, at least stage 1, eh? Remember that next time you open a DOS prompt your path will be back to normal, so you will need to do this again each session. Or, just never close that session like we do.
The next issue we ran into were unresolved reference warnings bombing us out of stage 2 linking. This is totally weird, as we found nothing that would indicate this “strict” mode. It’s a side effect of the sector-based approach, when used with a linker that expects to glob everything together right at the start. Perhaps in time we will find the actual fix for this idiocy, but for now it can be fixed by simply suppressing this warning in each offending makefile.
The warning is suppressed by adding DW(1,2) in the linker statement of the makefile, and more specifically – the stage 2 linker statement. It’s easiest to just show an example, so here is the Stage 2 linker statement from the Audio sector’s makefile.
Stage2 : LINK_Config = RS(256)
which must be changed to
Stage2 : LINK_Config = RS(256) DW (1,2)
And before too long, you should be the proud owner of a shiny new build. The output file (DPF206.bin) is suitable for flashing using ProgSPI.exe, and contains all of the little pieces (that you’ve decided to include) all assembled up and packed into one nice file. We suggest that you run a couple of factory standard builds before going and changing anything, just to prove to yourself that it DOES build properly (or DID before you started messing with it) as well as to give you some practice with the somewhat clunky make flow.
Your homework for next time is to study Config.ini, ResPos.cmd, and the SDK docs.