Forum Discussion
New ContributorNIOS V/m dbg_reset_out signal (Q25.1 Std, MAX10)
Hi pp123
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).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
New ContributorYes, my sequence is similar. But I'm using custom UART with FTDI device (no juart-terminal), I have Putty terminal open all the time.
In 5th step I observe some output (first logs) from APP-1.
My temporary workaround is (without niosv-shell):
1. Creating cfg file:
/altera/25.1std/quartus/linux64/openocd-cfg-gen niosv.cfg
2. Running OpenOCD server:
/altera/25.1std/quartus/linux64/openocd -c "tcl_port disabled" -c "gdb_port 3333" -c "telnet_port 4444" -f niosv.cfg
In the second terminal:
3. Halting CPU (optional step):
( echo "halt"; sleep 1; echo "exit"; echo EOF ) | telnet localhost 4444
4. Loading elf file:
/altera/25.1std/riscfree/toolchain/riscv32-unknown-elf/bin/riscv32-unknown-elf-gdb -batch -ex "set arch riscv:rv32" -ex "set remotetimeout 60" -ex "target extended-remote localhost:3333" -ex "load exeFile.elf" -ex 'set $mstatus &= ~(0x00000088)' exeFile.elf
5. Resetting CPU:
( echo "reset"; sleep 1; echo "exit"; echo EOF ) | telnet localhost 4444
For example my first logs were (printf redirect to my custom UART module -> FTDI -> PC):
Hello world - Uart started!
Hello!
I changed them to (only one change in app):
HELLO WORLD - UART STARTED!
Hello!
After niosv-download -r -g -o exeFile.elf execution in Putty terminal I can observe:
Hello world - Uart started!
Hello!
HELLO WORLD - UART STARTED!
Hello!
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)?
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.
I have checked that in Q24.1 Std "niosv-download -r -g -o exeFile.elf" works the same as Q25.1 (incorrect).
