Forum Discussion

pp123's avatar
pp123
Icon for New Contributor rankNew Contributor
3 months ago
Solved

NIOS V/m dbg_reset_out signal (Q25.1 Std, MAX10)

Hello, I have a problem with loading elf file. Signal dbg_reset_out (used for resetting HDL components) is inactive (low) when I'm using "niosv-download -r -g exeFile.elf" command (Q25.1 Std, v...
Nios Cpu
  • LiangYuG_Altera's avatar
    LiangYuG_Altera
    2 months ago

    Hi pp123​ 

    pp123 wrote:

    Signal dbg_reset_out (used for resetting HDL components) is inactive (low) when I'm using "niosv-download -r -g exeFile.elf" command (Q25.1 Std, v25.2.1 Ashling GDB Server, Linux OS, MAX10 device, NIOS V variant m).
    The same command for Q24.1 Std (previous version of Ashling GDB Server, the same OS and PC) works.

    For me temporary solution is using additional option -o (OpenOCD instead of Ashling® RiscFree GDB Server).

    LiangYuG_Altera wrote:

    Please continue using OpenOCD.
    We have reported this failure to Ashling for investigation. 

    Ashling have responded to us, and fix their latest Ashling GDBServer in the upcoming RiscFree IDE v26.1.1-C in Quartus Prime Pro 26.1.1. Since you are using Quartus Prime Standard, you will need to wait for the Quartus Prime Standard 26.1 for the working Ashling GDBServer.

    Regards,
    Liang Yu

LiangYuG_Altera's avatar
LiangYuG_Altera
Icon for Contributor rankContributor
2 months ago

Hi pp123​ 

In Q24.1 Std "niosv-download -r -g exeFile.elf" works as I expect so I suppose that my NIOS V reset connections are correct.

This one is using the Ashling GDBServer. Ashling is aware of this issue & working on the fix.

 

I have checked that in Q24.1 Std "niosv-download -r -g -o exeFile.elf" works the same as Q25.1 (incorrect).

This one is using the OpenOCD. Agree with this observation as there is no changes to the OpenOCD flow between 24.1std & 25.1std. So, both should display this strange behaviour.

 

Maybe no double reset but reset earlier than app load (CPU reset -> old app execution from the beginning/load elf file -> new app execution from the beginning)?

The niosv-download runs as such (when using OpenOCD): 

  1. reset halt
  2. riscv32-unknown-elf-gdb ....
  3. resume

So, your hypothesis is partially correct on the "reset earlier than load". 
But there is a "halt" between "reset" & "load".

https://openocd.org/doc/html/General-Commands.html 

Theoretically, both should end the same.

  • Altera's flow : Reset processor to reset vector, immediately halt on reset vector, load the new elf, resume from halted location.
  • Your flow: Halt the processor, load the new elf, reset to reset vector.

 

But maybe there is a tiny delay between "reset" & "halt" in actual system.
And that delay is more noticeable in faster system.

Your approach is more robust by turning it from a 4-step routine to 3-step.
Let me bring this into the team for review.

Regards,
Liang Yu