BPM WWAVUSBEPP: Difference between revisions

From Proghq
Jump to navigation Jump to search
(Created page with "====== Background ====== At one point they sold an upgrade board to convert older programmers to USB. Basically what it boils down to is: * The adapter should work for...")
 
No edit summary
Line 1: Line 1:
====== Background ======
= Background =


At one point they sold an upgrade board to convert older programmers to USB.  Basically what it boils down to is:
At one point they sold an upgrade board to convert older programmers to USB.  Basically what it boils down to is:


    * The adapter should work for BP-1400, BP-1600, BP-1700, and (some?) EPP series programmers
''' The adapter should work for BP-1400, BP-1600, BP-1700, and (some?) EPP series programmers
    * You can swap it from one unit to another (ex: swap from BP-1410 to BP-1600 to upgrade an old unit)
''' You can swap it from one unit to another (ex: swap from BP-1410 to BP-1600 to upgrade an old unit)
    * Units known to ship with this adapter
''' Units known to ship with this adapter
      * BP-1410 (probably BP-1610 and BP-1710 as well)
'''* BP-1410 (probably BP-1610 and BP-1710 as well)
      * Silicon Sculptor 3
'''* Silicon Sculptor 3
    * The adapter is no longer offered as an upgrade for the BP-1×00 models
''' The adapter is no longer offered as an upgrade for the BP-1×00 models


[[http://www3.bpmicro.com/web/bphome.nsf/(web.news)/FB83F285AEE1E5BB862570670047820E|http://www3.bpmicro.com/web/bphome.nsf/(web.news)/FB83F285AEE1E5BB862570670047820E]]
[[http:''www3.bpmicro.com/web/bphome.nsf/(web.news)/FB83F285AEE1E5BB862570670047820E|http:''www3.bpmicro.com/web/bphome.nsf/(web.news)/FB83F285AEE1E5BB862570670047820E]]


[[http://www3.bpmmicro.com/web/helpandsupport.nsf/69f301ee4e15195486256fcf0062c2eb/c4c2dac08101795c8625703e0062bde8/$FILE/Programmer Site USB 2.0 Adapter FAQ.doc|http://www3.bpmmicro.com/web/helpandsupport.nsf/69f301ee4e15195486256fcf0062c2eb/c4c2dac08101795c8625703e0062bde8/$FILE/Programmer Site USB 2.0 Adapter FAQ.doc]]
[[http:''www3.bpmmicro.com/web/helpandsupport.nsf/69f301ee4e15195486256fcf0062c2eb/c4c2dac08101795c8625703e0062bde8/$FILE/Programmer Site USB 2.0 Adapter FAQ.doc|http:''www3.bpmmicro.com/web/helpandsupport.nsf/69f301ee4e15195486256fcf0062c2eb/c4c2dac08101795c8625703e0062bde8/$FILE/Programmer Site USB 2.0 Adapter FAQ.doc]]


    * 2.4 Mb/s to 9.0 Mb/s potential speed upgrade
''' 2.4 Mb/s to 9.0 Mb/s potential speed upgrade
    * 14. What programming site models will this work with?
''' 14. What programming site models will this work with?
      * All EPP programmers.  This encompasses 6th-gen and 7th-gen.
'''* All EPP programmers.  This encompasses 6th-gen and 7th-gen.
      * This may be a different adapter board
'''* This may be a different adapter board
    * 17. About how much will these adapters cost to make?
''' 17. About how much will these adapters cost to make?
      * About $20 in materials
'''* About $20 in materials
    * 21. Why can’t I just buy an off-the-shelf USB-Parallel port adapter and use that?
''' 21. Why can’t I just buy an off-the-shelf USB-Parallel port adapter and use that?
      * There is no formal specification as to what you must do with these signals.  Printer makers adhere to an informal standard as to what each of these signals does, but such functionality isn’t suitable for device programmers.
'''* There is no formal specification as to what you must do with these signals.  Printer makers adhere to an informal standard as to what each of these signals does, but such functionality isn’t suitable for device programmers.
      * Even if the vendor-defined signals didn’t get in the way, the performance of any off-the-shelf adapter would be horrible (much worse than parallel port)
'''* Even if the vendor-defined signals didn’t get in the way, the performance of any off-the-shelf adapter would be horrible (much worse than parallel port)
    * 20. What are the Macola part numbers of the site adapter and the hub?
''' 20. What are the Macola part numbers of the site adapter and the hub?
      * Site Adapter:  WWAVUSBEPP
'''* Site Adapter:  WWAVUSBEPP
      * Hub: WWAVUSBHUB
'''* Hub: WWAVUSBHUB


[[https://www.febo.com/pipermail/time-nuts/2013-January/073818.html|https://www.febo.com/pipermail/time-nuts/2013-January/073818.html]]
[[https:''www.febo.com/pipermail/time-nuts/2013-January/073818.html|https:''www.febo.com/pipermail/time-nuts/2013-January/073818.html]]


<code>
<code>
Line 35: Line 35:
Other:
Other:


    * It's part number is WWAVUSBEPP
''' It's part number is WWAVUSBEPP


From another doc:
From another doc:
Line 41: Line 41:
'' > Automated Programming System users can determine if the handler is configured with the USB to EPP adapter through the PC Device Manager.  If “BP Microsystems SPC Interface” is present as shown in the object below, then the USB to EPP adapter is already installed.  If not, please contact BPM Microsystems Sales to order an upgrade kit part number: WHARUSBSPCKIT. ''
'' > Automated Programming System users can determine if the handler is configured with the USB to EPP adapter through the PC Device Manager.  If “BP Microsystems SPC Interface” is present as shown in the object below, then the USB to EPP adapter is already installed.  If not, please contact BPM Microsystems Sales to order an upgrade kit part number: WHARUSBSPCKIT. ''


====== Programmer compatibility ======
= Programmer compatibility =


Trying a 1600 with the adapter under 5.33.0 (last version to support parallel) worked fine.  However, under 5.47.0 (newest release version as of today):
Trying a 1600 with the adapter under 5.33.0 (last version to support parallel) worked fine.  However, under 5.47.0 (newest release version as of today):
Line 49: Line 49:
I analyzed the USB packet traces for kicks to see what was happening.  There are some minor differences (ex: later software chunks firmware load up smaller) but otherwise they are identical in purpose.  However, the newer software seems to just give up at one point.  My guess is that they removed the 1600 handling code, not just the parallel interface to it.
I analyzed the USB packet traces for kicks to see what was happening.  There are some minor differences (ex: later software chunks firmware load up smaller) but otherwise they are identical in purpose.  However, the newer software seems to just give up at one point.  My guess is that they removed the 1600 handling code, not just the parallel interface to it.


====== PCB overview ======
= PCB overview =


{{:mcmaster:bpm:wwavusbepp:top.jpg?300}}{{:mcmaster:bpm:wwavusbepp:btm.jpg?300}}
{{:mcmaster:bpm:wwavusbepp:top.jpg?300}}{{:mcmaster:bpm:wwavusbepp:btm.jpg?300}}
Line 55: Line 55:
Above:
Above:


    * ASSY No. WWAVUSBEPP
''' ASSY No. WWAVUSBEPP
    * EPCBD03181 Rev C
''' EPCBD03181 Rev C


{{:bpm:wwavusbepp:bpm_wwavusbepp.png}}
{{:bpm:wwavusbepp:bpm_wwavusbepp.png}}
Line 66: Line 66:
NOTE: a number of the component values above are best guesses.  In particular:
NOTE: a number of the component values above are best guesses.  In particular:


    * R6/R7 divider
''' R6/R7 divider
    * Most small capacitors.  T13/T17 are recommended values from cypress datasheet
''' Most small capacitors.  T13/T17 are recommended values from cypress datasheet
    * U3 is best guess
''' U3 is best guess


More info here: [[https://siliconpr0n.org/media/bpm/WWAVUSBEPP/|https://siliconpr0n.org/media/bpm/WWAVUSBEPP/]]
More info here: [[https:''siliconpr0n.org/media/bpm/WWAVUSBEPP/|https:''siliconpr0n.org/media/bpm/WWAVUSBEPP/]]


2015-04-24: tried plugging the adapter from my BP-1410 into my BP-1600 and it worked!
2015-04-24: tried plugging the adapter from my BP-1410 into my BP-1600 and it worked!


U1 ([[http://www.cypress.com/?docID=45142|CY7C68013]] FX2 MCU, [[http://www.cypress.com/?docID=48811|TRM]]):
U1 ([[http:''www.cypress.com/?docID=45142|CY7C68013]] FX2 MCU, [[http:''www.cypress.com/?docID=48811|TRM]]):


<code>
<code>
Line 103: Line 103:
</code>
</code>


====== Pinout ======
= Pinout =


^Pin ^Dbg color ^MCU pin ^Function ^PU/PD ^Note |
{| class="wikitable sortable" border=1
|1 |Black |30: CTL1/FLAGB | | | |
!Pin !!Dbg color !!MCU pin !!Function !!PU/PD !!Note |
|2 |Black |29: CTL0/FLAGA | | | |
|-
|3 |Brown |18: PB0/FD0 | | | |
| 1 || Black || 30: CTL1/FLAGB ||   ||    ||  
|4 |Brown |34: PA1/INT1# |  |PU | |
|-
|5 |Red |19: FB1/FD1 | | | |
| 2 || Black || 29: CTL0/FLAGA ||    ||   ||  
|6 |Red |38: PA5/FIFOADR1 | | | |
|-
|7 |Orange |20: FB2/FD2 | | | |
| 3 || Brown || 18: PB0/FD0 ||    ||   ||  
|8 |Orange |31: CTL2/FLAGC | | | |
|-
|9 |Yellow |21: PB3/FD3 | | | |
| 4 || Brown || 34: PA1/INT1# ||    || PU ||  
|10 |Yellow |N/A |GND | | |
|-
|11 |Green |22: PB4/FD4 | | | |
| 5 || Red || 19: FB1/FD1 ||    ||   ||  
|12 |Green |N/A |GND | | |
|-
|13 |Blue |23: PB5:FD5 | | | |
| 6 || Red || 38: PA5/FIFOADR1 ||   ||    ||  
|14 |Blue |N/A |GND | | |
|-
|15 |Violet |24: PB6/FD6 | | | |
| 7 || Orange || 20: FB2/FD2 ||    ||   ||  
|16 |Violet |N/A |GND | | |
|-
|17 |Black |25: PB7/FD7 | | | |
| 8 || Orange || 31: CTL2/FLAGC ||    ||   ||  
|18 |N/C |N/A |GND | | |
|-
|19 |Brown |33: PA0/INT0# |  |PU | |
| 9 || Yellow || 21: PB3/FD3 ||   ||    ||  
|20 |N/C |N/A |GND | | |
|-
|21 |Red |1: RDY0/SLRD |  |PU | |
| 10 || Yellow || N/A || GND ||    ||  
|22 |N/C |N/A |GND | | |
|-
|23 |Orange |2: RDY1/SLWR | | | |
| 11 || Green || 22: PB4/FD4 ||   ||    ||  
|24 |N/C |N/A |GND | | |
|-
|25 |Yellow |35: AP2/SLOE | | | |
| 12 || Green || N/A || GND ||    ||  
|26 |N/C |N/A |GND | | |
|-
| 13 || Blue || 23: PB5:FD5 ||    ||   ||  
|-
| 14 || Blue || N/A || GND ||    ||  
|-
| 15 || Violet || 24: PB6/FD6 ||    ||   ||  
|-
| 16 || Violet || N/A || GND ||    ||  
|-
| 17 || Black || 25: PB7/FD7 ||    ||   ||  
|-
| 18 || N/C || N/A || GND ||    ||  
|-
| 19 || Brown || 33: PA0/INT0# ||    || PU ||  
|-
| 20 || N/C || N/A || GND ||    ||  
|-
| 21 || Red || 1: RDY0/SLRD ||   || PU ||  
|-
| 22 || N/C || N/A || GND ||    ||  
|-
| 23 || Orange || 2: RDY1/SLWR ||    ||   ||  
|-
| 24 || N/C || N/A || GND ||    ||  
|-
| 25 || Yellow || 35: AP2/SLOE ||   ||    ||  
|-
| 26 || N/C || N/A || GND ||   || 
|-
|}


Resistor placed sub-optimially.  is there another pullup?
Resistor placed sub-optimially.  is there another pullup?
Line 137: Line 166:
17 signal pins, 16 LA channels.  Arbitrarily drop pin 8 in favor of hooking everything up linearly.
17 signal pins, 16 LA channels.  Arbitrarily drop pin 8 in favor of hooking everything up linearly.


====== USB protocol ======
= USB protocol =


As of 2015-10-04 I have PoC serial number readout working.  If the script isn't started from cold boot it gets a different response, but usually works
As of 2015-10-04 I have PoC serial number readout working.  If the script isn't started from cold boot it gets a different response, but usually works


===== Bulk EP 2 =====
== Bulk EP 2 ==


Transactions look like this
Transactions look like this
Line 152: Line 181:
Sample replies below
Sample replies below


==== //%%\%%//x00 ====
=== ''%%\%%''x00 ===


Repeatable.  TODO: is this issued anywhere?
Repeatable.  TODO: is this issued anywhere?
Line 160: Line 189:
</code>
</code>


==== //%%\%%//x01 ====
=== ''%%\%%''x01 ===


Repeatable.  Code issues this and get 132-136 bytes back depending on where it is
Repeatable.  Code issues this and get 132-136 bytes back depending on where it is
Line 188: Line 217:
</code>
</code>


==== //%%\%%//x02 ====
=== ''%%\%%''x02 ===


Tried this to see what it would do.  Caused unexpected responses to come back all the time and I had to power cycle the programmer
Tried this to see what it would do.  Caused unexpected responses to come back all the time and I had to power cycle the programmer


==== //%%\%%//x0E//%%\%%//x00 ====
=== ''%%\%%''x0E''%%\%%''x00 ===


<code>
<code>
Line 202: Line 231:
Above: serial number readout.  This may be some sort of EEPROM/flash read.  This packet is dissected in some more detail in the S/N section with some correlations to bus traffic.
Above: serial number readout.  This may be some sort of EEPROM/flash read.  This packet is dissected in some more detail in the S/N section with some correlations to bus traffic.


==== //%%\%%//x11//%%\%%//x10//%%\%%//x00 ====
=== ''%%\%%''x11''%%\%%''x10''%%\%%''x00 ===


Not followed by read
Not followed by read


==== //%%\%%//x11//%%\%%//x4E//%%\%%//x00 ====
=== ''%%\%%''x11''%%\%%''x4E''%%\%%''x00 ===


Not followed by read
Not followed by read


==== //%%\%%//x43... ====
=== ''%%\%%''x43... ===


<code>
<code>
Line 219: Line 248:
</code>
</code>


==== //%%\%%//x43... ====
=== ''%%\%%''x43... ===


<code>
<code>
Line 226: Line 255:
</code>
</code>


==== //%%\%%//x5A ====
=== ''%%\%%''x5A ===


<code>
<code>
Line 232: Line 261:
</code>
</code>


==== //%%\%%//x82 ====
=== ''%%\%%''x82 ===


<code>
<code>
Line 238: Line 267:
</code>
</code>


==== //%%\%%//xA6 ====
=== ''%%\%%''xA6 ===


<code>
<code>
Line 244: Line 273:
</code>
</code>


==== //%%\%%//xDB ====
=== ''%%\%%''xDB ===


<code>
<code>
Line 250: Line 279:
</code>
</code>


==== //%%\%%//xE8... ====
=== ''%%\%%''xE8... ===


<code>
<code>
Line 262: Line 291:
No read
No read


==== //%%\%%//xEA ====
=== ''%%\%%''xEA ===


<code>
<code>
Line 270: Line 299:
Not followed by read
Not followed by read


====== 2015-09-27 ======
= 2015-09-27 =


Project goal: understand how voltages/currents are read out
Project goal: understand how voltages/currents are read out


===== Phase 1: LA =====
== Phase 1: LA ==


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


    * Final setup
''' Final setup
      * [[https://twitter.com/johndmcmaster/status/648329962819182592|https://twitter.com/johndmcmaster/status/648329962819182592]]
'''* [[https:''twitter.com/johndmcmaster/status/648329962819182592|https:''twitter.com/johndmcmaster/status/648329962819182592]]
      * [[https://twitter.com/johndmcmaster/status/648348769746948097|https://twitter.com/johndmcmaster/status/648348769746948097]]
'''* [[https:''twitter.com/johndmcmaster/status/648348769746948097|https:''twitter.com/johndmcmaster/status/648348769746948097]]
    * Flaky: flying leads
''' Flaky: flying leads
      * [[https://twitter.com/johndmcmaster/status/648315944121425920|https://twitter.com/johndmcmaster/status/648315944121425920]]
'''* [[https:''twitter.com/johndmcmaster/status/648315944121425920|https:''twitter.com/johndmcmaster/status/648315944121425920]]
    * Complete failure: ribbon cable
''' Complete failure: ribbon cable
      * [[https://twitter.com/johndmcmaster/status/645354861383385088|https://twitter.com/johndmcmaster/status/645354861383385088]]
'''* [[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
Setup to trigger on J2.1.  Triggered during startup sequence reading serial number etc
Line 316: Line 345:
Above also shows that signals are at least in the 1-1.25 MHz range.  I'm currently sampling at 6.25 MS/s
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 =====
== 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.
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 ======
= 2015-09-29 =


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


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


Looks like bp1410_sn.py (bfb0464a) demonstrates the issue I was having:
Looks like bp1410_sn.py (bfb0464a) demonstrates the issue I was having:
Line 359: Line 388:
test file: la_sn.py (based on bp1410_sn.py)
test file: la_sn.py (based on bp1410_sn.py)


===== packet 147/148 =====
== packet 147/148 ==


{{:mcmaster:bpm:wwavusbepp:screenshot_from_2015-09-29_23_45_11.png}}
{{:mcmaster:bpm:wwavusbepp:screenshot_from_2015-09-29_23_45_11.png}}
Line 371: Line 400:
</code>
</code>


===== packet 157/158 =====
== packet 157/158 ==


Was not able to get any LA activity from this (CH0, 4 random channels):
Was not able to get any LA activity from this (CH0, 4 random channels):
Line 382: Line 411:
</code>
</code>


===== packet 149-154 =====
== packet 149-154 ==


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


===== packet 165/166 =====
== packet 165/166 ==


{{:mcmaster:bpm:wwavusbepp:screenshot_from_2015-09-29_23_56_17.png}}
{{:mcmaster:bpm:wwavusbepp:screenshot_from_2015-09-29_23_56_17.png}}
Line 400: Line 429:
Looks exactly like earlier but USB data is different
Looks exactly like earlier but USB data is different


===== packet 167/168 =====
== packet 167/168 ==


<code>
<code>
Line 411: Line 440:
No LA traffic observed.  The packet that gets lost
No LA traffic observed.  The packet that gets lost


===== S/N capture =====
== S/N capture ==


From win SW
From win SW
Line 421: Line 450:
My S/N: 34346
My S/N: 34346


    * 0x862a
''' 0x862a
    * 0b_1000_0110_0010_1010
''' 0b_1000_0110_0010_1010


This trace provides the first real insight:
This trace provides the first real insight:


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


===== Next steps =====
== 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
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 ======
= 2015-10-04 =


===== S/N extraction =====
== S/N extraction ==


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


    * 1 bytes: unknown
''' 1 bytes: unknown
      * <nowiki> \</nowiki>x08
'''* <nowiki> \</nowiki>x08
    * 4 bytes: bus transaction
''' 4 bytes: bus transaction
      * <nowiki> \</nowiki>x3A<nowiki>\</nowiki>x00<nowiki>\</nowiki>x90<nowiki>\</nowiki>x32
'''* <nowiki> \</nowiki>x3A<nowiki>\</nowiki>x00<nowiki>\</nowiki>x90<nowiki>\</nowiki>x32
    * 2 bytes: unknown
''' 2 bytes: unknown
      * <nowiki> \</nowiki>x00<nowiki>\</nowiki>x00
'''* <nowiki> \</nowiki>x00<nowiki>\</nowiki>x00
    * 8 bytes: bus transaction
''' 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
'''* <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
'''* Byte order: little endian
    * 2 bytes: unknown
''' 2 bytes: unknown
      * <nowiki> \</nowiki>x20<nowiki>\</nowiki>x00
'''* <nowiki> \</nowiki>x20<nowiki>\</nowiki>x00
    * 14 bytes: bus transaction
''' 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
'''* <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?
'''* Are the last 4 bytes actually part of this?
    * 4 bytes: unknown
''' 4 bytes: unknown
      * <nowiki> \</nowiki>xBF<nowiki>\</nowiki>x1D<nowiki>\</nowiki>x20<nowiki>\</nowiki>x00
'''* <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
Note: the USB trace is not the same trace as used on the LA
Line 527: Line 556:
</code>
</code>


====== 2015-10-06 ======
= 2015-10-06 =


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


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


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


    * LA traffic with bus activity
''' LA traffic with bus activity


bulkRead(0x86, 0x0200)
bulkRead(0x86, 0x0200)


    * Reads fx2 buffer.  No LA traffic
''' 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
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
Line 545: Line 574:
CH9:
CH9:


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


CH13:
CH13:


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


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


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


\\
\\

Revision as of 23:09, 7 May 2018

Background

At one point they sold an upgrade board to convert older programmers to USB. Basically what it boils down to is:

The adapter should work for BP-1400, BP-1600, BP-1700, and (some?) EPP series programmers You can swap it from one unit to another (ex: swap from BP-1410 to BP-1600 to upgrade an old unit) Units known to ship with this adapter * BP-1410 (probably BP-1610 and BP-1710 as well) * Silicon Sculptor 3 The adapter is no longer offered as an upgrade for the BP-1×00 models

http:www3.bpmicro.com/web/bphome.nsf/(web.news)/FB83F285AEE1E5BB862570670047820E

http:www3.bpmmicro.com/web/helpandsupport.nsf/69f301ee4e15195486256fcf0062c2eb/c4c2dac08101795c8625703e0062bde8/$FILE/Programmer Site USB 2.0 Adapter FAQ.doc

2.4 Mb/s to 9.0 Mb/s potential speed upgrade 14. What programming site models will this work with? * All EPP programmers. This encompasses 6th-gen and 7th-gen. * This may be a different adapter board 17. About how much will these adapters cost to make? * About $20 in materials 21. Why can’t I just buy an off-the-shelf USB-Parallel port adapter and use that? * There is no formal specification as to what you must do with these signals. Printer makers adhere to an informal standard as to what each of these signals does, but such functionality isn’t suitable for device programmers. * Even if the vendor-defined signals didn’t get in the way, the performance of any off-the-shelf adapter would be horrible (much worse than parallel port) 20. What are the Macola part numbers of the site adapter and the hub? * Site Adapter: WWAVUSBEPP * Hub: WWAVUSBHUB

https:www.febo.com/pipermail/time-nuts/2013-January/073818.html

>> All I have is an Actel Silicon Sculptor 3, also made by BP Micro,>> that looks like the BP-1710 (with the 'START' button) but connects>> via a USB port. On the main PCB of the BP-1600 and the SS3 are two,>> 2 row, 26 pin, connectors, one toward the back edge of the PCB toward>> the back panel and the other just inside the first connector. The>> inside connector directly connects to the parallel port on the back>> of the BP-1600. On the SS3, there is a small PCB that plugs into the>> same connector, takes a power input, and also has 6 pin connections>> to the other 26 pin connector. This small PCB has a USB connector>> that is> connected to the back of the SS3 as the USB connection.>>

Other:

It's part number is WWAVUSBEPP

From another doc:

> Automated Programming System users can determine if the handler is configured with the USB to EPP adapter through the PC Device Manager. If “BP Microsystems SPC Interface” is present as shown in the object below, then the USB to EPP adapter is already installed. If not, please contact BPM Microsystems Sales to order an upgrade kit part number: WHARUSBSPCKIT.

Programmer compatibility

Trying a 1600 with the adapter under 5.33.0 (last version to support parallel) worked fine. However, under 5.47.0 (newest release version as of today):

Bpm:usb newer.png

I analyzed the USB packet traces for kicks to see what was happening. There are some minor differences (ex: later software chunks firmware load up smaller) but otherwise they are identical in purpose. However, the newer software seems to just give up at one point. My guess is that they removed the 1600 handling code, not just the parallel interface to it.

PCB overview

Mcmaster:bpm:wwavusbepp:top.jpg?300Mcmaster:bpm:wwavusbepp:btm.jpg?300

Above:

ASSY No. WWAVUSBEPP EPCBD03181 Rev C

Bpm:wwavusbepp:bpm wwavusbepp.png

Where

Bpm:wwavusbepp:btm l.jpg?300

NOTE: a number of the component values above are best guesses. In particular:

R6/R7 divider Most small capacitors. T13/T17 are recommended values from cypress datasheet U3 is best guess

More info here: https:siliconpr0n.org/media/bpm/WWAVUSBEPP/

2015-04-24: tried plugging the adapter from my BP-1410 into my BP-1600 and it worked!

U1 (CY7C68013 FX2 MCU, TRM):

CY7C68013- 56LFC 0421 E 04 CYP 626381 KOR

U2 (?):

LT 515 176333

U3 (?):

U4 (8KB I2C EEPROM):

24C64W6 ST K414B

Pinout

Pin Dbg color MCU pin Function PU/PD
1 Black 30: CTL1/FLAGB
2 Black 29: CTL0/FLAGA
3 Brown 18: PB0/FD0
4 Brown 34: PA1/INT1# PU
5 Red 19: FB1/FD1
6 Red 38: PA5/FIFOADR1
7 Orange 20: FB2/FD2
8 Orange 31: CTL2/FLAGC
9 Yellow 21: PB3/FD3
10 Yellow N/A GND
11 Green 22: PB4/FD4
12 Green N/A GND
13 Blue 23: PB5:FD5
14 Blue N/A GND
15 Violet 24: PB6/FD6
16 Violet N/A GND
17 Black 25: PB7/FD7
18 N/C N/A GND
19 Brown 33: PA0/INT0# PU
20 N/C N/A GND
21 Red 1: RDY0/SLRD PU
22 N/C N/A GND
23 Orange 2: RDY1/SLWR
24 N/C N/A GND
25 Yellow 35: AP2/SLOE
26 N/C N/A GND

Resistor placed sub-optimially. is there another pullup?

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

USB protocol

As of 2015-10-04 I have PoC serial number readout working. If the script isn't started from cold boot it gets a different response, but usually works

Bulk EP 2

Transactions look like this

bulkWrite(0x02, cmd) reply = bulkRead(0x86, 0x0200)

Sample replies below

%%\%%x00

Repeatable. TODO: is this issued anywhere?

00000000 08 A4 06 02 00 |..... |

%%\%%x01

Repeatable. Code issues this and get 132-136 bytes back depending on where it is

00000000 08 80 A4 06 02 00 22 00 43 00 C0 03 00 08 F8 19 |......".C.......| 00000010 00 00 30 00 80 00 00 00 00 00 C0 00 00 00 09 00 |..0.............| 00000020 08 00 FF 00 E0 14 00 00 E8 14 00 00 84 1C 00 00 |................| 00000030 EC 14 00 00 D0 19 FF FF C0 19 FF FF 00 00 F0 3C |...............<| 00000040 FF FF 00 00 00 00 02 00 80 01 D0 01 02 00 01 00 |................| 00000050 00 00 56 10 00 00 88 1B 00 00 6C 1B 00 00 00 00 |..V.......l.....| 00000060 00 00 64 1B 00 00 66 1B 00 00 68 1B 00 00 44 1C |..d...f...h...D.| 00000070 00 00 70 1B 00 00 30 11 00 00 34 11 00 00 74 1B |..p...0...4...t.| 00000080 00 00 81 00 |.... |

validate_read("\x08\x84\xA4\x06\x02\x00\x26\x00\x43\x00\xC0\x03\x00\x08\x10\x24"

         "\x00\x00\x30\x00\x80\x00\x00\x00\x00\x00\xC0\x00\x00\x00\x09\x00"
         "\x08\x00\xFF\x00\xC4\x1E\x00\x00\xCC\x1E\x00\x00\xB4\x46\x00\x00"
         "\xD0\x1E\x00\x00\xC0\x1E\x01\x00\xB0\x1E\x01\x00\x00\x00\x30\x55"
         "\x01\x00\x00\x00\x00\x00\x02\x00\x80\x01\xD0\x01\x02\x00\x01\x00"
         "\x00\x00\x56\x10\x00\x00\xA0\x25\x00\x00\x84\x25\x00\x00\x00\x00"
         "\x01\x00\x7C\x25\x00\x00\x7E\x25\x00\x00\x80\x25\x00\x00\x74\x46"
         "\x00\x00\x38\x11\x00\x00\x3C\x11\x00\x00\x40\x11\x00\x00\x44\x11"
         "\x00\x00\xC0\x1E\x00\x00\x85\x00", buff, "packet 259/260")

%%\%%x02

Tried this to see what it would do. Caused unexpected responses to come back all the time and I had to power cycle the programmer

%%\%%x0E%%\%%x00

validate_read("\x08\x3A\x00\x90\x32\xA7\x02\x2A\x86\x01\x95\x3C\x36\x90\x00\x1F"

         "\x00\x01\x00\xD6\x05\x01\x00\x72\x24\x22\x39\x00\x00\x00\x00\x27"
         "\x1F\x20\x00", buff, "packet 263/264")

Above: serial number readout. This may be some sort of EEPROM/flash read. This packet is dissected in some more detail in the S/N section with some correlations to bus traffic.

%%\%%x11%%\%%x10%%\%%x00

Not followed by read

%%\%%x11%%\%%x4E%%\%%x00

Not followed by read

%%\%%x43...

  1. Generated from packet 213/214

bulkWrite(0x02, "\x43\x19\x00\x00\x00\x3B\x66\x1B\x00\x00\xFE\xFF\x3B\x64\x1B\x00"

         "\x00\xFE\xFF\x00")

validate_read("\x08\xA4\x06\x02\x00", buff, "packet 215/216")

%%\%%x43...

bulkWrite(0x02, "\x43\x19\x00\x00\x00\x11\xF0\xFF") big firmware load

%%\%%x5A

validate_read("\x08\x80\x01\x00", buff, "packet 235/236")

%%\%%x82

validate_read("\x08\x16\x01\x00", buff, "packet 255/256")

%%\%%xA6

validate_read("\x08\x81\x01\x00", buff, "packet 243/244")

%%\%%xDB

validate_read("\x08\x82\x01\x00", buff, "packet 251/252")

%%\%%xE8...

bulkWrite(0x02, "\xE8\x00\x00\x00\x00\xFA\x5A\x83\xEA\x05\x81\xEA\x00\x00\x01\x00"

         "\x81\xFA\x00\x00\x01\x00\x74\x1F\xBB\x00\x00\x00\x00\xB9\x00\x00"
         "\x01\x00\x66\x8B\x02\x66\x89\x83\x00\x00\x01\x00\x83\xC2\x02\x83"
         "\xC3\x02\x83\xE9\x02\x75\xEB\x8C\xC8\x50\xB8\xF0\xFF\x01\x00\x50"
         "\x0F\x20\xC0\x0D\x00\x00\x00\x60\x0F\x22\xC0\x0F\x09\xC3")

No read

%%\%%xEA

bulkWrite(0x02, "\xEA\xCC\x64\x01\x00\x08\x00\xFF\xFF\xFF\xFF\xFF\xFF\xFF\xFF\x3F")

Not followed by read

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/648348769746948097 Flaky: flying leads * https:twitter.com/johndmcmaster/status/648315944121425920 Complete failure: ribbon cable * 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:

Mcmaster:bpm:wwavusbepp:screenshot from 2015-09-27 21 43 18.png

Above: 1-8 at startup

Mcmaster:bpm:wwavusbepp:screenshot from 2015-09-27 21 52 05.png

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

Mcmaster:bpm:wwavusbepp:screenshot from 2015-09-27 21 55 51.png

Above: after hitting okay that's in unsupported mode

Mcmaster:bpm:wwavusbepp:screenshot from 2015-09-27 22 01 07.png

Above: software started but idle

Mcmaster:bpm:wwavusbepp:screenshot from 2015-09-27 22 03 26.png

Mcmaster:bpm:wwavusbepp:winxp not virus 2015-09-27 22 04 53.png

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:

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]

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

Mcmaster:bpm:wwavusbepp:screenshot from 2015-09-29 23 45 11.png

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

  1. Generated from packet 147/148

buff = controlRead(0xC0, 0xB0, 0x0000, 0x0000, 4096) validate_read("\x00\x00\x00", buff, "packet 147/148")

packet 157/158

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

  1. Generated from packet 157/158

buff = bulkRead(0x86, 0x0200)

  1. NOTE:: req max 512 but got 4

validate_read("\x08\x16\x01\x00", buff, "packet 148.5")

packet 149-154

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

packet 165/166

Mcmaster:bpm:wwavusbepp:screenshot from 2015-09-29 23 56 17.png

  1. Generated from packet 165/166

buff = controlRead(0xC0, 0xB0, 0x0000, 0x0000, 4096) print 'val 165: %s' % binascii.hexlify(buff)

  1. NOTE:: req max 4096 but got 3

validate_read("\x00\x00\x00", buff, "packet 165/166")

Looks exactly like earlier but USB data is different

packet 167/168

  1. Generated from packet 167/168

buff = bulkRead(0x86, 0x0200, timeout=500)

  1. NOTE:: req max 512 but got 4

validate_read("\x08\x16\x01\x00", buff, "packet 167/168")

No LA traffic observed. The packet that gets lost

S/N capture

From win SW

Mcmaster:bpm:wwavusbepp:screenshot from 2015-09-30 00 11 32.png

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

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

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

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

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

S/N details:

  1. Generated from packet 181/182

dev.bulkWrite(0x02, "\x0E\x00")

  1. Generated from packet 183/184

buff = dev.bulkRead(0x86, 0x0200)

  1. 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

2015-10-06

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

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

bulkWrite(0x02, "\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?

\\