Proghq - User contributions [en]

BPM WWAVUSBEPP LA

2023-05-01T00:45:07Z

RH: Undo revision 940 by RH (talk)

Logic analyzer test

17 signal pins, 16 LA channels. Arbitrarily drop pin 8 in favor of hooking everything up linearly.

= 2015-09-27 =

Project goal: understand how voltages/currents are read out

== Phase 1: LA ==

Ran into some signal integrity issues setting up capture. Had to do short wires. More info:

''' Final setup
'''* [[https:''twitter.com/johndmcmaster/status/648329962819182592|https:''twitter.com/johndmcmaster/status/648329962819182592]]
'''* [[https:''twitter.com/johndmcmaster/status/648348769746948097|https:''twitter.com/johndmcmaster/status/648348769746948097]]
''' Flaky: flying leads
'''* [[https:''twitter.com/johndmcmaster/status/648315944121425920|https:''twitter.com/johndmcmaster/status/648315944121425920]]
''' Complete failure: ribbon cable
'''* [[https:''twitter.com/johndmcmaster/status/645354861383385088|https:''twitter.com/johndmcmaster/status/645354861383385088]]

Setup to trigger on J2.1. Triggered during startup sequence reading serial number etc

Discovered Saleae only support 8/16 channels with USB 2. Ordered USB3 expresscard adapter.

SN:

[[File:mcmaster_bpm_wwavusbepp_screenshot_from_2015-09-27_21_43_18.png|frameless]]

Above: 1-8 at startup

[[File:mcmaster_bpm_wwavusbepp_screenshot_from_2015-09-27_21_52_05.png|frameless]]

Above: after hitting don't register. 02_post_sn.lda

[[File:mcmaster_bpm_wwavusbepp_screenshot_from_2015-09-27_21_55_51.png|frameless]]

Above: after hitting okay that's in unsupported mode

[[File:mcmaster_bpm_wwavusbepp_screenshot_from_2015-09-27_22_01_07.png|frameless]]

Above: software started but idle

[[File:mcmaster_bpm_wwavusbepp_screenshot_from_2015-09-27_22_03_26.png|frameless]]

[[File:mcmaster_bpm_wwavusbepp_winxp_not_virus_2015-09-27_22_04_53.png|frameless]]

Above: voltage monitoring. 03_voltage.lda

Above also shows that signals are at least in the 1-1.25 MHz range. I'm currently sampling at 6.25 MS/s

== Phase 2: USB cap/replay ==

Continue above project by toying with USB driver. Previously had some issue with certain response packet getting lost as it made its way back to the host (kernel capture: lost, libusb: lost, USB analyzer: received). This issue is what prompted this more detailed analysis. To that end, try to work in C to enable getting libusb help diagnosing the problem.

= 2015-09-29 =

Rewire Saleae cleaner. Confirmed that can select up to 500 MS/s with 2 channels with analog turned off

USB

''' VID: 14b9
''' PID: 0001

Looks like bp1410_sn.py (bfb0464a) demonstrates the issue I was having:

<code>
uvscada/bpm$ python bp1410_sn.py
Scanning for devices...
Found device
Bus 001 Device 006: ID 14b9:0001
val 157: 08160100
val 165: 000000
bulk read 167
Traceback (most recent call last):
File "bp1410_sn.py", line 689, in <module>
replay(dev)
File "bp1410_sn.py", line 495, in replay
buff = bulkRead(0x86, 0x0200, timeout=500)
File "bp1410_sn.py", line 276, in bulkRead
return dev.bulkRead(endpoint, length, timeout=timeout)
File "/usr/local/lib/python2.7/dist-packages/usb1.py", line 1174, in bulkRead
transferred = self._bulkTransfer(endpoint, data, length, timeout)
File "/usr/local/lib/python2.7/dist-packages/usb1.py", line 1144, in _bulkTransfer
raise libusb1.USBError(result)
libusb1.USBError: LIBUSB_ERROR_TIMEOUT [-7]
</code>

Step through code with LA to better understand whats going on

Open question: should I be renumerating?

test file: la_sn.py (based on bp1410_sn.py)

== packet 147/148 ==

[[File:mcmaster_bpm_wwavusbepp_screenshot_from_2015-09-29_23_45_11.png|frameless]]

LA: seeing some small transients. They are repeatable. Is this edge cross talk or actual signals? From:

<code>
# Generated from packet 147/148
buff = controlRead(0xC0, 0xB0, 0x0000, 0x0000, 4096)
validate_read("\x00\x00\x00", buff, "packet 147/148")
</code>

== packet 157/158 ==

Was not able to get any LA activity from this (CH0, 4 random channels):

<code>
# Generated from packet 157/158
buff = bulkRead(0x86, 0x0200)
# NOTE:: req max 512 but got 4
validate_read("\x08\x16\x01\x00", buff, "packet 148.5")
</code>

== packet 149-154 ==

Endpoint reset (packet 149-154) did not trigger CH0

== packet 165/166 ==

[[File:mcmaster_bpm_wwavusbepp_screenshot_from_2015-09-29_23_56_17.png|frameless]]
<code>
# Generated from packet 165/166
buff = controlRead(0xC0, 0xB0, 0x0000, 0x0000, 4096)
print 'val 165: %s' % binascii.hexlify(buff)
# NOTE:: req max 4096 but got 3
validate_read("\x00\x00\x00", buff, "packet 165/166")
</code>

Looks exactly like earlier but USB data is different

== packet 167/168 ==

<code>
# Generated from packet 167/168
buff = bulkRead(0x86, 0x0200, timeout=500)
# NOTE:: req max 512 but got 4
validate_read("\x08\x16\x01\x00", buff, "packet 167/168")
</code>

No LA traffic observed. The packet that gets lost

== S/N capture ==

From win SW

[[File:mcmaster_bpm_wwavusbepp_screenshot_from_2015-09-30_00_11_32.png|frameless]]

01_sn.logicdata

My S/N: 34346

''' 0x862a
''' 0b_1000_0110_0010_1010

This trace provides the first real insight:

''' CH1-8 appear to be 8 bit data bus
''' CH9: semi clock like or crosstalk
''' CH10: semi clock like or crosstalk
''' CH 13: clock like

== Next steps ==

Generate C version and double check data flow. Consider getting LA trace from Windows SW working correctly to better understand whats going on

= 2015-10-04 =

== S/N extraction ==

Given

<code>
dev.bulkWrite(0x02, "\x0E\x00")
buff = dev.bulkRead(0x86, 0x0200)
</code>

Generates a bus transaction (ex: getting serial number). S/N USB bytes:

''' 1 bytes: unknown
'''* <nowiki> \</nowiki>x08
''' 4 bytes: bus transaction
'''* <nowiki> \</nowiki>x3A<nowiki>\</nowiki>x00<nowiki>\</nowiki>x90<nowiki>\</nowiki>x32
''' 2 bytes: unknown
'''* <nowiki> \</nowiki>x00<nowiki>\</nowiki>x00
''' 8 bytes: bus transaction
'''* <nowiki> \</nowiki>x2A<nowiki>\</nowiki>x86<nowiki>\</nowiki>x01<nowiki>\</nowiki>x95<nowiki>\</nowiki>x3C<nowiki>\</nowiki>x36<nowiki>\</nowiki>x90<nowiki>\</nowiki>x00
'''* Byte order: little endian
''' 2 bytes: unknown
'''* <nowiki> \</nowiki>x20<nowiki>\</nowiki>x00
''' 14 bytes: bus transaction
'''* <nowiki> \</nowiki>x01<nowiki>\</nowiki>x00<nowiki>\</nowiki>xD6<nowiki>\</nowiki>x05<nowiki>\</nowiki>x01<nowiki>\</nowiki>x00<nowiki>\</nowiki>x72<nowiki>\</nowiki>x24<nowiki>\</nowiki>x22<nowiki>\</nowiki>x39<nowiki>\</nowiki>x00<nowiki>\</nowiki>x00<nowiki>\</nowiki>x00<nowiki>\</nowiki>x00
'''* Are the last 4 bytes actually part of this?
''' 4 bytes: unknown
'''* <nowiki> \</nowiki>xBF<nowiki>\</nowiki>x1D<nowiki>\</nowiki>x20<nowiki>\</nowiki>x00

Note: the USB trace is not the same trace as used on the LA

S/N details:

<code>
# Generated from packet 181/182
dev.bulkWrite(0x02, "\x0E\x00")
# Generated from packet 183/184
buff = dev.bulkRead(0x86, 0x0200)
# NOTE:: req max 512 but got 35
validate_read("\x08\x3A\x00\x90\x32\x00\x00\x2A\x86\x01\x95\x3C\x36\x90\x00\x20"
"\x00\x01\x00\xD6\x05\x01\x00\x72\x24\x22\x39\x00\x00\x00\x00\xBF"
"\x1D\x20\x00", buff, "packet 183/184")

Assuming negative clock on D13

Unmatched
0.2932924 0.0033224 0x0E
0.2932952 0.0000028 0x00
0.2973270 0.0040318 0x00
First
0.2973350 0.0000080 0x3A
0.2973430 0.0000080 0x00
0.2973510 0.0000080 0x90
0.2973590 0.0000080 0x32
Unmatched
0.2973670 0.0000080 0xA7
These bytes look to be a CRC, checksum etc but haven't matched up yet
0.2973750 0.0000080 0x02
Second
0.2973830 0.0000080 0x2A
0.2973910 0.0000080 0x86
0.2973990 0.0000080 0x01
0.2974070 0.0000080 0x95
0.2974150 0.0000080 0x3C
0.2974230 0.0000080 0x36
0.2974310 0.0000080 0x90
0.2974390 0.0000080 0x00
Unmatched
0.2974470 0.0000080 0x1F
0.2974550 0.0000080 0x00
Third
0.2974630 0.0000080 0x01
0.2974710 0.0000080 0x00
0.2974790 0.0000080 0xD6
0.2974870 0.0000080 0x05
0.2974950 0.0000080 0x01
0.2975030 0.0000080 0x00
0.2975110 0.0000080 0x72
0.2975190 0.0000080 0x24
0.2975270 0.0000080 0x22
0.2975350 0.0000080 0x39
0.2975430 0.0000080 0x00
0.2975510 0.0000080 0x00
0.2975590 0.0000080 0x00
0.2975670 0.0000080 0x00
end matches
0.2975750 0.0000080 0x27
0.2988804 0.0013054 0x14
0.2988832 0.0000028 0x38
</code>

= 2015-10-06 =

controlRead(0xC0, 0xB0, 0x0000, 0x0000, 4096)

''' LA: traffic but data bus has no activity (held high)

bulkWrite(0x02, "<nowiki>\</nowiki>x01")

''' LA traffic with bus activity

bulkRead(0x86, 0x0200)

''' Reads fx2 buffer. No LA traffic

Ran some experiments and confirmed that the first byte on the bus is the bulkWrite byte. Also can string multiple together to get them put together

CH9:

''' 1: Host to device (host write)
''' 0: Device to host (host read)

CH13:

''' Clock
''' Host reads on positive edge
''' Host changes data on negative edge
''' Device reads on positive edge?
''' Device changes data on negative edge

bulkWrite(0x02, "%%\%%xDE%%\%%xAD%%\%%BE%%\%%EF")

''' Resulted in %%\%%x9E%%\%%xAD on bus
''' Why did it drop the first high bit but no the second? Escape sequence of some sort?
'''* TODO: review data for 0x80 bit
''' Why did it stop after the first two bytes?

BPM WWAVUSBEPP LA

2023-05-01T00:44:14Z

RH: /* Phase 1: LA */

Logic analyzer test

17 signal pins, 16 LA channels. Arbitrarily drop pin 8 in favor of hooking everything up linearly.

= 2015-09-27 =

Project goal: understand how voltages/currents are read out

== Phase 1: LA ==

Ran into some signal integrity issues setting up capture. Had to do short wires. More info:

''' Final setup
'''* [[https://twitter.com/johndmcmaster/status/648329962819182592|https:''twitter.com/johndmcmaster/status/648329962819182592]]
'''* [[https://twitter.com/johndmcmaster/status/648348769746948097|https:''twitter.com/johndmcmaster/status/648348769746948097]]
''' Flaky: flying leads
'''* [[https://twitter.com/johndmcmaster/status/648315944121425920|https:''twitter.com/johndmcmaster/status/648315944121425920]]
''' Complete failure: ribbon cable
'''* [[https://twitter.com/johndmcmaster/status/645354861383385088|https:''twitter.com/johndmcmaster/status/645354861383385088]]

Setup to trigger on J2.1. Triggered during startup sequence reading serial number etc

Discovered Saleae only support 8/16 channels with USB 2. Ordered USB3 expresscard adapter.

SN:

[[File:mcmaster_bpm_wwavusbepp_screenshot_from_2015-09-27_21_43_18.png|frameless]]

Above: 1-8 at startup

[[File:mcmaster_bpm_wwavusbepp_screenshot_from_2015-09-27_21_52_05.png|frameless]]

Above: after hitting don't register. 02_post_sn.lda

[[File:mcmaster_bpm_wwavusbepp_screenshot_from_2015-09-27_21_55_51.png|frameless]]

Above: after hitting okay that's in unsupported mode

[[File:mcmaster_bpm_wwavusbepp_screenshot_from_2015-09-27_22_01_07.png|frameless]]

Above: software started but idle

[[File:mcmaster_bpm_wwavusbepp_screenshot_from_2015-09-27_22_03_26.png|frameless]]

[[File:mcmaster_bpm_wwavusbepp_winxp_not_virus_2015-09-27_22_04_53.png|frameless]]

Above: voltage monitoring. 03_voltage.lda

Above also shows that signals are at least in the 1-1.25 MHz range. I'm currently sampling at 6.25 MS/s

== Phase 2: USB cap/replay ==

Continue above project by toying with USB driver. Previously had some issue with certain response packet getting lost as it made its way back to the host (kernel capture: lost, libusb: lost, USB analyzer: received). This issue is what prompted this more detailed analysis. To that end, try to work in C to enable getting libusb help diagnosing the problem.

= 2015-09-29 =

Rewire Saleae cleaner. Confirmed that can select up to 500 MS/s with 2 channels with analog turned off

USB

''' VID: 14b9
''' PID: 0001

Looks like bp1410_sn.py (bfb0464a) demonstrates the issue I was having:

<code>
uvscada/bpm$ python bp1410_sn.py
Scanning for devices...
Found device
Bus 001 Device 006: ID 14b9:0001
val 157: 08160100
val 165: 000000
bulk read 167
Traceback (most recent call last):
File "bp1410_sn.py", line 689, in <module>
replay(dev)
File "bp1410_sn.py", line 495, in replay
buff = bulkRead(0x86, 0x0200, timeout=500)
File "bp1410_sn.py", line 276, in bulkRead
return dev.bulkRead(endpoint, length, timeout=timeout)
File "/usr/local/lib/python2.7/dist-packages/usb1.py", line 1174, in bulkRead
transferred = self._bulkTransfer(endpoint, data, length, timeout)
File "/usr/local/lib/python2.7/dist-packages/usb1.py", line 1144, in _bulkTransfer
raise libusb1.USBError(result)
libusb1.USBError: LIBUSB_ERROR_TIMEOUT [-7]
</code>

Step through code with LA to better understand whats going on

Open question: should I be renumerating?

test file: la_sn.py (based on bp1410_sn.py)

== packet 147/148 ==

[[File:mcmaster_bpm_wwavusbepp_screenshot_from_2015-09-29_23_45_11.png|frameless]]

LA: seeing some small transients. They are repeatable. Is this edge cross talk or actual signals? From:

<code>
# Generated from packet 147/148
buff = controlRead(0xC0, 0xB0, 0x0000, 0x0000, 4096)
validate_read("\x00\x00\x00", buff, "packet 147/148")
</code>

== packet 157/158 ==

Was not able to get any LA activity from this (CH0, 4 random channels):

<code>
# Generated from packet 157/158
buff = bulkRead(0x86, 0x0200)
# NOTE:: req max 512 but got 4
validate_read("\x08\x16\x01\x00", buff, "packet 148.5")
</code>

== packet 149-154 ==

Endpoint reset (packet 149-154) did not trigger CH0

== packet 165/166 ==

[[File:mcmaster_bpm_wwavusbepp_screenshot_from_2015-09-29_23_56_17.png|frameless]]
<code>
# Generated from packet 165/166
buff = controlRead(0xC0, 0xB0, 0x0000, 0x0000, 4096)
print 'val 165: %s' % binascii.hexlify(buff)
# NOTE:: req max 4096 but got 3
validate_read("\x00\x00\x00", buff, "packet 165/166")
</code>

Looks exactly like earlier but USB data is different

== packet 167/168 ==

<code>
# Generated from packet 167/168
buff = bulkRead(0x86, 0x0200, timeout=500)
# NOTE:: req max 512 but got 4
validate_read("\x08\x16\x01\x00", buff, "packet 167/168")
</code>

No LA traffic observed. The packet that gets lost

== S/N capture ==

From win SW

[[File:mcmaster_bpm_wwavusbepp_screenshot_from_2015-09-30_00_11_32.png|frameless]]

01_sn.logicdata

My S/N: 34346

''' 0x862a
''' 0b_1000_0110_0010_1010

This trace provides the first real insight:

''' CH1-8 appear to be 8 bit data bus
''' CH9: semi clock like or crosstalk
''' CH10: semi clock like or crosstalk
''' CH 13: clock like

== Next steps ==

Generate C version and double check data flow. Consider getting LA trace from Windows SW working correctly to better understand whats going on

= 2015-10-04 =

== S/N extraction ==

Given

<code>
dev.bulkWrite(0x02, "\x0E\x00")
buff = dev.bulkRead(0x86, 0x0200)
</code>

Generates a bus transaction (ex: getting serial number). S/N USB bytes:

''' 1 bytes: unknown
'''* <nowiki> \</nowiki>x08
''' 4 bytes: bus transaction
'''* <nowiki> \</nowiki>x3A<nowiki>\</nowiki>x00<nowiki>\</nowiki>x90<nowiki>\</nowiki>x32
''' 2 bytes: unknown
'''* <nowiki> \</nowiki>x00<nowiki>\</nowiki>x00
''' 8 bytes: bus transaction
'''* <nowiki> \</nowiki>x2A<nowiki>\</nowiki>x86<nowiki>\</nowiki>x01<nowiki>\</nowiki>x95<nowiki>\</nowiki>x3C<nowiki>\</nowiki>x36<nowiki>\</nowiki>x90<nowiki>\</nowiki>x00
'''* Byte order: little endian
''' 2 bytes: unknown
'''* <nowiki> \</nowiki>x20<nowiki>\</nowiki>x00
''' 14 bytes: bus transaction
'''* <nowiki> \</nowiki>x01<nowiki>\</nowiki>x00<nowiki>\</nowiki>xD6<nowiki>\</nowiki>x05<nowiki>\</nowiki>x01<nowiki>\</nowiki>x00<nowiki>\</nowiki>x72<nowiki>\</nowiki>x24<nowiki>\</nowiki>x22<nowiki>\</nowiki>x39<nowiki>\</nowiki>x00<nowiki>\</nowiki>x00<nowiki>\</nowiki>x00<nowiki>\</nowiki>x00
'''* Are the last 4 bytes actually part of this?
''' 4 bytes: unknown
'''* <nowiki> \</nowiki>xBF<nowiki>\</nowiki>x1D<nowiki>\</nowiki>x20<nowiki>\</nowiki>x00

Note: the USB trace is not the same trace as used on the LA

S/N details:

<code>
# Generated from packet 181/182
dev.bulkWrite(0x02, "\x0E\x00")
# Generated from packet 183/184
buff = dev.bulkRead(0x86, 0x0200)
# NOTE:: req max 512 but got 35
validate_read("\x08\x3A\x00\x90\x32\x00\x00\x2A\x86\x01\x95\x3C\x36\x90\x00\x20"
"\x00\x01\x00\xD6\x05\x01\x00\x72\x24\x22\x39\x00\x00\x00\x00\xBF"
"\x1D\x20\x00", buff, "packet 183/184")

Assuming negative clock on D13

Unmatched
0.2932924 0.0033224 0x0E
0.2932952 0.0000028 0x00
0.2973270 0.0040318 0x00
First
0.2973350 0.0000080 0x3A
0.2973430 0.0000080 0x00
0.2973510 0.0000080 0x90
0.2973590 0.0000080 0x32
Unmatched
0.2973670 0.0000080 0xA7
These bytes look to be a CRC, checksum etc but haven't matched up yet
0.2973750 0.0000080 0x02
Second
0.2973830 0.0000080 0x2A
0.2973910 0.0000080 0x86
0.2973990 0.0000080 0x01
0.2974070 0.0000080 0x95
0.2974150 0.0000080 0x3C
0.2974230 0.0000080 0x36
0.2974310 0.0000080 0x90
0.2974390 0.0000080 0x00
Unmatched
0.2974470 0.0000080 0x1F
0.2974550 0.0000080 0x00
Third
0.2974630 0.0000080 0x01
0.2974710 0.0000080 0x00
0.2974790 0.0000080 0xD6
0.2974870 0.0000080 0x05
0.2974950 0.0000080 0x01
0.2975030 0.0000080 0x00
0.2975110 0.0000080 0x72
0.2975190 0.0000080 0x24
0.2975270 0.0000080 0x22
0.2975350 0.0000080 0x39
0.2975430 0.0000080 0x00
0.2975510 0.0000080 0x00
0.2975590 0.0000080 0x00
0.2975670 0.0000080 0x00
end matches
0.2975750 0.0000080 0x27
0.2988804 0.0013054 0x14
0.2988832 0.0000028 0x38
</code>

= 2015-10-06 =

controlRead(0xC0, 0xB0, 0x0000, 0x0000, 4096)

''' LA: traffic but data bus has no activity (held high)

bulkWrite(0x02, "<nowiki>\</nowiki>x01")

''' LA traffic with bus activity

bulkRead(0x86, 0x0200)

''' Reads fx2 buffer. No LA traffic

Ran some experiments and confirmed that the first byte on the bus is the bulkWrite byte. Also can string multiple together to get them put together

CH9:

''' 1: Host to device (host write)
''' 0: Device to host (host read)

CH13:

''' Clock
''' Host reads on positive edge
''' Host changes data on negative edge
''' Device reads on positive edge?
''' Device changes data on negative edge

bulkWrite(0x02, "%%\%%xDE%%\%%xAD%%\%%BE%%\%%EF")

''' Resulted in %%\%%x9E%%\%%xAD on bus
''' Why did it drop the first high bit but no the second? Escape sequence of some sort?
'''* TODO: review data for 0x80 bit
''' Why did it stop after the first two bytes?

BPM Programmer

2023-04-29T06:34:56Z

RH: /* Parallel to USB upgrade */

[[Category:BPM]]
[[Category:Programmer]]
[[Category:Hardware]]

=BP series=

{| class="wikitable"
!Vendor
!Model
!Year
!Motherboard
silkscreen
!Motherboard
CPU
!Motherboard
RAM
!Motherboard
FPGA sticker
!Card
Model
!Tech adapter
silkscreen
!Power supply
!Accessory
!Last BPWin
!Note
|-
|Actel
|SS2
|2001
|CPCB12A Rev. C
|Intel FC80486DX4100
|Populated
|U5
W42MX24A
BP MICROSYSTEMS
09/20/02
|CPCBPD8B Rev B
2001
|CPCBVLTA REV. B
2000
|
|Button
|
|mcmaster
|-
|Actel
|SS3
|2008-05-12 
|WWAV12F
REV.F M0309

ASSY WWAV12F
|Intel UG80486DX4100
|SO DDR
Populated

CENTON

512 MB
|
|CPCBPD8B Rev B
2001
|
|SWG
CEM-??

CEL-22-LF000000006246

REV-A1
|
|
|
|-
|BPM
|1148
|
|
|
|
|
|
|
|
|
|
|
|-
|BPM
|1200
|1992
|BP-1200 Rev C
|AMD N80L286-16/S
|N/A
|
|CPCBPD8 Rev. D
|
|INTEGRATED POWER DESIGN 
|
|
|
|-
|BPM
|1400/84
|
|
|
|
|
|
|
|
|
|
|
|-
|BPM
|1400
(1400/240)
|
|CPCB11 Rev. G
|80C286
|
|
|
|CPCBTA240V REV. D
|29203118-C2
REV-C C2
|
|
|
|-
|BPM
|1410/84
|2005
|CPCBD03223 Rev. F
2005
|Intel 80486DX4100
|SO DDR
Unpopulated
|N/A
|CPCBPD8B Rev B
2001
|2002 BP MICROSYSTEMS
|Model?
Looks like SS3

CEL-22-000000001560

E145540, CS155-F3

HP-OK, REV A
|
|
|mcmaster
|-
|BPM
|1410
(1410/240)
|
|
|
|
|
|
|
|
|
|
|
|-
|BPM
|1600
|
|CPCB12A Rev. C 2001
|Intel FC80486DX4100
|72-pin SIMM
Unpopulated
|(handwritten)
MUS
28781
|CPCBPD8B Rev A 1999
|CPCBVLVTA REV. B 2000
|29203118-C2
REV-C C2
|
|5.33.0
|
|-
|BPM
|1610
|
|
|
|
|
|
|
|
|
|
|
|-
|BPM
|1700
|
|
|
|
|
|
|
|
|
|
|
|-
|BPM
|1710
|
|
|
|
|
|
|
|
|
|
|
|-
|BPM
|2000
|
|
|
|
|
|
|
|
|
|
|
|-
|BPM
|2100
|
|
|
|
|
|
|
|
|
|
|
|-
|BPM
|2200x4/240
|1998
|CPCB11 Rev. F
1998
|Harris CS80C286-16
|
|
|CPCBPD8A Rev D
1997
|Top
CPCBTA240V REV. D

1996

Bottom

CPCBTA240V Rev. D

1996
|29203118-C2
REV-C C2
|
|4.73.0
|mcmaster
REV vs Rev is inconsistent even on the same PCB...
|-
|BPM
|2500
|
|
|
|
|
|
|
|
|
|
|
|-
|BPM
|2510
|
|
|
|
|
|
|
|
|
|
|
|-
|BPM
|2600
|
|
|
|
|
|
|
|
|
|
|
|-
|BPM
|2600M
|
|
|
|
|
|
|
|
|
|
|
|-
|BPM
|2610
|
|
|
|
|
|
|
|
|
|
|
|-
|BPM
|2700
|
|
|
|
|
|
|
|
|
|
|
|-
|BPM
|2700M
|
|
|
|
|
|
|
|
|
|
|
|-
|BPM
|2710
|
|
|
|
|
|
|
|
|
|
|
|-
|BPM
|2800F
|
|
|
|
|
|
|
|
|
|
|
|}
General notes:

*The following are the same basic hardware
**BP-1400, BP-2200
**BP-1410, SS3
**BP-1600, SS2
*Power supplies
**Three generations

 
(11:36:56 PM) Lord_Nightmare: the main processor [of the bp1200] is an 80286-16, with a 32mhz xtal
(11:37:07 PM) Lord_Nightmare: [the board labeled] std48, it would [I assume] normally have [std48] printed on it nicely
(11:37:22 PM) Lord_Nightmare: this one was a refurbished unit and i guess they used an unprinted metal case for that pcb
(11:37:37 PM) Lord_Nightmare: std48 is the 'relay pcb'
(11:37:38 PM) digshadow: but whats the point
(11:37:52 PM) Lord_Nightmare: i think it controls which pins are powered with what [rail] but am not sure
(11:38:06 PM) digshadow: gotcha
(11:38:07 PM) Lord_Nightmare: the bp1200 it is a 'separate' pcb on top of the unit
(11:38:13 PM) digshadow: but its basically part of the unit right
(11:40:54 PM) Lord_Nightmare: the bp1600 has the 'relay board' integrated as a board which sits on top of the rest of the inside of the unit inside the case
(11:41:16 PM) Lord_Nightmare: i think the 1400 does as well
(11:41:33 PM) Lord_Nightmare: while on the 1200 it sat on top of the unit
(11:46:35 PM) Lord_Nightmare: the most basic bp unit was the bp-1148 "device programmer"
(11:46:55 PM) Lord_Nightmare: note the case is identical to the 1200, and the only difference [in appearance] is 'universal' is blacked out on the wording
(11:47:11 PM) Lord_Nightmare: http://vertassets.blob.core.windows.net/image/107fdcf5/107fdcf5-2dad-11d4-8c3d-009027de0829/bp1148.jpg
(11:47:46 PM) Lord_Nightmare: that picture is a mockup, the std48 'layer' is missing
(11:48:11 PM) Lord_Nightmare: http://thumbs.ebaystatic.com/d/l225/m/m1qMyAgqacqzlOo4KbeZLcw.jpg shows an actual 1148

ECO: WWAV20-4

*<nowiki>http://www3.bpmmicro.com/web/helpandsupport.nsf/69f301ee4e15195486256fcf0062c2eb/66634b97cb53c22e8625703e0062b99a!OpenDocument</nowiki>
*Effect 1: ECO: WWAV20-4 Effect 2: CPCB11 Rev A-F - TA-84 will occasionally fail relay test

<nowiki>http://www3.bpmmicro.com/web/helpandsupport.nsf/WebKeys/BPM-7Q2R96!OpenDocument</nowiki>
{| class="wikitable"
|BP-1148, BP-1200, BP-2000, BP-2100, BP-2500, BP-2510, BP-2600M Final Software Version 
|-
|
|-
|Legacy Programmer Last Software Version Reference 
|-
|
|-
|Per the following document, the final BPWin version for the legacy programmers listed above is BPWin 4.73.
<nowiki>http://www3.bpmicro.com/Web/helpandsupport.nsf/WebKeys/BPM-6AHS6M?opendocument&Cat=FAQ</nowiki>

You can download BPWin 4.73 from our software download page by clicking the "BPM Legacy Software Download" link in the upper-left corner of the page.
 
|}

==BP-1200==

[[File:Ln bpm bp-1200 unit top.jpg|frameless]]
[[File:Ln bpm bp-1200 unit top relay.jpg|frameless]]

[[File:Ln bpm bp-1200 relay btm.jpg|frameless]]
[[File:Ln bpm bp-1200 unit btm.jpg|frameless]]
[[File:Ln bpm bp-1200 unit side.jpg|frameless]]

[[File:Ln bpm bp-1200 pcb0.jpg|frameless]]
[[File:Ln bpm bp-1200 pcb1.jpg|frameless]]
[[File:Ln bpm bp-1200 ps.jpg|frameless]]

[[File:Ln bpm bp-1200 cpcbpd8 d back.jpg|frameless]]
[[File:Ln bpm bp-1200 cpcbpd8 d front.jpg|frameless]]

PC interface: parallel port

Chip interface: 2 plug SM

http://atariage.com/forums/topic/142884-bp-microsystems-eprom-programmer-a-cry-for-help/

*IF you get a TA-84 pin driver module (and a SM48D 48-pin DIP module, but NOT the one that comes with the BP-1148) it will convert your BP-1148 to a BP1200/84.

==BP-1400==

PC interface: parallel port

Chip interface: 3 plug SM

BP-1400/84: [http://web.archive.org/web/20061119190006/http://www.bpmicro.com/products.nsf/7df54a7a9b18958d862566710079b2a0/cd8e1e770bf83c0e862569510070a6cf/$FILE/1400-84%20Data%20Sheet.pdf]

BP-1400/240: [http://web.archive.org/web/20061119190026/http://www.bpmicro.com/products.nsf/7df54a7a9b18958d862566710079b2a0/cd8e1e770bf83c0e862569510070a6cf/$FILE/1400-240%20Data%20Sheet.pdf]

===EOL notice===

http://www3.bpmmicro.com/web/helpandsupport.nsf/WebKeys/BPM-7AUPV7!OpenDocument&Cat=Issue&Click=

End of Life for 1400 and 2200 model programmers

Summary
BPM announces the planned end of support for the 1400 and 2200 model programmers on December 31, 2008. Introduced in 1996 and discontinued in 2005, the 2200 and 1400 were the first in the industry to enable fine control of programming waveforms for the highest quality programming with the widest device support capabilities. Limitations of the original programmers hardware combined with new software compatibility and component obsolescence forces this end of support announcement.

Details
End of support means that BPWin software released in 2009 will not support the 1400 and 2200 model numbers. These models can continue to function with existing BPWin software released prior to 2009, but will not be eligible for additional algorithms or updates to existing algorithms. Hardware contracts will also not be available for these programmers. Also, repairs and calibration of these programmers are no longer possible.

===Motherboard===

[[File:pd_bpm_bp-1400_mb1.jpg|frameless]]
[[File:pd_bpm_bp-1400_mb2.jpg|frameless]]

Mezzanine board:

[[File:pd_bpm_bp-1400_mez_top.jpg|frameless]]
[[File:pd_bpm_bp-1400_mez_btm.jpg|frameless]]

===Power supply===

[[File:pd_bpm_bp-1400_ps.jpg|frameless]]

==BP-1410==

[[BPM BP-1410]]

External:

[[File:mcmaster_bpm_bp-1410_ext_btm.jpg|frameless]]
[[File:mcmaster_bpm_bp-1410_ext_side.jpg|frameless]]
[[File:mcmaster_bpm_bp-1410_ext_top.jpg|frameless]]

Power supply:

[[File:mcmaster_bpm_bp-1410_ps_overview.jpg|frameless]]

PC interface: USB

Chip interface: 3 plug SM

BP-1410/84 datasheet: [http://web.archive.org/web/20060321214044/http://www.bpmicro.com/web/bphome.nsf/webpages/141084-PDF/$FILE/1410_84.pdf]

BP-1410/240 datasheet: [http://web.archive.org/web/20060321214333/http://www.bpmicro.com/web/bphome.nsf/webpages/1410240-PDF/$FILE/1410_240.pdf]

===Motherboard===

[[File:mcmaster_bpm_bp-1410_mb_overview.jpg|frameless]]
[[File:mcmaster_bpm_bp-1410_mb_usb_off2.jpg|frameless]]

Motherboard USB connector:

[[File:mcmaster_bpm_bp-1410_mb_usb_off.jpg|frameless]]
[[File:mcmaster_bpm_bp-1410_mb_usb_on.jpg|frameless]]

==BP-1600==

External:

[[File:mcmaster_bpm_bp-1600_top.jpg|frameless]]
[[File:mcmaster_bpm_bp-1600_btm.jpg|frameless]]
[[File:mcmaster_bpm_bp-1600_side.jpg|frameless]]

PC interface: parallel port

Chip interface: 3 plug SM

BP-1600 datasheet: [http://web.archive.org/web/20050530023158/http://www.bpmicro.com/web/BPhome.nsf/webpages/1600-PDF/$FILE/1600DS_EN_0703.pdf]

1400 has a 286 and the 1410 a 486
1600 supports 1.5V parts
5000 more devices (probably a lot more by now)

===Motherboard:===

[[File:mcmaster_bpm_bp-1600_mb1.jpg|frameless]]
[[File:mcmaster_bpm_bp-1600_mb2.jpg|frameless]]
[[File:mcmaster_bpm_bp-1600_mb_parallel_off.jpg|frameless]]

CPCD12A Rev. C

CPU

intel
Intel DX4
iCOMP TM index=435
PC80486DX4100
L124EA01
&EW 3VOLT SL2M9
INTEL (M)(C) '89 '94

Connectors are numbered with 1 at the side of the top or left of the PCB, oriented such that writing is right side up (ie side with blue trim pot)

J10 (Fan, N/C)
{| class="wikitable sortable" border="1"
!#!!V!!Note
|-
|1||N/C?||
|-
|2||16.5||
|-
|3||0||
|-
|4||N/C?||
|-
|}

J11 (Term. 1, N/C)

{| class="wikitable sortable" border="1"
!#!!V!!Note
|-
|1||0.0||
|-
|2||1.1||
|-
|3||0.25||
|-
|4||5.1||
|-
|}

J12 (Term. 2, N/C)

Was this supposed to be identical to above? Broken?

{| class="wikitable sortable" border="1"
!#!!V!!Note
|-
|1||0.0||
|-
|2||0.0||
|-
|3||0.0||
|-
|4||0.8||
|-
|}

Voltage header

{| class="wikitable sortable" border="1"
!Label!!V!!Note
|-
| +5V||5.1||
|-
| +3.3V||3.3||
|-
|GND||0.0||
|-
| -3.5V||-3.5||
|-
| -5V||-5.0||
|-
|GND||0.0||
|-
| +2.5V||2.5||
|-
|PGD||4.1||
|-
|VTH||1.6||
|-
|}

===Power supply===

[[File:mcmaster_bpm_bp-1600_ps.jpg|frameless]]
[[File:mcmaster_bpm_bp-1600_ps_overview.jpg|frameless]]

J4 (12V fans...wtf?)
{| class="wikitable sortable" border="1"
!#!!Color!!V!!Note
|-
|1||Red||35.4||
|-
|2||Red||16.5||
|-
|3||Black||0.0||
|-
|4||Black||5.3||
|-
|}

J5 (to MB J4 or J20)
{| class="wikitable sortable" border="1"
!#!!Color!!V!!Note
|-
|1||Purple||35.4||
|-
|2||Orange||16.5||
|-
|3||Black||0.0||
|-
|4||Red||5.3||
|-
|}

J6 (to MB J4 or J20)
{| class="wikitable sortable" border="1"
!#!!Color!!V!!Note
|-
|1||Purple||35.4||
|-
|2||Orange||16.5||
|-
|3||Black||0.0||
|-
|4||Red||5.3||
|-
|}

==BP-2200==

"Concurrent Programming System"

PC interface: parallel port

Chip interface: 4X 3 plug SM

BP-2200 datasheet: [http://web.archive.org/web/20061119185923/http://www.bpmicro.com/products.nsf/7df54a7a9b18958d862566710079b2a0/bc7af9c2aab5d676862566540077413c/$FILE/2200%20Data%20Sheet.pdf]

==Parallel to USB upgrade==

Main page: [[BPM_WWAVUSBEPP]]

==USB hub==

Used on gang programmers

[[File:anon_bpm_wwavusbhub_1.jpg|frameless]]

[[File:anon_bpm_wwavusbhub_2.jpg|frameless]]

[[File:anon_bpm_wwavusbhub_3.jpg|frameless]]

=EP series=

==EP-1==

PC interface: parallel port

Chip interface: DIP

==EP-1132==

PC interface: parallel port

Chip interface: DIP-32

==EP-1140==
[[File:BP_EP_1140_Top.jpg|frameless|480px]] 

'''PC interface:''' parallel port 
'''Chip interface:''' DIP-40 
'''CPU:''' Intel 8088 
'''Memory:''' 8KB/32KB SRAM 
'''Firmware:''' 8KB/16KB/32KB EPROM 

[[File:BP_EP_1140_PCB_Front.jpg|frameless|480px]] 
[[File:BP_EP_1140_Parallel.jpg|frameless|160px]]
[[File:BP_EP_1140_CPU.jpg|frameless|160px]]
[[File:BP_EP_1140_Linear_Supply.jpg|frameless|160px]] 
[[File:BP_EP_1140_Variable_Supply.jpg|frameless|240px]]
[[File:BP_EP_1140_IO_Ground.jpg|frameless|240px]] 

'''Jumpers:''' 
*EPROM Type
**Left = ON for 27256, OFF for 2764/27128
**Middle = ON for 27128/27256, OFF for 2764
*SRAM Type
**Right = ON for 62256*, OFF for 6264
''ON = Up/Towards xtal'' 
''OFF = Down/Away from xtal'' 
(* Note: Even if the firmware can deal with more RAM, BPDos/BPWin might expect it to be hardcoded and crash the programmer if not set right.) 

'''Powersupply:'''
*Unregulated
**-13.4V/+11.1V
**-44.8V/+38.8V
*Linear
**+5V (TTL, CPU, DAC)
**+6V (CMOS)
**-3V/+29V (Op-Amps)
*Variable
**Overcurrent-protection
**13 DACs (DAC0830LCN)
**4 quad op-amps (TL084CN)
*Routing
**12 transistors for VCC/VPP (NSDU01)
**11 transistors which has something to do with VPP-pins (PN2222)
**8 transistors for GND (IRF-Z15)

'''Pinout:'''
*20 normal IO pins
*1 pin with VCC feature
*11 pins with VPP feature
*8 pins with GND feature
*Out of all the pins, 4 have some unknown additional feature

<nowiki>Pin features:
______ _____ _____ ______
_ VPP |_| VCC _
_ Pin* Pin _
_ Pin* VPP _
_ GND VPP _
___ Pin VPP ___
_ Pin VPP _
_ VPP VPP _
_ Pin Pin _
_ Pin VPP _
______ Pin VPP ______
_ GND GND _
_ GND Pin _
_ Pin Pin _
_ GND Pin _
___ Pin VPP ___
_ GND VPP _
_ Pin Pin _
_ GND* Pin _
_ Pin* Pin _
______ GND_____________Pin ______

* Unknown additional feature
</nowiki>

=PLD series=

==PLD-1128==
[[File:BP_PLD_1128_Top.jpg|frameless|480px]] 

'''PC interface:''' parallel port 
'''Chip interface:''' DIP-28 
'''CPU:''' Zilog Z80 
'''Memory:''' 2KB/8KB SRAM 
'''Firmware:''' 8KB/16KB/32KB EPROM 

[[File:BP_PLD_1128_PCB_Front.jpg|frameless|480px]] 
[[File:BP_PLD_1128_Parallel.jpg|frameless|160px]]
[[File:BP_PLD_1128_IO_Upper.jpg|frameless|240px]]
[[File:BP_PLD_1128_Linear_Supply_Upper.jpg|frameless|160px]] 
[[File:BP_PLD_1128_CPU.jpg|frameless|160px]]
[[File:BP_PLD_1128_IO_Lower.jpg|frameless|240px]]
[[File:BP_PLD_1128_Linear_Supply_Lower.jpg|frameless|160px]] 

'''Jumpers:''' 
*EPROM Type
**W1 = ON for 2764/27128, OFF for 27256
**W2 = ON for 2764 , OFF for 27128/27256
*SRAM Type
**W3 = ON for 6116, OFF for 6264*
*Unknown
**Jumper up by the parallel port = ??
''ON = Up/Towards CPU'' 
''OFF = Down/Away from CPU'' 
(* Note: V1.05d firmware only supports 6116-type SRAM)

'''Powersupply:'''
*Unregulated
**-10.9V/+10.3V
**+52.5V
*Regulated
**+5V (Digital)
**-5.8V/+11.3V (DAC)
**-5.8V/+30V (Op-Amp)
**Possibly more

=CP series=

==CP-1128==

PC interface: parallel port

Chip interface: DIP-28

=Silicon Sculptor=

Actel programmers made by BPM.

As these cost less than the "real" BPM programmers, presumably can't be used with normal BPM software and/or work with other adapters

==Silicon Sculptor 1==

Has 2 headers (left/right) that adaptors plug into

Interface: parallel port

There is version with 1 connector and a version with 6 connectors

1X markings

Silicon Sculptor
FAIL
ACTIVE
PASS
START
ACTEL DEVICE PROGRAMMER
BP MICROSYSTEMS

==Silicon Sculptor 2==

<nowiki>http://www.actel.com/kb/article.aspx?id=SL1039</nowiki>

*WWAV20 motherboard with pin driver boards (PD8As)
*286 processor
*2MB onboard RAM
*an additional 4MB SIMM to support concurrency

Markings:

Silicon Sculptor II
Actel
FAIL
ACTIVE
PASS
ACTEL DEVICE PROGRAMMER
BP MICROSYSTEMS

[[File:anon_bpm_ss2_ext.jpg|frameless]]

[[File:anon_bpm_ss2_ext_btm_label.jpg|frameless]]

[[File:anon_bpm_ss2_int_mb1.jpg|frameless]]
[[File:anon_bpm_ss2_int_mb2.jpg|frameless]]
[[File:anon_bpm_ss2_int_mb3.jpg|frameless]]
[[File:anon_bpm_ss2_int_mb4.jpg|frameless]]
[[File:anon_bpm_ss2_int_mb5.jpg|frameless]]
[[File:anon_bpm_ss2_int_mb6.jpg|frameless]]

[[File:anon_bpm_ss2_int_driver.jpg|frameless]]

[[File:anon_bpm_ss2_simm.jpg|frameless]]

[[File:anon_bpm_ss2_int_mez.jpg|frameless]]

===mcmaster notes===

2018-09-12

*Open SS2
*Think this was the eBay unit?
*PCB is identical to one used in BP-1600
*Both have blue bodge wire
*SS2 has RAM installed

==Actel Silicon Sculptor 3==

[[File:mcmaster_bpm_ss3_top.jpg|frameless]]

Above: DO NOT TOUCH!

This appears to be a crippled BP-1410 (however, it has the front-panel button and the 512MB of RAM present in the BP-1710). No analysis has been done to figure out where the devices differ (firmware, FPGA, host, etc)

Product page: [http://www.microsemi.com/products/fpga-soc/design-resources/programming/silicon-sculptor-3]

I love how they switched from roman numerals to Arabic numbers. Maybe they'll call the next one Silicon Sculptor D…

Has 3 headers (left/right/top) that adaptors plug into

Interface: USB

Markings:

Silicon Sculptor 3
Actel
FAIL
ACTIVE
PASS
START (button)
ACTEL DEVICE PROGRAMMER
BP MICROSYSTEMS

===External===

[[File:mcmaster_actel_ss3_ext_top.jpg|frameless]]
[[File:mcmaster_actel_ss3_ext_btm.jpg|frameless]]
[[File:mcmaster_actel_ss3_ext_side.jpg|frameless]]

===Motherboard===

Main assembly:

[[File:mcmaster_actel_ss3_mb1.jpg|frameless]]
[[File:mcmaster_actel_ss3_mb3.jpg|frameless]]

Driver board:

[[File:mcmaster_actel_ss3_cpcbpd8b_rev_b.jpg|frameless]]

===Power supply===

[[File:mcmaster_actel_ss3_ps1.jpg|frameless]]
[[File:mcmaster_actel_ss3_ps2.jpg|frameless]]