Hardy har har.. On a whim, we decided to enter the hardware bootloader mode by holding the MENU/POWER button while resetting the device. The vendor flash tool supplied in the SDK mentioned in our first DPF article worked like a charm!
We reflashed our COBY DP-151 with the generic firmware pre-built in the SDK. It ran OK, but the display was in portrait mode and appeared to be configured for the wrong LCD as the screen was dark and low contrast – almost unreadable.
To recover from this “wrong firmware” semibrick, we simply entered hardware bootloader mode again, and flashed the entire 2MB dump generated by Dermaik’s dump tool that we posted in the first article. That worked too! And the device was back to life.
So we’ve just verified hardware bootloader mode, verified that there is no checksum or filesize requirements on what is to be flashed, and enabled unbricking of all those poor test devices that died for a good cause.
Not bad for a day’s work!
One very interesting attribute that will have to be investigated is the flash tool’s requirement of a /Firmware folder with a SPI_LIB.BIN file. This certainly looks like the same kind of stub upload that we were talking about, to process the firmware flash without relying on the just-erased-fimware itself to process USB and SPI commands. Exciting stuff, especially if it shows us how to upload and execute software from RAM without writing it to flash first. That function may be bootloader-specific, but we will see what we can do.
For those of you who just want the flasher program, we’ve made a zip file with only the necessary components. Please unzip with directories, as the ProgSPI tool is going to look for a /Firmware subdirectory in order to fetch the SPI_LIB.BIN stub.
Here’s the flasher program only: AX206_HW_Bootflasher.
Last, for those of you with a COBY DP-151, you’ll note that it doesn’t have an explicit reset button. Since you must toggle reset while holding MENU/POWER to access the hardware bootloader, a little circuit board twiddling is in order. Click this pic to open it in a large size, and look directly below the left hand pins of the CPU for the text that says R6.
Fig 1- The DP-151 PCB Top Side
OK, found the R6 label? Just below that is a round test point – this is reset (!MCLR). In order to reset the device, you will need to ground this test point and then release it. We used a set of alligator clips with a small wire held in one. Clip to the shell of the USB jack to get ground, then hold the menu button and tap the reset test point with the small wire. Boom, you’re in. If you find yourself stuck in the bootloader, just tap this reset point (without MENU) to restart the device.
When you first press the MENU/POWER button the device will probably turn on, giving you backlight as an indicator. As soon as you ground and release the reset pad, that backlight is going to go out, indicating that you are in the loader. You can release MENU now, and plug in the USB.
UPDATE: You can do it all with USB connected. MENU+RESET will put it in bootloader mode while it is still connected.
The device will identify itself as a HID device instead of a CDROM, and at this point the ProgSPI tool will detect your dpf and light up channel 1 in green. Select your bin file, and go!. We usually use “Program” mode instead of “Update” mode as we’re guessing that’s a more complete erase/write. If the “Reset” check box is ticked, then the ProgSPI tool will reboot your DPF into the new firmware as soon as the flashing is done.
All in all, this is very easy stuff. And with the existence of a working hardware bootloader, this device can now be considered “brick-proof”! You can put any old garbage in flash, and the ProgSPI tool will be able to overwrite it with a virgin image whenever you want. Remember, it’s expecting to see a gang of 16 devices, all with blank flash chips – it doesn’t care what the heck you have programmed, it’s getting factory overwritten.
Which brings up an interesting point. Some devices automatically enter bootloader if their boot flash is empty. Think of the poor production line tech trying to press MENU/RESET on 16 devices at a time…? Definitely not machine-automatable. Maybe just erasing the flash is good enough to enter bootloader and use ProgSPI? It would save a lot of hassle for people who don’t have a RESET key. Just erase the flash, replug, and reflash. Something we’ll have to try.
UPDATE: Ya, an empty flash chip sends you straight to bootloader mode.
Enjoy, folks!
Hey, just wanted to let you know that directly next to the RESET test pad is a capacitor’s GROUND pad. Cap is the little grey square just south of the test point. So you don’t need alligator clips or any of that – just use tweezers or a rounded paperclip or something to short that test point to the cap terminal right below it – this is the easiest way to reset. In fact, it’s so easy you can do it accidentally just trying to touch the test pad!
Hey, does anybody know the pinout of exactly that screen. I bought exectly this Coby-Keychain by accident and now I try to use it with an AtMega328 but I can’t find the pinout on the Internet.
Thanks in advance!
We don’t, but you can probably find it out if you can determine the actual LCD module. Our time is too thin to put much effort into it at the moment but there are some other projects to connect the LCD to a propeller. Otherwise, let’s work together to try to figure it out!
And if any of you readers have the pinout or can scope/LA it to determine the pinout, please jump in!
For volume applications, typically the flash is programmed prior to soldering it down. Which is why most micros have a way of programming via SPI, they have machines that chug those things out. I used to work along-side the micro support group for a un-named giganto-corp, and they would typically pre-program prior to delivery to the assembly house.
can anybody help me here?
http://imageshack.us/photo/my-images/213/flashg.jpg
In one of those directories is an ini file that has definitions for various types of flash memory. The flash tool needs the info to determine how to flash the DPF. If your flash is not recognized you’ll have to add it, or change the definition for a similar flash to use your is strings. Beware, flashing with unknown settings can make your DPF catatonic, but its not too big a deal since the bootloader is in hardware and therefore you can always try again.
I’ve got what I believe is an AX206-based key chain (Kaiser Baas), I’ve managed to successfully rip the firmware using AX20xDump_Tool but I can’t program anything into it. Entering regular USB mode causes the SPI Programmer to display “Programmable Device Number: 0, Renewable Device Number: 1″ and none of the channels are showing any devices connected. Attempts to flash the original firmware back into it pops up the error message “No device”. Seems to me that I’m not entering hardware bootloader mode, although I’ve tried several combinations of reset + menu (this device has a reset button). Any ideas? Or is this most likely one of the devices that can’t be hacked?
Answering my own question…the keychain I was using was years old. I tried again on one of the Kaiser Baas units being sold these days and everything worked perfectly. Guess they’ve only started including the bootloader code recently.