Interesting Phenomenon

Discovery

I have a large industrial PropBasic program running my Propeller Activity Board (PAB) that includes a COG running a very accurate Run-Time-Clock.

Issue 1. The PC program is downloaded to the PAB with the time-of-day. The program runs and halts at a Do-While-Loop for a push button depression to start the main program. This program runs until the PC goes to sleep and Windows messes with the USB port that stops the program and puts the Propeller into an initial state.

Issue 2. With the Industrial program running, the USB cable to the PAB can be disconnected and the program runs fine...indefinitely. However, when the USB cable is re-connected to the PC USB port the propeller program stops and goes to the initial state. The system is designed to run without the USB cable connected.

Issue 3. One-wire protocol code is added to the Industrial program to read the temperature of a DS18S20. The program runs and reads the temperature repeatedly in the main program Do-Loop. However, when the PC goes to sleep the PAB stops running but when the PC is restored to operation the PAB program restarts, halts at the Do-While-Loop, and runs when the push button is depressed but with the wrong time.

Issue 4. With the Industrial program running including the One-wire code the USB cable can be disconnected from the PC and the PAB program stops running but then restarts and halts at the Do-While-Loop automatically. This is not desired. Disconnecting the USB cable should not affect the program but it does.

Issue 5. All of the One-wire statements were no-oped and the Industrial program ran properly with the USB cable disconnected. There is something about the inclusion of One-wire code that causes this phenomenon.

My first Industrial control board was fabricated and used a Propeller Plug for USB communication. The program was written in "C" without One-wire code. The Propeller ran fine with the USB cable disconnected but when the cable was reconnected to the PC the Propeller stopped running. To fix the problem a member of the forum suggested building an interface between the Propeller Plug and the Propeller that included a slide switch on the RST line. The switch was closed for downloading the program then opened for operations. The USB cable could be disconnected without any difficulty. The slide switch solved the problem.

Do you think that the same slide switch solution will work in the case described above? The board artwork will be sent to a PCB fabrication house and I can include the slide switch if it will solve the phenomenon.

Sincerely,
Discovery

msrobots

yes your problem is typical for the RST starting your board. The reason for change with addition off the one-wire code may be that you output debug data via serial?

Enjoy!

Mike

Discovery

The TX serial data One-wire code was not included in the Industrial program so there is no output to the PC. All the calculations are done in the PropBasic code that controls the factory equipment. The PC is removed from the USB after the code is downloaded.

Discovery

msrobots

no what I was hinting at is that serial output to the FTDI chip while NOT connected to the PC can powerup the FTDI thru parasitic power and the FTDI chip then in return resets the propeller.

The most secure way is a run/prg switch disconnecting /RST from the FTDI chip while running.

Enjoy!

Mike

Cluso99

Discovery wrote: »

The TX serial data One-wire code was not included in the Industrial program so there is no output to the PC. All the calculations are done in the PropBasic code that controls the factory equipment. The PC is removed from the USB after the code is downloaded.

Discovery

Ensure that P31/30 are inputs/tristate or you are attempting to power the FTDI chip. That causes the DTR/reset to cycle as it cannot powerup properly.

Discovery

Cluso99,
I am not sure exactly what you mean. What circuits must I include on the new printed circuit board to insure that the propeller does not go into reset when the USB is disconnected and one-wire networks are operating?

Sincerely,

Discovery

cheezus

I've had problems with the reset and here are my solutions.

#1 I usually connect the reset pin from prop plug to propeller with a jumper that can be removed when not programming. This keeps windoze from resetting the board pretty much whenever it decides to.

#2 Check to see if a prop plug is connected (and powered) before trying to start a serial driver. If RX (P30) is high, then we know that there's a prop plug connected (and connected to a pc). If this pin is low and we start a serial driver... Since the lines idle HIGH you'll be powering a prop plug from the propeller TX pin. While this isn't great, it doesn't seem to break anything UNLESS you have the reset line connected. It MAY have been on data transmission that the issue occurred but I can't recall.

For several years now, the only time I use a prop plug to directly program boards is with a blank eeprom or the initial debugging of a bootstrap. There are other ways to program the eeprom that actually make things a lot easier (once implemented). I'm using a cheap Bluetooth breakout for communication with pc that does not have a reset and have an SD card so my system is pretty complicated. Propellent might be worth checking out and if you ever consider adding wireless Bluetooth or WIFI paths seem to have been well traveled.

A simple jumper or switch on the reset line will solve the problem. It does add a step when programming but for industrial control, not a bad idea to begin with IMHO.

Cluso99

Short answer...

Don't enable the serial port if you don't have a USB connection.

If you enable the serial the TX (P30) will try to power the FTDI chip. There is not enough current to properly power the FTDI chip which causes the FTDI chip to continually power up and down. This is BAD!!!

BTW there is an app note showing how to power the FTDI chip from onboard 5V rather than USB. Don't use the FTDI 3V3 to power the Prop as there is insufficient current available.

Really, it's best to use an external PropPlug or USB to Serial board. I recommend putting the transistor circuit as an option on the Prop pcb.

Note this has all been discussed at great length on the forum. Google is your friend

Discovery

Cluso99,

I am confident that using a slide switch in conjunction with the propeller prop will solve the USB problem but how about the one-wire code problem that I delineated above? The one-wire networks (2) that I use are driven from a propeller pin and pulled to 5vdc with a 4.7k resistor. I do not see any way that this configuration can cause changes in the propeller prop and cause the program to recycle. When I no-op the one-wire instructions...the program recycle problem disappears.

Discovery

msrobots

can you post the code?

Mike

Discovery

I attached a portion of the code. The main body and subroutines were removed since they play no roll and take up a large space. The key problem is the one-wire instructions. They appear to affect the propeller's controls...somehow.

Discovery

Discovery

So, if I distilled everything that was discussed here correctly, after downloading the program from the PC and starting the program...I should slide a switch on the printed circuit board to open the /RST line to the propeller. At this time the propeller plug can be disconnected from the printed circuit board and the program should run without incident.

Is that correct?

Discovery

msrobots

electrically yes,

except your one-wire code does something to reset the propeller, I take a look if something jumps at me...

Looked at the code you provided and see no flaw there.

can you provide the onewire library code?

Mike

Discovery

Not easily,
The Library is
1-Wire Library for PropBASIC
by Jon McPhalen
28 MAY 2010

I could not get the Library to work. I use the demo file referenced by Tritonium.

It is the only code I found that reads the DS18S20 temperature...but the temperature value is ten times to large. That is a reading of 205 is actually 20.5 C.

Didcovery

msrobots

can you post the files you are using, please?

Because that could help to localize the problem,

Mike

Discovery

Hi Mike,
The actual one-wire code that I use is shown in the attached document in this thread dated 7 January. The one-wire library was printed to paper and entered into a test program but for the life of me...I could not get the code to compile. The library code is too complicated for me to understand. The demo file referenced by Tritonium above worked perfectly for reading the DS18S20 temperature.

Discovery