Shopping Cart Checkout Shipping Cost Download Website

Home

MP3 Player

8051 Tools

All Projects

PJRC Store

Site Map

You are here: MP3 Player Detailed Info Fast Flash Download

Search PJRC

PJRC Store Main Board, $150 LCD & Pushbuttons, $42 LCD/Backlight/PB, $77 IDE Cable, $9 Complete Parts List MP3 Player Main Page Detailed Info About The Player Photographs LCD User Interface Upgrade Instructions Fast Flash Download Physical Size Disk Format, Linux Troubleshooting User Photo Gallery Connecting The Board Firmware Download Side Projects Technical Docs Freq. Asked Questions FAQ #2 News And Updates

Fast Flash Download, 7 to 10 Seconds

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?

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

hex2fdl mp3player.hex > mp3player.fdl

Linux Based Instructions

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:

1. Get to the PAULMON2_MP3 prompt (type 'QUIT' or 'S' at startup)
2. Erase the flash rom (the 'Z' command and Yes, you are sure)
3. 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 Summary: OK: No Errors Detected :) PAULMON2_MP3 Loc:02000 >

Windows Based Instructions

• Stand-Alone Version
• VB6 Version, includes Visual Basic 6 Source

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.

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.

• Visual C Version (stand alone)
• CygWin Version (requires CygWin developer environment)

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 version 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

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:

1. 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.
2. 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.
3. Delay for 50 ms. This provides just a bit more time for the PC to switch back to 19200 baud.
4. 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:

• 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)

Rev A & B Modification For 115200 Baud

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!