cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
claudio_fidia
Observer
Observer
5,305 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
ibaie
Xilinx Employee
Xilinx Employee
4,507 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
sadanan
Xilinx Employee
Xilinx Employee
5,293 Views
Registered: ‎10-21-2010

Hi @claudio_fidia,

We will get back to you on this

0 Kudos
hemangd
Moderator
Moderator
5,263 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
claudio_fidia
Observer
Observer
5,234 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
sadanan
Xilinx Employee
Xilinx Employee
5,197 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
claudio_fidia
Observer
Observer
5,193 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
sadanan
Xilinx Employee
Xilinx Employee
5,189 Views
Registered: ‎10-21-2010

Hi @claudio_fidia,

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

0 Kudos
claudio_fidia
Observer
Observer
5,180 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
soumyah
Xilinx Employee
Xilinx Employee
5,086 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)
claudio_fidia
Observer
Observer
5,079 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
elaird
Newbie
Newbie
4,640 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
ibaie
Xilinx Employee
Xilinx Employee
4,636 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.
ibaie
Xilinx Employee
Xilinx Employee
4,508 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

elaird
Newbie
Newbie
4,497 Views
Registered: ‎11-19-2018
Works for me. Thanks for the solution.
0 Kudos
lechrisw
Visitor
Visitor
4,305 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
lechrisw
Visitor
Visitor
4,220 Views
Registered: ‎05-15-2018

This problem still exists with 2018.3

 

snehak
Xilinx Employee
Xilinx Employee
4,197 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
darcyw
Visitor
Visitor
3,548 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
darcyw
Visitor
Visitor
3,547 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
lechrisw
Visitor
Visitor
3,163 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
allard.potma
Visitor
Visitor
2,876 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
darcyw
Visitor
Visitor
2,859 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
youtie2010
Visitor
Visitor
2,488 Views
Registered: ‎06-28-2019

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

stepover-int.bmp
2,027 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
lechrisw
Visitor
Visitor
1,404 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
dirkcas
Visitor
Visitor
1,136 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