Leaving USB connected while oven is off

[dtmr-e]

ISP connector ... not the standard one as I wanted a sixth pin ... hooked up to 3.3V so I have a target voltage reference for my UART interface. Never a good thing to drive UARTs on SoCs if the SoC itself is not powered

Could you please clarify this part? Do you mean: Take 3V3 from some point on the oven PCB and put it into the VCC pin of the usb-to-serial converter while at the same time removing that converter's 3V3/5V selection jumper, so that the converter is powered from the oven, not from the PC?

[radensb]

What UART interface device are you using? I am using the FTDI FT232RL device that provides a 3.3V output that can be steared into the interface voltage input. Do not pull 3.3V from the oven to feed the interface voltage (VCCIO) if you have a 3.3V output from the device. Use the 3.3V output from the device that is sourced from the PC. Design as follows: The only UART connections you need to make are Rx, Tx, and Gnd. In the situation you want, the POWER net is 3.3V.

[dtmr-e]

I have a CH340 adapter (www.electrodragon.com/w/USB-TTL_Serial_CH340_Board):

It has a jumper on the output header CON2. That jumper can be set to bridge pin 2 (VCC) to pin 1 (5V) OR to pin 3 (3V3) - to power the VCC line of the adapter from 5V USB or from the regulated voltage on the module:

If I don't set that jumper at all, I think I should be able to feed the oven's 3,3V into the adapter's VCC pin 2 of CON2.

The only UART connections you need to make are Rx, Tx, and Gnd

If I do that and the oven is off but the USB adapter (PC) is on, a current will trickle into the target circuit via the TX line, driven by the USB adapter. I read that will strain the target's (SOC's) clamping diodes.

[radensb]

For that design, you can ignore the jumper as you will get 5V from the PC USB port. The device will get its VCC from the 5V USB power after about 1.4V is dropped over the two diodes providing ~3.6V. I assume that since there is no VCCIO equivalent, that the Rx and TX are set to 3.3V? If so, you're good.

Are you saying that one can connect the 3,3V output of the FTDI to the VCC of another circuit without getting smoke? Is that a special feature of that chip?

Do you mean a 3.3V source to another source? No, you wouldn't want to do that and are not doing that here. Lets say you connect a 5V source to a 3.3V source in a common grounded system. The 3.3V source would have less potential than the 5V source so there would be a net voltage potential of 1.6V which would cause current to sink to the 3.3V source, which is not what you want. This is one reason for the blocking diodes D1 and D2 in the circuit you provided. Let the USB device operate on the voltage source from the PC (the +5V net). The Rx and Tx signals can interface with the oven directly.

If I do that and the oven is off but the adapter is on, a current will trickle into the target circuit via the TX line (driven by the USB adapter). I read that will strain the target's (SOC) clamping diodes.

This is false. You are talking about parasitic powering and it shouldn't be a problem. Also, the TTL UART is active high, meaning that if there is no communication over the COM port, the Tx line is grounded anyway, so no possibility of parasitic powering.

[GitLang]

The FTDI ready made lead TTL-232R-3V3 or TTL-232R-3V3-WE works just fine, you can buy it online at http://www.ftdichip.com. I fitted a DIN EN 60529 Screw On 6 pin plug to my cable, and a DIN EN 60529 Screw On 6 pin socket to the side of the electronics enclosure of the oven. I also fitted a toggle switch to change between run and program mode, a push button for reset and an LED to show which mode it was in. Works fine. The cable uses the FT232RL chip as radenb mentions.

[dtmr-e]

FTDI ready made lead TTL-232R-3V3 or TTL-232R-3V3-WE works just fine

My adapter works, too, but I know from experience (FTDI232) that having it connected do a powered-down device introduces a current into that device over the TX line - which could be harmful (over SOC's VCC: should go into clamping diode of its RX pin). In my case, I had an AVR controlling a digital LED strip. Every once in a while the strip would flash even though the AVR was off, due to current introduced over TX (fix on that project: 2K2 series resistor in TX line).

(top-left photo: DS18B20 glued with Arctic Alumina Thermal Adhesive to the underside of the PCB; its GND/VCC soldered directly to thermocouple clamping block)

push button for reset

I didn't install a reset button - it's sufficient to hold the ISP button during power-on (= power on reset). The flash utility must be started quickly after that, there seems to be a timeout (select "ISP menu/Read device signature" menu item of Flash Magic within seconds). Heating element were disconnected before doing that because they'd turn while the MCU was in bootloader mode:

[GitLang]

Sure, I know from my experience that shoving power backwards into any powered off VLSI circuit is a bad idea. Yes, most of those inputs are protected, but it's more the 15kV for a few us they are protecting than a chunky power output. Just don't do it, ever.

If you develop firmware on it you'd have to be darn good to never see a crash. Easiest way out of that is to hit reset, it's less hassle that powering it on or off. AFAIC, a line that enables flash programming should be left alone unless programming is your intention. That's just me, I always err on the safe side.

[dtmr-e]

If you develop firmware on it you'd have to be darn good to never see a crash. Easiest way out of that is to hit reset

Does the MCU have a watchdog that auto-resets hanging code? If so, then a hard reset should hardly ever be necessary. Instead, a soft reset feature could be implemented, so that a 5s press of the same key that is supposed to start the bootloader if held during a reset (F1?) soft-resets the MCU. It would then jump right into the bootloader. At least that's what the "Upgrade firmware" item in the menu of my AVR projects does.

[GitLang]

So if you agree, why do you recommend a FTDI cable? Isn't that's just what it does, shoving power into the TX pin?

Because they are reliable USB to RS232 chip manufacturers with solid supported drivers, that's all. It doesn't matter what you use, any voltage source has the potential to damagae an unpowered VLSI input. That's why I said "Just don't do it, ever." Just as you wouldn't shove a live signal generator onto an unpowered circuit. It's one of those things that, rightly or wrongly, just becomes second nature over the years. If the LPX people hadn't been cheapskates and have used a MAX232 or similar RS232 interface chip then it wouldn't matter. They are fully protected in all combinations of input/ouput up to around +/-30V

BTW, I answered your message from the email notification as I usually do, but this time I accidentally clicked on "mute the thread" rather than "view it on Github". I think I've re-subscribed OK, but if I don't answer you I'm not ignoring you :)

As for your reset question, I have no idea if that particular ARM chip has a soft reset, I doubt it though. The firmware does have a watchdog in case anything goes awry. I'm still happy to just hit reset though, it does what it says and I don't see the downside. If you are restarting a CPU from a crashed state then you really do want to be certain it is back to ground state.

[dtmr-e]

no idea if that particular ARM chip has a soft reset ... The firmware does have a watchdog in case anything goes awry

Then it does have a soft reset: Enable the watchdog (assuming it's of the kind that must be reset periodically in the main code) and hang the MCU intentionally with for (;;)

[radensb]

I know from experience (FTDI232) that having it connected do a powered-down device introduces a current into that device over the TX line - which could be harmful (over SOC's VCC: should go into clamping diode of its RX pin). In my case, I had an AVR controlling a digital LED strip. Every once in a while the strip would flash even though the AVR was off, due to current introduced over TX (fix on that project: 2K2 series resistor in TX line).

Ah, I understand. I don't think that you have to worry about this situation with the LPC2134 device as it needs 40+mA of current to run (without peripherals connected) and your USB adapter has a 1.5K resister inline the Tx line limiting the current to 2.2mA @ 3.3V. Even if the power rail saw a voltage capable of powering the device, it wouldn't have the current capacity to run it.

[radensb]

I also cant seem to find mention of ESD clamping diodes in this device? Wouldn't that make this not a concern?

[radensb]

This is peaking my interest. I even looked over designs that others have done with USB to serial converters and none of them have any previsions for parasitic powering, including inline resisters, that I can tell. I am also having a hard time getting the information I need from datasheets for the LPC devices.

I realized that I left my oven off while being plugged in (FTDI was powered) for over a month via USB from a running PC. I just powered the unit up and noticed no issues. I would like to understand this better to decide if a modification should be added to designs that isolate the Tx line (and maybe the Rx line too) from the MCU to prevent this. Otherwise, this can be mitigated by powering up the oven before plugging the USB cable in.

@GitLang You mentioned designing a board in the other thread for the MAX31855's. Did it also support USB-Serial? If so, are there any previsions for this situation in your design?

[mikeanton]

@radensb

Why don't you power the USB to serial converter from the oven? Then there should be no problem.

The LPC devices don't seem to have the typical input specifications like most devices. Typically there is a spec for the max current into an input (which goes into the body diodes), and usually this is specified as 20mA max for most devices. So, generally it is safe to limit the input current to half of this. If there is a 500R to 1K resistor in series with the output from the USB adapter, it should be fine from a parasitic power standpoint. Now whether or not this would cause any reset problems is another issue, but the device won't be damaged under those conditions.

[radensb]

Why don't you power the USB to serial converter from the oven? Then there should be no problem.

I actually tried that in my first design that included a FTDI RS232RL device and it didn't work properly. I think that the device needs 4V - 5.25V to use the internal oscillators. Otherwise, you need external oscillators to run lower voltage.

I read in the data sheet the following:

"When the FT232R is in reset, the UART interface I/O pins are tri-stated. "

So perhaps something as simple as tying RESET# to the ovens 3.3V net and a pull down resister is all that is needed here. When the oven is off, the FTDI will be pulled into reset and the UART pins are tri-stated and cannot source power to the MCU through a DIO. When the oven is on and the 3.3V net is energized, it would pull the FTDI out of reset. Maybe a charging cap could be added to slow down the RESET# net voltage to allow the MCU to power up itself before the FTDI Tx can drive it.

[GitLang]

@GitLang You mentioned designing a board in the other thread for the MAX31855's. Did it also support USB-Serial? If so, are there any previsions for this situation in your design?

No, it wasn't my design, it it was the one several people made which was detailed in the wiki. The original designer gave a link to the PCB supplier so you can order boards just as you would if it were your own design. It does not have a USB <-> serial converter, the one I mentioned was the ready made lead TTL-232R-3V3 direct from FTDI shop.

[xnk]

The reasoning for my comment was from having bad experiences with latch-up in UARTs on other MCUs. That is, having a serial interface that keeps the TX line high (without any current limiting) when the receiving end is unpowered may result in back-feeding of voltage through the protection diode of the MCU. I’ve been using serial interfaces specifically designed to take an external voltage reference and only drive the TX pin if there’s voltage present. This way, as soon as the oven MCU is unpowered, TX will no longer be driven externally. Current limiting resistors starts to become a problem when running the serial link at higher bitrates (like 2 or 4Mbps), not really a problem in this case. The typical issues I have seen before when the UART is experiencing latch-up is that it simply stops working until all power is removed from the device (this is a classic issue with more than a few of the Qualcomm SoCs).

/wj

On 22 Apr 2018, at 11:44, GitLang notifications@github.com wrote:

@GitLang https://github.com/GitLang You mentioned designing a board in the other thread for the MAX31855's. Did it also support USB-Serial? If so, are there any previsions for this situation in your design?

No, it wasn't my design, it it was the one several people made which was detailed in the wiki. The original designer gave a link to the PCB supplier so you can order boards just as you would if it were your own design. It does not have a USB <-> serail converter, the one I mentioned was the ready made lead TTL-232R-3V3 direct from FTDI shop.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/UnifiedEngineering/T-962-improvements/issues/138#issuecomment-383368599, or mute the thread https://github.com/notifications/unsubscribe-auth/ADEoj3vGjhmxdizZ4Ow6cAG8SAvMCyCxks5trFEagaJpZM4TeCS6.

[dtmr-e]

your USB adapter has a 1.5K resister inline the Tx line limiting the current to 2.2mA @ 3.3V

Nicely spotted. I just replaced that with 4K7 and it's still working at 115200. For ATMegas, Atmel recommends max 1mA through protection diodes (not in the datasheet but in some app note that relies on them, "AVR182"). I hope it's similar here.