Is it possible to do XDB + JTAG debugging for the Intel Quark on Intel System Studio 2015 For Windows?

I have checked the product specifications and the only version that lists JTAG as part of the package is the Ultimate Linux version of Intel System Studio 2015.

Any help and information will be greatly appreciated.

Thank you beforehand.

Regards

I can't start debugging the Intel Quark target in Galileo board.

1.) I am using the "2015 Products.bat" file to start the debugger.

2.) Inside the debugger interface I use the "Intel Quark SoC x1000-60-pin XDP (Clanton)" option. No additional parameters. I know the Galileo can't work with the 60-pin interface right out of the box so I am using an adapter.

3.) This is the way the hardware is setup:

   - Intel Galileo + cables connecting the PREQ_B, PRDY_B, GND, and PWRMODE, pins connected to a connector that hooks to J3 on the XDP to 10Pin JTAG Adapter + 10-pin cable connecting Galileo to J8 in XDP to 10Pin JTAG Adapter.

  - XDP to 10Pin JTAG Adapter.

  - ITP-XDP 3BR JTAG Probe.

   - There is a J7 and I don't know exactly how to use it. What I did is to hook up pin 3 of J7 to the REBOOT signal of the SoC (This is what the documentation says is the RESET_OUT signal from the point of view of the XDP). In addition, I connected this same signal to pin 2 of J7 through a 1K resistor  (This is what the documentation says is the RESET_IN signal from the point of view of the XDP). In this way, the tool knows what is happening with the device. In any case, I tried without hooking these J7 signals and hoking only some of them as well as hooking all of them. Nothing changed the end result.

In any case, here is the Intel System Debugger console messages (with a couple of annotations):

Intel(R) System Debugger 2015 
Version 15.1.1448  [82.860.51]
Copyright(c) 2001-2014 Intel Corporation. All rights reserved.
INFO: Caching of registers and memory is *enabled*, subsequent reads from target will be cached
INFO: Initializing Target Connection Interface...
INFO: Initializing probe connection, this will take a moment...
INFO: Probe connection initialized!
INFO: Connected to Processor type: Clanton (1 threads)
WARNING: Unable to halt the target during debugger initialization, you may need to reset, power-cycle, or apply additional platform-specific steps to continue!
INFO: Initialization complete.
INFO: Target reset occurred (Note: Manual reset)
INFO: JTAG reconfiguration in progress...
INFO: JTAG reconfiguration complete.
INFO: Target reset occurred (Note: reset issued inside XDB)
INFO: Restarting target, this may take a moment...
INFO: JTAG reconfiguration in progress...
INFO: Target reset occurred
INFO: JTAG reconfiguration complete.
WARNING: target did not halt after reset, forcing a halt
E-2201: The debugger has lost control of the target, a target reset may be required.

I did try disconnecting and re-connecting the board, but this just holds the device in reset but nothing else changes. The end result is the same, I can't halt the device and, after some procedures, I keep loosing control of the target.

I would really appreciate any help. This may be a hardware problem due to the connections or a software setup problem. One of the main issues I faced was the complete lack of knowledge of the XDP to 10Pin JTAG Adapter so there may be some other signals I may need to consider or some other types of configuration of the signals.

Thank you beforehand for any help you may be able to provide.

Best regards.

Dear experts,

I'm developing a code and I have problems with the debugger. I have created a simple test example (attached) to illustrate the issue. 

I have a module/class that contains a derived type (doe) the derived type contains an allocatable array (x) that is allocated when the instance of the "class" is constructed. In my main program I declare an allocatable array of instances of the doe class. I allocate a number (in this case 2) instances of the doe class in the array doe1. This all works fine.

I have two sub-routines. In the first one (test_sub1) I send in only one of the instances in the array at a time. In the other one (test_sub2) I send in the entire array of instances. In the first case if I try to look at the array doe_in%x it works fine but in the second case if I try to look at the same array doe_in(1)%x  the debugger says it's an "unidentified pointer/array".

I tried calling test_sub1 from the test_sub2 to see if I could look at the array in test_sub1. This works fine. I also tried writing SHAPE(doe_in(1)%x) to see if the information needs is there and it seems to be.

I want to add that I'm fairly new to Fortran programming so what I have presented here might not be the conventional way of doing things. Please do comment if you can see a better way of doing this.

Any help on this issue would be greatly appreciated. 

Many thanks,

Jonathan

Hi All

    I have a debug software that want to integrate with Intel JTag debugger. Can I send command to it and control it to do these actions:

a) add/delete breakpoint base on physical address / virtual address

b) set/get value from memory base on physical address / virtual address

c) pause/continue <— I can send a pause command to JTag debugger so that i can pause the atom dev board

d) get/set all registers

e) single step the atom

Thanks Peter

In this beta test, you will have early access to Intel® Parallel Studio XE 2016 products and the opportunity to provide feedback to help make our products better.  Registration is easy through the pre-Beta survey site.

This suite of products brings together exciting new technologies along with improvements to Intel’s existing software development tools:

• Expanded Standards and Features – Scaling Development Efforts Forward
  Additional language support for C11 and C++14, Fortran 2008 Submodules and IMPURE ELEMENTAL, and C Interoperability from Fortran 2015, and OpenMP* 4.1 TR 3.  New support for SIMD operator use with SSE integer types, Intel® Cilk™ Plus combined Parallel and SIMD loops, OpenMP* 4.0 user-defined reductions (C++ only), enhanced uninitialized variable detection (Fortran only), feature improvements to Intel’s Language Extensions for Offload, annotated source listings, and a new directory structure.  All available in the Intel® C/C++ and Fortran Compiler 16.0 Beta.
   
• Vectorization– Boost Performance by Utilizing Vector Instructions/Units
  Vectorization Advisor identifies new vectorization opportunities as well as improvements to existing vectorization and highlights them in your code.  It makes actionable coding recommendations to boost performance and estimates the speedup.  Available in the new Intel® Advisor XE 2016 Beta!

• Big Data Analytics– Easily Build IA Optimized Data Analytics Application
  Intel® Data Analytics Acceleration Library (DAAL) 2016 Beta will help data scientists speed through big data challenges with optimized IA functions

• The Intel® Math Kernel Library 11.3 Beta introduces Inspector - Executor API for Sparse BLAS: a new two-stage API for sparse Matrix Vector Multiplication format, as well as MPI wrappers to support custom MPI Implementations

• The Intel® Integrated Performance Primitives 9.0 Beta adds new APIs to support external threading – a feature which allows users to choose different threading approaches for the applications

• Scalable MPI Analysis – Fast & Lightweight Analysis for 32K+ Ranks
  Intel® Trace Analyzer and Collector 9.1 Beta adds a new MPI Performance Snapshot feature for easy-to-use, scalable MPI statistics collection and analysis of large MPI jobs to identify areas for improvement

• Enhanced OpenMP* analysis and MPI+OpenMP multi-rank analysis
  Intel® VTune™ Amplifier 2016 Beta adds OpenMP parallelization inefficiency, imbalance and work sharing analysis to tune for more efficient use of parallel regions.  It also now supports multi-rank analysis of MPI compute nodes with or without OpenMP use.

If you are ready to get started, follow this link to complete the pre-beta survey, register, and download the beta software:

Intel® Parallel Studio XE 2016 Pre-Beta Survey
 

For more details and information about this beta program, check out the Intel® Parallel Studio XE 2016 Beta page, which includes additional information in the FAQ and What’s New documents.

As a Beta tester, you’ll be expected to provide feedback to our development teams via Beta surveys and submissions at Intel® Premier Support.

Hi,

I am new to gdb-ia, wonder if there is reference about how to use it for Fortran in Mac?

Thanks!

Liz

Hello,

We recently started using the Intel JTAG XDP probe with Atom E38xx processors using Coreboot and the Intel FSP.  On a BakerSport board the probe connects OK, but on our new board with an E3845 processor we get the following error message:

JTAG connection was established but the target appears to have security-restricted JTAG.  Please try disabling JTAG security in the platform firmware.

Searching the Intel docs and this forum haven't helped us figure out how to resolve this.  All I found was in the JTAG debugger release notes:

9.1.4  Platform security policy may inhibit debugger operation

In some platforms the security policy may disable JTAG access to the CPU, this is intended to prevent reverse-engineering.  In this case the JTAG debugger will successfully connect to the target, however it will not be able to discover any CPUs on the JTAG bus, and will warn the user that no CPUs are available.  To resolve this issue please ensure that that platform firmware has enabled access to the CPUs via JTAG, this is typically done by flashing a special “debug” firmware into the target.  

Also note that in some cases the CPU or CPU module may have physically disabled JTAG access, especially in production or near-production versions.  In this case please work with the platform business unit to obtain JTAG-enabled hardware.  

How do we get a firmware setup which will allow us to use the JTAG probe with our new board, please?

Thanks,

Bill

Hi, 

I am currently trying to debug a native Xeon Phi application using Intel Composer XE 2015 and eclipse. The Xeon Phi is installed on a remote server that I can ssh to through an intermediate server. 

I have managed to debug it using gdb-mic in console mode from my local computer. I can also run eclipse on the remote server by forwarding the X window to my local computer, and I managed to debug a native application. However, this solution is not really usable as the network limitations gives an extremely laggy debugging experience while forwarding the graphical interface and debugging the Phi.

Therefore, I would like to run eclipse on my local computer and connect it to the Xeon Phi installed on the remote server. I have however not managed to do so using these instructions (https://software.intel.com/en-us/articles/debugging-intel-xeon-phi-appli... Native Debugging), as the remote server is hidden behind the intermediary server and I was not able to connect to it using the RSE as explained in this guide. 

Another option would be to manually set up port forwarding from my local computer to the Xeon Phi, and manually start the application with gdbserver on the Xeon Phi listening to the forwarded port. Then, I could set up manual debugging with Eclipse on that port on my local computer, and start debugging. However, using gdb-mic, I run into this error :

Could not determine GDB version using command: /opt/intel/composer_xe_2015.3.187/debugger/gdb/intel64_mic/bin/gdb-mic --version
Could not find platform independent libraries <prefix>
Could not find platform dependent libraries <exec_prefix>
Consider setting $PYTHONHOME to <prefix>[:<exec_prefix>]
ImportError: No module named site

I have not found indications on how to solve this issue, and I am not very familiar with gdb on eclipse yet. 

Are there any solutions to this problem or another way to debug the native Xeon Phi application on an hidden remote server using Eclipse?

Thank you for your time

Hi

I have experienced a rather counter productive bug in parallel studio over the last few months ...

I use the latest version of the Fortran compiler and debugger in parallel studio with visual studio 2012 on windows 2008 r2.

If I hit "stop debugging" in the middle of a debugging session I am no longer able to link the program without restarting visual studio. I get the error message below and it happens consistently when I terminate a debugging session running on normal cpus. If I terminate the session while inside a MIC offload region everything works as it should ...

Hope you are able to reproduce the problem so the bug can be fixed ... 

Thanks!

C

Error    1     fatal error LNK1201: error writing to program database 'xxx.pdb'; check for insufficient disk space, invalid path, or insufficient privilege    LINK    

I am using a derivative of QuarkBSP on my GalileoGen2 board, a Flyswatter2 debugger, and OpenOCD 0.9.0 and Intel System Studio 2015 for Windows.  OpenOCD is running and ISS connects to the GalileoGen2, but I can't figure out how to get my firmware symbols loaded.  Does anyone have advice?

At xdb prompt I type "efi" and see many commands, including EFI "LOADMODFROMMAP %s %s"

This command, and probably others, isn't listed in Debugger Help => Help Contents.

Request: please scrub all Help documentation to ensure it is in sync with the app's help output.

Hello, I am creating this forum post because I can't seem to find a place to submit a bug report to Intel. I hope that this will help anyone else who runs into the same problem.

The debugger that comes with intel studio 2016 has an error in the debuggervars.sh script found in

/opt/intel/debugger_2016/bin/debuggervars.sh

By default, Ubuntu leaves the MANPATH and INFOPATH shell variables empty. However, setting them overwrites the man and info search paths. To retain the default search paths, ensure an empty string is one of the paths set in MANPATH. I.e.,

export INFOPATH=$GDBMAN

should be

export INFOPATH=$GDBMAN:$INFOPATH

If INFOPATH isn't set, the latter will still work as desired while the former won't. This is an error on lines 97 and 104 of the script.

As a workaround, you can simply add

export MANPATH=${MANPATH}:
export INFOPATH=${INFOPATH}:

somewhere in your profile.

I'm following the instructions for debugging a native Phi (KNC) under Eclipse, here:

https://software.intel.com/en-us/articles/debugging-intel-xeon-phi-appli...

After one or two minutes, the Eclipse debugging session terminates with a pop-up message:  "Connect to mic0 was cancelled" (see also the screen shot).  If I attempt to restart the clicking the "Debug" window again, it generates a 'Launching New_configuration' error (New_configuration is the name of the remote debugging configuration). I have to go back to Run->Debug to actually get a new session to start up on mic0, but that terminates after a couple of minutes as well.

Seen this? Found a fix? Thanks, -John

gdb 7.6, 7.7 and 7.8 have a ELF bug that causes them to crash in some situations.

Please see this discussion for more information: http://stackoverflow.com/questions/27355304/gdb-crashes-at-start-interna...

We have solved this problem by building our own version of gdb from the 7.9 source code. However, I don't think this is possible for the MIC, as the gdb for MIC has lots of modifications from the gdb mainline.

When will gdb based on 7.9 be released by Intel?

The error message that gdb spits out is

../../gdb/dwarf2read.c:16760: internal-error: follow_die_offset:
Assertion 'dwarf2_per_objfile->reading_partial_symbols' failed.
A problem internal to GDB has been detected,
further debugging may prove unreliable.

Hi all,

I am working on development of a customized android tablet based on intel Baytrail-T.

In the above project we are facing a issue due to I2C.

Here is the step by step scenario of the issue:

1-Power on the board and let it boot to the android GUI.

2-Press the power button for some time and then power off the board from the Android Gui.

3-Now power on the board without disconnecting the power supply.

Then the board gets stuck and we get the beow logs continously.

[   14.198812] i2c_designware 80860F41:01: ===== REGISTER DUMP (i2c) =====

[   14.206396] i2c_designware 80860F41:01: DW_IC_CON:               0x65

[   14.213639] i2c_designware 80860F41:01: DW_IC_TAR:               0x18

[   14.220957] i2c_designware 80860F41:01: DW_IC_SS_SCL_HCNT:       0x214

[   14.228295] i2c_designware 80860F41:01: DW_IC_SS_SCL_LCNT:       0x272

[   14.235592] i2c_designware 80860F41:01: DW_IC_FS_SCL_HCNT:       0x50

[   14.242811] i2c_designware 80860F41:01: DW_IC_FS_SCL_LCNT:       0xad

[   14.250032] i2c_designware 80860F41:01: DW_IC_INTR_STAT:         0x0

[   14.257236] i2c_designware 80860F41:01: DW_IC_INTR_MASK:         0x246

[   14.264539] i2c_designware 80860F41:01: DW_IC_RAW_INTR_STAT:     0x10

[   14.271762] i2c_designware 80860F41:01: DW_IC_RX_TL:             0x20

[   14.279527] i2c_designware 80860F41:01: DW_IC_TX_TL:             0x20

[   14.286814] i2c_designware 80860F41:01: DW_IC_ENABLE:            0x1

[   14.293916] i2c_designware 80860F41:01: DW_IC_STATUS:            0x2

[   14.301360] i2c_designware 80860F41:01: DW_IC_TXFLR:             0x2

[   14.308489] i2c_designware 80860F41:01: DW_IC_RXFLR:             0x0

[   14.315595] i2c_designware 80860F41:01: DW_IC_TX_ABRT_SOURCE:    0x0

[   14.322718] i2c_designware 80860F41:01: DW_IC_DATA_CMD:          0x0

[   14.330427] i2c_designware 80860F41:01: ===============================

[   14.339419] i2c-2: recovery ignore

In the above condition either or both the SCL and SDA line remain low on boot time.

On this I2C we have only one device i.e Audio Codec from TI.

Please help us asap.

We are on very tight schedule.

Also if i reboot by removing the power supply then the board boots fine.

Hello.

I have a problem with debugging an Intel Core processor. My hardware is listed below:

1. Intel Core i3-4130 (Haswell) Processor

2. ITP-XDP 3BR Kit 

3. TSP-H3-ULGA 

I think I have assemled a testing PC proper, because it loads OS and work normally. But when I try to connect to the PC throw Intel System Debugger I see:

Intel System Debugger 2016 (x64) 
Version 16.0.84641  (64-bit)
Copyright(c) 2001-2015 Intel Corporation. All rights reserved.
INFO: Caching of registers and memory is *enabled*, subsequent reads from target will be cached
INFO: Initializing Target Connection Interface...
INFO: Initializing probe connection, this will take a moment...
INFO: Probe connection initialized!
INFO: Connected to Processor type: Haswell (4 threads)
Target did not halt execution.
WARNING: Unable to halt the target during debugger initialization, you may need to reset, power-cycle, or apply additional platform-specific steps to continue!
INFO: Initialization complete.
E-2201: Target did not halt execution.

And if I try to suspend the PC, last line prints one more time. I don't understand at all why I have this problem. In documentation I found this out:

Errors include “E-2201: Target has no active threads, this operation is not permitted.” and “E-2201: Target did not halt execution.” This condition occurs when the debugger attempts to halt the target, but the CPUs are asleep and therefore unresponsive to debugger commands. Workaround: manually bring the CPUs out of sleep (e.g. by fiddling with the tablet) *or* try repeatedly to halt via the debugger, after 2-3 tries the target typically wakes up

My PC is not in sleep or another low-power state.

What I should do in this situation?

Hey,

I'm using the Intel Debugger for the first time, Version 13.0, on Redhat Linux.  I am debugging a fortran program and noticed that none of my parameter declarations can be evaluated.  If I mouse over, the popup doesn't appear and if I drag, for example, mxld into an Evaluation window, the Value field says, "No symbol "mxld" in current context.  The source code was compiled using ifort with the -g option (among others). Variables evaluate just fine.  How do I get my parameters to evaluate?

I have this:

Intel(R) Visual Fortran Composer XE 2013 SP1 Update 3 Integration for Microsoft Visual Studio* 2010, 14.0.0092.2010, Copyright (C) 2002-2014 Intel Corporation

I would like to use a 3rd party IDE (Winteracter) to invoke the debugger.  Is there supposed to be an idb file in this release?  Please let me know.  Thank you.

Sincerely,

CHobbs

Have you ever been in the position of having written a DLL that is incorporated into a Windows Forms application that has no console window....
... and all the diagnostic trace code requires console output.

While it is simple to create a console inside your code of the DLL, what do you do when the error your are trying to trace out occurs at DLL load time prior to entry into Main of your forms application?

I recently had come upon this situation. My DLL depended upon a 3rd party DLL that had load issues. Fortunately, their DLL had an option switch, enabled by environment variable, that would dump out diagnostic information to the console. Unfortunately when there is no console, this information gets lost.

The solution is to create the console at the time of LoadDLL that is called inside the runtime system initialization phase at program load time. To do this you add a startup routine, typically referred to as DllMain.

function DllMain (hInstDLL, fdwReason, lpReserved)
!DEC$ ATTRIBUTES STDCALL, DECORATE, DLLEXPORT, ALIAS:"DllMain" :: DllMain
    USE IFWINTY
    USE Kernel32
   
    IMPLICIT NONE
    integer(BOOL) :: DllMain
    integer(HANDLE), intent(IN) :: hinstDLL
    integer(DWORD), intent(IN) :: fdwReason
    integer(LPVOID), intent(IN) :: lpReserved
   
    character(500) :: eVar
    logical, save :: FirstTime = .true.
   
    integer(BOOL) :: b
   
    if(FirstTime) then
        FirstTime = .false.
        b = AllocConsole()
        write(*,*) "***************************"
        CALL GET_ENVIRONMENT_VARIABLE("MIC_LIBRARY_PATH",eVar)
        write(*,*) "MIC_LIBRARY_PATH=",TRIM(eVar)
        CALL GET_ENVIRONMENT_VARIABLE("MIC_LD_LIBRARY_PATH",eVar)
        write(*,*) "MIC_LD_LIBRARY_PATH=",TRIM(eVar)
        write(*,*) "***************************"
        flush(6)
        DllMain = 1
    else
        DllMain = 0
    endif
end function DllMain

In my situation, an additional environment variable had to be set to enable the other DLL's trace output. This worked to get the information we needed to start the investigation of offload failure.

Jim Dempsey

Previous usage of ISS-2015 System Debugger worked OK with my BroadIsland(Broadwell cpu) target board.

INFO: Probe connection initialized!   INFO: Connected to Processor type: Broadwell (4 threads) INFO: Initialization complete.

execution stopped by "MWAIT C1 B break"

THEN, installation of ISS-2016 System Debugger is having trouble recognizing Broadwell cpu.

INFO: CPU type "Broadwell" is unknown, generic x64 CPU registers will be used. INFO: Initialization complete.

PLEASE HELP me understand this message?

HWM