XModem Bootloader
XModem Bootloader (COM)
FPGA image only
FPGA and Nios II image
XModem Bootloader (virtual COM)


If the FPGA is operated in conjunction with a CPU, as in this example, there is no direct access to the EPCS memory. This requires a special FPGA bootloader to update the FPGA through the CPU or without special hardware.

"The default EPCS Bootloader from altera resides in the first 0x400 (1K) bytes of the epcs controller. This bootloader figures out the size of the sof information loaded in the EPCS device and then assumes that that code follows immidiately afterwards. This works fine for single hardware and software images. However if you have multiple images or you wish to place the nios code at a different location, the default boot loader will not work for you."
(Source: "EPCS bootloaders" Altera Wiki)

To solve this problem, the XModem bootloader environment was created with the source of an alternative EPCS bootloader, the RSU code of the BeMicro example, and a XModem functionality.


Here the DE0-Nano Development and Education Board was used:

By the way, C3 (TXT) and A3 (RXD) are used for the UART.


The alternative EPCS Bootloader and the RSU code from the example are only needed for Quartus versions less than v15. From version 15 onwards, the new EPCS serial flash controller and the Remote Update IP can be used without modifications. But here I use Quartus version 11.1sp2.

Additional hints can be find here:

XModem Bootloader (COM)

The DE0-Nano board is equipped with an EPCS64 or EPCS64 compatible serial configuration device. This configuration device is like a SPI flash memory. In case of the XModem Bootloader the address map looks like:

 Area  Address Offset  Size (bytes)
 Bootloader area  0x00000000  1024K
 User area  0x00100000  7168K

The EPCS64 has a size of 8 MBytes. Where the first 1 MByte is reserved for the XModem Bootloader which contains the FPGA image and Nios II program. The user area, starting by 0x00100000, can be used for a FPGA image only, or an image with Nios II program.

The data received from the XModem Bootloader must contain a valid XBOOT header. The XBOOT header looks like:

The header and data are secured by a checksum. The data follows directly after the XBOOT header. "StartAddress" is the start address of the XBOOT header in the EPCS memory. The size of the update file, header and data, must be 64K bytes aligned. 64K bytes is the size of a sector inside the EPCS memory.

The update file can be generated with the tool "rpd2xboot". This little tool requires an Altera RPD (Raw Programming Data File) file for input and generates the XBOOT (XBO) update file.

The XModem Bootloader checks if a valid image is available at address 0x00100000. If the image is valid, it will be started automatically. If "KEY0" of the DE0-Nano is pressed while the power is turned on, no valid image is started and the update mode will entered.

In this example, a real UART was used. However, it is also possible to use a virtual UART for the update.

Some more features:

  • The UART use 115200 baud, 8 bits, no parity, 1 stop bit and no flow control.
  • Only a packet size of 128 bytes with CRC-16 is supported.
  • A ping each second is send to start the XModem transfer.
  • The XModem Bootloader will send a NAK to request a retransmitting if the delay between two consecutive bytes of the same packet is more than 1000 ms.
  • The XModem Bootloader will send a NAK to request a retransmitting if a CRC error is detected.
  • Once the transfer ist started, the XModem Bootloader will abort the transfer and send a CAN if no data was received for more than 10000 ms.
  • The XModem Bootloader will abort the transfer and send a CAN if it cannot synchronize anymore to the packet number.

FPGA image only

Here the example "de0n-xboot-blinky" is used to test the XModem Bootloader and to create the sample screenshots.

After power on, and without a valid image available, the output looks like:

While the data is transferred, the output looks like:

If the transfer is finished, some tests will be done with the image. If the tests was successful, the new image will be stored in the EPCS memory. The output looks like:

The image can be started by pressing "s". Now the LEDs should be running on the DE0-Nano board.

After power on, and with a valid image available, the output looks like:

And the image was started automatically by the XModem Bootloader.

If "KEY0" of the DE0-Nano is pressed while the power is turned on, no valid image is started and the update mode will entered. The output looks like:

FPGA and Nios II image

Compared to the previous "FPGA image only" example there is an additional Nios II application available here. Because of the multi image application, a new EPCS Bootlaoder is needed. This alternative bootloader, "BROM", is implemented in the on-chip memory of the FPGA. The address map here looks like:

 Area  Address Offset  Size (bytes)
 Bootloader area  0x00000000  1024K
 FPGA image  0x00100000  768K
 Nios II image  0x001C0000  64K

"HW_OFFSET" and "SW_OFFSET" in "_create_img.bat" is used to set the address offset from the FPGA and Nios II image. After power on the output looks like:

Here the FPGA image at address 0x00100000 is started by the XModem bootloader. This starts the EPCS bootloader which in turn starts the Nios II application. By the way, the Nios II reset vector offset inside the EPCS memory must be set with the Qsys "EPCS Reset vector offset" too:

For the "FPGA and Nios II image" example "de0n-xboot-test" was used.

XModem Bootloader (virtual COM)

This example is more a Proof of Concept than a full featured application. The XModem bootloader here has the same functionality as the previous one but with a virtual COM port. Therefore the control is no longer done via TeraTeram but via the CPU with which the virtual COM port is "connected". To test the XModem bootloader with the virtual COM port, a DE0-Nano and an EA-LPC1788 board were used, which are connected with jumper wires.

The example "de0n-xboot-blinky" was also used here, where the XBO file was converted into a
C array with the help of xbin2c.


If you got an error like "Generating BSP... has encountered a problem" take a look here, maybe "bsp-path-check" can solve the problem.

XModem Bootloader (COM) de0n-xboot-com_20170923 (699 KB, for Quartus II 11.1sp2)

XModem Bootloader (vCOM) de0n-xboot-vcom_20170923 (1.83 MB, for Quartus II 11.1sp2)

Test image "blinky" de0n-xboot-blinky_20170827 (40 KB, for Quartus II 11.1sp2)

Test image "test" de0n-xboot-test_20170915 (981 KB, for Quartus II 11.1sp2)

rpd2xboot-source_20170915 for Microsoft Visual C++ 6.0 (14 KB)

xbootinfo-source_20170918 for Microsoft Visual C++ 6.0 (11 KB)

rpd2xboot-win_20170915 application (23 KB) md5sum zip file: 137A34A7D450D7E1ACA285C2242AD53D

xbootinfo-win_20170918 application (21 KB) md5sum zip file: 4C2F820CF8902298E1E2049DB63846B4