I can't seem to find a way to create a CCES v2.8.1 for Windows Debug Configuration that will allow me to debug SC573 Core1 and Core2 SHARC code without halting the Linux code running on Core0.
If I create a brand new CCES project called, for example, BlinkLED to have both SHARC Core1 & Core2 blink an LED on the ADSP-SC573 EZ-Kit, CCES asks me which cores will be involved in this project. I skip the ARM Core0 because it doesn't support the Linux Toolchain, only the Bare-Metal Toolchain, which is not my case because my ARM Core0 code was built outside CCES using my Linux development host's Linux Toolchain with its 'make' command and the Linux Add-In v1.2.0 for CCES Buildroot configuration & code I customized.
I select Core1 and Core2 because that's the only code CCES for Windows can handle in my situation & that's the code I want to debug. It creates the projects (ex: BlinkLED_Core1 and BlinkLED_Core2) and all that builds fine. Now, I want to debug it, so I need to configure a new Debug Configuration, and that's where I never get the Debug button at the bottom right of that window to become available (i.e. not be grayed-out) to start debugging, even with BlinkLED_Core1.dxe and BlinkLED_Core2.dxe under their respective Device [Core N] headings. CCES is forecing me to <Click here to select a program to load> under the Device [Core 0] heading, which it will load over the running Linux system on the ARM Core0. I need a way to remove Device [Core 0] heading completely from the Debug Configuration, don't I? If it's not going to be intuitive, where is this documented at least?
In order to leave the ARM core (ADSP-SC589 Core 0) alone, you should remove all programs from Core 0 in the launch configuration.
After you've removed the last program, you'll be prompted with a dialog that asks if you'd like to update the Target options so that core 0 is not halted when you connect to the target. Swtich to the target options tab and you'll see that you can not enable/disable "Halt core after connecting to target".
This option should be unchecked so that the launch does not touch the ARM core.
Note that a Core reset will happen when you launch your configuration (the SHARC cores will be reset) but a System reset will not occur meaning that any perhiperals etc. will not be reset when you launch as there is already a core running.
That's my point. When I do that, the Debug button becomes unavailable:
I've Applied this configuration, closed it, re-opened it, and confirmed this was all saved ... and still Debug was grayed-out. I then unchecked "Halt core after connecting to target" for the Core0 and noticed that the Automatic Breakpoints tab showed all the usual breakpoints enabled for Core0. I Applied it anyways, closed it, and re-opened it, and confirmed the Debug button is still not available. So, I can't even start a debug session.
I put my current configuration aside and I created a whole new one. This one had the Debug button available so I tried it:
I'll remove all the Core0 breakpoints manually & try again.
After shutting-down & restarting CCES, I'm now able to debug Core1 & Core2 SHARCs without crashing ARM Core0, but my Linux console is painfully (almost unusably) slow:
I suspect it might be the semihosting that's enabled by default at the bottom of the Automatic Breakpoints tab. Like the breakpoints, this setting should be disabled if no code is loaded. I'll try turning it off to see if my ARM Core0 runs Linux at the usual speed.
Yep, disabling semihosting on ARM Core0 did the trick; my Linux shell running on ARM Core0 now seems to be just as responsive as when not debugging SHARC Cores 1 & 2.