NIOS V/m dbg_reset_out signal (Q25.1 Std, MAX10) - 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, 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). Is there any better solution? Replies: Re: NIOS V/m dbg_reset_out signal (Q25.1 Std, MAX10) Dear pp123 , I'm glad that your issue is resolved. We will continue to monitor this post for the next 5 days. If there are no further inquiries during this period, I will step back and allow the community to assist with any future follow-up questions. Thank you for engaging with us! Best regards, Altera Technical Support Replies: Re: NIOS V/m dbg_reset_out signal (Q25.1 Std, MAX10) Thanks for the information. Replies: Re: NIOS V/m dbg_reset_out signal (Q25.1 Std, MAX10) 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 Replies: Re: NIOS V/m dbg_reset_out signal (Q25.1 Std, MAX10) Thanks pp123 pp123 wrote: Yes, of course - dbg_reset_out output connected (indirectly) with reset input. It casued probably debug module reset and (sometimes) stranged behaviour. "Sometimes" because using niosv-download -r -g (Q24.1 Std) at Linux PC seems worked without problems. Oh ya, that is a thing to beware of. Resetting the debug module during "niosv-download" -r can cause un-deterministic behaviour. In your words, "sometimes strange behaviour". It is mentioned here . But we should rewrite it more explicitly for future readers. pp123 wrote: This connection also worked properly in our older projects using NIOS2. The NIOS2 Debug Module is different from RISC-V Debug Module. We aimed to make them as similar as possible at the top-level. But there are slight difference between them. You may refer here for migration tips from NIOS2 to NIOSV. (Rewrite this more explicitly too) Regards, Liang Yu Replies: Re: NIOS V/m dbg_reset_out signal (Q25.1 Std, MAX10) Would you mind sharing what is the incorrect reset connection? Yes, of course - dbg_reset_out output connected (indirectly) with reset input. It casued probably debug module reset and (sometimes) stranged behaviour. "Sometimes" because using niosv-download -r -g (Q24.1 Std) at Linux PC seems worked without problems. This connection also worked properly in our older projects using NIOS2. Replies: Re: NIOS V/m dbg_reset_out signal (Q25.1 Std, MAX10) Hi pp123 pp123 wrote: it seems that the problem with reset & halt was my incorrect reset connection. Would you mind sharing what is the incorrect reset connection? If possible, we would like to improve our documentation to warn other dbg_reset_out user. pp123 wrote: So I only wait for Ashling's fix (GDB server). Got it, I will let you know once it is ready. Regards, Liang Yu Replies: Re: NIOS V/m dbg_reset_out signal (Q25.1 Std, MAX10) Hello, it seems that the problem with reset & halt was my incorrect reset connection. I am sorry. It is interesting that I haven't noticed problems using Q24.1 Std. So I only wait for Ashling's fix (GDB server). Replies: Re: NIOS V/m dbg_reset_out signal (Q25.1 Std, MAX10) Hi pp123 LiangYuG_Altera wrote: But maybe there is a tiny delay between "reset" & "halt" in actual system. And that delay is more noticeable in faster system. After some experiment, there is no "tiny delay / RUNNING state" between reset & halt . The hypothesis above is debunked. Here are some picture showing the difference between reset run & reset halt . reset run (Processor enters ELF's _reset/reset vector immediately after reset, aka RUNNING state after reset) reset halt (Processor enters park loop in dm_agent immediately after reset, aka HALTED state after reset) FYI Info on park-loop/dm-agent Unfortunately, I are unable to replicate this "double reset" issue, and require more info from your design. Can you share a picture of your system? (Perhaps dbg_reset_out is connected differently between your & my design) Can you setup similar SignalTap above? (Capture the 1st instruction with dbg_reset_out falling edge as trigger during reset halt) Regards, Liang Yu Replies: Re: NIOS V/m dbg_reset_out signal (Q25.1 Std, MAX10) LiangYuG_Altera wrote: But maybe there is a tiny delay between "reset" & "halt" in actual system. And that delay is more noticeable in faster system. Yes, that may be true. LiangYuG_Altera wrote: 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. So, I wait for your team's opinion. Thank you for your research and response. Replies: Re: NIOS V/m dbg_reset_out signal (Q25.1 Std, MAX10) 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): reset halt riscv32-unknown-elf-gdb .... 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 Replies: Re: NIOS V/m dbg_reset_out signal (Q25.1 Std, MAX10) Yes, 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). Replies: Re: NIOS V/m dbg_reset_out signal (Q25.1 Std, MAX10) Hi pp123 pp123 wrote: Using OpenOCD causes another problem (I haven't examined it yet). During load new elf file (niosv-download -r -g -o exeFile.elf) the NIOS V CPU is starting execution of old program and then it is executing the new one (double reset?). I am unable to replicate the "double reset" issue described. Is your sequences similar to mine? (Running the experiment in a single Linux terminal) niosv-download -g -r -o APP-1.elf juart-terminal //Prints APP-1 output Ctrl-C niosv-download -g -r -o APP-2.elf juart-terminal //Prints APP-2 output only (Didn't observe any APP-1 output) Ctrl-C Regards, Liang Yu Replies: Re: NIOS V/m dbg_reset_out signal (Q25.1 Std, MAX10) Thank you for your response. Using OpenOCD causes another problem (I haven't examined it yet). During load new elf file (niosv-download -r -g -o exeFile.elf) the NIOS V CPU is starting execution of old program and then it is executing the new one (double reset?). Replies: Re: NIOS V/m dbg_reset_out signal (Q25.1 Std, MAX10) Hi pp123 For me temporary solution is using additional option -o (OpenOCD instead of Ashling ® RiscFree GDB Server). Is there any better solution? Please continue using OpenOCD. We have reported this failure to Ashling for investigation. Regards, Liang Yu