ADSP-SC573 debugging SHARC affects ARM

I'm running Buildroot Linux on the ARM core, and two bare metal apps on the SHARC+ cores. When I connect with the ICE 1000, using a debug configuration that only loads symbols and attaches to one of the SHARC cores, Linux slows waaaay down, like by a factor of 100 or more. I can still type commands on the serial console, but the response dribbles out slowly. Needless to say, when I run an app on Linux, it also runs slow, which makes it difficult to debug things that communicate between Linux and a SHARC.

The other thing that happens is that when I initially connect, frequently I get a crash in my Linux application. Here is a typical error dump that appears on the console:

Unhandled prefetch abort: debug event (0x002) at 0xffff0008
Internal error: : 2 [#1] ARM
Modules linked in:
CPU: 0 PID: 525 Comm: AudioPipe Not tainted 4.0.0-ADI-1.3.0-svn40580 #13
Hardware name: SC57x-EZKIT (Device Tree Support)
task: cd935b00 ti: cdbd8000 task.ti: cdbd8000
PC is at _einittext+0x3fab6e58/0xfffe0658
LR is at 0xb6f8a566
pc : [<ffff0008>]    lr : [<b6f8a566>]    psr: 800f0093
sp : cdbd9ff8  ip : 000000dd  fp : befff99c
r10: b6fff000  r9 : 00000000  r8 : 00000000
r7 : 000000dd  r6 : 00000034  r5 : 00000001  r4 : 00000003
r3 : befff930  r2 : 00000000  r1 : 00000003  r0 : 00000003
Flags: Nzcv  IRQs off  FIQs on  Mode SVC_32  ISA ARM  Segment user
Control: 10c53c7d  Table: 8ec38059  DAC: 00000015
Process AudioPipe (pid: 525, stack limit = 0xcdbd8210)
Stack: (0xcdbd9ff8 to 0xcdbda000)
9fe0:                                                       00000000 00000000
Code: bad PC value
---[ end trace 1b7950c7194121d7 ]---

It's always the same exception, and the code at the LR location is an SVC instruction. (AudioPipe is the name of the app.) Obviously, this makes things undebuggable.

Any ideas on how to solve these two possibly related problems? Does anyone else see either of these?

Top Replies

    •  Analog Employees 
    Mar 12, 2020 in reply to pderocco +1 verified

    Hi ,

    The CCES configuration I mentioned above is for debugging SHARC code with CCES 2.8.3 on Windows. I have reproduced the slow issue you reported myself, the root-cause is the "semihosting".…

Parents
  • 0
    •  Analog Employees 
    on Mar 9, 2020 2:44 AM over 1 year ago

    Hi ,

    I think these two issues are related with the hardware resource conflict between ARM and SHARCs. Is that possible to share your code of the these projects to the following E-mail Address, that will be very appreciated!

    E-mail: processor.tools.support@analog.com

    Thanks a lot.

  • I can't do that without special permission. But are these problems anomalous? (I hope so.) It's hard to imagine what application specific thing could cause Linux to slow down, merely as a result of attaching to an already running SHARC program. And it happens whichever of two very different SHARC apps I attach to in the two cores. And Linux doesn't just slow down while the SHARC is halted. And as soon as I disconnect the debug session, it runs full speed again.

    While in this slow state, the "top" command shows something like this:

    Mem: 20844K used, 201012K free, 220K shrd, 2280K buff, 12460K cached
    CPU:   0% usr  52% sys   0% nic  46% idle   0% io   0% irq   0% sirq
    Load average: 0.79 0.62 0.73 1/37 544
      PID  PPID USER     STAT   VSZ %VSZ %CPU COMMAND
      544   519 root     R     2244   1%  52% top -d 1
      466     1 root     S     2172   1%   2% watchdog -t 5 /dev/watchdog
      478     1 root     S     4036   2%   0% /usr/sbin/sshd
      519     1 root     S     2244   1%   0% -sh
      482     1 root     S     2240   1%   0% sbin/inetd
      455     1 root     S     2172   1%   0% /sbin/syslogd -n
      458     1 root     S     2172   1%   0% /sbin/klogd -n
        1     0 root     S     2172   1%   0% init
      514     1 root     S     2172   1%   0% udhcpc
      413     2 root     SW       0   0%   0% [iccqd]
        3     2 root     SW       0   0%   0% [ksoftirqd/0]
      414     2 root     SW       0   0%   0% [iccqd]
      315     2 root     SW       0   0%   0% [kworker/0:1]
      432     2 root     SW       0   0%   0% [mmcqd/0]
        9     2 root     SW       0   0%   0% [kworker/u2:1]
        2     0 root     SW       0   0%   0% [kthreadd]
        4     2 root     SW       0   0%   0% [kworker/0:0]
        5     2 root     SW<      0   0%   0% [kworker/0:0H]
        7     2 root     SW<      0   0%   0% [khelper]
        8     2 root     SW       0   0%   0% [kdevtmpfs]

    However, the time-of-day clock runs at full speed.

    If it's any help, I'm using CCES 2.8.3, and connecting with an ICE 1000 that has a 1.2 sticker on the second-largest chip on it. Is everyone else seeing Linux run at full speed while debugging the SHARC?

  • 0
    •  Analog Employees 
    on Mar 11, 2020 4:39 AM over 1 year ago in reply to pderocco

    Hi ,

    Sorry to make you confused.

    Have you disabled the semihosting in the "Automatic Breakpoints" view of your CCES debug configurations as mentioned in the Linux add-in userguide?

  • I'm not using CCES to debug Linux, I'm using 2.8.3 on Windows to debug SHARC code. It doesn't have a "semihosting" option, and turning off the few auto breakpoints doesn't change anything. Linux just boots up on its own, and I don't even have to be running a specific Linux application; just typing "ls" on the serial console slows way down when I attach to a running SHARC app. My SHARC apps are started by two calls to the loadsharc_SC573 program in a script in /etc/init.d.

  • +1
    •  Analog Employees 
    on Mar 12, 2020 2:36 AM over 1 year ago in reply to pderocco

    Hi ,

    The CCES configuration I mentioned above is for debugging SHARC code with CCES 2.8.3 on Windows. I have reproduced the slow issue you reported myself, the root-cause is the "semihosting". 

    I recommend you to follow the section "6.5 Run Linux on ARM and bare-metal application on SHARC" of the linux_add_in_user_guide.pdf to debug your SHARC application with the CCES on windows.

    And the configuration is also working if you want to load/reload the SHARC applicaton after ARM boots into Linux.

    Thanks a lot.

Reply
  • +1
    •  Analog Employees 
    on Mar 12, 2020 2:36 AM over 1 year ago in reply to pderocco

    Hi ,

    The CCES configuration I mentioned above is for debugging SHARC code with CCES 2.8.3 on Windows. I have reproduced the slow issue you reported myself, the root-cause is the "semihosting". 

    I recommend you to follow the section "6.5 Run Linux on ARM and bare-metal application on SHARC" of the linux_add_in_user_guide.pdf to debug your SHARC application with the CCES on windows.

    And the configuration is also working if you want to load/reload the SHARC applicaton after ARM boots into Linux.

    Thanks a lot.

Children