-
Notifications
You must be signed in to change notification settings - Fork 137
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
ARC debug support broken after Zephyr SDK 0.14.2 #631
Comments
@jkiepert thanks for the report, let us look at what's wrong here. I'm wondering if this issue is blocking any important activities on your side, i.e. how soon that needs to be resolved? |
@abrodkin thank you for taking a look into this issue. To answer your question, this issue mainly prevents us from migrating to Zephyr v3.3 for our ARC-based products since Zephyr v3.3 requires SDK 0.15+. For the time being, we will stay on SDK 0.14.2 and Zephyr v2.7 until things have been fixed in the later Zephyr SDK versions. |
@abrodkin I did a bit further investigation and found that there is a Zephyr version dependency to this issue as well. Specifically, I moved to the minimum SDK supported by Zephyr v2.7 (SDK 0.13.1) and then tested I found that the debugger connection and openocd thread awareness works for all zephyr versions between v2.4 and v2.6, but it breaks with Zephyr v2.7 and above. I do see a crash report generated for openocd. I've attached an example crash with 0.13.1, but similar crashes occur for SDK 0.14.2, 0.15.2, and 0.16.0-beta1. Here's an example snippet from the 0.13.1 openocd crash report (report is similar for newer SDK versions):
|
Hi @jkiepert, We are still working on the issue, but I'd like to suggest you workaround. If you type Suggestion is to make a manual call of openocd and move the os-awareness command at the and of the argument list.
In parallel GDB should be executed with unchanged list of parameters:
|
Thanks @kokas-a, I'll give this a try. |
@kokas-a There seems to be something more going on here with ARC debug targets, or at least the FTDI debug interface to OpenOCD in the most recent toolchains/zephyr versions. I applied your patch above to Zephyr v3.3 OpenOCD runner with SDK 0.15.2 and while thread-aware debugging does work with the patch, several things are still going wrong:
|
Could you please provide output of |
@kokas-a Here's the log with
|
@kokas-a interestingly, if I manually run openocd and gdb I see non-thread-aware debug loading work. The key is to not pass in Proceedure that seems to work for
In another terminal:
|
In issues zephyrproject-rtos/sdk-ng#631 and zephyrproject-rtos/zephyr#55686 root case is in an attempt to access arc registers at early stage of OpenOCD initialization process. At this stage transport is not configured and this cause fault with error "Assertion `jtag_trst == 0' failed". As temporary solution this patch remove early access to ARC cores. This also disables Zephyr RTOS suport for ARC_SEC cores. Signed-off-by: Nikolay Agishev <agishev@synopsys.com>
In issues zephyrproject-rtos/sdk-ng#631 and zephyrproject-rtos/zephyr#55686 root case is in an attempt to access arc registers at early stage of OpenOCD initialization process. At this stage transport is not configured and this cause fault with error "Assertion `jtag_trst == 0' failed". As temporary solution this patch remove early access to ARC cores. This also disables Zephyr RTOS suport for ARC_SEC cores. Signed-off-by: Nikolay Agishev <agishev@synopsys.com>
In issues zephyrproject-rtos/sdk-ng#631 and zephyrproject-rtos/zephyr#55686 root case is in an attempt to access arc registers at early stage of OpenOCD initialization process. At this stage transport is not configured and this cause fault with error "Assertion `jtag_trst == 0' failed". As temporary solution this patch remove early access to ARC cores. This also disables Zephyr RTOS suport for ARC_SEC cores. Signed-off-by: Nikolay Agishev <agishev@synopsys.com>
In issues zephyrproject-rtos/sdk-ng#631 and zephyrproject-rtos/zephyr#55686 root case is in an attempt to access arc registers at early stage of OpenOCD initialization process. At this stage transport is not configured and this cause fault with error "Assertion `jtag_trst == 0' failed". As temporary solution this patch remove early access to ARC cores. This also disables Zephyr RTOS suport for ARC_SEC cores. Signed-off-by: Nikolay Agishev <agishev@synopsys.com>
Overview
There appears to be a regression in ARC debugger support with Zephyr SDK releases after 0.14.2. Initially, we encountered this with our own ARC EM7D-based SoC, but I have also reproduced this regression with the natively supported Synopsys ARC EM Starter Kit (EMSK) board across Zephyr release versions when using Zephyr SDK 0.15.2 or later.
Board target: em_starterkit_em7d
Zephyr versions tested: v2.4, v2.7, v3.3
Zephyr SDK versions tested: 0.12.1, 0.14.2, 0.15.2, 0.16.0-beta1
Application tested:
zephyr/samples/basic/threads
Bug
There appear to be two major regressions after SDK 0.14.2:
CONFIG_DEBUG_THREAD_INFO=y
(orCONFIG_OPENOCD_SUPPORT=y
in earlier versions of Zephyr)CONFIG_DEBUG_THREAD_INFO=y
)It should be noted that code loading via
west flash
is functional with recent SDK versions. It is only debug functionality that is broken (whether using west debug or cmake --target debug).To Reproduce
Steps to reproduce the behavior debugger connection failure using Zephyr v3.3 (or v2.7) with SDK 0.16.0-beta1 or 0.15.2:
Notice the JTAG failure message:
Steps to reproduce the behavior GDB load/step failure using Zephyr v3.3 (or v2.7) + SDK 0.16.0-beta1 or 0.15.2
At this point openocd continues to spew that last line until openocd is manually killed (
killall -9 openocd
).Expected behavior
Connecting the debugger with
west debug
should halt the CPU and allow one to load code, single step the processor, and when CONFIG_DEBUG_THREAD_INFO=y, openocd should detect Zephyr and provide thread awareness such asinfo threads
. All of this functionality is present when using Zephyr SDK 0.14.2 and 0.12.1.Impact
This is a showstopper for Zephyr ARC development with Zephyr SDKs after 0.14.2.
Logs and console output
See above
Environment (please complete the following information):
Additional context
The EMSK board is configured for the EM7D CPU with the DIP switch set to OFF,OFF,OFF,OFF. However, the behavior appears to be the same independent of the particular ARC core used.
The text was updated successfully, but these errors were encountered: