This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

[DSTREAM]Target Message: Could not determine target state

Hi all,

I have a QCA IPQ4019 board. I am following this blog https://community.arm.com/tools/b/blog/posts/porting-linux-made-easy-with-ds-5 to debug from the stage in which  u-boot loads the Kernel.  I can get to below step described in the blog.

>A compressed kernel will stop at the breakpoint at 0x80008000 before decompressing. 

(Note, in my case the breakpoint is 0x80208000)

But I encounter error "Target Message: Could not determine target state" and I can not control the CPU core any more. Below is the full log. Any advice why there is such error?  Thanks !

Signals handled by operating system
Connected to running target QCA - IPQ4019-detect-debug-and-trace on USB:002273
cd "/home/tonyhe/DS-5-Workspace"
Working directory "/home/tonyhe/DS-5-Workspace"
hbreak -d -p *N:0x80208000
Hardware breakpoint 1 at N:0x80208000
condition 1 
break-script 1 ""
ignore 1 0
break-stop-on-cores 1 
unsilence 1
Breakpoint 1 unsilenced
break-stop-on-vmid 1
enable 1
Breakpoint 1 enabled
Execution stopped in SVC mode at breakpoint 1: N:0x80208000
N:0x80208000   BL       {pc}+0x1a20 ; 0x80209a20
Target Message: Could not determine target state

update1:  add more details or background of my question.  IPQ4019 is with 4 cores. In the u-boot mode, the debugger can not connect 4 cores. I encounter below error when connecting 4 cores.  Debugger can only  connect 1 core.  It seems that the other 3 cores are power-down. So in my question, only 1 core is connected.  I am suspecting the only core is also power-down when I encounter error "Target Message: Could not determine target state".  Any suggestion?

Parents
  • Hi Tony,

    You have very likely hit upon the problem. When SoC designers choose not to separate the power domains for core/cluster and debug logic, when the core powers down the debug logic goes as well. This results in the debugger being unable to read the core state. For many SoCs this issue can be worked round by requesting uboot (or the Linux kernel) to not power down the cores when they enter the idle code. The details on how to do this are usually SoC dependant. I am not familiar with the device you are using so I cant offer you any specific help. Maybe others will know the details.

    Best wishes, Tony.

Reply
  • Hi Tony,

    You have very likely hit upon the problem. When SoC designers choose not to separate the power domains for core/cluster and debug logic, when the core powers down the debug logic goes as well. This results in the debugger being unable to read the core state. For many SoCs this issue can be worked round by requesting uboot (or the Linux kernel) to not power down the cores when they enter the idle code. The details on how to do this are usually SoC dependant. I am not familiar with the device you are using so I cant offer you any specific help. Maybe others will know the details.

    Best wishes, Tony.

Children