Nios® II Embedded Design Suite (EDS)
Support for Embedded Development Tools, Processors (SoCs and Nios® II processor), Embedded Development Suites (EDSs), Boot and Configuration, Operating Systems, C and C++
Intel Support hours are Monday-Fridays, 8am-5pm PST, except Holidays. Thanks to our community members who provide support during our down time or before we get to your questions. We appreciate you!

Need Forum Guidance? Click here
Search our FPGA Knowledge Articles here.
12455 Discussions

EPCQ bootloader corrupted after powercycle


Hi guys,


this is my setup:

  • Cyclone V GT Development Kit (set to support active serial configuration)
  • Nios II/f @ 125 MHz
    • Reset vector memory: Serial Flash Controller (EPCQ)
    • Reset vector offset: 0x01A0 0000
    • Reset vector: 0x4DA0 0000
    • Exception vector: ddr3 ram
  • Serial Flash Controller Intel FPGA IP @ 25 MHz
    • connected to Nios via Avalon-MM Clock Crossing Bridge
    • Avalon-MM address mem: 0x4C00 0000
    • Avalon-MM address csr: 0x4E00 0000
  • DDR3 HMC as program/data memory
    • Nios executes code from here after bootloader finished copying from epcq
  • PIO for "Alive"-LED

For setting this up I followed the instructions in the Embedded Design Handbook (section I also convert the elf into a hex file with embedded boot_loader_cfi.srec and put the sof and hex file together in a jic with the convert programming files dialog.

After flashing the jic to the EPCQ everything works fine.


Now it sometimes happens, that the Nios won't boot after a power cycle -> LED doesn't start blinking.

The FPGA configuration works fine -> CONF_DONE LED turns on.

I can also still start the software from the Nios II SBT for Eclipse.

In Debug mode I looked at the EPCQ memory with the memory monitor and compared the contents at the CPUs reset address (0x4DA0 0000) to the contents of the boot_loader_cfi.srec.

In every case I could observe, the data of the bootloader was corrupted (a few bits were different from the original srec data but not always the same bits).

I also could fix the boot problem by overwriting just the boot loader in the epcq with the quartus_pgm --nios2 command and the boot_loader_cfi.srec adjusted to the addresses for my specific setup.


In my software I don't access the Serial Flash Controller at all. It is just there for booting. I also tried to use a hardware breakpoint while debugging my software to break execution on a write access to the memory address range of the bootloader... no write access detected so far. I couldn't reproduce the behavior while debugging the application, yet.


What could possibly cause the epcq contents to get corrupted?

How could I further debug this issue?


Let me know if I forgot some information to understand this issue.


Thanks in advance


0 Kudos
1 Reply



unfortunately a colleague of mine stumbled upon the same problem. Is there anyone who also knows this issue or an explanation for it?