DEBUG Interface Problem
Discovery
Posts: 606
in BASIC Stamp
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
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
Comments
First step is to post the code.
Second step is describe the hardware.
Then there are more steps.
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
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
Sincerely,
Discovery