Intermission: PSOC5LP Compile/Debug On Mac (Updated)
Posted On December 16, 2021
I found out about OneThinx a few months ago, but never had the round-tuit. I acquired a tuit the other day, about the same time I came across Rolf Nooteboom’s post on the Cypress (Infineon) community page where he indicated he had done a Visual Studio project for PSOC5 LP.
With their work, released under the Apache license, you can compile and debug projects on the Macintosh natively, AFTER FIRST BUILDING THE HARDWARE ON PSOC CREATOR. This saves a lot of time, but you will run into pain.
If you decide to follow this work, follow the instructions religiously. They are extremely close to what you want. They are not exactly incorrect, just not really finished. I only did the Mac instructions. I am running High Sierra (10.13), because everything is stable and my iMac hardware is too aged to quickly run newer OS versions. If I need a newer version of Mac to test with, I use VMWare or VirtualBox 6.3.
UPDATE: I was trying to use Kicad and after they changed the code’s OS requirements 3 times in one release, I researched upgrading. I finally upgraded to a reconditioned iMac from Apple, and migrated up to Monterey, briefly stopping at Big Sur. That was a nightmare. Apple no longer allows developers to control their machines unless those developers are extremely persistent. (Hi!)
One suggestion: DO NOT ENABLE APPLE’S T2 chips unless you really understand the consequences. Buy an Older Macintosh if at all possible to avoid this problem. (The downside is a thief will be able to use your computer. The upside you will always be able to use your computer, even if a child changes your password on you. If you get locked out accidentally with a T2 chip, good luck. Expensive repair bill incoming. There are some inexpensive work arounds, but you have to apply those work arounds each and every reboot, which bothers thieves not one little bit. So, Apple’s security fixes provide very little security in the end.)
The TLDR; of this is that making things work on Monterey sucks. Also, many of your favorite programs are now toast. They will not run unless you know some magic. And that magic varies with the age of the program.
(Hint: an easy workaround is called VMWare, but there is no graphic acceleration with it, so some things naturally suck.) You will have to upgrade to VMWare Player (which is now free for individuals and is almost just like VMware Pro). I guess VirtualBox is giving them a run for the money.
Back To The Regularly Scheduled Program
The OneThinx system did not workon my Mac with a CY8CKit-059! However, it was *very* close, so I started diving in. I was starting to understand what was going on. (That is how it works for me. The light slowly dawns over a few crucial brain cells.) Note: This information may also (generally) apply to Windows and Linux.
Setup Of VS.
The Visual Studio program from Microsoft is convoluted and confusing, but not as confusing as Eclipse (Modus Toolbox). However, I finally understood enough about it to get extensions installed. (Hint: Use the View Menu, select Extensions, and use the search bar. You may have to disable the clangd extension to use Visual Studio on the Mac, as Microsoft intellisense and clangd extensions fight each other and complain all the time.)
Follow all of the setup information for the Visual Studio parameters to work with the Creator generated part. If I can stumble through it (in about 5 hours), you can too!
Information Left Out (Sort of)
(1) Visual Studio requires you open a “folder” to open a project. So, you will open the folder for the downloaded project (PSOC5_VS_Creator-main) by going into that folder and selecting open.
(2) The magic for debugging is in the hidden folder .vscode in the project folder.
(3) KitProg3.cfg selected in the launch.json file (in .vscode) simply does not work with the CY8CKit-059’s KitProg debugger. Keep reading for how to use the stub debugger.
(4) They did something different to the PSoCCreator project and structure. The workspace and project files don’t live where they do normally in a PSOC project. I have not determined how to make (all of) their changes to an existing project. So, take their project and modify it, but be careful. Their project also uses a “Post Build” command (under Creator Project Menu->Build Settings->ARM GCC-> User Commands) to move the component library into the right location for linking.
(5) The magic for compiling is in the CMakeLists.txt. The “source” directory and its name is a requirement for this system. You *must* *not* have the automatically produced working C files in the .cysdn directory. Creator is ONLY used for the hardware generation.
(6) You *can* add into your Creator project the files in the source directory. That allows you to bail out to PSOC Creator, rebuild and debug when you need to set breakpoints on variable write, or enable flash protection, etc. So, you are not sacrificing much to allow yourself to natively compile and debug on the Mac (or Linux).
(7) I use VmWare (or VirtualBox, which is free, but less feature rich) to run PSOC Creator on my Mac. It works well, with hiccups. You can read about those hiccups in earlier articles on this blog.
(8) There are hard coded directory names in the files in the .vscode and config directories, etc. If you move things around, you have to change these fixed directory names.
Additional Things To Do to Actually Use
Once the project folder is opened, you have to click on the Square Boxes at the Bottom of the Visual Studio to initially configure your project. (They are a stupid version of buttons, in my enlightened opinion. The whole purpose of a GUI is to provide intuitive access to features to the uninformed. This revolutionary concept, started by Apple, has been abandoned, even by Apple. Don’t worry, I am holding back.)
Button clicks and changes for your project:
(1) Debug — click, then on the dropdown that shows at the top of the screen, select DEBUG CMSIS-DAP.
(2) CMake — click, then on the dropdown that shows at the top of the screen, select DEBUG Variant.
(3) Select A Kit — click, …. select GCC 9.3.1 arm…. (If this option is not showing on the Mac, log out and log back in. Yes, I know all your programs will close. It is a pain.)
(4) Click Clean and Reconfigure. (You have to. ugh. CMake requirement. You have to do this every time you go back and change something in PSOC Creator, also.)
(5) Finally, click Build. NOTE: You may have to delete the build directory on Monterey. Permissions (?) prevented it from creating a file in the “build” directory.
Note 2: You will have done something wrong and it won’t work the first time, so just bang on it until you get it right!
KitProg Usage “Fix”
The KitProg will not work in its default mode. TLDR; Press and hold reset until green light blinks (breathes) slowly.
(In a future post I tell you about upgrading KitProg2 to work.) But will work as a CMSIS-DAP device, once you have changed a few things. Note that KitProg is the breakaway stub debugger attached to the CY8CKit-059 main board.
When I ran the kitprog with the kitprog3 configuration file, it kept giving me a kitprog3 get_version error, and the debugging session stopped cold. I fumbled around with it and tried several things. Nothing resolved that issue. It cost quite a bit of time.
I surfed some forums and came away with the idea of using the CMSIS-DAP mode. (You can also use that mode with Creator 4.4. When using the CMSIS-DAP mode in Mac or Linux, the serial usb ports on the kitprog don’t seem to be available. )
To get into the CMSIS-DAP mode, you have to press the Reset button on the Debugger stub and hold it for about 5 seconds (I count to 10 slowly) until the green LED blinks (breathes) slowly. If the green LED is solid, it is in proprietary KitProg mode; if it blinks slowly it is in CMSIS-DAP mode. This is a semi-permanent change that stays between power on events, press it for 5 seconds again to go back to KitProg mode.
However, even switching into CMSIS-DAP mode does not work yet. You have to modify the launch.json file, in the .vscode directory. Fortunately VS will give you a drop down dialog that offers to open the launch.json file for you when the debugger fails to launch properly. Open that file using the drop down dialog.
In the launch.json file, change the top (CMSIS-DAP selection) command parameters section to the following information:
(1) comment out “kitprog3 power_config …” line (use // in front of the line)
(2) Comment out the “interface/kitprog3.cfg” line
(3) add “interface/cmsis-dap.cfg,” line. Note that a “../cmsis-dap.cfg” line also worked for me, as there is a copy of that file in the directory above the interface directory. Note: the “,” is needed at the end of the line.
So, the modified part of the launch.json file will look something like this:
"adapter speed 500",
//"cmsis_dap_serial 141610F301237400",// Select debugger if you have multiple connected
//"kitprog3 power_config on 3300"
//"interface/kitprog3.cfg", <--this fails with "kitprog3: get_env" error
Finally, It Works!
If you are fortunate, you can click on the “Run And Debug” icon in the left menu bar. (The hollow white divot with a tesseract cube (or a “bug”) fourth from the top.) In the new panel that opens up, click on the square start button area (the hollow green divot, not worthy of being called an arrow,) at the top of the panel in Visual Studio (make sure CMSIS is chosen) and start debugging your project. If not, keep fighting it. It will be worth it.
Here is a screen shot of my project being debugged:
Note 1: I programmed a TQFP package project into a QFN package. It mostly worked. Be careful about that.
Note 2: I also had a failure in moving one of my projects over (Using Copy and Paste) An EEPROM Linker error. I had to add the following line from the main.c of the example project on the github site, as shown following. The EEPROM still works, so this is just to fix the linker error: (This is in the notes from OneThinx, which I ignored at the beginning)
static volatile uint8_t dummy __attribute__ ((section(".cyeeprom"),unused)); // Fix for linker error.cyeeprom data will not fit in EEPROM
Note 3: I was unable to program the psoc I was working on. It had been previously programmed with Flash Protection. In theory, you can erase a protected flash and reprogram it. With OpenOCD, you cannot. I had to go back to Creator and program it with an Unprotected Flash example to fix this problem. Once done, the chip programs and debugs just fine. BE SURE TO not USE ECC in PSOC Creator.
Note 4: Popups for variables and watch of values is nice, but defaults to decimal. Many times you want hexadecimal. Click on the Debugger console and type “set output-radix 16” and press enter. That switches the values to hex.
Build is very, very fast. Debug is very fast, even at the 500khz selection for the cmsis-dap. (I was able to change it to 1500khz successfully, but your mileage may vary). VS Code is still being modified. Some things work well, some don’t.
There are limitations to this environment. I don’t know what other problems will show their head, but for the most part, the repetitive work can be done natively in Mac or Linux. Final work can be done in a psoc creator project for things like Flash protection and any issues not covered with the cmsis-dap debug experience. I consider this a win.
It is sad to see intuitive user interfaces being abandoned by the corporations with money. Someday I will stop holding back and tell you how I really feel. <grin>