Skip to content

Latest commit

 

History

History
295 lines (246 loc) · 23.1 KB

0026-2020-06-06.md

File metadata and controls

295 lines (246 loc) · 23.1 KB

6 Jun 2020

I'm going to test out my Dangerous Prototypes XC9572XL board before I try assembling my own board.

  • I'm installing the 15GB Xilinx ISE Webpack 14.7 VM version on Windows 10 (Home?) 64-bit. It normally installs its own copy of VirtualBox but instead it detects the VirtualBox I already have and offers to just add to that (with a warning about being untested on my version).
  • It takes a long time at the "Import ISE Virtual Appliance" step. It's an ova file.
  • I've dug out my DP XC9572XL board and Bus Blaster v2.0a1.
  • I downloaded CPLD.Breakout.Package.v1.0.zip. It's a ZIP of this GitHub tree. I don't know whether I'll actually need it, but it includes:

Initial test of the DP XC9572XL breakout board

Bus Pirate first

  • Get to know my Bus Pirate v3.5 again: I'll use it as my power supply.
  • Plug in Bus Pirate via USB. PWR led comes on. Windows recognises it as COM13 for me. Windows offers "Advanced" settings for the device, allowing the COM port number to be changed, if needed.
  • Configure PuTTY to use Serial mode to COM13 at 115200 bps. PuTTY has advanced settings in Connection > Serial: Ensure 8/N/1 and Flow control should be set to None.
  • Start the connection and hit ENTER, and hopefully the HiZ> prompt will appear. ? command can be used to see available options.
  • i command shows version info: 
    HiZ>i
Bus Pirate v3.5
Firmware v6.1 r1676  Bootloader v4.4
DEVID:0x0447 REVID:0x3043 (24FJ64GA002 B5)
http://dangerousprototypes.com
  • Not sure what version is documented here but my version lacks some bus modes inc. JTAG. This is what I get from the m command: 
    HiZ>m
1. HiZ
2. 1-WIRE
3. UART
4. I2C
5. SPI
6. 2WIRE
7. 3WIRE
8. LCD
x. exit(without change)
  • Either my version is old, or my version is newer (and the extra modes were removed for other reasons). There's some info here (under "Old legacy stuff") that talks about my firmware v6.1 being official, but old. That page also explains that the BusPirate/Bus_Pirate repo on GitHub is where you can get the best new firmware, with discussion here about its release. More info about v6.1 and JTAG here and it effectively explains this old version of the firmware does not include terminal-mode JTAG but it can be used in a binary mode via OpenOCD (at least I think that's what it means).
  • Check pin states with v command: 
    Pinstates:
1.(BR)  2.(RD)  3.(OR)  4.(YW)  5.(GN)  6.(BL)  7.(PU)  8.(GR)  9.(WT)  0.(Blk)
GND     3.3V    5.0V    ADC     VPU     AUX     CLK     MOSI    CS      MISO
P       P       P       I       I       I       I       I       I       I
GND     0.00V   0.00V   0.00V   0.00V   L       L       L       L       L
    I think this can be read as follows, after the Pinstates: line:
    1. 1st line identifies pin number and colour when using the supplied probes (hooks on IDC ribbon).
    2. Pin name.
    3. Pin function (P = Power; I = Input?)
    4. Current level. 0.00V indicates that power supplies are off.
  • There is a W command to turn PSUs on, and w to turn them off, but these commands don't work in HiZ mode.
  • Per this, PSUs can only be enabled if not in HiZ mode, and PSUs (3.3V, and 5V) can supply 150mA each.
  • I tested with my DMM: in the initial HiZ mode, the +5V pin is not powered.
  • By doing m2 or m8 we can go to a mode that requires no other choices to be made, and the MODE LED will turn on.
  • Doing W now should turn on the VREG LED, show about 5V on the DMM, and v should show about 3.3V on pin 2 and about 5V on pin 3: 
    LCD>v
Pinstates:
1.(BR)  2.(RD)  3.(OR)  4.(YW)  5.(GN)  6.(BL)  7.(PU)  8.(GR)  9.(WT)  0.(Blk)
GND     3.3V    5.0V    ADC     VPU     AUX     SCL     SDA     -       -
P       P       P       I       I       I       O       O       O       I
GND     3.29V   5.16V   0.00V   0.00V   L       L       L       L       L
  • Go back to m1 to turn off PSU and return to safe HiZ state.
  • Attach proper hooks/probes loom to BP, attach GND and 5V hooks to DMM, and test with m2 followed by W to make sure the hooks have their PSU lines working properly.
  • Turn off PSUs with w, then attach GND and 5V hooks to GND

Hooking up the BP to the XC95 board

  1. Make sure BP is in HiZ mode with m1.
  2. Plug in BP hooks/probes, and attach to XC95 board: GND hook to GND on XC95, and 5V hook to V+ on XC95.
  3. Attach DMM to XC95's JTAG header: GND and VTG. This will be for testing the XC95's 3.3V supply.
  4. Put a jumper across the XC95's 3V3 / IO header pins. This selects the main 3.3V supply as the VCCIO voltage.
  5. Go to mode m2 and do W command.
  6. DMM should show about 3.3V, and XC95 board should have PWR LED lit, at minimum.
  7. With default firmware, XC95's D1 should be lit.
  8. Press the pushbutton on the XC95, and while pressed, D2 should be lit and D1 will turn off.
  9. This verifies that the default firmware is working.
  10. Go to mode m1 again to turn everything off.
  11. VERY IMPORTANT FOR NEXT TEST: Disconnect 5V hook.
  12. Attach 3.3V hook to the XC95's 3V3.
  13. Go back to mode m2 and do W again.
  14. Test in points 6..9 should work again. NOTE: I've observed that the DMM shows VTG to be a little flat: A hair under 3.2V. This is probably the BP supply's fault.
  15. Go to mode m1 again to turn everything off.
  16. Move the 3.3V hook's connection to the XC95's VTG pin. Probably need to disconnect the DMM.
  17. Go back to mode m2 and do W again.
  18. Test in points 6..9 should work again: This should show that the JTAG VTG pin is in fact wired up to the same net as the 3V3 pin.
  19. Go to mode m1 again to turn everything off.
  20. It should also be possible to power V+ using the 5V hook and take the VIO jumper off and instead power the IO pin using the 3.3V hook... but I'm not going to take a risk there and muck around with that if I don't need to :)

IMPORTANT: Don't ever power the XC95's V+ and 3V3 (or VTG) lines at the same time. That would mean two different power supplies, and possibly contention, and might lead to damage.

"Burning" the XC9572XL

Bus Blaster and UrJTAG trouble with XC9572XL specifically

  • DP Bus Blaster method of programming using UrJTAG reportedly doesn't work properly with XC9572XL due to a UrJTAG bug related to timing.
  • Instead of using Bus Blaster, loading the Bus Pirate with the XSVF player firmware is recommended instead.
  • Some specific mention of the issue here. Supporting findings here.
  • See an alternative way of programming XC9572XL using Bus Blaster using xc3sprog. This might require a Linux VM with USB pass-through for the Bus Blaster. NOTE, however, that this utility uses JEDEC (.jed) files instead of (X)SVF...? It's further mentioned here but not sure how relevant it is.
  • Programming with Xilinx ISE is apparently another alternative, but could be complicated without the right hardware/cable.
  • Someone did a write-up of the problems they were having with all this in Jan 2019. Might be helpful to follow along. Since Jan 2019, there has been a (major?) new version of UrJTAG (going from 2018.09 to 2019.12)... maybe it has a fix?

Trying out Bus Pirate with the XSVF player

This page describes the overall concept and process.

NOTE: I've got BP firmware 4.4, which is good because v4+ firmware makes a few things easier.

  1. Download BPv3.XSVFplayer.v1.1.zip (referenced on this page).
  2. Plug in the Bus Pirate v3.5, and make sure its hooks are not attached to anything.
  3. Take note of the BP serial port (COM13 in my case).
  4. Connect to the BP serial port and make sure you're in HiZ mode; issue command m1 if necessary.
  5. Trigger the bootloader by issuing the command: $
  6. Close the serial connection.
  7. Extract BPv3.XSVFplayer.v1.1.zip
  8. Run BusPirate-firmware\ds30 Loader GUI.exe
  9. Make sure your COM port is selected.
  10. For Hex-file, locate bpv3-xsvf-vb.hex
  11. Click the Download button. Don't try to interact with the app while it's writing the flash: I found it interrupted it and caused an error. I was able to retry the Download button, though, and it succeeded: 
    Initiating download...
    Searching for bl . 
    Found PIC24FJ64GA002 fw ver. 1.0.2
    Waiting for bootloader to be ready...ok
    Writing flash...ok
    Download finished
    Tx 65.2kB / Rx 382 bytes / 12.3s
  12. Exit the ds30 Loader GUI and unplug the BP's USB.
  13. Plug the BP back in.
  14. With this firmware, the 5V and 3.3V PSUs should be on by default. Verified with DMM.
  15. Unplug BP again.
  16. Connect BP to XC95 JTAG header per this, plus 3.3V hook connected to VTG.
  17. Plug in the BP and verify the XC95 still works (i.e. pushbutton toggling LEDs).

NOTE: To put back the original 6.1 firmware:

  1. Download BusPirate.package.v6.1.zip (referenced on this page).
  2. It might be necessary to start the BP in bootloader mode by using the jumper trigger method, but I'm not sure.

Now to try programming the XC95...

From command-line, within the extracted BPv3.XSVFplayer.v1.1 directory, run:

BPXSVFplayer.exe -p COM13 -s 115200 -f xc95prog.xsvf

The first time I tried, I got this error:

D:\FPGA\BPv3.XSVFplayer.v1.1>BPXSVFplayer.exe -p COM13 -f xc95prog.xsvf
-----------------------------------------------------------------------------

 BusPirate XSVF Player V.01
 http://www.dangerousprototypes.com

-----------------------------------------------------------------------------
File is 53289 bytes, read 53289 bytes Opening Bus Pirate on COM13 at 115200bps, using XSVF file xc95prog.xsvf
 Entering XSVF Player Mode
 Waiting for first data request...ok
Sending 4096 Bytes (1000)...ok
End of operation reply 03
  Device did not respond: XSVF_ERROR_MAXRETRIES
 Thank you for Playing! :-)

This error shouldn't happen. I was using the BP hooks, and it was a mess, so I unplugged the BP from USB, and tried switching to Dupont wires. The first time I tried after plugging back in, it hung here:

File is 53289 bytes, read 53289 bytes Opening Bus Pirate on COM13 at 115200bps, using XSVF file xc95prog.xsvf
 Entering XSVF Player Mode
 Waiting for first data request... waiting for reply...

I unplugged the USB again, applied pressure to the Dupont wires, plugged the USB back in, and ran again, and this time it worked:

D:\FPGA\BPv3.XSVFplayer.v1.1>BPXSVFplayer.exe -p COM13 -f xc95prog.xsvf
-----------------------------------------------------------------------------

 BusPirate XSVF Player V.01
 http://www.dangerousprototypes.com

-----------------------------------------------------------------------------
File is 53289 bytes, read 53289 bytes Opening Bus Pirate on COM13 at 115200bps, using XSVF file xc95prog.xsvf
 Entering XSVF Player Mode
 Waiting for first data request...ok
Sending 4096 Bytes (1000)...ok
Sending 4096 Bytes (2000)...ok
Sending 4096 Bytes (3000)...ok
Sending 4096 Bytes (4000)...ok
Sending 4096 Bytes (5000)...ok
Sending 4096 Bytes (6000)...ok
Sending 4096 Bytes (7000)...ok
Sending 4096 Bytes (8000)...ok
Sending 4096 Bytes (9000)...ok
Sending 4096 Bytes (A000)...ok
Sending 4096 Bytes (B000)...ok
Sending 4096 Bytes (C000)...ok
Sending 4096 Bytes (D000)...ok
Sending 41 Bytes (D029)...ok
End of operation reply 00
  Success!
 Thank you for Playing! :-)

NOTE: During programming, the D1 and D2 LEDs go dim. I'm not sure why: I thought they would go Hi-Z.

After this, the button toggling worked again.

I then downloaded, programmed, and tested each of these in turn (all from here), verifying that they indeed worked as expected:

The final one ends up being the same as the demo that comes pre-loaded.

Other notes:

These are mostly outdated now. Could still try the "Pirate-Loader" console app and "Parallel cable and ISE", but the rest I'm not sure about...

  • Originally I was planning to use "Pirate-Loader", because I wasn't sure if I could find a reliable source for the "ds30 Loader GUI", but it turns out it is in BPv3.XSVFplayer.v1.1.zip.
  • This ("JTAG cables") says to use "Parallel cable and ISE" or "FT2232 JTAG". Not sure whether either of these means USB Blaster or DP Bus Blaster.
  • This ("Loaders") says that (X)SVF files contain the CPLD configuration and it can be "played" via JTAG cable, with suggestions to use either:
    • UrJTAG - load SVF with a number of programmers, including common FT2232 programmers
    • OpenOCD - detects FPGA/CPLDs, but doesn't do much with them.
  • There are evidently two different versions of BPXSVFPlayer which report as "BusPirate XSVF Player V.01": 
    D:\FPGA\BPv3.XSVFplayer.v1.1>BPXSVFplayerV01a.exe -p COM13 -x
-----------------------------------------------------------------------------

 BusPirate XSVF Player V.01
 http://www.dangerousprototypes.com

-----------------------------------------------------------------------------
 Performing Chain Scan..
 Waiting for a chain scan reply
 Chain Scan Result: 04 93 40 60 59
    The JTAG IDCODE value here is (I think) 0x59604093. Xilinx information about this code can be found here, and while it's a little screwed up, the xc9500xl.zip BSDL file from Xilinx contains xc9572xl_vq44.bsd which contains this information: 
    attribute IDCODE_REGISTER of xc9572xl_vq44: entity is
        "XXXX" &               -- version
        "1001011000000100" &    -- part number
        "00001001001" &         -- manufacturer's id
        "1";                    -- required by standard
    ...so our value of 0x59604093, in this format, comprises:
    Bits Field
    0101 Version (i.e. 5; stepping 5?)
    1001011000000100 Part number (0x9604), but made up of 1001011 (family code; 0x4B or 75) and 000000100 (part size)
    00001001001 MFR ID (0x49 or 73); identifies Xilinx in the JEDEC list (see also here)
    1 Required by standard

Notes

These notes are half-baked:

  • Try out JTAG: Can we talk to the chip?
  • Use BP to get to know how to control various modules, inc. via various serial protocols, and then make sure we can make the XC95 do the same: A good test to verify that the devices work before trying to prove we can do Verilog properly. Will help weed out programming mistakes, hardware faults, and general mishaps. BP will come in handy later when trying to do tests of my CPLD code/circuits.
  • This says "5volts max" for V+. I'm sure it would take more, but don't push it. It's pretty tiny!
  • SVF is the standard format. XSVF is Xilinx' own compressed format. See also: http://dangerousprototypes.com/docs/JTAG_SVF_to_XSVF_file_converter

Improvements for my next XC9572XL board

  • Check the footprints of all components I actually intend to solder on.
  • My screw holes are tiny. Diameter needs to be at least doubled to fit a standard PC screw (which fit my stand-offs), and head clearance needs to be WAY more.
  • Better form factor to suit other devices it might plug into?
  • Thinner PCB?
  • Smaller boards, or put more on them?
  • Footprints for different XC9500 chips. This could be tricky: XC9572XL's 64-pin pitch is 0.5mm, while 44-pin (?) version has a larger pitch.
  • JTAG pins on the edge: Make into a nice 90° header?
  • Larger pad for LDO.
  • Beware thermal relief design: Pads need straight leads out to avoid tombstoning.
  • Better capacitor placement.