Friday, June 20, 2014

Unlocking the temperature on a Weller WSL or WSD 81 Solder Station

[Credit for the fix goes to Todd Wild]

Just had a weird problem with my Weller WSL with WMP pencil:

Symptom of initial failure:
The base unit was resetting and making a clicking noise while the iron temperature dropped.

When I looked closer the clicking noise was a screw I had put on the top of the base unit - every time it reset the screw jumped!

After opening the WMP pencil I discovered the strain relief failed and the wires inside the iron were shorting. After fixing that it worked perfectly but the base unit had become locked to 375°C! [Speculation is that the EEPROM in the micro was corrupted by all the hard resets and/or the EM pulses].

Symptom of locked base unit:
Trying to change the temperature failed with the display just flashing when up or down is pushed. Just in case you didn't know nearly all solder stations for production environments can be locked to prevent inexperienced people altering the soldering parameters.

Solution:
Purchase a WCB1 calibrator for $1500 (only joking! read on...)

-or-
Opened WSL / WSD81 base unit - the reset jumper is to the right of the "up button" at the top right

  1. Open the case (spudgers needed, start with prying open the keyholes sideways on either side of the heatsink on the back and then pry the case up from the slots along both sides starting at the back. It should pop off towards the front).
  2. Install a jumper on the empty 0.1" pitch pins to the right of the "Up" button on the top right of the PCB. In the picture they are just visible to the right of the black square which is the up button.
  3. Power on the base unit - watch out for the live 120/240V!
  4. Wait for the display to show FSE.
  5. Remove the jumper while it is powered on.
  6. ...
  7. Profit!
Hope this may be of some use to someone else.

Thursday, June 19, 2014

Making my Lenovo MCE RC-6 IR Receiver immune to interference by my TV backlight - Success

Please see this article for the starting point of this work.

Installing the new Vishay module has completely solved my problem with the TV backlight. It was terribly simple as the part is 100% compatible with the original design.

Excellent!

Thursday, June 12, 2014

Modding a Gigabyte i-RAM (GC-RAMDISK) to run without being plugged into a PCI slot...

Gigabyte i-RAM or GC-RAMDISK, PCI version

The Gigabyte i-RAM (or GC-RAMDISK) is a curious device. I have always been uncertain if it was a commercial success or not however the main specifications are here:
  • PCI 3.3V and 5V slot for power (bottom edge connector)
  • SATA 150 hard disk connection (red connector, top right)
  • Maximum capacity of 4 gigabytes (yes 4)
  • One benchmark has it at 25,576 RW IOPS for 512k (YES 25k IOPS)
  • Doesn't wear out or degrade with time or capacity like an SSD
  • Backup battery (on the right) keeps the data on the drive live for about 16 hours.
The only point of real interest is the IOPS. You can get the whole thing setup from eBay for <$200 while to achieve better IOPS from a SSD requires something like the OCZ Vector at $450. Note that for all normal uses the OCZ Vector is a much better solution!

ZFS ZIL

I am a big user of ZFS on Linux for many reasons (note unless they have released 0.6.3 use git HEAD as so many important fixes have been bundled in since 0.6.2).
ZFS is an excellent file system (you can read about it here) but mainly I value it for the data integrity first and the ease of configuration second.
ZFS is designed to take advantage of hierarchical storage to deliver increased performance, i.e. you can feed it hard disks for bulk storage, SSDs and things like this RAMDISK as caches/log volumes and it will present a single, high integrity, higher performance, volume to the operating system.
The log I care about particularly (as do most ZFS users) is the ZIL or ZFS Intent Log. For full details read the blog but basically every so often a filesystem must commit data to persistent storage before carrying on for data integrity/safety's sake. Having a low latency, separate log allows the filesystem to massively accelerate its performance by moving those critical writes off the slow bulk storage onto a dedicated device until they can be committed to bulk storage in an scheduled, ordered, sane manner. This also frees the bulk storage to service the other outstanding requests for data.
SSDs work well as ZIL devices however the device is constantly hit with small writes which will wear the disk reasonably quickly and degrades the IOPS as the different areas of the flash array are written to and the management IC works harder.
The Gigabyte i-RAM (GC-RAMDISK) doesn't wear, nor does it suffer from degraded IOPS over time. It also still has a very high IOPS value for such an old piece of hardware.

Modifying it to run outside a PCI socket

While the i-RAM looks like it is a PCI card it merely uses the socket for power, nothing else. A bit of reverse engineering reveals the i-RAM uses the following:
  1. 12V seems to be related to the battery backup subsystem
  2. 5V used to power the DDR termination supplies and charge the battery, certainly high current
  3. 3.3V used to power the main electronics on the board
  4. 3.3Vaux [always on] used to trickle charge the battery and keep the RAM contents alive when the computer is powered down
  5. RST# used to switch the card from standby to on when the PC powers up and off again on power down
So if we look inside the PC (not using the motherboard or a PCI slot) then the ATX connector has nearly all the signals we need:
  1. 12V
  2. 5V
  3. 3.3V
  4. 5Vsb [always on] 
  5. PS_OK indicates the power supply if fully turned on and voltages stable
So the connections are (i-RAM - ATX):
  1. 12V - 12V
  2. 5V - 5V
  3. 3.3V - 3.3V
  4. 3.3Vaux - Power Regulator - 5Vsb
  5. RST# - PS_OK
The only supply missing is the 3.3Vaux however there is the 5Vsb available. With a suitable linear LDO and heatsink it was possible to build a regulator. The i-RAM is quite naughty and draws far too much current from the 3.3Vaux in the PCI bus - I have measured it at over 1.3A! To cope with this I chose the Texas Instruments LM1084 LDO linear 3A regulator.

Here are the photos of the final product:
 
Rebuilt i-RAM attached to standoffs inside the case lid
Component side (B) of the modified i-RAM showing heavy flywires and Molex sockets
Side A of the modified i-RAM showing heavy flywire connections
Inline ATX 5VSB to 3.3Vaux linear regulator (in fact the regulator on this board is incorrect and was replaced with the LM1084)






Screw terminal block splicing the necessary ATX voltages for the i-RAM

Wednesday, May 28, 2014

Making ModelSim ALTERA STARTER EDITION vsim 10.1d work on Ubuntu 14.04

[WARNING: Some people are reporting that following the steps for them does not fix the problem. I am working on trying to find out what the issue is.]

Trying to get a version of ModelSim running on a very modern version of Linux often presents challenges. Luckily I had lots of helpful information on the internet (major sources linked below) to get it going. This article mostly adapts the work done by the Arch Linux crew.

Problem number one: The free version of ModelSim Altera Edition is 32 bit only while the normal Linux PC will be 64 bit.

On Linux this requires us to install the 32 bit versions of the libraries that it depends on. Luckily this is fully supported on a modern Linux like Ubuntu 14.

sudo dpkg --add-architecture i386
sudo apt-get update
sudo apt-get install build-essential
sudo apt-get install gcc-multilib g++-multilib \
lib32z1 lib32stdc++6 lib32gcc1 \
expat:i386 fontconfig:i386 libfreetype6:i386 libexpat1:i386 libc6:i386 libgtk-3-0:i386 \
libcanberra0:i386 libpng12-0:i386 libice6:i386 libsm6:i386 libncurses5:i386 zlib1g:i386 \
libx11-6:i386 libxau6:i386 libxdmcp6:i386 libxext6:i386 libxft2:i386 libxrender1:i386 \
libxt6:i386 libxtst6:i386

Problem number two: If you have the following error when running vsim:

** Fatal: Read failure in vlm process (0,0)
Segmentation fault (core dumped)
 
Then you probably need to build a new version of freetype, a font setting library and modify ModelSim to use it. For an unknown reason ModelSim has an issue with modern versions shipping in Arch and Ubuntu 14.04. First download the source code of freetype 2.4.12:

http://download.savannah.gnu.org/releases/freetype/freetype-2.4.12.tar.bz2

Now install the build dependencies needed for libfreetype6, extract the source (using tar) and configure and build libfreetype:
sudo apt-get build-dep -a i386 libfreetype6
tar -xjvf freetype-2.4.12.tar.bz2
cd freetype-2.4.12
./configure --build=i686-pc-linux-gnu "CFLAGS=-m32" "CXXFLAGS=-m32" "LDFLAGS=-m32"
make -j8
The finished libraries are now available inside the "objs/.libs" directory. As they are necessary to run ModelSim we need to copy them into the install directory so they don't get lost and then modify ModelSim's vsim script to use the new libraries instead of the system wide versions. Change directory to the directory where you installed ModelSim, /opt/altera/13.1/modelsim_ase/, on my system. Note you may need to edit the directory paths to match those used on your system.
sudo mkdir lib32
sudo cp ~/Downloads/freetype-2.4.12/objs/.libs/libfreetype.so* ./lib32
Now we need to edit the vsim launch script to ensure the new freetype libraries are used:
sudo vim bin/vsim
Search for the following line:
dir=`dirname $arg0`
and underneath add the following new line:
export LD_LIBRARY_PATH=${dir}/lib32
 
Test by running vsim and hopefully you will be greeted by the ModelSim GUI.

[Tested on fresh install of Ubuntu 14.04]

Sources:
  1. https://wiki.archlinux.org/index.php/Altera_Design_Software
  2. http://stackoverflow.com/questions/3261909/build-32bit-on-64-bit-linux-using-a-configure-script 
  3. https://wiki.debian.org/Multiarch/CrossDependencies

Saturday, May 10, 2014

Making my Lenovo MCE RC-6 IR Receiver immune to interference by my TV backlight

Sadly due the newer technologies employed in CFL bulbs (which incidentally is the technology behind my TV) emit a lot of IR interference on the frequency ranges used by the older IR controls. Vishay publishes a summary which goes into more technical detail here: http://www.vishay.com/docs/80072/disturan.pdf.

My MCE receiver is an RC-6 system by SMK RXX6000-40 branded Lenovo, if you want to buy one of your own then please checkout eBay.


HP Remote with USB Receiver RC-6 [Taken from eBay auction linked here]

However despite being aesthetically excellent the receiver suffers from interference from the TV backlight which makes it unusable if the room light isn't bright, wholly unsuitable for certain movies.

This is a pretty common problem for the older IR systems however newer IR receiver modules have been enhanced with better filtering systems.

 Opening the receiver is easy, a single screw hidden in the center of the label and the top and bottom come apart to reveal a single PCB.


The IR module is the black module standing up on the lefthand edge of the PCB (the "front" of the PCB is the south west side). Careful scrutiny of the top of the module reveals it is a Vishay Siliconix TSOP34838, a 38kHz filtered IR module.
Consulting the datasheet from Vishay, http://www.vishay.com/docs/82489/tsop322.pdf, we can see that there is another, pin compatible module, with an enhanced filtering system (Vishay's Active Gain Control 4 or AGC4) to exclude the interference the TSOP34438 is vulnerable to.

I have the new module on order and when it arrives I'll post the results.




My current home media center build: Mythmaster

Apologies - working for two long under various agreements that mean I can't discuss my work means I haven't posted anything in too long.

Hardware

Bought from eBay from Tamsolutions (there may be more available as they seem to have shipments regularly as of May 10th 2014). The computer is quite noisy so it is based down in the basement and connected to the TV by an HDMI extender and a USB extension cable.

Case: AIC RSC-4ED2 with 6x SATA-II 3.0 Gbps four position backplane (TW-000-51675-AR).

Motherboard: SuperMicro H8DME-2 nVidia MCP 55 Pro.
 - Modified one of the PCIe 8x sockets to accept a x16 GFX card by opening the end of the socket.

GFX Card: GeForce GT 240. [Chosen as it can do the most complete deinterlace on 1080i video]
 - Modified with a flywire to connect the PRSNT#1 pin (1A) to PRSNT#2 (48B) so the motherboard detects the card in the modified PCIe 8x socket.

CPU: Two Quad Core Opteron 2389s. [An eBay purchase to replace the single Dual Core 2212 HE. Don't forget the extra CPU cooler]

Memory: 24 Gigabytes of PC-5300P. [Increased by another eBay purchase]

3x SATA Controller Cards: AOC-SAT2-MV8

Drives:
2x HP ST3250824AS 250GB SATA HDDs in Linux Software RAID 1. Note please don't waste time trying to enable SATA-II or NCQ on the HP versions of this disk. They are SATA-I and don't advertise NCQ.

6x 2TB Seagate or Western Digital HDDs managed by ZFS.

TV: 47" VIZIO E470VA

HDMI Extender: No real name HDMI over dual CAT5e or CAT6 cables from Amazon.

USB Long Cable: An active USB 2.0 cable from Amazon.

ATSC Receiver: HDHR4-2US Silicondust HDHomeRun Dual Tuner.

Remote control: Lenovo RC-6 receiver by SMK RXX6000-40.

Software

OS: Linux Ubuntu 14.04 LTS.
 - nVidia drivers from Ubuntu 319.
 - Pulseaudio removed to enable sound in XBMC standalone
 - User autologin running XBMC standalone.
 - Modified the udev rules to enable the IR remote (MCE USB by SMK) device ids, read this thread for details.

Disk Management: ZFS on Linux, GIT head (as the current 0.6.2 release is old and the new version is about to be released. To work on Kernel 3.14 the latest GIT version is necessary).

Frontend: XBMC 13.0 Gotham.

Backend: Mythtv 0.27 managing the Silicondust HD HomeRun and scheduling recordings.

Monday, August 8, 2011

Mapping the Absolute Addresses of Registers from a C Header

Why am I doing this, you may ask? Doesn't the microcontroller manufacturer provide the absolute addresses of the registers? Well in this case, no they don't, and I need them to complete the plugin for the Keil µVision debugger which will make them visible and editable via human readable names.

There are a number of ways of mapping hardware into C but due to the limitations of the const keyword [did you know you can cast the const away? add it to the list of things in C like = actually being assign, declare a pointer with * and then deference it's content with *, etc., etc.] most microcontroller manufacturers end up using #define statements as they can be made to result in fixed numeric constants that can then be optimized correctly in all situations.

[For a quick counter example create a function that accesses a global const pointer, call it and then look at the ASM. Does that look optimal to you? But don't blame the compiler - it can't assume you haven't messed with the const pointer with casts! A good discussion is here.]

Anyway the normal way is to begin with several layers of #defines. The reason is for maintainability and portability. Typically the registers for a microcontroller peripheral are created at a fixed offset from a base and typically they will want to use the same peripheral in several micros. So this is how they arrange things for the USB module in the Fujitsu MB9BF506R, an ARM Cortex M3 based microcontroller:

#define FM3_PERIPH_BASE    (0x40000000UL)

...

#define FM3_USB0_BASE      (FM3_PERIPH_BASE + 0x42100UL)

So the USB peripheral is actually to be found starting at address 0x40042100UL. However the actual device registers are laid out by a C struct. The struct creates the offsets for the individual registers internally and maps them to the human readable names.

Structs have several rules imposed on them by the C standard and also have a few gotchas so please treat these header files with great care when used with a different compiler UNTIL you have verified it. The rules are:
  1. The named elements of a struct will be in the same order as declared in C .
  2. Suitable padding may be included between elements to speed access to the data.
For more information refer to this article: http://www.eventhelix.com/RealtimeMantra/ByteAlignmentAndOrdering.htm.
    [If you don't want suitable padding to be added then consider using the pack attribute, e.g. in gcc #pragma pack. This can have terrible performance consequences so as always, know what you are trying to achieve.]

    Here is a fragment of C from the mb9bf506r.h header file which creates the C symbols for the appropriate registers:

    typedef struct
    {
      union {
        union {
          __IO uint16_t HCNT;
          stc_usb_hcnt_field_t HCNT_f;
        };
        struct {
          union {
            __IO  uint8_t HCNT0;
            stc_usb_hcnt0_field_t HCNT0_f;
          };
          union {
            __IO  uint8_t HCNT1;
            stc_usb_hcnt1_field_t HCNT1_f;
          };
        };
      };
    ...
    

    So following the rules of struct's in C we have the first element being an unsigned, 16 bit long register called HCNT at the first address of this struct, 0x40042100UL. Note the use of unions to allow the same address in memory to be accessed several different ways. In this case it is enabling HCNT to be accessed as a 16 bit wide register and as two separate 8 bit ones called HCNT0 and HCNT1.

    Lets look at the same piece but with the next register's definition included:

    ...
      union {
        union {
          __IO uint16_t HCNT;
          stc_usb_hcnt_field_t HCNT_f;
        };
        struct {
          union {
            __IO  uint8_t HCNT0;
            stc_usb_hcnt0_field_t HCNT0_f;
          };
          union {
            __IO  uint8_t HCNT1;
            stc_usb_hcnt1_field_t HCNT1_f;
          };
        };
      };
            uint8_t RESERVED0[2];
      union {
        __IO  uint8_t HIRQ;
        stc_usb_hirq_field_t HIRQ_f;
      };
      union {
        __IO  uint8_t HERR;
        stc_usb_herr_field_t HERR_f;
      };
            uint8_t RESERVED1[2];
    ...
    

    The line of real interest is uint8_t RESERVED0[2]; between the two 16 bit registers. ARM devices' memory map is byte addressing, i.e. each byte attracts a unique address number. So the 16 bit variable is sitting across two 8 bit numbers (which the union allows individual access to). However the main memory of an ARM system is typically organized on 32 bit words, i.e. two 16 bit words and four 8 bit words. The uint8_t RESERVED0[2]; array of two 8 bit words 'pushes' the next register (the 8 bit HIRQ) to the start of the next 32 bit word. This means that the HCNT is at 0x40042100UL while the HIRQ is at 0x40042104UL, 4 bytes offset from the USB peripheral base.

    Laird Tpcm 7250 is as good as Honeywell PTM7950 as thermal paste / interface for PC

    [This is not very scientific, however it is notable. At 7.5W/m-K vs the installed SYY-157 at 15.7 W/m-K it performed better in real world lo...