This is not related to displaying huge arrays in a single-step scenario.
I find that after entering debug mode, after everything is settled and ready, I press F5 and wait many (10-20, stopwatch) seconds before the processor starts executing code. If I hit a breakpoint, and press F5 again, I still have to wait many seconds before the processor starts executing again.
Is there a diagnostic I could run on the debug probe that would determine whether it's faulty?
Is there some other test I could perform to determine the cause of this
This is a relatively new development. I have been working on one form or another of this project for several months, and only in the past couple of weeks has it become _really_ slow. Prior to that it was the examination of several 2048 byte buffers that slowed things down.
I don't know whether this is a separate problem or related, but the debugger consistently loses contact with the probe after ten or fifteen minutes (this I have not timed with a stopwatch). This results in an error message in the output window: "Error: dbg.M0015: Debugger exited unexpectedly during run. Encountered error (Target disconnected See output window for more information.)". Unfortunately, this is the only information available in the output window.
Message was edited by: John Griswold
PSoC 4 Architecture
If we have relatively large (512 x 4 byte) arrays in debugger watch window then it takes a lot of time to update the value of these variables.
The delay is caused by GDB reading long arrays one element at a time.
Presently, there are no Creator releases planned anytime soon resolving this issue..
Moving the arrays to another scope (such as global variables) might prevent them from being displayed in the Locals window.
If you feel above is not your case, please share the project in order to recreate the issue.
I am not able to share the project due to proprietary concerns, but this is not a case of reading back memory. There is nothing in the watch window. The only windows open are Output and Notices.
I've been bitten by the large array problem in the past. This is different.