Posts Tagged ‘pdi5’


OctoPDI5 board underway


The product I’m working on consists of a number of devices strung out on a bus, all of which need to be reprogrammed and debugged at the same time.  The problem is, they’re potentially meters apart, and more critically their ground potentials are all different (they derive power from said bus, which will sag inward from 0-V+ over distance).  I’ve made several attempts to solve this problem (isolated USB, wireless debugger) and so far they’ve all fallen short for various reasons (none of which can’t be overcome, given enough time, which I don’t have).  This latest attempt is far more likely to work, because it’s based on existing tech and more straightfoward (and breadboarded!).

This board consist of an Xmega 128A1 coupled with an FT245R, along with 8 isolated PDI5 ports.  The ports consist of an Analog “isoPower” ADuM5403 and a 74AHC1G125 tristate buffer plus USB micro-B connector.

The FT245R is hooked up to the memory interface of the Xmega, which means in theory I can read and write the USB serial port just by reading and writing a memory location.  I haven’t had much success getting that to actually work in the past, but I’m giving it one more shot.  I know the bitbang interfacing works, so I can always fall back on that.

Each PDI5 interface is half of an “interface” port on the Xmega, and is set up for the USART.  The TXD, XCK, and TXEN lines go through the ADuM5403 one direction, and the RXD goes the other way.  TXEN drives the 1G125 buffer to engage TXD, because the target side of the PDI5 interface ties the RXD and TXD lines together via resistors to provide the PDI_DATA line.  The Xmega can easily tristate the TXD line when it’s time for the target microcontroller to talk back, but the ADuM5403 doesn’t know any better.  The buffer enables this to work on the isolated side of the circuit.

The software I’m porting over to this beast is existing code that multiplexes communication to all the configured logical modules over the USB uplink.  Each PDI5 port consists of two logical modules: the STK600-compatible programming stack, and a straight serial port.  Using the STK600 port disables the serial port for the duration, but otherwise the serial port provides debug communication with the target.

The micro-B connector has a different pinout than I originally planned.  Rather, this one is actually planned…  I’ve found that even though mini- and micro-B connectors have 5 pins and a shield, nobody makes pre-made cables that have the 5th wire.  As a result I’ve shuffled things so that the +3v3 pin is the one that ends up not being connected between the programmer and target.  This is fine for two reasons: we have a ground and known voltage level, and the ADuM5403 also provides power on the isolated side to run the buffer.

Once this board is up and running, I can use the collection of micro-B to micro-B cables I purchased from Digikey in order to spider out to all the units I’m developing.