Modern UI and the Remote Procedure Call Failed

New Windows 8.1 updates have arrived so I had to make quick visit to Windows Update Modern UI application. There I was greeted with The remote procedure call failed. So I tried to open Control Panel - same issue. All Modern UI application suddenly didn’t work. Ok, when I say suddenly, it might have been days - I am not really using Modern UI applications in my daily work. But, since I needed one now, it was a time to do a cleanup.

First order of business was running System File Checker utility:

SFC /scannow
 Beginning system scan.  This process will take some time.
 Beginning verification phase of system scan.
 Verification 100% complete.
 Windows Resource Protection found corrupt files but was unable to fix some
 of them. Details are included in the CBS.Log windir\Logs\CBS\CBS.log. For
 example C:\Windows\Logs\CBS\CBS.log. Note that logging is currently not
 supported in offline servicing scenarios.

As soon as it finished repairs, I could use my Modern UI applications once more, including Control Panel and Windows Update. But some corruption was left. In order to determine what exactly, I extracted parts of CBS log:

FINDSTR /c:"[SR]" %windir%\Logs\CBS\CBS.log >"%userprofile%\Desktop\sfcdetails.txt"

In newly created sfcdetails.txt I found this damning entry:

[SR] Cannot repair member file [l:36{18}]"Amd64\CNBJ2530.DPB" of prncacla.inf, Version = 6.3.9600.16384, pA = PROCESSOR_ARCHITECTURE_AMD64 (9), Culture neutral, VersionScope = 1 nonSxS, PublicKeyToken = {l:8 b:31bf3856ad364e35}, Type = [l:24{12}]"driverUpdate", TypeName neutral, PublicKey neutral in the store, hash mismatch

Well, it was the time to get the big guns out. Here comes [Deployement Image Service and Management](http://technet.microsoft.com/en-us/library/hh825265.aspx) utility (DISM for friends):

C:> DISM /Online /Cleanup-image /Restorehealth

Deployment Image Servicing and Management tool Version: 6.3.9600.17031

Image Version: 6.3.9600.17031

[==========================100.0%==========================] The restore operation completed successfully. The component store corruption was repaired. The operation completed successfully.

After a long time (overnight actually) and few megabytes DISM has updated the system. Short verification proved the same:

C:> SFC /scannow

Beginning system scan. This process will take some time.

Beginning verification phase of system scan. Verification 100% complete.

Windows Resource Protection did not find any integrity violations.

I'll probably never know what exactly caused this, but fix worked as a charm. More cynical side of me cannot help noticing that Windows is becoming more and more like Linux in the extensive use of a command line tools to fix GUI issues. Not sure that is improvement though. ;)

PS: You might as well ignore progress bar for DISM. It only updates every 20%. Idiotic.

End-to-end Encryption

Well, with all these NSA revelations it had to happen. Not only that Google is thinking about easing encryption in GMail but we got a pretty nice early code drop in a form of a Google Chrome extension.

Extension is called End-To-End and it will help you use OpenPGP encryption for your e-mails. Since it is a really early code drop, Google intentionally made it a bit difficult to install. First of all, you’ll need to compile thing yourself.

For that you would need any Linux machine (e.g. Mint 17). Step-by-step instructions are really good and work flawlessly after you install Git and Subversion:

sudo apt-get install git
sudo apt-get install subversion

After going through all steps, the extension is ready for deployment under /end-to-end/javascript/crypto/e2e/extension. To load it into the Chrome, go to Tools, Extensions, Load unpacked extension. I all went good you will see an additional icon next to the address bar.

Click on that icon will allow you access to Options where you can import key if you already have one (RSA or ECDSA). If you don’t have a key, you can provide your e-mail have one created (only ECDSA). From that moment on you can create a new message by clicking that same magical button.

Currently extension is not really polished. Sending mail still requires a few manual steps, e.g. opening mail window yourself, decryption is not automatic, there is no public key lookup… but this is still probably best solution I have seen for a web mail. Best of all, it works with essentially any web mail - not just GMail.

While there is still a lot of work remaining to make this a comfortable solution, first steps are promising. Mail encryption is a bit hard by design but I could see myself explaining all necessary steps to someone with basic computer knowledge and having them send encrypted e-mail within minutes. To me that means that biggest issue is resolved. All other stuff is just an icing on the cake.

P.S. Those who don’t have a Linux machine (or don’t want to deal with compile) can download unpacked extension here. But do notice that this extension is alpha and I probably won’t bother updating these binaries as the source gets updates.

[2014-12-17: Project source is now available on GitHub.]

How Much for the Shipping?

One of the most common ways to interface a computer and custom electronics is still a serial port. Since 9-pin connectors are mostly thing of the past usual choice these days is an USB to serial bridge chip.

While I am usually relying on excellent FTDI’s FT232R, I am always open for a something new. Therefore I was click-happy when I saw Silicon Labs tweet about $5 evaluation kit of their CP2104.

I went forward only to be surprised at the shipping cost for a device that cannot be heavier than a few dekagrams. Cheapest shipping within United States was $26 - a way too much for this device especially when anyone, as a private person, can get a better deal from UPS. How come that company such as Silicon Labs cannot ship it cheaper? Answer is - they can.

Over-inflating shipping cost became popular on ebay as a way to seem really cheap. You decrease item cost and increase the shipping. Total amount you get is still the same but your offer stands out as the cheapest one. With time this way of pricing has spread to Amazon and essentially any site that allows you to set shipping cost.

Somebody from Silicon Labs wanted to be able to say they do cheap kits but without all the hurdle of actually being cheap. I call that lying, they call it marketing. :)

CAN Bus Setup

Note: If you are only interested in bit-rate calculator, skip to the bottom.

As you start designing CAN bus node around Microchip’s PIC microcontroller everything seems deceptively simple on the paper. Like with good old UART you only set for a node frequency and everything is fine and dandy. And then reality hits with various bit times and their “fuzzyness”. At times it might seem that there are a gazillion different ways it can be configured. How to decide?

There are four main parameters that determine all others. Obvious one is microcontroller’s frequency. You are pretty much required to use crystal because CAN bus tolerances and stability needs don’t allow for internal oscillator. My personal preference is using 12 MHz crystal as an oscillator source. 12 MHz allows quite high frequency (48 MHz with PLL) and it is quite commonly used for USB so you can share it (via REFO pin) with other devices on board (e.g., serial to USB converter).

Since all CAN nodes have to share the same baud rate, decision is made for you if the new node has to be integrated in the existing network. If you are designing your bus from scratch there is a whole slew of speeds you can select. I personally like to stick with CiA DS-102 defined speeds (10, 20, 50, 125, 250, 500, 800 and 1000 kbps). Higher baud rate allows for more messages/second but it works only at shorter distances and demands for better frequency stability. Lower baud rates allows for more distributed nodes and you might even get away with R/C oscillator source (at very low speeds). I use 125 kbps (500 meters max) as a starting point and deviate only if I really have to.

Maximum bus length is function of allowed signal delay. Higher the bitrate lower the distance and vice-versa. This parameter is basically our sanity checking mechanism and one of inputs when we calculate propagation segment duration.

Time quanta (TQ for friends) is smallest time unit in CAN bus and it controls duration of a single bit. To represent a single bit, you need between 8 and 25 TQ. Those TQ units are further subdivided into synchronization segment (always 1 TQ), propagation segment (1-8 TQ), phase segment 1 (1-8 TQ) and phase segment 2 (1-8 TQ). Bigger the TQ, more control you have over fine bit tuning but at the cost of higher frequency need (i.e., 16 TQ subdivision will need double the frequency compared to 8 TQ to maintain same bit rate).

Synchronization segment always last for single quanta and CAN bus uses it internally to adjust bit edge. This ensures that various nodes don’t drift in time because of slight frequency differences. This is only segment with fixed duration.

Propagation segment that follows is there to compensate for a physical delay of the signal going over wire and its receival in driver. Rule of the thumb is that its value gets bigger with physical distance.

Phase segment 1 tells us duration (in TQ) before bit is actually sampled from line. Higher value you have, later sampling will occur. Actual sampling happens after sync + propagation + phase 1 quanta. More often than not, you want this time to be as close to the full quanta as possible.

Phase segment 2 is last segment and its duration concludes full bit time. It is very useful to keep this at at least 2 TQ because otherwise your sample point might get too close to edge of next bit.

First programming parameter that PIC will actually use is the baud rate prescaler (BRP). Based on it we determine bit rate according to following formula BRP = FREQUENCY / (2 * TQ * BITRATE). This value than gives you actual TQ time (TQTIME = 2 * (BRP + 1) / FREQUENCY). From that you can get duration of a single bit (TBITTIME = TQ * TQTIME). Since BRP value can only be integer, to get nominal bit rate PIC we use another calculation BITRATE = 1 / TBITTIME. If everything goes alright actual bit rate will match desired bit rate. If such thing does not happen, a bit of input parameter tweaking might be beneficial.

I prefer to calculate phase 1 duration next. General rule is to have it last as long as possible. Half of total bit duration is as good approximation as any. Of course, maximum of 8 TQ.

Propagation segment length gets calculated based on desired physical bus. I use standard 5 ns/m figure for bus delay and I add 250 ns as worst case processing delay in transceiver and use that as a minimum value. If TQ is higher propagation delay must be increased regardless of actual physical distance because of phase 1 and phase 2 having maximum of 8 TQ.

Phase 2 gets calculated from whatever is left after sync, propagation and phase 1 segment get their share.

Synchronization jump width is fuzziest of them all. In theory it would help you if clock drifts between nodes. However, make it too big and PIC starts detecting sync bits where there are none. I usually go with half of propagation length as a starting point and then I adjust it not to be longer than either phase 1 or phase 2. This gives a bit of wiggling space for clocks to drift but it is not overly aggressive.

Below is a small form which actually does these calculations. Might come in handy.

PS: Some additional information that might be useful:

• Microchip AN754: Understanding Microchip’s CAN Module Bit Timing
• Bosch: The Configuration of the CAN Bit Timing

Forcing Rebuild in MPLAB X.

For a project of mine I needed a random serial number. I got it in Intel hex file not by memory address as you would commonly have, but by search & replace of a string. While I prefer this approach in most cases, it also meant that once code has been replaced, next replace would fail. I needed a rebuild.

Unfortunately MPLAB is too smart and it avoids rebuilding if no file has been changed. Of course there is no option to force rebuild either. Only thing left is to actually change a file or at least its time.

Under Linux there is a touch command. Under Windows there is an almighty copy. To update file time we need to simply execute:

COPY /B **source**+,,

To use this in MPLAB X go to project Properties, Building and check Execute this line before build. In text box underneath just apply newly found command on project’s main file (App.c in my case):

COPY /B **${ProjectDir}\App.c**+,,