PulseView.app Crashes On OSX

I was using PulseView with inexpensive logic probes. A few months ago, the latest PulseView downloads stopped working. I moved on to the Kingston probe and software and did not look back.

In order to get PulseView to work, you may have to install MacPorts, (https://www.macports.org), which I have installed. I have also installed HomeBrew. The two can co-exist. Using MacPorts, (and brew) I have previously installed dbus. gettext was also installed, probably using HomeBrew. (Pulseview works without fiddling on my office machine due to previous installs that I have lost track of.)

I was home during the Thanksgiving holiday in 2024, and downloaded the latest PulseView from sigrok. It also failed. I decided to “report” it to Apple using their GUI. On a whim, I looked at the “details” and found out the app was looking for a library in the wrong place.

Here is the sequence of events to get PulseView to work:

Open PulseView. OOPS:

Can’t Open an application

Click Cancel!

To solve this problem, you must first change the rules for OSX. Using spctl, you can allow PulseView.app to run on your system. Open a terminal and type:

spctl --master-disable

That will allow you to run apps from anywhere. Now, go into the preferences and select Security And Privacy (looks like a house). You should see something like the following image. Note that if you have to click on the “General” tab, you will have to close and re-open the Security and Privacy screen to enable using the PulseView.app. If you click on General, you won’t be able to click on the “Open Anyway” button. This is a bug that OSX has had for a long time. Click on the “Open Anyway” button and close the Preferences window:

Security, allow PulseView.app to open

The Security System will make sure you want to open it anyway by double-checking. Click Open, again.

If your application crashes immediately, you can “Report to Apple,” then look at the “details” and find out why. In my case, two libraries were being looked for in the wrong places. (I had to find out which libraries were missing one at a time. The crash happened twice: once for each library.) I used the terminal app to make soft links in the directories so the PulseView app could find the libraries.

On my home Mac, PulseView did not run. To make it run on the home machine, I had to open a terminal and enter the following:

sudo su
password:
cd /usr/local
mkdir opt
cd opt
mkdir dbus
mkdir gettext
cd dbus
ln -s /opt/local/lib
cd ../gettext
ln -s /opt/local/lib

On my home machine I have MacPorts installed. To be safe, I installed dbus using MacPorts after the crash occurred. I also installed gettext. (The libraries being referenced may already exist on the Mac. I don’t know.)

To get PulseView to run, you need libdbus-1.3.dylib, and libintl.8.dylib installed on your machines, and pointed to by aliases or existing inside the /usr/local/opt/dbus/lib and /usr/local/opt/gettext/lib directories.

Once all of that is done properly, you should be able to get PulseView to come up and run, even without a logic probe attached. You need the probe plugged in when it starts for PulseView to properly work the first time. Even so, it is finicky. If you don’t have a probe and click on buttons, PulseView may bail on you.

Once it works, you should be able to scan at 12mhz and collect 10 million samples in under a second:

Pulseview after a run on an LHT00SU1 probe, nothing attached to the probe.

I have not tried running PulseView at a faster rate than 24mhz with the LHT00SU1. At that rate, it can be problematic whether or not you get samples using the fx2 driver. The limiter is the 480mbs rate for the USB 2.0 fx2 chip that these cheap probes use.

Fini

Enjoy. This little problem bugged me for a while, I am glad I got around to getting it to work.

Add a Comment

Your email address will not be published. Required fields are marked *