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  

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.

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

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

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.

1. Can you share a picture of your system?
   (Perhaps dbg_reset_out is connected differently between your & my design)
   
   
2. Can you setup similar SignalTap above?
   (Capture the 1st instruction with dbg_reset_out falling edge as trigger during reset halt)

Regards,
Liang Yu

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.

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

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

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)

1. niosv-download -g -r -o APP-1.elf
2. juart-terminal                                       //Prints APP-1 output
3. Ctrl-C
4. niosv-download -g -r -o APP-2.elf
5. juart-terminal                                       //Prints APP-2 output only (Didn't observe any APP-1 output)
6. Ctrl-C

Regards,
Liang Yu