Prop Plug DTR
VonSzarvas
Posts: 3,488
Does anyone recall the behavior of the DTR/RESET pulse that has been mentioned in the past as undesirable ?
Not sure if those are all "things of the past", or if there's still improvement to be had ?
I seem to recall some cases where you connect PropPlug to a live circuit, and that might cause a reset. Something like that. Might be other things too.
Reason for asking; there might be an opportunity to tweak the DTR behavior as we were looking at a Prop Plug improvement including a few things such as:
1) TX and RX become fully protected against parasitic power at idle, in either direction, powered or unpowered.
2) Allow user to enable/disable RESET (DTR) signal using the FTDI config tool.
Not sure if those are all "things of the past", or if there's still improvement to be had ?
I seem to recall some cases where you connect PropPlug to a live circuit, and that might cause a reset. Something like that. Might be other things too.
Reason for asking; there might be an opportunity to tweak the DTR behavior as we were looking at a Prop Plug improvement including a few things such as:
1) TX and RX become fully protected against parasitic power at idle, in either direction, powered or unpowered.
2) Allow user to enable/disable RESET (DTR) signal using the FTDI config tool.
Comments
1) is a good Idea.
2) is BS. Sorry, but reprogramming a PropPlug is not needed at all, you can just connect the Plug with wires and leave out reset. The reset disable thing is needed for all Parallax boards with build in USB. Because there you need to cut traces.
Mike
This is the detail that's missing.
WHY is that needed? What happens now that is not desirable, and would have you thinking about cutting traces as the solution ?
/* normally we use DTR for reset but setting this variable to non-zero will use RTS instead */ static int use_rts_for_reset = 0; void serial_use_rts_for_reset(int use_rts) { use_rts_for_reset = use_rts; }Perhaps, loadp2 just needs to subscribe to the use_rts_for_reset variable and provide for it in its options?dgately
That being said, I guess if the DTR where setup such that a short pulse would not cause a reset then that might be better.
I do know that when I new USB device is plugged in or removed the DTR is pulsed and causes a reset. This is fixed by going into the com port and set it to not do that.
Also if the USB port is closed in some cases causes a reset.
If you can reproduce these issues and build a circuit around them then that would make a better product. This may also break existing programs.
Some people may leave the thing plugged in as a serial interface or power and don't want it to reset under any circumstance. Then a small dip switch may be needed to disable that function.
Mike
That means set-on-open and short-pulse-on-open artefacts are ignored.
UB3 also allows simple decisions based on widths 50~1000ms - with P2 that selects Flash or SD boot, & the i2c can interrogate the pulse width to allow hidden target test modes.
UB3 also uses a resistor pull down, so P2 is held in reset at power up, and only when the MCU completes init does reset release. (The UB3 BOD is thus used as a reset generator)
Reset is also a narrow pulse, so saves external parts
IMHO a RESET 0.050" link (pads) on the pcb would be nice. Short the pads with a pcb trace that can be cut.
Provide a male 2x1 0.050" 1.27mm pin header and a 0.050" 1.27mm shunt with the board and/or PropPlug.
The user can...
* Cut the track/trace if desired, and then
* Solder the male header and install the jumper when required.
My boards (P1 and P2) provide the transistor reset circuit on the boards, with a link to select either the transistor reset circuit or bypass it.
The transistor reset circuit was done (by Chip more than a decade ago) to solve a problem with windoze removing DTR between programs. By using the inverted DTR together with the transistor reset circuit, the DTR reset between programs was avoided. It's a little deeper than this but this explanation will do. It prevented a reset after downloading a program with PropTool and then running PST.
The second, and unrelated problem, is the phantom powering up of the FT232RL via the prop's TX pin. FTDI provided a circuit solution for when the FT chip is on the main board by powering it from the board and not the USB. This wasn't implemented on Parallax's boards. This does not solve the problem when using an external PropPlug and the USB connection is removed without unplugging the propplug from the pcb.
Be careful of any solution that puts something between the prop tx pin and the ft rx input because we are now regularly using 2,000,000 baud and above for downloading, and anything in the path may reduce this maximum transfer speed. We may soon be downloading up to 512KB of code to the P2.
The be more accurate I don't think there's a problem with PropTool and PST, nor FlexPropGui and its terminal, but the problem appears when you stray outside this system, eg running TeraTerm, or a custom application on the PC (VB Python etc). These assert DTR for the duration they are running, currently causing the reset on entry to the program, rather than exit from it. To prevent this we have used FT_PROG to invert the DTR on many of our P2 boards, though the ability to easily program flash now makes these issues less significant.
As for the parasitic power issue we have solved this in the past with the P1 by pulling up RX, TX, and often Reset too for good measure. I think we use 3x30kohm but 10kohm would likely be fine too. I think I emailed links to the thread where this was discussed for the P1 some years back
I've added a new -RTS flag to loadp2 to use rts for reset. I'm not sure how much this will help with the problems discussed in this thread, but it probably won't hurt
Parts like CH340E, in teensy MSOP10, have only RTS bonded.
(Addit also small FT234XD bonds only RTS)
That’s a good candidate for the various KISS P2 boards to include USB (~40c/100)
Well I try again. Somehow my English seems not to be good enough to explain this.
Imagine a production line and you want to plug the USB into a laptop. Just to get to some diagnostic info pushed out over serial constantly or even some small serial cmd interface to inquire the running system.
P1/P2 are powered independent of USB so already running in production.
You plug USB in and the Propeller will reset. NOT desirable.
@iseries is right that you can change settings in Windows to prevent this, but you need to do that prior to plug into the running system and have to guess the port it will connect to. With many units in the field and different operators/laptops this is not doable.
On boards without build in USB using a PropPlug you can avoid that by not connecting reset and just use GND/RX/TX.
On boards with built in USB you are basically f....d and have to cut a trace and put a jumper there for programming, and none jumper for disabling reset.
Sadly Ken decided to put USB on every board Parallax sells (except the new Edge) the last one w/o USB was the P1 protoboard sold in 5-packs, stopped selling years ago. The only one having that jumper was the spinneret.
Another issue (maybe solved on newer boards) is that with nothing connected to the USB chip any output on TX will power up the FTDI parasitic and - hmm - resets the propeller.
All of this could be solved with a jumper between USB chip and Propeller reset pin.
Call it 'Programming Enabled' or something like that and sell it as a security feature. Jumper in you can program, jumper out you can not. No accident in overwriting the wrong Prop when multiple connected. Maybe even on a PropPlug, alas using three wires instead of plugging in solves the problem there.
Enjoy!
Mike
In my own products I have a jumper that must be plugged to enable reset. Having DTR (or RTS) active for reset is disturbing when program development is finished. I often use the same serial port to communicate with the PC. Usually DTR gets toggled when exiting the PC program, this resets the device, which often is not desired.
I also like to protect against unintentional reprogramming. Several times I had my PropScope reprogrammed while testing some new stuff , simly because it was connected and I was not careful enough to select the correct port.
https://forums.parallax.com/discussion/116711/can-parallax-do-something-about-the-ftdi-reset-bug/p1
Take a look at the FLiP module schematic. It solves the problem by using pullups on USB-tx and Prop-tx, with series resistors between the Prop and USB chips on both tx and rx. But, as pointed out above, the series resistors will prevent very high baud rates.
For higher baud rates, a buffer from the LVC logic family would be better than the series resistors.
-Phil
These cost about the same as MSI tiny-logic parts, and have the ability to add BOD, WDOG, and time windows on DTR to exclude errant resets.
Possible parts in 3mm MSOP10 would be OB38R08A1W10MP (18c/100) or MS51BA9AE (22c/1k), or EFM8BBx in QFN 3mm or STC8G1K08-36I-DFN8 (17c/100) or STC8G1K08A-36I-DFN8 (19c/100)