Please note: This description is outdated because some details of the protocol have been changed. However, the principle is still the same.

---

EtraxFlasher is organized in 4 stages, each of them used to transfer a program image.

The reason for using multiple stages is that each stage requires a bit more of hardware that has to be initialized before it can be used:

Stage	Started by	Max size	Features used	Tasks
1	ETRAX boot	784 bytes	serial line	Change baudrate (set via serial line) and load stage 2 image
2	Stage 1	8 kb (resides in cache)	serial line, ram/register access, flash readonly access, SDRAM init	initialize and test RAM, execute commands coming in from serial line where one command loads stage 3 image into RAM and starts it
3	Stage 2	available SDRAM	serial line, SDRAM, interrupts, flash detection, erasing and writing	transfer a large flash image over a high speed serial connection and store it in flash avoiding useless transfering and re-writing.
4	not started	available FLASH	This is the new operating and file system for your ETRAX.

When the ETRAX processor goes into serial boot mode, it expects 784 bytes to come in at 9600 bps from serial line 0. This data is loaded into the cache and then executed. Our image just loads a bigger image into the memory left in the cache area (about 7kb) because you can't do much in 784 bytes.

At the end of the transfer the program jumps to the beginning of the stage 2 image.

The stage 2 image expects commands consisting of a 32 bit command value. Depending on the command some more 32-bit values may be sent.

The commands are not discussed here, however one commands tells the program go on loading stage 3.

Then the SDRAM is being initialized so that we can load a much larger image because our flash program does not fit into 7 kb code. The stack is also being initialized to operate in the SDRAM memory. All memory accesses are configured to bypass the cache otherwise it would destroy the stage 2 image currently running.

The serial line is also initialized to operate at higher speeds. The actual baudrate setting is decided by EtraxFlasher itself.

The third stage is the most complex stage where a serial interrupt handler is being installed to handle data at high speed. The interrupt handler is written in assembler to be very fast and does not more than reading data coming in from the serial line and writing it to a FIFO buffer. It would be probably better (and faster) to use DMA-assisted transfer. This might be implemented later.

Outside the interrupt a protocol takes care that no errors occurr during transfer. A 16 bit CCITT CRC is used and invalid blocks are transferred again. The block size is 8-64 kbyte depending on the configuration. The complete image is stored in RAM (not a FIFO buffer).

While still receiving the image data it is already being written to the flash. The program checks if a sector is already erased or does not even have to be re-written and avoids useless accesses. With other words, if you transfer the same image twice, no sector is erased or written twice.

Empty blocks (filled with 0xFF) are not transferred but the flash will be exact anyway. This is a feature of the underlying transfer protocol and typically shrinks the image to 40% of it's original size.

The protocol also tells EtraxFlasher how much has been written to the flash chip so that it knows when the processor is ready for a reboot.

At the end some statistics are sent and the ETRAX is put in an endless loop.

Stage 4 is only the process of transferring the flash image itself. The data is handled by the stage 3 program.

Stage 1

• stage1.img is padded to 784 bytes (with NULL bytes) and sent to the ETRAX at 9600bps, 8N1
• ETRAX sends ACK (ASCII 0x06)

Stage 2

• 4 bytes containing the length of stage2.img in bytes are sent to ETRAX
• A byte containing the desired baudrate is sent to ETRAX (normal register setting)
• ETRAX sends ACK
• Both ETRAX and EtraxFlasher change to the new baudrate and EtraxFlasher gives about one second time for the serial interface to be ready.
• stage2.img is sent to ETRAX
• ETRAX sends ACK

Stage 3

• 4 bytes containing the length of stage3.img in bytes are sent to ETRAX
• ETRAX sends ACK
• stage3.img is sent to ETRAX
• ETRAX sends ACK

Stage 4

• 4 bytes containing the length of stage4.img in bytes are sent to ETRAX
• 2 bytes containing the 16-bit CCITT CRC of the complete image are sent to ETRAX

EtraxFlasher then begins sending blocks of variable size (up to 64kbyte) that come with the following header:

Offset	Length	Description
0	1 byte	SOH (0x01)
1	5 bytes	ASCII "KCOLB" (inverse of "BLOCK")
6	4 bytes	Block offset in image (bytes)
10	4 bytes	Length of block in bytes
14	2 bytes	16-bit CCITT CRC of block
16	n bytes	Block data

When the block has been received successfully, ETRAX sends ACK (0x06), otherwise NAK (0x15). In the latter case (or when no response is received within a defined timeout) a resynch may be necessary and EtraxFlasher sends n NULL bytes where "n" is the number of bytes in the previous block. That is why ETRAX has to ignore everything that comes before the SOH byte.

EtraxFlasher only sends incrementing block offsets (except when the last block is repeated after a NAK). It may however, make a jump to a much higher position. In that case the remaining bytes are filled with 0xFF in the internal RAM image. This way large unused empty blocks in the image don't need to be transferred.

The last block is sent by EtraxFlasher in any case so that ETRAX knows he's got the complete image.

The protocol expects only ACKs and NAKs from ETRAX. All other bytes are textual data for debugging purposes. That is what is displayed in the "LOG window" in EtraxFlasher. You will notice some [flash_written=0x########]" messages in that window. These messages are used by EtraxFlasher to know how much has been really written to the flash (the second progress bar).

Back to the EtraxFlasher page

Deutsch · Italiano