09-07-2018 08:37 AM
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
11-27-2018 11:05 PM
09-08-2018 02:51 AM
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.
09-14-2018 04:49 AM
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
09-14-2018 08:17 AM
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
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).
09-20-2018 02:29 AM
Please try your testcase with the attached patch, it fixes the issue. You can use it in one of the following two ways
11-19-2018 08:38 AM
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?
11-19-2018 08:49 AM
11-27-2018 11:05 PM
12-10-2018 04:41 AM
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.
12-17-2018 10:29 PM
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.
04-15-2019 07:55 PM
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"
04-15-2019 07:58 PM
06-07-2019 02:56 PM
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.
07-16-2019 12:51 AM
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?
07-16-2019 12:21 PM
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!
01-19-2020 06:26 PM
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.
06-23-2020 03:07 AM
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?
09-07-2020 05:20 AM
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?