Link Instruments MSO-19

File:MSO-19.JPG

Link Instruments MSO-19

File:MSO-19-naked.jpg

PCB Front

The Link Instruments MSO-19 is a 2GSa/s oscilloscope, 200MSa/s logic analyzer, 100MSa/s pattern generator and a TDR. It is also extremely portable and is only $249 (including probe, clips, wires and software).

See Link Instruments MSO-19/Info for more details (such as lsusb -vvv output) about the device.

Hardware

• Lattice MachXO LCMXO2280 PLD
• Kenet KAD2710C-10 10bit, 105MSPS ADC
• Silabs CP2103 USB to UART Bridge

Original software

Link Instruments ships the product with its FrontPanelTM Oscilloscope software. Software is for Windows only. Written in .NET (C#), without any kind of obfuscation, which makes it a real breeze to reverse engineer.

USB protocol

It's just serial-over-USB, supported by the Linux kernel through the cp210x driver, though as of Kernel 2.6.37 it needs to be patched to recognize the Link Instruments Vendor/Product ID (3195:f190).

iSerial was exploited by Link Instruments to store hardware type, hardware revision, calibration quirks and the actual serial number.

• for an iSerial of 4294333650260000000 we have:
  • 42943 336 502 6 0 000000
    • vbit = 42943 / 10000
    • dacoffset = 336
    • offsetrange = 502
    • hwmodel = 6
    • hwrev = 0
    • serial number = 000000

Serial protocol

• Control message
  • Fixed header: 0x40, 0x4c, 0x44, 0x53, 0x7e
  • Variable size payload, 16bit aligned
    • Looks like each 16bits of payload are a register write operation
    • register writes are 4bits for addr, 8 bits for value, 2 unused bits and 2 bits im not sure what they are for :)
      • The simplest explanation for the unused bits is that the device bus width is 7 bits (being a CPLD that is very acceptable).
      • The 2 special bits seem to be synchronization bits. 0x7e violates the conversion (high byte), and that may be used to reset the CPLD parser at the end of the packet.
    • .?12 AAAA .?34 5678
    • Conversion is: ((v & 0x3f) | ((v & 0xc0) << 6) | ((a & 0xf) << 8) | (((v ^ 0x20) & 0x20) << 1) | (((v ^ 0x80) & 0x80) << 7))
    • Byte order is big endian
  • Fixed footer: 0x7e

Registers description

There is no way to read from registers, only write is possible.

The purpose of registers 0 to 8 seems to depend on the value of register 15.

Registers for R15 == 0

• Read Sample buffer (1): Write 0 to this register to read the samples buffer.
• Read Trigger status (2): Write 0 to this register to read the trigger status.
• TRIGGER_CONFIG_L (3):
  • lsbyte of the threshold value.
• TRIGGER_CONFIG_H (4):
  • bits [1:0] hold the msbits of the threshold value
  • (1 << 2): Trigger on falling edge
  • bits [6:5] hold the trigger configuration:
    • 00 : DSO level trigger
    • 01 : DSO pulse trigger, width less than TRIGGER_WIDTH
    • 10 : DSO pulse trigger, width equal or greater than TRIGGER_WIDTH
    • 11 : LA combination trigger
• LA_TRIGGER(5):
• LA_TRIGGER_MASK(6):
• SCOPE_TRIGGER_THRESHOLD(7-8):
• CLKRATE(9-10):
• TRIGGER_WIDTH (11): Stores the pulse width for the DSO pulse trigger, in sample units. Forced to be greater than 3 by the mso19 app.
• DAC(12-13):

Registers for R15 == 1

This mode seems to be used to configure the pattern generator.

• UNKNOWN (0):
• UNKNOWN (1):
• UNKNOWN (2):
• UNKNOWN (3):
• UNKNOWN (4):
• UNKNOWN (5):
• UNKNOWN (6):
• UNKNOWN (7):
• PATGEN_CFG (8): Configures the pattern generator.
  • (1 << 1): Enter pattern write mode.
  • (1 << 3 | 1 << 2):
    • 11 : Manual start (pulse in register 9 (PATGEN_TRIG?)
    • 10 : Start on MSO trigger
    • 01 : Start on MSO "Go" (MSO trigger arm)
    • 00 : Disabled
• PATGEN_TRIG? (9): writen 0x1 and then 0x0 in several ocasions, seems to act as a trigger.
• PATGEN_WORD (10): In pattern write mode, it takes the word for the current sample. Not sure for other modes...
• TRIGGER_WIDTH (11): ?
• PATGEN_LOOPS (12): Stores the number of loops for the pattern generator
• PATTERN_MASK (13): Stores the output bit mask (1 for enabled bits, 0 for disabled bits)

Registers for R15 == 2

This mode is used to set the i2c or spi triggers. NOTE: the difference between i2c and spi capture seems to be the TRIGGER_CFG_H bits (see R15 = 0)

• TRIG_WORD0 (0): Holds the first word to be matched.
  • If matching less than 4 words, this register is set to 0 (match bus idle) and the mask is set to 0xff. See below.
• TRIG_WORD1 (1): Holds the second word to be matched. Same as above.
• TRIG_WORD2 (2): Holds the third word to be matched. Same as above.
• TRIG_WORD2 (3): Holds the fourth word to be matched. Same as above.
• TRIG_MASK0 (4): Holds the mask for the first word.
  • If matching less than 4 words, this register is set to 0xff. This forces a match on a "bus idle" state.
  • Could forcing the match to bus idle cause trouble whith packets too close together??
• TRIG_MASK1 (5): Holds the mask for the 2nd word.
• TRIG_MASK2 (6): Holds the mask for the 3d word.
• TRIG_MASK3 (7): Holds the mask for the 4th word.
• TRIG_SPI_MODE (8): Holds the SPI mode for triggering (valid modes 0, 1, 2, 3). Is set to 0 for I2C (not sure if mandatory)

• CLKRATE(9-10): (not used?)
• TRIGGER_WIDTH(11): (not used?)
• DAC(12-13): (not used?)

Registers which don't seem to change purpose (so far)

• CONTROL (14):
  • (1 << 0): Reset SFM
  • (1 << 4): Reset ADC (?)
  • (1 << 6): Reset ADC (?)
  • (1 << 7): Led on/off
• SLOWMODE(15): This should be renamed BANK perhaps!