This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

TMS320F28P650SK: XDS100v2 Reference Design Questions

Part Number: TMS320F28P650SK

Tool/software:

We are trying to design a simple JTAG debugger board for our P650 MCU based on the XDS100v2 reference design as that is what is available. We are not dead set on the XDS100v2 design, but we have to do a lot of PC app development and figure the FTDI chip will allow us to get up and running very quickly.

Our connection to our MCU only has the JTCLK, JTMS, JTDI, and JTDO pins and nothing else. We will just be putting the FT2232 onto the board and not the CPLD. However, ideally we would like to use PORTA of the FTDI chip for both JTAG & UART (multiplexed) and PORTB for SPI. We can put buffers and switches onto the board controlled by PORTB to perform the multiplexing. The idea is that at time x, CCS will be able to use the JTAG on port A and at time b, our custom program configures and uses the UART of PORTA.

After reviewing the XDS100v2 reference design, I have a few questions.

  1. The FT2232 boots up in UART mode and sets the RTS pin as an output. It looks to me that the CPLD connects this pin also to an output. Won't this cause bus contention upon POR or is there some OE pin being manipulated to the CPLD via the GPIOL/H pins also on PORTA? The CPLD code is very simple and I could not find where any OE was being used within the code on that pin. I did look into the cool runner 2 data sheet and found it has global output enable pins to tristate its outputs, but again it looked like none of these pins were connected or manipulated by GPIOL/H.
  2. If we are only intending to hook up the 4 JTAG pins to our DSP, what other input pins must be manipulated on GPIOL/H for the connection to work correctly?

The FT2232 pins will ultimately go to digital isolators but we can add buffers or logic in between. In the end, I cannot see a way given the initial FT2232 pin states on POR and the connection to the CPLD how we can avoid bus contention also if we want to add analog switches to multiplex the PORTA JTAG & UART connection.

I talked to our hardware engineer and proposed we could add high valued series resistors (~800 Ohm) to the pins. We will only be operating PORTA at 1MHz. All the pins on the FT2232 and destination ICs will be Schmitt triggered and the traces will be extremely short. If we do the rise and fall time calculations, I think we can easily support 1MHz with the resistors.. after it looks like 1MHz I2C can use ~800 Ohm pullups. The resistors will defeat the bus contention and miss configuration of all the pins at different times due to them being both inputs & outputs by keeping all of the I/O pin currents on the ICs into their recommended ranges.

  • Hi Colton,

    Thanks for using our E2E forums. The XDS100v2 is an older design so I'm still searching to see who the best expert is to help assist you with this

    Regards,

    Peter

  • Thanks Peter

    Further investigation:

    I have access to an Olimex XDS100v3, which uses the FT2232 and I believe the same pinout. I probed some of the signals such as OE (pin 28 of FT2232) to see what it was doing. If we assume that OE is what it says it is, OE is being activated during the JTAG communication, presumably to gate the CPLD outputs only when needed. If that is the case, it is good news and we could use it.

    I found this thread: https://e2e.ti.com/support/tools/code-composer-studio-group/ccs/f/code-composer-studio-forum/752078/ccs-am5726-implementation-of-xds100v2-on-custom-board

    Pin 28 is explicitly called out here as OE.

  • Hi Colton,

    Let me consult my colleague on this design. I'll provide a reply by the end of the day.

    Best,

    Matt

  • Colton,

    I would not recommend designing in an XDS100.  Instead I would recommend using an XDS110.  The design files for the F28P650 LaunchPad are available on Ti.com and can be used as a reference.

    https://www.ti.com/tool/LAUNCHXL-F28P65X

    Regards,

    John

  • The XDS110 uses the MSP432, which is a much larger pin count compared to FTDI. I am also not sure if that lends itself to an easy design path. How do we initially program the MSP432 and what firmware to use?

    Our design requires several ports: JTAG, UART, and SPI, and GPIO. It does not look like we can achieve SPI & GPIO with the XDS110 design. As it stands, we are already having to add a second USB device and a USB HUB IC to get the other ports. I am also going to assume the USB device descriptors have to be branded with magic TI strings in order for it to work.

    What would be really nice is if the USB JTAG communication spec could be published or a new generic USB / serial driver could be used with CCS. That would allow people to design debuggers using whatever chips they want, exactly to their use case without having to be limited by the basic ports provided by the TI designs.

  • The bootloader and firmware images are included with CCS.  <install dir>/ccs_base/common/uscif/xds110. There is also a readme in there with some instructions for programming the firmware.

    I will need to send this back to the C2000 team for hardware questions.

    Note that the XDS100 while simple is very obsolete.  The performance can be very poor.

    Regards,

    John

  • Hi Colton, 

    Can you help provide a little more information about the intended application or end equipment you're building is? Do you really need to have the option to debug through multiple different communication protocols with our XDS110 debugger or is this more related to enabling communication through the on-chip C2000 communication protocols and perhaps you could use some other bridge device in case that communication needs to be translated to a different protocol

    Regards,

    Peter

  • We are trying to create a board that has multiple capabilities, not just debug. CCS will be able to connect to the board through the JTAG so that we can debug the device. In addition to JTAG debugging, we have several serial ports that are used for communication in the end application. All of the ports (JTAG, UART, SPI) use the same connector.

    The required usage of the FT2232 is one thing, where we are forced to use a 64 pin device and waste about 30 I/O pins, because that is what the reference design is for the XDS100v2. Now we are saying use an MSP432 instead, which will waste about 60 - 70 I/O pins because that is what the reference design is for the XDS110. I have a what ? 100 + pin MSP432 that definitely has all the serial ports we would need and we can't use them, because we are boxed in by the reference design.

    To gain the ports we need, we will need to add an additional USB device that we control ourselves and a USB HUB device. I mean, we will have to do what we have to so that we can make it work, but its extremely wasteful.

    If CCS instead just had some generic driver and the USB spec was published to just write raw JTAG sequences (maybe like a JAM player?), then end users could implement the devices that make sense without being wasteful.

    The reason we are making the debugger board is that our application has particular constraints. We have a ton of EMI and noise where we want to connect the debugger to. Currently, we have to use several adapter boards for the debugger which have their own ribbon cables sprawled about. This is a nightmare for EMI & crosstalk within our application and the debugger rarely works. Instead, we can integrate the debugger functionality onto a single board that uses a shielded USB cable, which should get rid of most of our noise issues. 

  • Hi Colton,

    Thank you for providing context for your design requirements. Note that that the XDS100 has been deprecated in support and we cannot provide much assistance for people looking to create their own. However, I'm continuing to assess options and will get back to you tomorrow on what I find.

    Best,
    Matt

  • It may be best for us to take a different route. The reason I suggested to my team to build our own integrated debugger board was because I was under the impression it would be low hanging fruit based on the XDS100 design. However, when digging into it, there were several unknowns. I understand that its old and unsupported. However, we do have some sort of size constraint and adding a 100+ pin MCU and another USB device would greatly increase the size of the board.

    We don't want to get into the business of building debugger boards for our designs as tools already exist today. A better option for us I think is to try to solve the cabling issue by getting the cable outside of our enclosure in a more controlled way. Once the cable is outside the enclosure, we can use standard tools and are not constrained at all by size.

    We can close this thread as it is clear to me now that building our own debugger board is not the best option long term.

    Thanks everybody for your help.