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): The value of the LA byte that generates a trigger event (in that mode).
• LA_TRIGGER_MASK(6): The mask for the LA_TRIGGER (bits set to 1 matter, those set to 0 are ignored).
• SCOPE_TRIGGER_HOLDOFF1 (7):
• SCOPE_TRIGGER_HOLDOFF2 (8): Store the trigger holdoff (delay between a triggering event and the trigger rearming).
• 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.

• REG_PATGEN_CLOCK1 (2) :
• REG_PATGEN_CLOCK2 (3) : Stores the sample clock configuration. Not sure how these two bytes work together...
• REG_PATGEN_START_L (4):
• REG_PATGEN_START_H (5): The start address for the pattern generator buffer (1023 samples long). When writing to the buffer, it is set to 0.
• REG_PATGEN_END_L (6):
• REG_PATGEN_END_H (7): The end address for the pattern generator buffer (1023 samples long). When writing the buffer, it is set to 0x3ff. When in normal mode (to set the end of the output) it is writen as the end address minus 2 (probably due to the actual implementation details).
• PATGEN_CFG (8): Configures the pattern generator.
  • (1 << 1): Enter pattern write mode.
  • (1 << 3 | 1 << 2):
    • 11 : Manual start (starts after a pulse in 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, acts as a manual trigger to activate "stuff".
• PATGEN_WORD (10): In pattern write mode, takes the word for the current "instant".
• PATGEN_IO (11): In pattern write mode, writing 0x1 makes the instant an output one, and writing 0x0 makes it an input one (?)
• PATGEN_LOOPS (12): Stores the number of loops for the pattern generator. Set to 1 for pattern buffer writing mode.
• 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. NOTES:

• the difference between i2c and spi capture seems to be the TRIGGER_CFG_H bits (see R15 = 0)
• how does the hardware handle the start/stop conditions or the ack bit??

The protocol matcher seems to be comprised of a 4 byte shift register. The serial bits are shifted in through the last byte comparator (word 3) and exit through the first byte comparator (word 0). This is why if the trigger is set up with less than 3 words, the first bytes are the ones that end up empty (word set to 0x00, mask set to 0xff)

• 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.
• 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)

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!