Intermission: PSOC5 Compile/Debug Natively on the Mac Part 2 (Updated)

Posted On December 28, 2021

I did not expect to make another post about this, but I have some experience with this process now. Update includes info (see BIG HINT) on the debugger part, and running software on later Mac builds.

Setup Stumbles

During my attempt to set up this environment at home, it failed. No build folder. The problem was rather stupid. I missed the CMake tools extension. Duh.

I tell you this to let you know that it does indeed work on different systems (work is High Sierra, home is a bastardized Catalina (which is giving me fits).)

Sidebar: New MacOS Issues (You can skip this section if you understand spctl, synthetic.conf, Relocated Items)

(Update) Apple is trying to protect us from ourselves. And doing a great job at it. Unfortunately, it makes it difficult for developers at the same time. Once you are at Big Sur or Monterey, it get totally ridiculous.

First, you have to bring up a terminal (found in Application/Utilities) and run “sudo spctl –master-disable” (IN MONTEREY IS sudo spctl –global-disable) This will allow you to go into System Preferences -> Security & Privacy, unlock it, and click on the “Allow apps downloaded from: Anywhere” radio button.

Even so, that is just part of the story. After this, you have to run all of the command line programs in the “VSCode_OnethinxPack_macOS” directories at least once from the GUI. I found that you can go into a bin directory and use the shift key and select all the programs in the directory, then right click and choose “open.” Once this is done, allow the programs to run through the pop-up dialogs. Close all the terminals. After that, you will be able to run CMake from VSCode (after doing the same thing for CMake!) which will run the other programs from the make files.

The nanny OSX will complain the first time you do this, because you are not smart enough to be a developer and google this for yourself. Remember, you are no longer accountable for your actions, it is always some one else’s fault. Ugh. Nuff said!

The third problem was a bit more obtuse. I also use VMWare. Big Sur totally broke VMware due to Apple’s changes. In theory, you can get VMWare Player for a personal use license, but I am stuck in an infinite loop inside VMWare right now due to an expired account which activates, but does not activate, but requires activation and activates, but does not activate….. (Update: Vmware finally fixed that for me)

Fourth, I use Dropbox to shuttle code back and forth, and to have an offsite backup for important data. It is also a crude but effective versioning system. I can always go back to an earlier version of a file with DropBox. I don’t have to go to any extra “check-in” effort to do this.

If only one person is doing code, the extra-ordinarily simple (and fully automated) *almost* a version control effect that DropBox provides can be exactly what is needed. Git is good; it is based on svn which is also good. All version control systems (except using Dropbox in this stupid way) can lead to loss of data or badly compiling systems if the user is not rigorously precise and punctual in their work and checkins. Nothing is perfect. Relying on Dropbox can also give you a fit, so be careful. It is not a version control system, so using it like that causes major headaches, and is not suitable for teams, in my opinion, unless some smart people write some good code.

When I upgraded my Mac to Catalina, all root level folders were moved to a strange directory under /Users/Shared…. which has the name “Relocated Items.” Gee, thanks Apple. No mention of this that I could find during the upgrade process. I also lost use of a *lot* of programs I depended on. Ugh. (Same thing for Big Sur)

I thought my data had disappeared. Nope, just hidden. There is a way to get the directory “back” by using a configuration file in the /etc directory called synthetic.conf. Google it. There is no real detailed information on it, so my first couple of tries failed, but I got it to work. You can take control of your machine back, by disabling spctl and one other thing, but I decided against that for now. It probably makes it harder for viruses with those changes, but somehow I suspect virus writers can be smarter than Apple. (Look at the iPhone issues, for example.)

The synthetic folder caused a problem with Dropbox. Dropbox does not handle it well. Somehow it stopped being notified of file changes in the synthetic folder. Oh, well, just relocate the drop box root folder. It did work well with VMWare, though.

Back to the Main Theme: PSOC5 on Mac.

The Next Problem was building on the Mac was now broken. Even though there are no spaces in folder names in the synthetic folder path, the Mac OS gives the running code the “true” path to the files, which included the folder “Relocated Items,” which has a space in the name, and does not play nicely with the CMAKELists.txt. Thanks again, Apple!

The CMake build engine barfs on folders with spaces in their names. That is a problem with CMake, or the Cmake description file. Thanks CMake! I tried to fix after googling, but no luck. They ganged up to hurt me!

However, neither Apple nor Cmake cares. No, not one bit. I used to think they did, but their actions over the past few years proves they don’t. The world is ending! <grin> (It is, but that is a different story.)

So, I moved the folder to a path without names, and changed the synthetic.conf file so that VMWare and other things I have done are still happy. (You know, a hard link might have worked; note to Apple: It has existed for years in the Unix world….but that is so un-apple!) No spaces in the folder name now.

Success! It will blend…er… build! (BlendTech)

OK, So What Next? I Know, Normal Projects!

What I really wanted was to be able to use a more or less standard Creator project with this environment. After Much Stumbling Around (AMSA), I came up with a solution. There are also problems, but they are easily resolved once the thinking apparatus is removed from the nether regions.

I have determined how to easily take a current project and modify it so that it works with the OneThinx methodology, without a tremendous amount of pain. This set of steps also preserves the ability to jump into Creator and test your software, allowing you to make changes to existing files in either environment and have the work transfer between them without having to think (much).

If you take the example project pointed to in my last post, you will see that the Creator workspace was renamed PSoC_Creator. So is the project. That is unnecessary. It also confused me. I am simple that way. I had to examine source code to determine which of many projects I was working on at the time. OneThinx also moved the workspace into the project directory, which involved some manipulation of defaulted paths within Creator that I did not want to do.

So, here are the steps to use a “normal” project on the Mac and Windows, (or VSCode and Creator within Windows) with a minimal amount of headaches:

1. To make this simple, take the example folder from my last post as your starting point. (PSOC_VS_Creator-main) (If you want to avoid being simple, copy the .vscode directory, config directory, CMakeLists.txt file, and “source” directory into your destination folder. Empty the source directory so you don’t get cross-project contamination.)
2. Rename that folder to what you want it to be. (i.e. myProj) Keep the PSOC_Creator.cysdn folder for now.
3. Inside your folder, using Creator, open a new workspace. Name it whatever you want.
4. Ignore the fact that you have the workspace files at the same level as the CMakeLists.txt
5. Copy the CreatorPostBuild.exe file into your cysdn folder (myProj.cysdn) from the PSOC_Creator.cysdn folder. (I later copied it into the “config” folder and left it there.)
6. Move the PSOC_Creator.cysdn folder to the trash.
7. Open your project (if it is not already open) in Creator, and click on the WorkSpace Explorer Window, on the “Project myProj” and hit F2. Rename it to be PSOC_Creator. Your Workspace is now myProj, and your project is PSOC_Creator.
8. Once you have OK’d this, your project folder is now named PSOC_Creator.cysdn, but your workspace is named something significant.
9. (NOTE: If you feel lucky, skip steps 7 and 8, and edit CMakeLists.txt and change the PSOC_Creator.cysdn references to your folder. I choose not to for now, so the whole thing is portable to new projects without having to remember too much in the future.)
10. THIS IS IMPORTANT: Go to the Design Wide Resources, click on System and make sure “Store Configuration data in ECC Memory” is UNCHECKED. Your project will build and run, but do nothing to the outside world if that box is checked. Very confusing.
11. Move all the C and H files into the “source” directory (which is at the same level as CMakeLists.txt (after cleaning it out from the last project).
12. In Creator, delete these files using the Workspace Explorer. Then right-click on the “Source Files” folder in the explorer and choose “Add->Existing Item…”
13. In the dialog that comes up, you can enter *.c in the file name box at the bottom. You can then click on a file name, use the shift key, and select multiple files to put back into your project.
14. Do the same for the “Header Files” folder.
15. In the Project menu, choose Build Settings… In the Build Settings Dialog, click on the ARM GCC section, choose User Commands, and enter “CreatorPostBuild” (Update: I now reference it as ../config/CreatorPostBuild.exe)
16. Optional: Creator’s debugging system has an issue when debugging using a lot of files. You can be pointed to the wrong file while debugging. To fix this, click on Linker[+] and click on Optimizations in the Build Settings Dialog. Change “Removed Unused Sections” from True to False.
17. Once you have finished the above, build and debug.
18. Stop the debug, and if using VMWare, disconnect the CMSIS-DAP KitProg from the Virtual machine, open the folder in VSCode.
19. It should prompt you for a kit. If not, click on the bottom “select a kit” area. Then, at the bottom of VSCode: 1) Choose GCC 9.3.1. 2) Change “CMake” to Debug. 3) Click “Clean-Reconfigure” If that all works, you should be good to build and debug on the Mac

What Do You Gain?

1. Time!

What is gained from these gymnastics is blazingly fast compile, debug, modify, compile, debug, …. iterations. What takes minutes in Windows (VM) is almost instant on the Mac. I save hours each week, due to my iterative development methodology. I have found over the years that a “stepwise refinement” process in development speeds up development without a corresponding increase in bugs, irrespective of project complexity. (Up to a point. There are always limits.) It also forces me to create more modular subsystems so code can be dropped in with few changes.

Modular subsystems create a lot of small files, each doing one thing perfectly. I use “init_foo()” and “handle_foo()” in my main and operational loops. Then, for a new project, copy and paste the schematic, change pin assignments if needed, add my foo.c and foo.h files, add init_foo() and then handle_foo() at the right places, and I know how my code will behave. On to new things after that.

I keep the Virtual Machine window showing on my second monitor while using VSCode so I can see the schematics during initial development. If anything changes on the Creator (Windows) side, a Clean-Reconfigure brings the Mac side up to current and you can continue development natively on the Mac. If files are added to VSCode, I also add them to Creator.

What Do You Lose?

Not a lot, in my opinion, especially during the debug phase. Here is what you don’t have:

1. No ECC.
2. No Flash Protection.
3. Programming will fail on the Mac if the Flash is protected, even to undo the protection. You must use Creator to unprotect your flash.
4. GUI EEPROM data assignment probably does not work (not tested). However, EEPROM interfacing from code does work.
5. Using the KitProg serial ports does not work, since the debugger is in the CMSIS-DAP mode. (UPDATE: If you use a KitProg3 (or KitProg2 updated to KitProg3) you can use the serial port at the same time as you debug. KitProg still does not provide that service.)

A note about KitProg on Mac/Linux. It’s serial port shows up as a usbmodem (without drivers!) under Mac and Linux. You can use the “screen” program on the Mac (or add it to Linux) to connect to the debugger stub’s serial port and communicate with the CY8CKit-059 pins 12[6] and 12[7], just add a UART to your build. This is not available in the CMSIS-DAP mode.

UPDATE: See more recent posts. If you take a KitProg2 (5 volt) and update it to a KitProg3, you can get the side channel USBUART back and debug and communicate over TTL RS232 with your PSOC with the one debugger stub.

Development is a bit wonkers with VSCode, as you have to go into Creator to modify the hardware and assign pins, then Clean-Reconfigure to get VSCode working well again. However, this is a minimal problem.

The gain in speed during debugging is worth it. (BIG HINT for debugging: The debugger console is available, and the “set output-radix 16” provides you hex for all your variable pop-up values.)

I suspect the KitProg issues will be resolved by someone smarter than I, soon. (See my recent posts about KitProg2 to KitProg3 update. I was able to solve it. Huh!)

Even so, with the dual environment setup, the “Final Configuration” compile and load can be done with Creator. You can then choose ECC if you wish, and you can handle Flash Protection at that time. By carefully keeping the same file list in both Creator’s side bar (populated manually) and VSCode’s side bar (populated by files in the directories), you can move between the environments quickly and get work done efficiently.

Enjoy!