Nios® V/II Embedded Design Suite (EDS)
Support for Embedded Development Tools, Processors (SoCs and Nios® V/II processor), Embedded Development Suites (EDSs), Boot and Configuration, Operating Systems, C and C++
12600 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?




0 Kudos