Hi Paul,
Correct, only the VSCode_HelloWorld is yet suited for use with the separate dependencies pack. We still need to find some time to update our examples 
Rolf
Well, It looks like I was wrong about the VSCode_HelloWorld example working. While I can build it, I can’t debug it. The same problem as before, the perpetual traveling blue bar, still occurs.
I hate to whine, but I’ve wasted far too much time trying to get a development system working. Both Modus Toolbox and VSCode appear to be patchwork setups that are far too complicated for someone who cannot devote 100% of his work schedule to software. If I can’t get a system working soon, I will have to abandon PSoC 6 based products and look for substitutes. I don’t want to do this, but our customer won’t wait forever.
I’m desperate. Please help.
Paul
Hi Paul,
Are you able to post the adapter output?
Thanks,
Rolf
Here is a screen capture.
As you can see, there is no option for adapter output. The little blue bar above the debug toolbar moves endlessly from left to right.
Paul
Paul, Did you install the [Windows dependencies pack] (https://github.com/onethinx/VSCode_OnethinxPack_Windows) according the instructions (and run the .bat file)?
Rolf
Yes, I did.
Here’s where it gets even more interesting (mysterious). I installed VSCode and the Onethinx pack on a laptop computer in exactly the same manner as I did with my desktop computer. The debugger appears to work on the laptop, but does nothing on the desktop.
Now that I have at least one working system, I can proceed. But, I would much rather have it working on my desktop, since it is a much higher performance machine.
Paul
Hi Paul,
That’s strange indeed. I remember I saw this issue a while ago, but I don’t remember the exact cause.
- Do you see an error when you click “Check Build” (blue bar below)?
- What happens if you type
arm-none-eabi-gdb -vinto your terminal window (cmd) of VS code? - Did you try to restart your PC?
Rolf
Hi Rolf,
It appears that my long nightmare is over. I have systems working on both computers. I’ll describe what I did, in case someone else has a similar situation.
After the successful installation on the laptop, I decided to compare the two computer setups. I noticed that the desktop had Cmake, MinGW, ARM-GNU, and other software left over from previous installation attempts based on old instructions (forum, Github, whatever). I suspected that parts of the VSCode setup might be accessing these, while other parts might be trying to use those that were in the Onethinx pack. So, I did the following:
- Uninstalled VSCode
- Deleted all VSCode extensions (in the C:\Users\…\.vscode folder)
- Deleted the Onethinx pack
- Uninstalled ARM-GCC (or whatever it was called)
- Uninstalled Cmake and Cmake Tools
- Uninstalled all MinGW components
- Reinstalled VSCode, extensions, and the Onethinx pack
- Ran the setVariables batch file and restarted the PC
After all this, I still got errors at configuration time. Somehow, I figured out that, in the Cmake Tools extension, the “Cmake Path” setting was still set to the old Cmake location (it’s difficult to completely get rid of anything in Windoze). Once I changed the setting to cmake (the default setting), everything worked OK.
I hope this can help someone else avoid the frustration I endured.
I might also add that, due to the patchwork nature of this environment, it’s difficult to correct a bad setup, since settings/parameters/etc. are scattered among several files and extension settings. It would be nice if someone could make a list that describes important settings and where/how they are accessed.
Actually, it would be best if Cypress could change PSoC Creator to allow debugging the M4 core with a locked down M0. But I’m not going to hold my breath.
Paul
1 Like