DEBUG Interface Problem

Discovery

Some time ago, I described a problem with the DEBUG Interface and a solution was provided but I cannot find the answer.

The problem is that the Basic stamp will stop processing a program for a reason that is not well understood. When the DEBUG is used to display computations made in the Basic program on the computer screen...there will come a time when the program will halt. The stoppage has been random occurring from days to months but it will eventually stop the process.

The solution was to do something to the Rx or Tx lines but I don't recall.

The same situation occurs on the Propeller interface to the computer screen. If the interface is disconnected, the programs run fine but my system design requires monitoring data sent to the computer screen.

Discovery

microcontrolleruser

First step is to post the code.

Second step is describe the hardware.

Then there are more steps.

Mike Green

There is a known problem with the Propeller ... not the Propeller itself, but the USB-serial interface ... where debug data is written to the USB-serial adapter on I/O pins 30/31, but the USB bus is not connected. The FTDI chip is partially powered by the serial data and occasionally (seemingly at random) can generate a reset pulse for the Propeller. The Basic Stamp could theoretically exhibit the same behavior although it would require more energy from the USB-serial interface and is less likely to happen. Solutions include keeping the USB-serial interface powered or disconnecting the /Reset line except when you need to re-program the device. The Propeller can detect the idle state of the receive line from the USB-serial interface and only transmit debug information if the USB-serial interface is connected. The Basic Stamp can't do this.

Discovery

Hi Mike,

I was trying to recall what the correction to the problem was...when I began a two-year factory construction project in which the control systems would reside. I recalled the solution...disconnect the USB from the BS2p; however, that won't work in the new design since system status is printed to the computer screen via the DEBUG.

I cannot disconnect the propeller USB connection, which is also part of the systems design, since the propeller program will stop. It could be a disaster if either the BS2p or the Propeller stopped with a piece of equipment running or not running as the case may be.

You are right in that the program stoppage is a random process.

I need a real solution to this USB interface issue. Are you suggesting that I tie 3.3 or 5 volts to the Propeller USB interface board? The BS2p signals have only a ground interface...no power.

Discovery

msrobots

Problem: Powering up the USB chip by stray current from p31/30 without having USB connected may reset P1. Same goes for enumerations of the USB-Port Host when connected. They simply will reset the P1.

Solution is to cut connection to /RST and put a jumper there for programming. As far as I know just Spinneret had that jumper, IHMO all boards using buildin USB should have a jumper to protect /RST.

It is not random at all, If the Host-System enumerates USB it will reset the P1, just watch it and unplug mouse and plug mouse into your computer. P1 reset when connected.

Same problem occurs when sending data to USB from the prop, when NOTHING connected to the USB. Then P1 powers up USB and FTDI resets the propeller.

You can pull P31 down for a moment and then check if high, that can tell you if FTDI is pulling up P31. if not, don't start serial COG and don't output anything.

It's a kludge, but known since @Mparcs Sphinx.

Known since years. On all Parallax Boards with USB except the original Spinneret. And most other Boards too. Solution: Jumper to protect P1 reset when not programming. Or stop using USB on all boards and go back to PropPlugs. There you can just use a small adapter/wires to not connect /RST when plugged into the host.

But nobody seems to notice and nobody seem to care...

Enjoy!

Mike

Mike Green

As msrobots and I noted, you have to break the connection to /reset and replace with a jumper or switch for when you have to update the program. When the USB cable is disconnected, the FTDI chip is partially powered by the signal on the Tx line from the Propeller or Stamp via leakage within the FTDI chip. Solutions ... either break the /reset line to the Propeller or Stamp or you can supply power directly to the FTDI chip keeping it fully powered. With the Propeller, you can also stop sending data to the FTDI chip and leave both I/O pins 30 and 31 in input mode so they can't power the FTDI chip.

Discovery

Thanks Mike...I will give that a go.

Sincerely,

Discovery