We are using both the USB and UART interface in our product. If our host processor is powered off, is there a way to tristate the UART TX line so it doesn’t back-drive the host processor?
Hi, David,
I think it may be a hardware problem?
I would like to suggest you could cut off the GND pin of UART, then the host processor will be powered off thoroughly.
Thanks
Job
Hi Job.Bao,
I’m not sure I understand your response, but maybe I wasn’t clear or didn’t give enough detail.
We will run our host processor with the USB and UART TX/RX lines connected to the EC25.
When the host is not busy, we will power it down, but leave the EC25 running.
We send AT+QSCLK=1, deassert AP_READY, and remove voltage to the EC25 USB_VBUS.
In this state, we would expect the EC25 not to drive its UART TX line high because this will backdrive the CV25. But it does drive that line high.
Maybe if we had DTR wired and deassert that when going to sleep, this would fix it?
Hi, David,
1,Have you tried to have DTR wired? and how about the result of it?
2,I want to know that does the voltage of EC25’s UART TX line will awake CV25 or the high state of that will awake CV25?
3,And I want to know whether the mean of BACKDRIVE is same as AWAKE?
Thank you,
Job
Thanks for your reply Job.Bao.
By backdrive, I mean the EC25 UART TX applies a voltage to the host processor UART RX input when the host processor is in the off state. I’m told this is not good.
We have not tried wiring the DTR line because we are short on GPIO’s. The EE has already released a PCB design that protects against this backdriving.
When the EC25 needs to wake the host processor, we are using RI which actually goes to a different low-power processor which will then wake up the main host processor. The UART lines are not involved in waking up the host processor.
When the host processor needs to wakeup the EC25, we are using AP_READY. It seems like the EC25 should not drive any inputs to the host processor when AP_READY is not asserted.