Community
cancel
Showing results for 
Search instead for 
Did you mean: 
Highlighted
Beginner
97 Views

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 5.2.3.4). 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

Sebastian

0 Kudos
0 Replies