(Updated) CY8CKit-059 On Linux, Finally! Mac Monterey Issues.

Posted On March 18, 2022

If you have read the previous posts about debugging the PSOC5LP on the Macintosh, you have noticed that I have not approached working with Linux. Having a Mac environment was enough for me. Well, that changed recently. TLDR skip rambling –> go to “Linux OnethinxPack Reinstall, Reading Directions This Time!”

Monterey Upgrade Gotcha’s

I upgraded/downgraded (take your pick) from Big Sur to Monterey. Big Sur has some issues with Time Machine. It can sometimes refuse to allow you to exclude certain folders. Now that Monterey is out, Apple will (usually) not fix issues on Big Sur. It will do security updates for Big Sur, but that will be it. It is the same as Microsoft’s attitude.

You have to understand that corporations are not people. They have no soul. They have no morals. Their only motivating factor is sales, to satisfy share holders. Only laws and strong law enforcement keep them in check, after the founders are no longer directly associated with them. This is not a complaint, only an observation. And sometimes corporations will accept fines in the future, to boost profits today. Just read the headlines. Fargo anyone?

Python Framework Gone!

The Monterey upgrade *removed* Python version 2.7. Not only that, there is no longer a Python framework in /Library/ in a similar location to the previous (Big Sur and previous) versions of OSX. That alone broke a lot of existing developer tools. With Apple’s new SIP policy, you can no longer update anything in the root folder or /Library, /usr, etc. folders, even as root, so putting Python 2.7 back is almost impossible.

This is both good and bad. Good in that bad actors have difficulty putting in malware. Bad in that you can no longer use the tools for development that worked 24 hours ago. You can disable SIP and fight to install those dependencies, but that is a tremendous amount of trouble.

In order to be a Mac developer, you also have to disable spctl, unless you only use the Apple Sandbox tools. I use tools other than Apple’s toolbox, although I have used it in the past. My nightmares are about XCode’s complexity. Don’t get me wrong. I have apps currently in the IOS store. But I have abandoned future Apple development due to their hostility to developers.

It recently took 2 days to compile, link, and execute an application from an existing XCode project due to SIP, spctl, XCode’s (almost) hidden features and code signing. Most of that time was spent googling to fix problems that Apple imposes onto the build. There can be a better way, but I don’t think their DNA allows them to know how to do it.

Trouble in Sock Land

Suddenly, my Macintosh’s VSCode PSOC5LP debugger died. After some emails exchanged with Mr. Nooteboom, (Mr. N). I finally realized that the gdb for ARM I inherited (version 10 of the Arm tools because the version 9 gdb was being deprecated) was linked to a python enabled gdb that died because of no python. Putting it back to a non-python enabled gdb solved that issue. However, before I was able to do that I desperately looked for another way for a couple of days.

Linux To the Rescue, Not!

First, I tried Linux. No Go. ugh. I totally missed Mr. N’s comments about Linux requiring cyelftool to be built for Linux, or using wine with cyelftool.exe. I went back to Creator and suffered through several 5 to 10 minute compile cycles. No doubt about it, I was spoiled.

Linux OnethinxPack Reinstall, Reading Directions This Time!

My older linux (LUbuntu 20) had heartburn, so I brought up a new LUbuntu 21 VM. I chose that version due to the lightweight install. At my day job, I create real time GUI systems that use Linux in that flavor. So, I worked on bringing up PSOC5LP there.

UPDATE: On Lubuntu 22LTS, GDB would not run due to missing libncurses.so.5. Fix this by running “sudo apt-get install libncurses5.” I also installed libncurses5-dev, that may be part of the fix. The error was a “debug” attempt just sat there with no error indication after compile-link, but the normal load and run to main() did not happen.

I went back to the OneThinx install for Linux, and did the download and followed instructions from here:

https://github.com/onethinx/VSCode_OnethinxPack_Linux.

I followed its instructions carefully, downloading the “HelloWorld” that it links to. It has additional instructions that are important. I loaded the project, opened its readme.md and followed the text inside to allow the PSOC USB to work with the OS. I opened the project and got a compile and link. This is great for the PSOC6. However, the PSOC6 cyelftool from Infineon does not support the PSOC5. PSOC4 and 6, but not 5. Go figure.

I downloaded and installed the PSOC5 kit from Mr. N. I made the changes (for debugging using KitProg1) to the launch.json file in VSCode, as described in post https://socmaker.com/?p=1004.

I did a build. It built, but the .elf file creation failed with an unexpected “)”. That error was a “red herring.” I started looking. My eyes were crossed. After going to sleep, the next day I looked at it again.

The real error turned out to be that the cyelftool included in the PSOC5 kit from Mr. N is a Macintosh executable. Duh. He said that. Head slap. Following his instructions, I went to the Infineon site and downloaded the FOSS cyefltool code, and attempted a build.

Failure. Perl build script failed. VSCode load of directory and compile failed. I added ninja. Failed again due to not including zlib. Tried to fix. Still failed. Bumped down to command line and did a link with -lz. Failed with errors of trying a static build with .so libraries. I stopped at that point, too many hours in that path. I had some time limits to obey.

Non-Alcoholic Wine To The Rescue

So, I followed a suggest from Mr. N and installed wine on Lubuntu. (I used “sudo apt install wine-stable” from a terminal.) I then ran “wine cyelftool” from a terminal and had success after a fairly long configuration episode from wine, with no input from me! Great! Less things to learn during a time crunch. The second time wine ran very fast. A cyelftool build worked from the command line.

I then had the self imposed problem of wanting to use the exact project in both Linux and Macintosh simply by opening a shared folder over the network, without tinkering with the contents of the build folder. I checked, and Mac and Linux both can run bash. (Even Monterey, though Apple prefers zsh.)

After searching and experimenting, I renamed the existing (mac version) cyelftool to cyelftool.mac. Then I created a bash executable script called “cyelftool.” The contents of the cyelftool script file are as follows: (Change it to be executable after creation with the command “chmod +x cyelftool“.)

#!/bin/bash
case "$OSTYPE" in
  linux*)   wine ../config/cyelftool.exe "$@" ;;
  darwin*)      ../config/cyelftool.mac "$@" ;;
  win*)     echo "Windows" ;;
  msys*)    echo "MSYS / MinGW / Git Bash" ;;
  cygwin*)  echo "Cygwin" ;;
  bsd*)     echo "BSD" ;;
  solaris*) echo "Solaris" ;;
  *)        echo "unknown: $OSTYPE" ;;
esac

The “wine ../config/cyelftool.exe” and “../config/cyelftoo.mac” format is required. The side effect from using CMakeLists.txt for the PSOC5 build (which launches executables from the VSCode system) tends to cause the current directory to be non-obvious, but predictably nested. (hmmm. Say that 5 times real fast!) In any case, the script works.

Its Alive!

I tested it on Linux. It built, and cyelftool script ran wine on the cyefltool.exe causing the .elf file to be generated. Great! I launched a debug session with KitProg3. It worked! I launched a debug session with KitProg1 (using the modifications from the previous socmaker.com posts). It also worked!

The build on Linux with a local directory is blazing fast. Just a tiny bit slower than using the Mac. (Maybe 5% to 10% slower.) Using wine with the cyelftool only chews up a second or so, in my experience, so the slowdown of using wine is not really noticed.

And the good thing is that you can keep your VM if you like your VM. This new policy will not screw with your current medical, er, development, environment until you are ready. I highly recommend using a VM to host critical development tools, as doing that tends to insulate you from Heavy Handed Corporations (HHC’s) that believe they know better than the owner of the computer.

The penalty for using a VM is usually a 5% to 10% slowdown in builds. I use Dropbox to synchronize between Virtual machines and Host Machines as using shared folders over a network is 50% to 75% slower than local files synchronized with Dropbox. So, for PSOC5, the speedup is 500% or more over a Windows build using Creator. That is so fast that a 10% slowdown using a VM is not noticed.

Finally

I thought I wanted to work with PSOC4’s on Mac/Linux. I have tried several things to get VSCode build and debug of PSOC4, but it has always failed. Using kits available on Github, I have tried several things that are being reported as working. No luck so far, but I can be an idiot, so it may be my fault.

My last experiences have included getting all the way to gdb talking to the PSOC4 chip, but unable to take control of the PSOC. After enough frustration, I abandon the effort.

PSOC4 Is Typically Limited

After doing a project with the PSOC4 (under PSOC Creator), I realized those devices are usually very limited on the inside. Since the PSOC4 family has very limited routing options and very small number of UDB’s, I have abandoned that work for now. PSOC5 is my best option. Most of the work I do has complex requirements. Hopefully Infineon will keep that marvelous device around.

Enjoy!