| Electronics > Projects, Designs, and Technical Stuff |
| Sencore USB Interface Project |
| << < (6/6) |
| coromonadalix:
for the ft2232, i use at my job a kanda atf1504 programmer .. around 50$ usd ??? it is an ft2232d inside |
| pigrew:
I finally have a PCB that doesn't fry itself when plugged in. :) Unfortunately I had to make a few modifications to the board due to my swapping pins and grounding things when making the schematic. Adding a bunch of 0402 pull-down resistors works, but isn't too fun. At least now I can make blinking LEDs from the FPGA and get the micro to connect to a USB host (even in DFU mode). The micro can be programmed via USB or JTAG... whichever. The FPGA still needs a JTAG programmer. If I used a larger isolator and had pins to spare, I could have programmed it from the micro over SPI... (CS, data_in, data_out, clock, interrupt?) Speaking of USB, I really dig the red color of the selected USB port, but not so much the high retention. I feel like I'm going to rip the board apart when plugging in a USB cable. I got distracted by writing a USB driver for the STM32F0. The one ST provides uses a bit too much RAM and is just generally too bulky for such a small micro. I've been working on porting TinyUSB to it, though are were a few other choices, such as libopencm3 and Keil. |
| pigrew:
Argh, signal integrity! The USB interface is now mostly working, which is great. However, I'm getting errors when transmitting certain commands, and I believe it is due to signal integrity issues.The modern driver ICs have much too high of a drive strength, creating fast edges, inducing large amounts of crosstalk. The interface uses one unidirectional nPROG line and a bidirectional 4-bit bus. I assembled a 50cm long shielded cable, and when probing nPROG (~4cm probe wires to a 1.5 GHz active probe), see nPROG bouncing about 1.9 V when my driver outputs to the 4-bit bus. This crosstalk is sometimes causing the FPGA to trigger a second time on the nPROG line (it's edge triggered). The bus driver outputs to the bus a few internal clock cycles after the falling edge of the clock (in order to decrease the chance of bus contention) which causes the observed jitter. At the moment, earth is isolated from circuit common on my interface board. Common is connected to earth inside the Sencore chassis by ~10kohm. Perhaps I'll end up putting a small cap (47pF?) from the shield to common, and connect the shield continuously to the USB shield. Since everything is so slow (data access time is supposed to be <750 ns), I think the solution is to just increase the series resistance on the 4-bit bus. I'm presently using 33 ohm, but will boost it to 220 ohm or so. Guestimating 150 pF of load capacitance, this will give a 76 ns rise time (plenty fast). I really like Okawa's RC calculator page for computations like this. On the USBTMC front, I got my most of my USB class driver changes merged into the TinyUSB project, so I'm communicating over USBTMC and not CDC, which is pretty nice. (I just ordered a rough looking HP 432A power meter from eBay, I think I'll retrofit a USB SCPI interface into it, and maybe a digital display). FOLLOWUP: It was inductive coupling (not capacitive like I had guessed). My circuit was driving the bus too soon and there was contention on the bus for about 300 ns, creating pretty severe current spikes (hopefully made less damaging by the 33 ohm resistors I had). I was driving the bus 125 ns after the clock edge, but the MCU goes tri-state after about 600ns. Replacing the resistors with 300 ohm and also delaying driving the bus ~700ns after the clock edge helps, and sending commands is more reliable. However, it may not be data-sheet compliant for the bus because the access time is supposed to be <650ns. With the required timing, bus contention seems guaranteed. |
| Navigation |
| Message Index |
| Previous page |