Fast Flash Download, 7 to 10 Seconds
The fast flash download is a feature that allows you to download the
entire MP3 player firmware in only 7 to 10 seconds! That's much
faster than the original intel-hex based download, which takes
2 to 3 minutes. This speed comes from two factors:
- 2.7 X increase due to efficient binary encoding, with slight compression
- 6 X increase due to using 115200 baud, instead of 19200 baud
Is Your MP3 Player Board Compatible?
The Fast Flash Download code resides inside the 87C52 chip, which
is not flash upgradable. All 87C52 chips programmed by PJRC
after May 11, 2002 have the Fast Flash Download. To check if your
board has a 87C52 chip with the Fast Flash Download, look for
this message as the player starts up:
Program Name Location Type
Memory Editor (VT100) 1000 External command
Fast Flash Download 1500 External command
If your board has the original 87C52 programming, you will need
to swap it with a new chip. You can
order a 87C52 upgrade chip.
If you have blank a 87C52 chip and an EPROM programmer capable of
writing it, you can download the source code from CVS, compile it
and use PM2_MP3.HEX to program your own 87C52.
In most cases, we provide free upgrade chips to active developers
(those who have CVS write access and are actively working on the
firmware development). If you are a developer, please contact
us about getting a new chip.
Rev C boards can use the fast 115200 baud download, but
Rev A and Rev B boards require a small modification
to receive data properly
at 115200 bits/second (six times faster than the original 19200).
.FDL vs .HEX File Formats
A new binary data format is used for the fast flash download.
Firmware encoded in this format is named with the extension
.FDL (Fast DownLoad). New firmware
revisions should include both .HEX and .FDL firmware images.
If you have only a .HEX version, you can use the
hex2fdl perl script
to create a .FDL file from the .HEX file:
hex2fdl mp3player.hex > mp3player.fdl
Linux Based Instructions
This xmit115200 utility program
is used to transmit the .FDL firmware to your MP3 player. The
utility is provided as C source code. You must edit the code and
set PORT to the name of your serial port, and then compile the code
using the command described in the comments.
Fast Flash Download is easy with Linux, since the Linux kernel
allows multiple processes to write to the same serial port.
This simple utility can do all the work for you, regardless of
which terminal emulator you use.
You should run your terminal emulator as usual (minicom, seyon, etc)
and follow these simple steps:
Here is what you should see in your terminal emulator's window:
- Get to the PAULMON2_MP3 prompt (type 'QUIT' or 'S' at startup)
- Erase the flash rom (the 'Z' command and Yes, you are sure)
- Run the xmit115200 utility with "xmit115200 < mp3player.fdl"
(note the redirect to stdin, which is required)
PAULMON2_MP3 Loc:02000 > Erase flash rom
Erase flash rom, Are you sure?
Flash rom erased
PAULMON2_MP3 Loc:02000 > Fast Flash Download
Begin Fast Flash Download:
Fast Flash Download Finshed
OK: No Errors Detected :)
PAULMON2_MP3 Loc:02000 >
Windows Based Instructions
Franck created a nicer Windows fast download utility on May 12, 2003.
|Franck's WIN32 XMITFDL utilitiy|
Here is his message regarding the program:
It was raining last week end, so i have written a more sexy tool to
fast download my firmware version rapidly to the player.
I'ts working only on WIN32 platforms in graphical mode.
Zac Bedell ported the xmit115200 utility to Windows on May 21, 2002.
Here is the message he posted:
XmitFDL is a small TTY terminal + specific tools for the PJRC MP3
player, as the Fast Download at 115 200. This is much more easy to
use than the (efficient) usual xmit command line. WIN32 platforms only.
VB Sources have been posted in the file section.
I've uploaded binaries & source for doing the new fast firmware
upload on Windows machines.
One is built w/ CygWin, and requires all the various Cygnus runtime
installed to work -- perfect for the developers out there. This
version is directly based on Paul's xmit115200.c, and should work as
a direct drop-in replacement for Paul's version. The binary
defaults to COM1 (/dev/ttyS0), and takes the FDL file as its
standard input. If you need a different COM port with this version,
you'll have to build it yourself.
The other ZIP is built w/ Visual C++, and should require only
Microsoft C Runtime to function. It is built w/ Visual
Studio .NET, so you might need to get the latest CRT, but I don't
think so. This version is written from scratch with native Win32
API calls, and it behaves a little differently from Paul's
as it does a Z flash erase before starting the upload. This version
can take the FDL info on stdin just like Paul's, but it can also
take a filename on the command line. You can also specify the COM
port on the command line.
Some valid usage examples of the VC version:
xmit115200_VC COM1 mp3player.fdl
xmit115200_VC COM2 < mp3player.fdl
hex2fdl | xmit115200_VC COM4
xmit115200_VC < mp3player.fdl
hex2fdl | xmit115200_VC
Of course, both of these versions will require you to disconnect any
terminal software you're debugging with before you can use them.
If anyone wants to write macros for TerraTerm or SecureCRT to
disconnect, run the upload, then reconnect; that'd be nifty?
Let me know if anyone has major problems using these. You'll of
course need a new 87C52 from Paul and a Rev C or modified Rev A/B
board AND A GOOD SERIAL CABLE ;-) for this to work. I've tested
it w/ a Rev B board on a P-4 running WinXP, for what it's worth.
Protocol Specification For Fast Flash Download
Fast flash download is begun by typing '~' (tilde) at the
PAULMON2_MP3 prompt. The message "Begin Fast Flash Download:"
is printed to indicate that the fast flash download is
waiting for data.
Bytes received are written into consecutive locations of the
flash rom. No flow control is used.
The fast flash download can receive data and commands at a
sustained rate of 115200 baud! The one exception is a brief
delay required between the baud rate change command and transmission
of data at the new baud rate. A sequence of waits and delays
are implemented on the MP3 player at the end of the transfer
to allow time for the PC to gracefully return to 19200 baud
after it has transmitted all of the data. These waits/delays
also allow the MP3 player to "swallow" extra data after an
abort or error and still allow a graceful return to 19200
baud even when the PC is unaware that an error occurred that
caused the transfer to abort.
Eleven bytes are reserved for
embedded commands, where two of those commands are used to
encode those 11 bytes when they occur within the firmware image.
Some commands have 1 to 3 additional data bytes. Bytes
following a command always have their most significant bit
set (values 128 to 255). Any byte without its MSB set
causes its command to be treated as an Abort Transfer command.
- 0x29 - Set Address: (3 data bytes) Sets the address where
bytes are to be written into the flash rom. Byte #1: bits 0-6,
Byte #2: bits 8-14, Byte #3, bits 7,15,16 (packed in three lowest bits).
- 0x1D - Skip Undefined Section: (1 data byte) Advance the
current address. Byte #1: number (minus 128) to add to the current address
- 0x59 - Escape Special Byte: (1 data byte) Byte #1: actual
byte to write into flash rom, after clearing the MSB. Allows values 0 to
127 to be written, but in practice it's only used for 10 of these 11
reserved bytes. Those 10 bytes were chosen because they are the
least likely to occur within the firmware image (0x1B is ESC, but also
happens to be unlikely in the firmware image).
- 0x5A - Zero: (no data bytes) Write a zero at the current
address. This special code is used instead of the slower 0x59 because
zero occurs very frequently in the firmware image, and zero must cause
an abort as described below.
- 0x2D - Two 0xFF's: (no data bytes) The next two bytes of
the firmware image are 0xFF. This provides some compression of strings
of 0xFF (common in the FPGA config data), and the fast flash download
only verifies that those bytes of the flash are erased to 0xFF.
- 0x19 - Three 0xFF's: (no data bytes) The next three bytes of
the firmware image are 0xFF.
- 0x3C - Checksum: (2 data bytes) Compare the running checksum
to the 14 bits provided, and set the checksum error flag if they do not
match. A dot '.' is printed if they match, and a plus '+' is printed
if they do not match. Byte #1: bits 0-6, Byte #2: bites 8-14.
- 0x6A - Set 115200 Baud: (1 data byte) Change baud rate to
115200 bits/second. Byte #1: 0xB4=normal, 0xB5=wait for keystroak
before returning to 19200. A brief delay (10 ms) is recommended
after sending this command before transmission begins at the new baud
rate. Of course, this command must be completely received at the
current baud rate.
- 0x58 - End Of Transfer: (no data bytes) Marks the end of
data transfer. This is the only way to end without an error displayed
that the transfer was aborted.
- 0x1B - Abort Transfer: (no data bytes) Abort the transfer (ESC key).
- 0x00 - Abort Transfer: (no data bytes) Also abort. Nearly anything sent at 19200 baud and received at 115200 will contain a zero, including the ESC key.
At the end of a transfer, initiated by either the End Of Transfer command
or the Abort Transfers commands, the following sequence is followed by
the MP3 player:
- Wait for 40 ms of silence. When a transfer is aborted due to
an error, this allows the PC to transmit the remainder of the data.
The MP3 player will not continue the sequence and return to 19200
baud until there has been no data for 40 ms.
- Wait for a keystroak, if the baud rate switch command specified
this option. This is intended for PC software which can not determine
when its serial port buffering (in the UART or operating system) has drained.
The PC may wait for a "safe" time to allow all the
data to leave at 115200 baud, then switch back to 19200 baud and send
a single byte to allow the MP3 player to continue. The Linux-based
xmit115200 utility does not use this option.
- Delay for 50 ms. This provides just a bit more time for the PC
to switch back to 19200 baud.
- Print a summary of the download (at 19200 baud) and indicate if
any errors occurred.
The checksum is implemented with a 16 bit register that is initially
zero, and it changed with addition and exclusive OR operations as
data and certain commands are received. A checksum command causes
14 bits to be compared to 14 of the 16 bits in the checksum register,
and the register is then reset to zero.
The checksum is updated in the following events:
Rev A and Rev B boards require two modifications to receive
data at 115200 baud. Of course, the 87C52 chip must have support
for the fast flash download, so all Rev A and Rev B boards will
require a 87C52 upgrade, as well as Rev C boards made before
May 11, 2002.
- Normal Data: A word composed of the byte in both the upper and lower
8 bits is exclusive-OR'd with 0x5600, and then added to the checksum
(cksum += (byte | (byte << 8)) ^ 0x5600)
- Zero Command: Treated as normal data with a value of 0 (cksum += 0x5600)
- Escaped Data: Treated as if the data byte had occurred as normal data.
- Address Command: Each of the data bytes is exclusive-OR'd by a constant
and added to the upper 8 bits of the checksum (cksum += ((byte1 ^ 0x6B) << 8) +
((byte2 ^ 0x5A) << 8) + (byte3 << 8))
- Skip Undef Command: The data byte is exclusive-OR'd by a constant
and added to the upper 8 bits of the checksum (cksum += ((byte1 ^ 0x4E) << 8))
- Two FF Command: 0x5D00 is added to the checksum (cksum += 0x5D00)
- Three FF Command: 0x3C00 is added to the checksum (cksum += 0x3C00)
The first modification is to replace the 1N4007 diode near
the FPGA chip with a 1N4148. The 1N4148 is installed in the
same polarity as the original diode. It is important to
disconnect the serial cable before the 1N4007 is removed,
as it protects the input of a 2N3904 transistor.
|Rev A&B Mod #1: Replace 1N4007 Diode With 1N4148
Other "small signal" diodes will
probably also work, though only the 1N4148 has been tested.
The original 1N4007 diode has a slow reverse recovery time,
which causes no trouble at 19200, but it is not fast enough
for 115200 baud and must be replaced.
The second modification is to add a 1K "pullup" resistor,
connected to the RXD pin on the 87C52 and +3.3 volts. This
figure shows where to solder this resistor:
|Rev A&B Mod #2: Add 1K Pullup Resistor To RXD Pin
The 1K pullup is needed
to make the 2N3904 transistor recover from "saturation"
so that 0's aren't stretched. The effect of the 2N3904
saturation is minimal at 19200, but significant at 115200.
With these two simple mods, and of course a chip swap
of the 87C52, the rev A and B boards can use the new
fast flash download, which is able to download the entire
firmware in approx 7 seconds!