Propeller Held in Reset
geo_leeman
Posts: 190
in Propeller 1
I've got the propeller in a device that sits on the end of a 3 meter cable. I want the controlling unit at the other end of the cable to have access to the propeller's reset line incase things go bad and the controller needs to restart the device. I have the reset line pulled high with a 10k resistor that's part of a resistor network pulling things up that go out on the cable to the world. Oddly enough, the prop boots IF I have the prop clip connected, but as soon as I remove the prop clip, it is being held in reset. If I remove the prop clip and disconnect the reset line from the cable, it boots again. Is the solution here a smaller value pull up for the reset line? Seems like 10k should have done the trick. There is a tranzorb and series 10k series resistor in-line as well for protection.
Comments
Btw, it could be that capacitive crosstalk from the tx line is coupling across to the reset due to the length. Very first transition on this line and the Prop gets reset before it can go any further.
-Phil
There is battery power (~12 VDC) coming down the 3m cable. That cable terminates on a small PCB that has the input protection diodes, series resistors, and a 3.3V switching regulator. That 3.3 V, reset, etc, goes to the main PCB on a 6" ribbon cable. The main PCB has the Prop, accelerometer/magnetometer, ADC, temperature sensor, and several analog amps.
What I'm trying to get at is whether connecting the Prop Plug (presumably with a computer attached) completes a ground circuit that's otherwise open. IOW, the Prop may not be held in reset; it may just not be getting power.
-Phil
I'd be wary about connecting any 3m cable too directly to the reset pin. That's a great aerial you have made.
An irony here is the connection to reset, can cause what you hope to avoid....
Try a digital transistor, or even an opto coupler, which isolates things, and ensures nothing too fast can make it to the Prop RST pin.
@jmg - I'm thinking that the transistor solution is probably the way to go, but will know more as soon as I test the divider idea in a few hours.
+1
I was going to suggest the optocoupler on the propeller end of the reset cable as well. It eliminates any RFI and EMI concerns as well as protecting the propeller from ESD. By far the most reliable and interference free method of remotely resetting a system.
With the opto, do people still recommend a 10k pull up to make the reset less susceptible to mis-triggers?
-Phil
Sorry, I thought he meant a 10k pullup. Definitely don't want or need a 10k between the transistor and the /RST pin.
Is there any possible source of crosstalk on the cable itself? It's good that the problem went away but, what can you do about the alignment of the planets!?
I still think that all you need is an npn circuit rather than venturing into opto-isolation.
btw, you should always be using your scope but just make sure you attach the ground correctly and directly otherwise you may see false noise.
Isn't troubleshooting fun? Phil mentioned a possible weak ground connection via the Prop Plug. I ran into a situation like that yesterday. The setup was one master Prop talking to 4 slave props via 3V RS232 out on 15 inch cables. I got the firmware running on a Mac/bst and then we went to test it also on a PC, but nothing. Back to the Mac, it ran fine, that is, until I disconnected the Mac from its line wall wart. Weird, no other connections to earth ground. Could it be some kind of grounding issue?. However, probing with the 'scope revealed a weak RS232 signal from the Prop Plug and the slave tx data was also showing up as big triangle waves on the master data line. All that when away when the Mac wall wart was reattached. The short of it is, changing to a new Prop Plug solved the problem on both the Mac and the PC. I guess the first Prop Plug was defective, although I don't see any breaks on the connectors, which is the usual stress condition for those. It is as if it were running on parasite power. One of those out of left field troubleshooting issues. I don't know why the Mac wall wart made a difference.
I found an older post from Tracy talking about using pre-biased transistors for the reset logic. It looks like the recommended part is being EOL'd, but the PDTC114ET,215 is a drop in replacement.
I find that a lot of problems could be solved if the details weren't held so close to the chest, as if someone on the forum is going to "steal" ideas and make a fortune
All the stuff that is really security sensitive is dealt with without the help or knowledge of the forum. My advice then is if you need the forum then just share all the details right up front, you will be sure to get the best help. Most of the time a market advantage is not due to technology, but due to being in the right place at the right time and knowing the right people.
I'm still not clear about the "controlling unit" that will be connected at the outside end of the cable. Is that also Propeller-based? And where does the option come in for the user to "connect this to power and a RS232-USB adapter and run just connected to a computer"?
Currently for a prebiased NPN I use the MUN5211 family from ON Semi, with variations in SOT23 and SC70. It (and a host of other) are equivalent to the DTC... part.
Onto your question. This will likely be hooked up to some customer's in-place telemetry systems. Often that's USB to a computer or hooked into some funky satellite data link. I'm leaving that up to them, but "stock" you power it up and data comes shooting out the RS232 lines on the connector.
I plan on making a compatible logger (prop based) that will go with this and log the data to an SD card as well as enabling PPS lock, etc. One of the best features is I can use the trigger line to put the unit to sleep for people that want very sparse sampling rates, but need low power. (Like tidal researchers that need a reading every 5-10 minutes, but on batteries over the Arctic/Antarctic winter in the most extreme example.) My logger will handle all of that, but undoubtedly some adventurous folks will try to rig their own setups together, hence why I want to make all of the extra lines (trigger, etc) be pretty robust to someone accidentally hooking it up to a 12 V battery or some other nonsense.
There is no good reason at all to inflict +9V to -9V transitions just to pass serial data which we do quite well at much higher speeds at much lower voltages unbalanced as in the case of I2C etc. If you must have RS232 then don't feed those "RS232" signals down a shared data cable, just have a small active RS232-TTL header at the remote end. You will find though almost without exception that you can feed inverted logic levels into "RS232" and simply use a current limit resistor of around 33k (+pulldown) or so to receive RS232 (also good protection) since none of the proper RS232 receivers are proper anymore and are designed accept to logic signals.