opto-insulating PDI interface

Go To Last Post
11 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I am working on the redesign of a 3-phase e-meter. I am thinking to opto-insulate the PDI interface, in order to debug the board even when connected to the power grid.

The current board already mounts the Si8602AC insulator for an I2C port, and I wonder if I can use the same for PDI as well - with PDI.CLK as SCL and PDI.DAT as SDA. Apart from the pull-up resistors, not needed, PDI and I2C seem quite similar from the electric point of view.

The problem could be how to give VTarget to the debugger, but this can be easily solved.

Any opinions?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I am not sure if PDI works as open-collector. It can work as push-pull (SWD works that way) and then that would be tricky.
Did Atmel publish at least the physical layer details of PDI?

No RSTDISBL, no fun!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Recall that the clock is one way, driven by the programmer, while the data line is bi-directional.

Still doable, just means you need to spend a little more time designing the interface.

Recall, also, that the (original) PDI spec's stated that the lines were to have matched impedance, (i.e., amongst other things, one was not to put a cap on the reset line).

JC

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

May be you can use the ADuM4160 isolator from Analog Device.
This is for USB and is bidirectional.
Analog Devices has also other ADuMs.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I know that IC from Analog, I already tested it with USB and it works fine.
This could be an idea for PDI as well.
The Si8602AC relies on weak pull-ups to detect the transmission sense, and this may not work if PDI uses push-pull.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

If you only need to debug the unit for development purpose would a usb isolator work between the computer and programmer? You wouldn't have to fit the extra components on the board then.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Not a bad idea either... but I am not sure I can get the CE marking in that case.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

j0n90 wrote:
If you only need to debug the unit for development purpose would a usb isolator work between the computer and programmer? You wouldn't have to fit the extra components on the board then.
If willing to forego the debug functionality then use ISP; this is arguable in lieu of a bootloader.
Implement Dean's AVRISPmkII clone (a mega U4?) with a USB device isolator.
IIRC, the published PDI protocol may have enough to obtain some of the debug functionality.

"Dare to be naïve." - Buckminster Fuller

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Anyway, tomorrow I will test the ADuM, somewhere in the lab we have a ready to use circuit.
I will post the results here, in case someone is interested.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

I am not sure I can get the CE marking

Would you be wanting other people to be plugging in a programmer to your board on the pdi port? If you wish to do field upgrades to the firmware then maybe you could write a bootloader that runs through the already isolated i2c port or even isolate a spare uart with an adum1201, I do this on one board and have put an ftdi USB chip on there too.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

kalbun wrote:
The current board already mounts the Si8602AC insulator for an I2C port, and I wonder if I can use the same for PDI as well - with PDI.CLK as SCL and PDI.DAT as SDA. Apart from the pull-up resistors, not needed, PDI and I2C seem quite similar from the electric point of view.

I did this a year or so back, and still implement it in my programming jigs. Attached is a fragment of the schematic for my 8-port isolated programmer.

The key problem is that the DAT line is bidirectional, and has to be controlled by the protocol itself. That means the programmer needs 4 wires to the isolator - CLK, RX, TX, and TXEN. The isolator is an ADuM5401 which provides isolated power as well as data. This power is used strictly for driving the 74xx1G125 that drives the isolated TX when TXEN is asserted.

I use a USB micro-B connector because it fits the space I have (edge of very small board in middle of 3mm-spacing stack), which only contains GND, CLK, RX, and [TX]. On the target, I connect RX and [TX] both via 220R resistors to the DAT line.

Conveniently, I also connect RX and [TX] to a UART on the chip, because as long as CLK[RESET] is not being messed with, I can use those two lines as a serial debug into the part. Trick there is that the part has to detect if the programmer is connected before enabling transmit, otherwise the resistors form a loopback between the UART Tx and Rx.

The code on my latest programmer talks STK500v2 over USB (cloning an AVRISP mkII essentially) but also has a CDC interface that is active whenever the STK500v2 protocol is not.

Attachment(s):