cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
Highlighted
Observer
Observer
4,685 Views
Registered: ‎11-07-2017

Step-over during debugging stops at interrupt vector

Jump to solution

Hi all

 

I'm developing a FreeRTOS application on Zynq system and when I execute a step-over on code during

debug the SDK (my version is 2018.2) always stops at irq interrupt entry point.

The single-step command instead work properly.

This is a tedious problem for debugging because I need always to use breakpoint or run-to-line command.

In a previous post I red a similar problem with single-step command that was corrected in SDK 2017.4.

Is there a patch to correct the problem of step-over command in SDK 2018.2?

 

Thanks for help

0 Kudos
1 Solution

Accepted Solutions
Highlighted
Xilinx Employee
Xilinx Employee
3,887 Views
Registered: ‎10-06-2016

The issue has been finally fixed and AR#62132 has been published with the proper patch.

Regards


Ibai
Don’t forget to reply, kudo, and accept as solution.

View solution in original post

25 Replies
Highlighted
Xilinx Employee
Xilinx Employee
4,673 Views
Registered: ‎10-21-2010

Hi @claudio_fidia,

We will get back to you on this

0 Kudos
Highlighted
Moderator
Moderator
4,643 Views
Registered: ‎03-16-2017

Hi @claudio_fidia,

 

Are you facing the same issue as mentioned in this AR? https://www.xilinx.com/support/answers/70375.html

 

If yes, than i have already filed a change request on this issue to factory. 

 

Regards,

hemangd

 

Regards,
hemangd

Don't forget to give kudos and mark it as accepted solution if your issue gets resolved.
0 Kudos
Highlighted
Observer
Observer
4,614 Views
Registered: ‎11-07-2017

Hi

Yes, appear a similar problem.

This is the result of a step-over command during debug.

 

Vector_table after step-over.jpg

0 Kudos
Highlighted
Xilinx Employee
Xilinx Employee
4,577 Views
Registered: ‎10-21-2010

Hi @claudio_fidia,

 

Are you seeing this issue while stepping over the code in BSP. If so, this is expected since the BSP is compiled with -O2. This is a known problem with GCC - Optimized code is not suitable for proper debug. You can re-build the BSP with optimizations disabled (add -O0 to extra_compielr_flags under BSP settings => CPU driver) for better behavior. If you're seeing this problem with optimized code, please let us know

0 Kudos
Highlighted
Observer
Observer
4,573 Views
Registered: ‎11-07-2017

Hi @sadanan

 

I see the behavior when I execute step-over on my code. Anyway my BSP is compiled with -O0 and -g3 options.

0 Kudos
Highlighted
Xilinx Employee
Xilinx Employee
4,569 Views
Registered: ‎10-21-2010

Hi @claudio_fidia,

Can you please post a testcase so that we can look into this more

0 Kudos
Highlighted
Observer
Observer
4,560 Views
Registered: ‎11-07-2017

Hi @sadanan

 

I investigated a bit about the problem and I got some conclusions.

In my application I use FreeRTOS+TCP for the ethernet connection and the problem

appear when the TCP communication is working. In this case a step-over command stops at irq handler

and if I step through the interrupt I see the irq is requested by the EMAC (function XEmacPs_IntrHandler).

I don't know why this happen, but someone in Xilinx may know if the problem is something related to the priority settings or

similar.

In attachment you will find my project. Is a simple TCP example that can run (I hope) on all demo

board (I use a picozed SOM).

 

Thank you

0 Kudos
Highlighted
Xilinx Employee
Xilinx Employee
4,466 Views
Registered: ‎07-06-2018

Hi @claudio_fidia

 

Please try your testcase with the attached patch, it fixes the issue. You can use it in one of the following two ways

 

  1. Extract the contents of the zip to $XILINX_SDK (ex. C:\Xilinx\SDK\2018.2), such that the files in the zip overwrite the files in SDK installation
  2. Create a new directory (ex. C:\myvivado), and extract the contents of the zip to this directory. Before starting SDK/hw_server, set the env variable MYVIVDAO to point to this new directory (ex. set MYVIVADO=C:\myvivado)
Highlighted
Observer
Observer
4,459 Views
Registered: ‎11-07-2017

Hi @soumyah

 

I copied the file in my SDK and now the step-over command works as it is expected.

 

Thank you very mauch

0 Kudos
Highlighted
Newbie
Newbie
4,020 Views
Registered: ‎11-19-2018

I'm working with 2018.2 and a ZCU106 and seeing a similar problem, but the patch doesn't seem to resolve the problem for me (applied using method 1: extracting to overwrite SDK installation, after creating backup of original hw_server.exe binary)

Is the patch Zynq-specific? Any thoughts on why it's not resolving the problem for me? Something I could be doing wrong?

Tags (1)
0 Kudos
Highlighted
Xilinx Employee
Xilinx Employee
4,016 Views
Registered: ‎10-06-2016
Hi @elaird,
It seems that the patch posted in the post is not fixing the issue for A53 processor so development team is already working on it and we should soon see a patch.
Regards

Ibai
Don’t forget to reply, kudo, and accept as solution.
Highlighted
Xilinx Employee
Xilinx Employee
3,888 Views
Registered: ‎10-06-2016

The issue has been finally fixed and AR#62132 has been published with the proper patch.

Regards


Ibai
Don’t forget to reply, kudo, and accept as solution.

View solution in original post

Highlighted
Newbie
Newbie
3,877 Views
Registered: ‎11-19-2018
Works for me. Thanks for the solution.
0 Kudos
Highlighted
Visitor
Visitor
3,685 Views
Registered: ‎05-15-2018

The behaviour has changed after adding the patch but it's not fixed in linux environment. Stepping over causes the processor to be held in the isr but unlike 2018.8 without the patch it doesn't break. The only option is to <suspend>, <step out> and continue <single step>.

I extracted the patch file hw_server replacing the old hw_server & applying the same permissions including owner and group. Perhaps I've not installed it correctly, please advise. 

0 Kudos
Highlighted
Visitor
Visitor
3,600 Views
Registered: ‎05-15-2018

This problem still exists with 2018.3

 

Highlighted
Xilinx Employee
Xilinx Employee
3,577 Views
Registered: ‎09-20-2018

Hi @lechrisw,

I have tried to reproduce this issue ,looks like this issue is fixed in SDK18.3.

If the issue is still coming please provide the steps or test case for reproducing the issue.

 

Regards,

Sneha

0 Kudos
Highlighted
Visitor
Visitor
2,928 Views
Registered: ‎10-22-2018

I'm seeing this in 2018.3 as well...  I tried replacing the 2018.3 hw_server.exe with the patched version from 2018.2 (ignoring the mismatch warning) and I still encounter the problem.  I'm working on a large existing code base after migrating from 2016.2 so creating an example isn't straight forwards...

I'm placing a breakpoint in a routine, after the Zynq 7020 has been running for a minute or so and upon stepping over a function the debug windows shows the core as "Running", but upon pausing it's *always* sitting at the line "LDR PC, _irq"

 

 

Capture.PNG
0 Kudos
Highlighted
Visitor
Visitor
2,927 Views
Registered: ‎10-22-2018

@ibaie wrote:

The issue has been finally fixed and AR#62132 has been published with the proper patch.

Regards


Hi Ibaie, this seems to still be a problem in 2018.3

0 Kudos
Highlighted
Visitor
Visitor
2,543 Views
Registered: ‎05-15-2018

This isn't fixed. Still exists with 2019.1, 2018.3. It's dependent upon the application.

Create a project with a freertos example. Step over works until the scheduler is started. I assume it works to this point becausee the ISR's aren't enabled.

 

0 Kudos
Highlighted
Visitor
Visitor
2,256 Views
Registered: ‎08-17-2018

This is indeed still broken in 2019.1. It really makes the debugging process a pain in the ass!

Any new from Xilinx about this, are they working on it?

0 Kudos
Highlighted
Visitor
Visitor
2,239 Views
Registered: ‎10-22-2018

There's a patch for 2018.3 in another thread, but that still doesn't work...  The lack of progress is highly frustrating given how much we're spending on the Zynq parts!

0 Kudos
Highlighted
Visitor
Visitor
1,868 Views
Registered: ‎06-28-2019

The problem is still unsolved by sdk2018.2 or sdk2018.3

stepover-int.bmp
Highlighted
1,407 Views
Registered: ‎01-13-2020

This is deeply frustrating, and I've been on a deep-dive to determine what's happening, as none of the versions of hw_server I've tried have worked.

The root cause appears to be hw_server isn't handling the INTdis bit correctly in the DBGDSCR register - it's supposed to be set during a single step operation specifically to suppress interrupts.

I can manually set the bit and then successfully step over, but I have to do it every step.

0 Kudos
Highlighted
Visitor
Visitor
784 Views
Registered: ‎05-15-2018

The issue still exists with Vitis 2020.1.

Are there any plans to fix it? Fixing showstoppers are more important than new features. BTW unrelated but what happened to the toolbar controls in Vitis?

0 Kudos
Highlighted
Visitor
Visitor
516 Views
Registered: ‎04-21-2015

Seeing the same thing with Microblaze debugging with Vitis 2019.2.

Stepping through the code is impossible since it will end up in __interrupt_handler() every time.

Any updates on this?

0 Kudos