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".…