Why am I getting a "Target not responding" error message when I connect to the target?
This error message could be caused by the following:
- Unreliable JTAG Connection — Try reducing the JTAG clock frequency or reducing the target interface's cable lengths as much as possible.
- You are connecting to a target that requires adaptive clocking with a target interface that is not configured for adaptive clocking and is running the JTAG TCK too fast for the target. This typically happens with synthesized cores such as the NXP LPC2000.
- Current Active Project Not Intended For Target Device — Make sure that the CrossWorks project you have loaded and selected is intended for the device you are targetting.
- Incorrect ARM Debug Interface Type — Check that the Target > ARM Debug Interface project property matches the type of target you are trying to connect to.
Comments
8 comments
Make sure the project you're using is executable (example - has a 'C' main function), and is not a library.
Thank you Dave, this was my "stupid" problem.
Certainly a clearer message than "Target not responding" would make a poor developer's life much easier! Don't you think, Rowley?
Actually, no. CrossWorks allows you to connect to a target without a project loaded because you may well want to do that--you just need to set the target interface correctly. We do this when targeting a new board with a new CPU. The "Target Not Responding" indicates no life at the other end of the wire, for whatever reason...
Ok Paul, thank you for the quick answer. You may not agree on this, but I would like to explain better the problem.
I've got a solution made up of two projects, one of which is a library. Both projects are set on the correct target ARM architecture. I wasn't aware that for some reason the lib got selected as "active" project. Since then, whenever I tried just to "connect" the target - without loading any code - I got a "Target not responding!" error.
If, as you say, this error indicates "no life at the other end" - which is exactly how I interpreted the message - then I think you should change it to a more truthful one, since my target was alive and kicking!
Thank you.
Regards
Joe
I have had some similar issues with a USB CrossConnect and have tried using it on a separate PC (of my colleague) with no problem. On my PC is says 'Target Not Responding' and I think I have tried pretty much everything.
So far I have also:
Windows is detecting the CrossConnect as normal and telling us that the Device is operating correctly. It seems to set the driver up okay and assigns the location to Port_#0002.Hub_#0004 (Whatever that is meant to mean).
In addition to the classical methods mentioned before I have been onto the Rowley forums and looked for people who have had similar problems. Some suggestions offered that I tried included:
Someone else suggested that the problem might be caused by the firmware not having a main function, so I deleted all the firmware and did a fresh CVS checkout of all the repositories and tried again. I did a keyword search for ‘int main (void)’ and sure enough, there it was and not missing at all, so I wasn’t missing a main function or something stupid like that.
In summary this error indicates that CrossStudio thinks that there is no life at the other end – but of course I know there is nothing wrong with the driver, the hardware, the cables etc, so I am really at loss to explain the cause of these problems that seem to have occurred for no reason, because there is no logical answer.
Check the CrossConnect target settings match the ones that work on the other PC.
No, not Duh. That is ARM7/9/ADIv5/whatever. As the CrossConnect works on another PC, it is clearly a setting either in your project, a setting on the target interface, or a difference in your board setup. Hence, do the sensible thing, try replicating target settings and using the known-good board. If your colleague has another CrossConnect, and you use it on your config and it doesn't work, then you know it is a setting/target board issue.
Oops I had multiple projects open and had not 'set the active project'. It was trying to compile a USB library instead, which of course did not have a main function. Sorry. It is connecting now.
You should probably also mention: the device might have JTAG disabled due to a security level being enabled. In that case, the device must be erased (perhaps through ICP serial port using e.g. Flash Magic) for JTAG to be enabled.
Please sign in to leave a comment.