Opps, JTAG_BUF_EN. It toggles the JTAG programming pins outputs or high impedance. I think the goal is to take the programmer completely out the circuit (Hi-Z) when not in use.
I wonder if, overall, it would be cheaper to use jumpers and logic chips with the 44pin CPLD instead of the 100pin one.[/quote]
Thanks for the explaining :)
I think I myself will go with the 100 pin CPLD. I don't think the benefit is that much (for me) and this way I have the bigger CPLD - which I like :) Also using logic chips would mean that there are even more chips on the board which I have to route and to solder. And using more jumpers would cause me to have I don't know as much as maybe 5 jumpers? That would obfuscate the board a lot I think...
Yah I think a bigger CPLD is the way to go if you want to support all of it.
The CPLD could then be a XC2C64A with 100 pins for example. It's a little bit more expensive but (for me) that's ok I think.
Also you could then break out all unused pins of the CPLD so they can be used for other modifications which I can't think of now ^^. Maybe some of them for controlling internals of the CPLD?
I think I will put some work in a modified layout the next days but I can't promise it.
Nils
PS: Just to get it right: Why does the jtag reset pin has to have a buffer enable? Is the state undefined while it is not active? Why can't it simply connected?
there is SWD and part of it is SWV (serial wire viewer).
The SWD consists of only 2 connections, SWDIO and SWDCLK. These are the pins used for the JTAG like debugging. But you can enable the SWV pin which gives you a plain output stream of very nice data - look at the ARM CoreSight architecture to learn more about it.
For example: It gives you the ability to view system and memory states in realtime (on some processors) because it can be clocked at up to 100MHz. Also it gives you the ability to trace your program execution for profiling the application running on the microcontroller.
The SWO (serial wire out, also named SWV) has two operation modes which I now of: The realtime 100MHz tracing mode and also a USART style mode which operates on 1MBit/s and seems to give you the data in a RS232 manner so you can read it in with a UART -> USB converter for example.
There is already a little code snippet laying around somewhere in the OpenOCD list which could connect on such a UART port on linux and read the data and perform some operations to convert it into a GProf readable file.
The SWD support is currently beeing implemented in OpenOCD and will (hopefully) be ready in version 0.5.0. The first device having drivers for it is the freely available Versaloon.
Also there is the LibSWD (http://sourceforge.net/apps/trac/libswd) which seems to be the SWD library which is beeing developed for usage in OpenOCD. On the main page of the project (see link) there is also a link to the stm32primer2swd project wiki which states the KT-Link as SWD kompatible.
To say the truth I don't know really much about the SWD thing. But I wanted to take every chance to support it because of the profiling thing. So I did include the UART so one can use OpenOCD to activate it and another software to read the SWV output on the second UART channel of the FT2232H.
Just a thought: Maybe you want to also think about connection the FT2232H BDBUS1 (UART RX) to a free pin of the CPLD - it's imo the only thing needed to build the KT-Link interface into the CPLD (KT-Link: http://www.shop.kristech.eu/product_inf ... anguage=EN, user manual with interface diagram on site 6: http://www.shop.kristech.eu/download/KT-LINK-UM-ENG.pdf). The KT-Link is prepared for the use of the SWD protocol (UART style - so it needs the UART RX) and since this protocol is currently beeing build into OpenOCD I think there will be a lot of people who will use it :).
Yah I know the thing with the clearance. I'm currently into some sort of "it has to be small, it has to be small" thinking because I spent to much time in the lower zoom factors of KiCad ;). I lost the feeling for the real size so I'm really impressed by the small size everytime I see a printing on paper ^^.
Thanks for the advice. I will look into this and clean it up :).
By the way why don't you run traces between the pads of a SMD passive? I've done this a few times with 1206 parts and never had a problem on boards which I etched by myself. But maybe it was luck - I'm just doing hardware stuff for 4 or 5 months now ^^.
I've done a new version of schematics and pcb. The pcb again is quick&dirty.
My changes are: I wanted to support the hopefully-soon-coming SWD support in OpenOCD. Especialy I'm interested in the SWO/SWV feature of the STM32. There is one SWO mode in which the output is in UART style - so I connected the BBUS RX pin to the CPLD. Also I wanted to have support for a 10-Pin JTAG connector I use in some of my boards - it has all signals + UART RX/TX so I needed a UART port here, too.
All these things are going through buffers so I can enable/disable them by jumpers. Also I have connected all CPLD JTAG pins to buffers - if I disable it there is absolutely no connection between the CPLD and the FT2232 BBUS. It's more a thing of "I think this may be safer..." than of real need :).
The target_present circuit had to go because there were a pin on the CPLD that was not really needed...
I chose the 74AC125SC buffer because it is cheap (~0,22 Euro @ 100) and it has an enable pin for each of the four channels separatly which enables me to use it in both directions with different enable/disable signals.
I think I will soon buy a PCB of this version - then I'll report :).
So my idea was: Why not create a small board which interfaces a single SDRAM chip from a CPLD and gives the MCU the possibility to interface it like any SRAM. First parallel but maybe also via SPI or so.
The CPLD they used for the interface to the mobile SDRAM was a XC2C128 with 128 mcells and 144 pins (VFQ144 package) (102 macrocells and 86 pins used). This chip costs about 8Euro @ 1.
For the DDR SDRAM interface they even only used 60 macrocells and 78 pins...
I would like to see your suggestions to this. I don't know if I will try to develop this board some time but maybe there are others who are also interested in this :). Maybe it will push my motivation ;).
When not powered from the target side, the CPLD leaks 0.6volts, which is enough to half-light the LED. The TARGET_DETECT part is just useless, so I stripped it from the v2.a1 PCB. Check out also the TI reference design we based the BBv2 on - they have a different circuit, though I don't think it will work for the way I typically use JTAG debuggers (single patch wires). [/quote]
Hey Ian,
that sounds interesting. I will look into this. When I have a new design I will post it here. Hopefully I will be able to test it on a PCB in the near future .
[quote author="ian"] Also, I think only TDO (CPLD->FT2232H) and CLK (FT2232->CPLD) need to be buffered to use all of port B. I think if these are disabled between the FT2232 and CPLD then all the other CPLD pins are hi-z (maybe pullup) and shouldn't cause issues to the normal JTAG B use. [/quote]
That's a good hint, I wasn't shure about this. Although I'm still thinking about just using some jumpers instead of a buffer.
[quote author="ian"] Nice work getting all the pins to headers. [/quote]
Thank you
[quote author="ian"] It looks like it has a lot of elements of our design, even the exact same (broken) TARGET_PRESENT circuit [/quote]
Hehe, typical moment of "I KNEW I should've done it by myself and don't just copy it" . Thanks for the hint. Yeah to say it clearly, all stuff on the right side was more or less copied from your design and then modified - regarding the target_present circuit, I wasn't shure if I want to have it or not. But it in the end LEDs are great .
Since I don't know much about CPLDs I wanted to use a design which should work for the CPLD part.
The rest is the FT2232H connection described in the datasheet.
[quote author="ian"] Be sure the connections are correct, and check out our patched urJTAG, nothing else currently programs on JTAG B as far as I know.
Also, I'm going to split this thread into a new topic after posting this, it doesn't belong here [/quote]
I was developing my own version of a JTAG programmer with the FT2232H as I saw this project here.
I liked the Idea with the CPLD very much and I'd love to play with CPLD's or FPGA's so I decided to adopt this idea.
I didn't want to wait for this project not because I need it fast but because I wanted to have a JTAG programmer which also breaks out the B-BUS of the FT2232H so I could do other things with it than only JTAG at a time.
Well, now I wanted to share my somewhat forked design with you .
It did get a little bit crazy: I have the FT2232H and a XC2C64A (I want to play with it, so this is the slightly bigger version ^^). The CPLD is used as a buffer for the JTAG channel A of the FT2232H (support for a wide range of voltages ). It can be programmed via the JTAG channel B.
The connection JTAG channel B -> CPLD JTAG can be interrupted - there is a buffer in the middle which can be disabled by removing a jumper - so the full channel B can be used otherwise.
I like the overall setup because this now is somewhat of a USB -> Dual Serial Communication + FT2232H breakout board + XC2C64A breakout board + XC2C64A small development board ^^. You could even cut the pcb in two halfs and each one would work as a breakout board on its own ^^.
I attached the schematics and a quick&dirty version of the PCB (100mmx46mm in size). The design is done with KiCad. If anyone is interested in the design files I can post them here.
Also it is completly untested PCB's are expensive so I have to wait for some other PCB's before I can send them to the manufacturer. Sadly I'm completly unsure about the buffer - I have no idea if it will work this way - I think it will but I know me I'm thinking about replacing it with four simple jumpers - then it will work .
I bought it from Watterott Electronics in germany but the have a great customer support so this won't be a problem .
Sure you can use it, I will also look if I can take a better picture but this could take a few days till I can use a real camera and not just my phone - I will then post the new picture here, Hopefully it will be better visible then .
I love this small tool it made my live already a lot easier .
thank you a lot for your help. I think I found the problem.
I just started to look more precisely at the hardware and started to measure some copper wires when I saw:
When you look at the OLS with the probe connectors right and the USB connector left then there seems to be a big copper blot right above the middle of the 50MHz oscillator connecting two of the five traces goind to the fpga (the lower ones).
I tried to make a picture of it but it didn't get very good quality.
I guess that these two traces are somewhat nessecary for the new firmware?
So I will return it for a replacement - no chance to repair this one...
.
. Thanks for the hint.